Puzzles and Pieces: Game Design Inaction

There are certain types of design tasks that I find really difficult to begin. I usually leap on any other opportunity, work-related or otherwise, to fill the time while I alternately procrastinate and attempt to identify which edge of the problem to address first. This usually ends up dragging out the work into the weekend, or in this case, a holiday. Whee.

In many cases, I usually get unblocked by talking to someone about the problem; during the conversation, I get distracted from the anxieties that are clouding the issue, and the pieces start falling into place by themselves.

One of the benefits I hope for from this blog is that I can use it to have these conversations by myself, and in doing so, find my way through this period of worklessness quickly and without all that dreaded social interaction. I hope this also proves to be an entertaining way to present some of the work I do as a designer.

A little background first. I'm working right now at Harmonix Music Systems, the developers of Guitar Hero and other music games before them. They're an incredibly smart, extremely creative company working on a number of tightly focused projects, and it is definitely a boost to my fluttering ego that they consider me worthy of joining them on a pair of unannounced projects. (And as the projects are unannounced, I'm going to have to be a little vague on specifics.)

The task before me lies on the border between design and art, as do many design specs (short for specifications). For the sake of not getting fired I'll describe the challenge in terms of a game you hopefully already know about: Guitar Hero.

Guitar Hero has a number of venues – stages where your band performs. Each venue uses unique art, animations and sound to create an exciting environment; but in addition to looking cool, those sound and art assets fulfill a design role by reflecting the player's performance. When you do well, the audience gets larger and starts cheering; large stage props might open and animate (like a nuclear reactor that deploys a large mushroom cloud); lighting might become more dramatic, and band members might pose more dramatically. In addition, some assets might be used to change the mood of a stage between the verse and chorus of a song. Others might be used to make the venue look different for different songs.

The task I have right now to list out all the elements of a venue like this, and assign them to all these different "triggers." We already have a list of various assets we might use, and various triggers we might assign them to; the goal here is to turn all these half-baked ideas into a structure that we can use to generate schedules of specific art and scripting tasks.

There's a metaphor I like to use when describing game design: it's like trying to put together a puzzle when you're not sure what the pieces are. When you're done, everything should feel like it all fits together, with no missing or extra pieces lying around; but when you start out, you have a bunch of random stuff that may or may not apply to the task at hand.

Often, there are interconnected issues that twist around each other and make it hard to make decisions. For example:

• Maybe the most dramatic way to reflect performance is to animate a huge piece of the stage – say, by causing a giant balloon animal to rise out of a hidden container and float above the audience, with searchlights shooting red beams out of his eyes.
• But these are also the most expensive assets, so for each one of these big-ticket items you do, there might be ten cheaper assets (like, small pyro explosions or a single animating spotlight) you could get done in its place.
• Now, maybe five of those cheap assets, replicated and scattered around the stage, could have as almost as much impact as the one big item.
• So, how do you split your time between big and small items?
• Or, if you don't have time or budget (largely the same thing) to do even one big item, which small items should you choose to create the most impact?

On the project I'm working on, we've sorted out the big items, but need to generate lists of the smaller items, like patterns for the stage lights, or particle effects such as "flame-jets".

These can fulfill various functions:

• Items that reflect the player's when the player is doing well, poorly
• Items that reflect different sections of a song (e.g. verse vs. chorus)
• Items that are deployed to punctuate a specific instant in a song
• Items that make each song performed on a given venue look different from each other
• Items to save for the start or end of a song

And these assets come in all different flavors:

• Sound effects for the audience
• Sound effects for the interface
• Triggered Visual effects like pyro, animating banners
• Cycling Visual effects like stage lighting
• Rules for making audience members appear, disappear, or change animations
• Visual effects applied to the entire screen (like motion blur)
• Visual effects applied to characters on stage (like special lighting, or custom animations)
• Visual effects applied to the game's interface (instead of the venue itself)
• Rules for choosing specific cameras or camera movement
• Rules to deploy specific character animations

-- and probably a bunch more I'm forgetting. (Remember, I'm procrastinating here, not working.)

It's fairly easy to assign broad categories of assets to specific functions (e.g. crowd density reflects performance), and lay them out in a big matrix (i.e. an Excel spreadsheet), but there some bits are trickier. For example, if you are going to get a big bunch of animations for each character on stage, maybe you assign some animations to performance, and some to specific moments in a song? And maybe some of each of those animations are restricted to specific songs as well, so "bad performance-reflecting animation #1" only appears during songs 2 and 4? And when you start subdividing assets like this, how do you communicate that within the table?

All of these are solvable problems, and no one of them is particularly difficult, but taken together, they can get intimidating. Add in the fact that some of these assets haven’t been budgeted yet, so that it's not clear how many if them are reasonable to expect, and it gets trickier still.

So you rattle all the bits together and see which ones are easier to lock in, then once those corners of the carpet is nailed down, you start looking for another batch of decisions that are easier to make now that you've answered some questions. And you keep going through that loop until everything's answered – or until you realize that one of your earlier decisions was flawed, and you pull it apart and start again.

It's exciting to get to the end of one of these specs; even more if the result is legible to anyone other than yourself. We'll see how long it takes to sort this one out.