How I Learned to Stop Worrying and Love Project Management

Probably the best part about designing my own adventure game is that I get to be closely involved in all of the interesting parts of the project, from generating plot and puzzle ideas to acting as the de facto art director and all around supreme overlord of my own little universe. And probably the worst part of my "job" is that I also have to be intimately involved in all of the boring stuff, too—the who, what, where, when, and (most importantly) how of it all.

As a project like this grows from a few ideas here and there into a massive undertaking involving volunteers from different continents, there has to be some dark, shadowy figure in the background, pulling all the strings and making sure that everything goes according to plan. This is where I come in, armed with my razor sharp project management skills (yeah, right) and the Mother of All Microsoft Word Documents.

After more than a year of coordinating the work of background artists, musicians, animators, and my own plot and puzzle elements, I think I've come up with a process that works. At least, it works for me. But keep in mind that I was just as clueless as anyone else who walks into a project like this without any previous game design experience, so my ideas aren't necessary better or worse than anyone else's would be—they're just, well, mine.

The first thing I did was create one overarching game design bible, or as I like to call it, The Document That Ate My Life. It gives an overview of the game itself—the background history leading into the game, the character descriptions and motivations, and the general plot outline from start to finish. (And, yes, I'll admit that I even explore a few ideas for a sequel near the end. Can you say... franchise?)

This hellish design document is also home to a list of screen descriptions, inventory items used and acquired, necessary actions that the player can perform on each screen, et cetera. Basically, if it happens in the game, it's described in here. It's not meant to be read straight through from start to finish, though—it just gives an overview of what can happen on each screen. Here's a partial entry describing the game's very first screen:

Each entry in The Document That Ate My Life also includes the list of actions available to Jake, and the responses these actions will generate from the game. The first screen alone lists more than 20 potential actions specific to that screen. Here are a few examples:



Another important document that I maintain is the walkthrough, which lists the shortest possible route for completing the game. It's useful for players who just want to get from start to finish, but I also use it as a de facto design document that helps me keep tabs on the linear development of the game. It's my crib sheet of what needs to be animated, what musical cues we need when a certain event occurs, et cetera. For example, on Screen # 012 of the game, the walkthrough lists the following three actions:



This way, when I'm working on each screen I know that I need to animate, code, and create sound effects for these actions. I also know that for any unfinished screens, I need to make sure that the background art can accommodate those animations. The walkthrough also acts as a sort of unfinished assets list for me. An "asset" is any visual or audio element of the game that needs to be created—an inventory item, a sound effect, a movable object, that kind of thing. The unfinished assets list is like a great big to-do list, and so in some ways it's my own little game designer's walkthrough.

All right, well that about sums it up for this time. Hopefully this made sense—I'm doing my best to walk a fine line between using specific examples from my game and not giving away all the stuff that I want you to discover as part of the game-playing experience. Which, incidentally, you can expect to enjoy sooner than you may necessarily think...

Next: Um, some character design stuff, maybe?