Justin Toupin
Much to my 8-year-old daughter's enjoyment, we make a lot of games around here. We're rounding third base on our latest game right now. Animations are in place. Game play is mostly built out. After several months of work, we're finally to the part where we get to play it for the first time.
Trouble is, it isn't much fun. Something's missing... the essential chemistry of style, pace, and challenge isn't quite right.
Don't Panic
It isn't a problem. We've just made it to that point in the game development cycle where we get to pull everything together and actually make it fun.
In our experience, fun almost always comes late in the development cycle for games. It requires having all of the pieces in place in a way that can actually be played with and experienced. The concept is important, of course; as is each character and object in the game, which go through their own cycles of feedback and revision. But the thing that actually makes the game a game, the compelling dynamic that comes from the way each element interacts with its environment, is often sorted out late in process. In a way, we spend the first 80–90% of the development cycle creating opportunities. The last 10–20% of development is spent capitalizing on those opportunities.
A Couple Examples
Midnight Messenger
In Midnight Messenger, Li Ming wanders through swamps and forests with a jar of fireflies to light her way. Early in the design process, we decided that the level should never actually fade to total blackness. Rather, if Li Ming lost fireflies during game-play, the level would fade to a dark gray. Why? A completely dark environment covered up all of the illustrations and animations that made the game look so captivating, and when completely black, the game screen designs looked really boring.
Once we had all of the elements in place, though, and could actually play the game, we realized that this was in fact exactly how it should have been. Making the level fade all the way to black as Li Ming lost fireflies was what made the game fun. We made that change, which led to one more: we made the fireflies remain visible -- as dancing orbs of light -- even as the screen fades to black. The user could see the fireflies, but couldn't see the obstacles between them and Li Ming.
This combination of changes, while fairly simple and late in the development process, were what made the game so compelling and fun.
Wrekin' Ball Billie
In Wreckin' Ball Billie, Billie drives his wrecking ball crane through a neighborhood and tears down poverty housing. Where each dilapidated house is demolished, a crew from Habitat for Humanity appears to rebuild a replacement.
We originally envisioned Wreckin' Ball Billie as a slow-paced game where the user carefully arranges the crane with the arrow keys, lines up the wrecking ball on a trajectory that will slam into the appropriate house, and presses the space bar to let it go. The challenge would be in correctly setting up the crane and making sure no neighboring structures were damaged.
Once we had the prototype in place, however, we realized that the compelling opportunity was in speeding up the pace. The crane should drive quickly from one house to the other. Controls should be simple, and users should pound away at the keyboard to tear down houses. Caution to the wind, this demolition game became a race against time and a frenzy of destruction (all for a good cause, of course).
Planning for the Unknown
In light of the fact that there are almost always significant changes in game play toward the final stages of the project, we have found it incredibly important that all development is executed in as flexible a way as possible. Clean, well-commented code is a good starting point. In addition, every factor in game play that could be variable should be variable. Throughout the process, we work to identify potential areas of change; for example, "We might want the kid to run faster," or, "We may want a steeper camera angle." We often find it difficult to know what the final decision for these variables will be, and build for flexibility wherever we can.
We have also found it critical to identify what isn't flexible, early in the process. That way, we know what isn't on the table for change once we have a prototype. Understanding our limitations in the project lets developers avoid the frustration of dealing with impossible requests, and gives us helpful boundaries for fine-tuning the compelling challenge of the game.
Hitting that point where we finally have an actual prototype to play with, and implementing changes that make it come alive, is an exciting and necessary step in the process. Being ready for these changes, and embracing the opportunities we discover, is critical. For us, this is the step that makes games fun.