17 The Design Process: Prototyping

Remember, the more times you can iterate on your idea, the better the final game will be. Once you have a basic idea, the next step is to get it in playable form as quickly and cheaply as possible. That will leave you with as much time as possible to playtest and iterate.

As mentioned last time, iteration is the most critical for those parts of your game that have high design risk. For “clone-and-tweak” games where you are mostly lifting gameplay from an existing game, rapid prototyping is less important. This does not mean that “clone” games do not benefit from iteration, but simply that you should use it selectively in those areas where you are innovating.

“Laws” of Prototyping

Remember that the entire purpose of prototyping is to maximize the number of iterative cycles. Corollary: do everything you can to reduce the time required in each iteration. Now, consider that each iterative cycle consists generally of four steps: design, prototyping, playtesting, and evaluation. Of these steps, where can you save time?

• You can’t really reduce the time it takes to design the rules of the game, without compromising your goals. You can’t rush creativity.
• You can reduce time spent in playtesting by being efficient about scheduling and designing playtests to give maximum information for minimum play time… but there is a natural limit to this, and beyond a certain point you can’t rush through playing the game.
• Evaluation doesn’t take very long; you’re making a simple yes/no decision of whether the game is “done” or “good enough” based on playtest results. There is little to be gained by rushing through this further.
• So, that leaves reducing the time it takes to create a prototype.

Some things to keep in mind when building a playable prototype:

• Build it as fast as possible. Cut corners. Make it as ugly and cheap as you can get away with.
• Minimize what you need to build. Only do what is absolutely necessary to evaluate your game. If you’re trying to test out a new combat system, you do not need to build the entire exploration system. If you’re making a card game, hand writing on index cards is faster to make than typing everything into Powerpoint, printing on heavy card stock, and cutting it all out manually. There is a time and place for making nice-looking components, and the early stages of game design is not that time or that place.
• Make your prototype easy to change. You will find problems in playtesting, so make it easy to adjust on the fly.

All of these guidelines push designers towards one inevitable direction…

Prototyping in Paper

You can call it “paper” or “cardboard” or “non-digital” or “analog” or any number of things, but the idea is to have a physical, tabletop game that is playable without computers (or at least, without requiring programming code). Programming is wonderful and powerful but it is also slow and expensive in comparison to paper prototypes. Here are some advantages of paper prototyping:

• It is cheap. Most systems can be prototyped with little more than a pencil and some paper, although I will give suggestions for other components for those of you that have some money to spend.
• It’s fast. You don’t have to mess around with programming, or layouts, or artwork. Just write a few words on a scrap of paper.
• It’s easy to change. Don’t like one of your numbers? Erase it and write in a new one.
• There is no guilt about throwing it away. You came up with an idea that didn’t work? Oh well, you lost a whole half hour. Big deal. It’s like making stick-figure drawings: if your first attempt at drawing a stick figure doesn’t work, it only took you a few seconds, so just cross it out and try again.
• Paper can be used to model most gameplay systems. Yes, even most of the ones we normally associate with being specific to video games.
• By making something playable, you are forced to actually design the systems. No more handwaving of “this game will have 50 undefined cards”. You have to actually do your job as the game designer, and design the game!

Limitations of Paper

Paper prototypes do have some limitations that you should be aware of:

• They cannot always handle “twitch” (dexterity or timing based) mechanics… although be aware that there are many dexterity-based non-digital games. Consider the similarities and differences between the Street Fighter series of video games, and James Ernest’s real-time card battle game Brawl. Some things carry over well… others, not so much.
• Information that is hidden to both players but that still requires bookkeeping, such as the “Fog of War” mechanics prevalent in Real-Time Strategy video games. Again, note that this can sometimes be worked around — the classic children’s game Battleship has “fog-of-war-like” mechanics, and the board game Clue has information hidden from all players.
• Extremely complex calculations are tedious on paper, and the systems that use them may be better suited to “prototyping” in a spreadsheet program like Excel. However, if the complex systems are a necessary and core part of the game, it may be a sign that “the computer is having more fun than the player” (to quote Sid Meier), and that perhaps some simplification would make the game more accessible.
• “Eye candy” such as high-quality art and animation is obviously not prototyped easily with stick-figure drawings and handwritten cards. Then again, these are not part of the game mechanics. If your game relies on visuals rather than systems, that is a sign that you are not doing a strong enough job as the systems designer.
• Paper prototypes are not very well suited for testing the user interface (UI) of a video game. Computer UIs are dynamic, but paper is static. You can get an idea of the visual layout with some paper sketches, but to know how it will actually be used on a computer, you’d need a digital prototype.

As you can see, the advantages of paper prototyping are very general and the limitations are specific, so the ability to prototype in paper is an important skill for any game designer to develop, whether they work in video games or board games or anything in between.

Prototyping Realtime Systems

For a turn-based game like Battleship, a non-digital prototype is easy enough to put together. What if you wanted to prototype a First-Person Shooter video game like Halo? Is there any possible way to do that on paper, when most of the game is running around and shooting things in real time? The answer is yes, absolutely. Here are some hints:

• One “turn” of a board game is equivalent to some amount of time (say, 3 seconds) of real-time play
• For “twitch” mechanics like dodging and accuracy that require accurate timing, either a player succeeds or fails at these based on how difficult they are and how skilled the player is. This can be modeled with a random die roll. Note that even though the video game’s system is not random at all, it may as well be random from the opponent’s perspective: if I shoot at you and you either do or do not successfully dodge, I have no control over that.
• Many real-time games take place on an open 3D map that is not subdivided into “spaces”. This does not prevent you from making a game board that has spaces anyway.

A Short Note about Grids

There are many ways to make a game board, but here are three common ways to get you started:

• Subdivide into a grid of squares. Square grids are easy to navigate and are familiar to most players, so they will not intimidate casual players as much as some other methods. For grids that include lots of obstacles and movement challenges, grids are ideal because it is easy to block off a path: a single impassable square forces you to go quite a bit out of your way to get to the other side. The drawback of squares is that you inevitably run into a problem with diagonal movement: does it count as one space or two in order to move diagonally? One space feels too fast; two spaces feels too slow. (The actual value is the square root of 2, or about 1.4 spaces… but if you’re dealing with whole-number values this obviously does not work.)
• Subdivide into a grid of hexes. Hexes have some nice mathematical properties to them, in that something that is 3 hexes away is always that many hexes, no matter which of several paths you take; this gets around the “how fast to move along a diagonal” problem of square grids. On the down side, hex boards make it much easier to move around obstacles, so movement is a lot less constrained. This may be desireable or not, depending on the nature of your game. Also, hexes are quite “geeky” and are likely to put off players who are not that experienced with this style of play.
• Open area, no board. Use a tape measure instead, and move your pieces a certain number of inches (or centimetres, or what have you) per turn. This gives the most fluid and precise movement, although it has many of the same disadvantages as hex maps, and is also vulnerable to someone accidentally bumping the table and sending pieces slightly off of where they were.

Adding Features versus Keeping It Simple

Many early prototypes are simply begging for extra features, such as health and ammo and various other resources. Why not start with all of these extra systems already in place, as opposed to starting with just the simple core system? There are a few reasons to start with a simple, core rule set and then add on one rule at a time, instead of trying to design the entire game in one big effort:

• If the basic, core rules don’t work, then adding extra rules on top of it will generally not make it work. Get the basics working first, before you start adding complexity.
• In fact, if you build extra rules on an unstable foundation, the real underlying problems in your design could be obscured! Something might seem wrong, but if there are a lot of systems and resources and game objects it can be hard to tell if you’re experiencing a problem with the core mechanics, or the balance of a particular resource, or the design of the map, or something else.

Early on in a design process, it’s generally better to keep things as simple as possible. For every rule or mechanic or object or resource that you want to include, ask yourself: is this really necessary right now? At this point, let your laziness override your creativity. It is far easier to add something to your design than to take it away, so add the minimum possible to have a working, playable game.

If you have trouble with this, try writing down a list of all of the ideas you have that you want to include in the game, and then cross off as many as you can. Ask if whatever items are left on your list would make a complete, playable game. If so, try to cross off more, until you absolutely can’t anymore.

It may also help to run your idea by another designer who is not personally and emotionally attached to your pet idea. Invite them to be merciless in deciding which of your rules can be trashed. For the purposes of this course, you can offer a trade with any colleagues in your area: you look at my prototype, I’ll look at yours!

Moving Forward

Once you have the core gameplay, and it works, then you can add new features. The temptation at this point is to add everything you originally thought of. Resist this temptation. Instead, add one new feature, and playtest again until the new feature works, or you have decided that it doesn’t work and it needs to be abandoned.

Why not add everything at once? Because every new thing you add may have some problems with it. If you only add one new rule and a critical game system becomes broken in playtesting, you know exactly where the problem is, because you only changed one thing. If you add ten new rules and something breaks, it’s harder to isolate which rule (or combination of rules) caused the problem. Incidentally, this part is similar to programming: if you write code in small chunks and then unit test, it’s easier to find bugs than if you write ten thousand lines of code between tests.

Yes, this is tedious. You have to playtest, then change one rule, then playtest again, then change another rule, and keep doing this dozens (or even hundreds) of times. The first few playtests are fun, but you will quickly become sick of the whole business. This is part of the process of design. Sometimes, game design is hard work that is not particularly fun. This is something you need to accept if you have aspirations to become a professional designer. Just remember that the purpose of this is to make a game that is fun, and if it’s not there yet, that should be your incentive to change something and playtest again until you reach your goal.

This chapter was adapted from Level 4 of Ian Schreiber’s Game Design Concepts course.