Of Progress, Rewards, and Spooky Things

Today I'm going to talk a little bit more about teams. For all that content is super important (I mean, it's literally what makes up the game), in my experience with development most of the conversation focuses on content creation, so throughout development of Project Kassa, I'll be making periodic blog posts about other aspects that are important as well but seem to get a bit less emphasis. You'll be able to find all these posts under the "Producer" tag if you'd like to read more of them.

Last time I wrote one of these, it was about the assembly of a team, today we're going to talk a little bit about a lot of things, ultimately boiling down to morale. Keeping team morale high is important for team health, sanity, and quality of work. A team with low morale won't work as hard, or as well, as a team that is happy with themselves, each other, and the project.

One of the most important things to keeping morale high is a sense of accomplishment. People who have achieved something, or feel like they have, generally feel better about themselves and whatever it is they're working on. One of the easiest ways to do this is to track progress. Now there are a ton of ways to do this, and what is going to work for one team won't necessarily work for another, and sometimes what works for one team might only work for a specific project, so I'm going to stick with talking about what we're doing for this project rather than going too into the many options available.

We initially tried using VersionOne, which is a lovely site that I highly recommend trying if you are a fan of scrum and are looking for a reasonably priced option for it, the staff was communicative and the I found the interface very easy to learn and use. Unfortunately, it went under utilized, it didn't mesh well with the team. What we wound up with, and has been working so far for us, is a simple whiteboard.

Current Whiteboard

Different team members have different colored post-its, and we have three columns "To-Do," "In Progress," and "Completed." Only tasks from the current milestone (which - for us - is monthly), or outstanding from past milestones, are on the whiteboard. Each team member is responsible for moving their tasks to the appropriate column as they progress, and at the end of the milestone we take all the "Completed" post-its and stick them here:

Our progress spindle!

We bought a receipt spindle from an office supply store. There's something satisfying about impaling completed tasks on a pointy object. You may notice that our particular progress spindle has several marks on it, when we got it we decided to break it up into inches and whenever we complete enough tasks to reach an inch, we go on a morale adventure.

Morale adventures are fun, we've already done one in the form of visiting Fort Stevens in Oregon and Cape Disappointment in Washington, which gave us the additional benefit of a TON of photo/video/sound reference for our game as well as an opportunity to get out as a team and do something.

For our first inch, which we are rapidly approaching, we're discussing going to the ghost town Monte Cristo in Washington, where Danny and Branden will get us killed by following horror movie tropes instead of being sensible about the whole thing. The other options include the haunted soda machine in Seattle, or doing the Pike Street ghost tours. Obviously we lean towards spooky rewards, given the focus of our game and our apparent disinterest in not getting murdered by ghosts.

And once again, this post is turning out long, so I'm going to end it here, and talk a little bit more about smaller-scale morale boosting events in a later post.

On Assembling a Team, Part 1

Hello all, I'm here to talk about a very important, and not very frequently discussed, aspect of making a game: The team.

Before I get into that, however, I'd like to bid farewell to our dear friend Paul. He's found himself an industry job, and unfortunately doesn't have time to dedicate to a second project. We're, of course, happy he found employment doing what he wants to do (Congrats, Paul!) and wish him all the best at his new employers!

 Back on the subject at hand, now. Teams and team-building are things that, in my experience, often fall by the wayside in project planning. Obviously a game (or any large scale project, really) needs more than one person to make it succeed. And therefore, a good, strong team is ideal. The two biggest components of this are: Skill sets and personalities.

Skill sets are the aspect of teams I see neglected least, simply out of necessity. If none of the team members have a specific, needed, skill, then the team can't complete that part of a project. So if you need, say, a programmer and none of your team members can program, your game isn't going to get very far.

Personalities are where I have seen many teams struggle and fall apart. It can be difficult to work with someone who clashes strongly with your personality, and this problem is compounded if only one member of your team doesn't fit. It's not to say that you can't work with someone you don't agree with, or even get along with outside of work, merely that I find that teams are stronger and work goes smoother if everyone gets along. Nor is it to say that everyone on a team should have the same (or even similar) personalities. The important aspect is compatibility: Can the individual members of a team get along and get work done without regularly having serious conflicts of personality, minor conflicts are to be expected and perfectly acceptable so long as they aren't so constant that morale and production are hindered.

As a result of these two things, when Ryan and I first began discussing Project Kassa, and the potential of making the jump from idea to product, one of my first concerns was finding team members that not only fulfilled the required skill sets, but could get along well. Before actually joining the team, we tried to have what were - essentially - informal interviews for each member. Both to give them an idea of what the game we wanted to make would be like, and to gauge their personalities for potential compatibility with the team. After the informal interview, next step was to introduce them to the team as a potential team member and look for conflicts there, since neither Ryan nor I can be 100% certain of how well a person will do with a team without seeing them with said team. And then, finally, officially have them join the team.

Prior to all of this, though, was the real hurdle. Finding people. Ryan and I were (and are) in the fortunate position of having gone to a school where the majority of our peers also wanted to make games, so we had a good start there at the very least, as well as already personally knowing and being friends with several potential members. We already knew and were close friends with Frank and Paul, so they joined up quickly. We tried using Craigslist, though got no serious responses from it, as well as relying on our connections to friends and peers from DigiPen, which proved to be much more useful. Unfortunately, the programmers we knew at the beginning were either uninterested in the game itself, or were far too busy to take on such a time-intensive project. The same problem occurred with concept artists, and an animator. I then was fortunate to meet and work with Branden through a friend's senior projects team, and he was interested and would have the time after the semester was over. Through him, we found Danny, which brought our team total up to six.

 We, fortunately, have yet to have any serious issues with disagreements or conflicts of personality, so we haven't had to actually solve any of that sort of thing yet.

Since this has already turned out a fair bit longer than I anticipated, I'll discuss team-building and morale in a future post about teams.