On Prototyping Games Quickly

Will Wright—the creator of Sim City, the Sims, and other games—says that rapid prototyping is a core discipline of the game design process¹. The important thing is to build something interactive as quickly and cheaply as possible, with a specific question or goal in mind.

A problem that I have with prototyping video-games is defining the scope of what my prototype is solving. Games are a complex activity where everything seems to play a part: the graphics, the visual feedback, the accessibility of the controls. So, where should I cut corners?

Other more well-established design activities have better-defined patterns around this kind of problem. For example, in architecture, you have sketches, plans, and technical blueprints; in user interface design, you have wireframes and high-fidelity mock-ups. There’s a generally shared understanding of what should be done or not done in each one of those.

More importantly, in both of those areas, an experienced designer can solve and convey the core of the problem he’s working on with only sketches. A Sketch is a medium where it’s possible to prototype and address the heart of an architectural/UI issue. It’s hard to find a parallel to that for video-games. What’s the core of what a game is solving, and which kind of prototype can support that?

Some interesting developments around that are projects about doing games quickly. It’s usual for games to take a long time to develop, and during that time, the core of the game to don’t be clear nor solved—Bioware Anthem is a prime example of that². By pushing a game to be finished quickly, those problems can be averted.

The Ludum Dare Game Jam is an event where game designers have 72 hours to do a game around a pre-defined theme. There are several stories of successful indie games that started as a Ludum Dare game and later were expanded into a full-fledged commercial release. That means that their 72-hour game was effectively a prototype that managed to validate the core of the design. What came after that was polishing, more content, and production value.

To do games in a shorter time is to learn to be effective at prototyping games. Rami Ismail talks about the importance of getting experience at failure³, and how the high volume of small quick games from his partner Jan Willem Nijman created the base for his successful games. The game Downwell from Ojiro Fumoto was a result of a 12-week sprint doing 12 quick games⁴, all failures except his last one.

But the best material I have found so far about prototyping games comes from The Experimental Gameplay Project done at the Carnegie Mellon University. They were a team of four grad students who developed several games during a semester following three rules: 1. Each game must be made in less than seven days, 2. Exactly one person must make each game, 3. Each game must be based around a common theme, i.e., “gravity,” “vegetation,” “swarms,” etc. One of the games that came from this experiment was the famous World of Goo.

On a white paper about the project⁵, the designers outlined several things that they learned from their experiment. Next, I analyze the most relevant ones.

Embrace failure. The main objective of a prototype is to test and validate an approach, which means that most prototypes will be “failed” games. By embracing failure, rewarding experimentation becomes possible.

Enforce short development cycles. With focus and experience, most gameplay ideas can be prototyped in less than a week. It’s essential to keep the prototype a prototype, because that is where most of the value and learning will come from.

Simulate in your head, pre-prototype the prototype. I have always defended the importance of being able to prototype things in code as soon as possible. Code is a better medium to test the complexity of interactive applications. But it’s also more expensive in terms of the time and cognitive focus it needs. It’s not worth doing trial and error “design decisions” by noodling around in code.

The solution to that is to first simulate the game in your head. Imagine you playing the game, pushing the buttons, and seeing the consequence of each action. If the simulation doesn’t seem fun in your head, you should look for another idea before committing to a code prototype. If the concept is too hard and too complex to simulate in your head, that’s a good indication that you should simplify and reduce the scope of the game before prototyping it.

Nobody knows how you made it, and nobody cares. For a prototype, it does not matter how it was coded. It does not matter if the code is more modular, more testable, more pretty. It only matters that it allowed you to play with your idea. Forget about great engineering and build the “toy” part of your game first.

Cut your losses. Continually evaluate your results. When the time spent in an idea is not yielding results anymore, move on.

To wrap up, the best way to approach a prototype is with the mentality that what your doing is proving to yourself that the core mechanic you came up with is worthwhile (or that you’re learning to do the aforementioned).