Level 4: The Early Stages of the Design Process

We have already made some games in this course, so we have already been through the creation process on a small scale. But our method of design, for the most part, has been ad-hoc: here are a bunch of elements, just throw them together and call it a game. The results of this type of design can be expected to be hit-and-miss.

What about for larger projects where the stakes are higher? Is there a process that can be followed that will lead to better games? There is the iterative process, to be sure, but we have not gone into detail on any of the iterative steps (design, playtesting, evaluation). How exactly do you come up with an initial design? What is the most effective way to playtest? When evaluating a game, what do you look for, and how do you know what to change? These are the things we will be concerned with throughout the rest of this course.

Today, we examine the first step of the iterative process: initial design.


Course Announcements

Just a couple of comments based on feedback received from the first forum challenge:

  • When the assignment is to design a game, I am looking for something that is in a state where you could print out the rules, create the components, and play. Some people posted, say, a card game and just handwaved over this: “The deck contains 50 cards, here are a couple of samples but I haven’t designed the others yet.” This is not a complete design. I encourage you to make complete designs, when you are designing a game and not just a concept. It is these details that are the essence of design.
  • If there is confusion over what I am asking for, as I’m sure will happen just about every time, do feel free to ask for clarifications in the blog comments. However, I also encourage you to make your own interpretations to the best of your ability. In classroom courses (and usually in the Real World) you can ask for immediate clarification if a constraint is unclear; but in this course, since we go so quickly, there is not always time to post a comment, wait for me to respond, and then read the comment. Be creative but fair in your interpretations.


A Note on Constraints

An interesting thing happened for this Monday’s challenge: more people attempted the Black Diamond (highest difficulty) than those who did all of the other difficulties combined. By contrast, when signing up, only about a tenth of the participants identified themselves as experienced game designers. What is going on here?

Part of it may be pride. Even though people will admit a total lack of experience to me in private email, broadcasting it on forums is another thing entirely. Part of it may be the thrill of the challenge. People want to know just how far they can push themselves.

However, part of it may be that adding constraints makes a challenge easier. This sounds unintuitive; after all, isn’t a new constraint just one more thing you can’t do? With more roadblocks, shouldn’t a task be harder? Not always, in the case of game design.

To understand this, we can look at the process of game design as a successive layering of constraints on a game. Every new rule you add, every resource you define, is just one more constraint on the players. At the start of the design process you may have nothing, and the players could do anything at all; by the end, the player experience is sharply defined and heavily constrained in a way that is fun. (We will address what “fun” actually is, later in the course.)

To put this in perspective, consider the so-called genre of “open world” video games (popularized by Grand Theft Auto). The typical player reaction is that these games let you do anything, they give complete freedom to the player, and that is why they are fun. However, a critical look at the games shows that they do not give complete freedom. The games actually constrain the player in many ways: there are only certain ways a player can move, a defined set of objects they can interact with, and the autonomous computer-controlled agents that wander around are governed by specific algorithms. The player has many decisions and a relatively open set of goals, to be sure, but there are a great deal of constraints that lead to this illusion of “being able to do anything.”

If you accept this explanation, that design is the creation of constraints, then you can see that constraints imposed from outside can be thought of as providing some of the initial design. By adding constraints, there is less design work to be done. Thus explains the paradox.

Constraints can also provide a useful anchor for your ideas. If I just say “go make a game” with no constraints, many people would just sit there like a deer in headlights, wondering where to begin. By adding a constraint (such as “World War I”), the question is no longer “where do I start” but rather, “what do I do with this.” And that is a much easier question to answer.

Most of the challenges in this course will involve constraints. In fact, most design in the Real World happens within constraints: a publisher asking for a game that uses a certain IP or within a certain genre or within a given time and budget, for example. One of the reasons I mention this, then, is to remind you that these constraints may sometimes seem ridiculous (“do I really have to come up with a concept for a My Little Pony game for DS?”) but that in fact they can often make a designer’s life much, much easier.

There is one other reason I mention constraints. For those rare times in your life when there are truly no constraints imposed on you by others (this is more common with “indie” development and hobbyist designers than with professionals), if you have trouble getting started, one way is to generate some constraints for yourself. Give yourself a time limit (“Game Jam” events typically challenge people to make a game in as little as 24 or 48 hours). Choose a subject matter that interests you and use it for the theme. Select a core mechanic that you’d like to explore. It can be completely arbitrary, but if you are stuck and don’t know what direction to take your game, go ahead and just choose an extra constraint to get yourself moving. (With iteration, you can always remove that arbitrary constraint later if you find it’s holding back your design.)


Generating Ideas

The first thing that happens in a design is that you must come up with the basic core of an idea. This isn’t necessarily fully-formed, but just a basic concept. There are many different starting points for a game’s design. Here are some examples, in no particular order:

  • Start with the core “aesthetics” — what do you want the player to feel? How do you want them to react? What should the play experience be like? Then work backwards from the player experience to figure out a set of rules that will achieve the desired aesthetic. Think about the best experience you’ve ever had while playing a game; what game rules led to that experience?
  • Start with a rule or system that you observe in everyday life, particularly one that requires people to make interesting decisions. Look at the world around you; what systems do you see that would make good games?
  • Start with an existing, proven design, then make modifications to improve on it (the “clone-and-tweak” method). This often happens when making sequels and ports of existing games. Think of a game that you thought had potential, but didn’t quite take the experience as far as they could; how would you make it better?
  • Start with technology, such as a new game engine (for video games) or a special kind of game piece (like a rotateable base for miniature figures). Find a way to make use of it in a game. What kinds of items do you have lying around your living space that have never been used in a board game before, but that would make great game “bits”?
  • Start with materials from other sources, such as existing art or game mechanics that didn’t make it in to other projects. Design a game to make use of them. Do you have an art portfolio, or earlier game designs that you didn’t turn into finished products? What about public domain works, such as Renaissance art? How could you design a game around these?
  • Start with a narrative and then design game rules to fit, making a story-driven game. What kinds of stories work well in games?
  • Start with market research: perhaps you know that a certain demographic is underserved, and want to design a game specifically for them. Or maybe you just know that a certain genre is “hot” right now, and that there are no major games of that type coming out in a certain range of dates, so there is an opportunity. How do you turn this knowledge into a playable game?
  • Combinations of several of these. For example, starting with core aesthetics and narrative at the same time, you can make a game where the story and gameplay are highly integrated.

When you think of new ideas for games, what kinds of ideas do you have? What are your starting points? What does this say about you as a designer, and the kinds of games you are likely to make?


Other Methods of Idea Generation

If you are stuck with “designer’s block” (the game design equivalent of “writer’s block”) there are a number of strategies you’ll see mentioned in various places. Here are a few:

  • Keep a permanent collection of all of your ideas for games, mechanics, stories, and everything else. Look back through it from time to time to see if there’s anything from years ago that you can use. Add to it whenever an idea occurs to you that you can’t use immediately, but that you want to return to later.
  • Think of something random. Try to find a way to integrate it into your game.
  • Do some research. Learn about some aspect of the game in more depth, and you will likely find new ideas.
  • Go back to the basic. Think of the formal elements of your game. What are the player goals? Rules? Resources? And so on. Note that you’ll need to define these anyway in order to have a game, so by focusing on these one at a time it may give you new questions to answer.
  • Formalized brainstorming, either alone or in a group. Some people swear by this method, while others say the results are questionable. The best I can say is that the results are highly unpredictable… as is the case with most R&D.
  • Think critically about games. You may have my textbook on game design that contains some of what Brenda and I have learned over the years, but you should write your own book over the course of your lifetime (whether you publish it or not, at least keep it for yourself). When you discover something that does or doesn’t work in a game and you think you can identify the root cause as a “law” (or at least a guideline) of game design that is broadly applicable, write it down! If you don’t know why, write that down too, and come back to it periodically until you find the answer.
  • Play lots of games! But… play as a designer and not just a player. Don’t just play for enjoyment. Instead, play critically. Ask yourself what choices were made by the designer of the game, and why you think those choices were made, and whether or not they work. Play games in genres that you don’t like or have never tried, and try to figure out why other people find them fun. Also, published hint guides can be useful to read — they are basically glorified design documents that detail all of the systems of a game!
  • And lastly, practice. Work on your own projects. The more you make games, the better you get at making them… just like any other art form.


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. Keep this in mind for today’s challenge.

“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.

The Non-Digital Designer’s Prototyping Kit

What follows is a list of materials that I have personally found useful when prototyping. Other designers may have their favorite materials, so I look forward to seeing the discussion that will inevitably be generated by this list:

  • Paper, of several varieties: blank, lined, and graph. These are useful for general note-taking, and for the fast construction of makeshift game boards and other surfaces.
  • Colored pens and pencils. Obviously you need something to write with. Colors give an easy way to differentiate between game elements, or to annotate your game components.
  • Index cards (3″x5″). These make it easy to make cards. They shuffle reasonably well. You can cut them in halves or thirds for different card sizes. You can also just write ideas down on these and tape them on the wall, making it easy to arrange your thoughts visually. These are versatile and cheap.
  • Scissors and tape. For breaking things apart and sticking them together, respectively. These are to game design what WD-40 and duct tape are to handymen, for the same reasons.
  • Paper clips and/or binder clips. This lets you store related materials in one place. For example, if you create several “decks” of index cards, this lets you hold them together so they don’t get mixed up with each other (or worse, mixed up with cards from other prototypes).
  • Glass beads (sometimes called “Pente stones”) in different colors. These make great markers, counters, and playing pieces.
  • Dice, of varying types (4, 6, 8, 10, 12 and 20 sided). Several of each type, in different colors. These provide independent random variables (as opposed to the dependent randomness of card draws). For more information on the uses of dice and cards, see Chapter 5 in the Challenges text. Note that dice can also make decent playing pieces that can simultaneously “store” a single number on them — for example, a six-sided die could represent a warrior with up to 6 hit points.
  • A small bag of low-value coins (pennies in the United States, and I admit ignorance to how other countries handle coin-based currency). Coins make good markers, they can be flipped for a random variable, they have two sides so they can represent either of two states (such as which of two players currently controls them), and they can be stacked more easily than dice or glass beads.
  • Colored sticky-dots (small round adhesive labels). You can put them on stones, dice or pennies to mark them, differentiate them, or customize them. You can write on the dots to provide additional information if needed.
  • A paper notebook that is kept with your prototypes and used exclusively for taking notes in playtests. This is not something you want to accidentally lose track of!

Where do you find these things? It depends where you live. Most, you can get at an office supply store (Staples, Office Depot and Office Max are the big stores near where I live; you may have others), except for dice, glass beads, and coins. The coins, you can get at a bank (in the United States, you can get a hundred pennies for only one dollar — a bargain by any standard for quality game components 🙂 ). Dice are generally found in hobby-game stores or comic-book shops, or purchased online. Glass beads can be found in a variety of places. Hobby-game stores have them. Pet stores that sell fish equipment may sell them as aquarium stones. Art/craft hobby stores may sell them as glass beads for jewelry and craft projects. They also come as components with many games (notably Pente), if you can find a game with glass beads for cheap.

Craft and hobby stores, both the retail chains and online (Michael’s is the big chain store in my area), can offer great inspiration for game designers. I’ve found large quantities of unpainted and colored wooden cubes (great as resource markers and also as custom dice) and wooden discs (they feel better and are larger than pennies). Once, I found a set of flat painted wooden cut-outs, maybe an inch square, of bunnies and another set of carrots; I don’t know what I’ll ultimately do with them, but there is a game that will be made with them some day. Craftparts has wooden people-shaped pawns and square tiles in various sizes. These kinds of quality components may not be immediately suitable for quick-and-dirty paper prototypes, but they can certainly come into use as your project becomes more developed.

Your First Paper Prototype

Here are the rules for the classic children’s game Battleship:

  • Players: 2
  • Objective: sink all five ships in your opponent’s fleet before they do the same to you.
  • Setup: Each player has a 10×10 grid of squares, with the rows labeled with numbers 1 through 10 and the columns labeled with letters A through J. Each player has five ships: one ship that is 2 squares long, two ships that are each 3 squares long, one ship that is 4 squares long and one ship that is 5 squares long. Each player secretly places their ships on their own grid, in such a way that each ship is oriented sideways or up-and-down (not diagonally) and that ships do not overlap. A player is chosen to go first.
  • Progression of play: On a player’s turn, they call out a single square by its coordinates (such as “B-5” or “H-10”). If the named square is not occupied by any of the opponent’s ships, the opponent says “Miss”. If the square is occupied, the opponent says “Hit”. Additionally, if the square was a “hit” and the ship that was hit has had all of its sections hit, the ship is considered “sunk” and the opponent must tell you which ship was sunk. No matter what the result, after the action is resolved, play passes to the opponent.
  • Resolution: When one player sinks all five ships of the opponent’s fleet, that player is the winner.

Normally, this game is available in toy stores. It comes on a plastic board with plastic pegs. Some fancy electronic versions require batteries and have sound. But I bet if you think about it, you could prototype this game in paper in less than five minutes. How would you do this?

If you couldn’t guess, all you’d have to do is draw two 10×10 grids on a sheet of paper for each of the two players (one to keep track of your fleet, and one to track the results of your shots against the opponent). This is all you need to play, and it gives pretty much the same experience as the “real” version!

Now, try this thought experiment: critically analyze Battleship as a game. What are the weaknesses of its design? How would you modify the rules of the game to make it better? If you are taking this course in a group, discuss this with your colleagues. Then, consider: how would you modify your paper prototype to test out your new rules in a playtest to see if they work? Usually, this is trivial to do. Here are some examples from the times when I’ve taught this course in a classroom:

  • Allow players to move their own ships if they haven’t yet been hit. (To modify the prototype: just allow players to erase and re-draw their ships.)
  • Allow players to use a “sonar sweep” instead of firing a shot on their turn: they name any 3×3 square area on the board, and the opponent says the number of squares in that area (from 0 to 9) that are occupied by ships. (No modifications necessary, just play with this as a new rule.)
  • Let players take another turn immediately if they score a “hit”. (Again, no modifications necessary, just play with this new rule.)
  • Use differently-shaped ships: instead of lines, have a T-shaped or square-shaped ship, like Tetris pieces. (To modify the prototype, just draw the ships in different shapes.)
  • Give each player one area-effect bomb that hits everything in an entire 3×3 square area. They can use it on their turn instead of taking a normal shot, but only once per game per player. (Again, just play with the modified rules.)
  • Shorten the game by playing on a 6×6 grid instead of 10×10. (Just draw the grid differently on paper.)

As you can see, modifying the rules to a paper prototype is very fast and easy, and you could go through many iterations in a short period of time. Don’t be afraid that your idea will be “bad”! Of course it will be bad. Even experienced designers create “bad” games in their first iteration. But you will never turn it into a good game unless you start somewhere. A paper prototype is very often the ideal starting point.

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.

For example, consider these rules:

  • Players: 2 to 6, free-for-all
  • Objective: shoot your opponents
  • Setup: Players start at designated starting locations on the board. The board is subdivided into hexagons (“hexes”). Each player is facing in one of the six directions leading away from their space towards another hex. Each player takes a set of the following cards: Move, Turn, Move/Turn, Fire.
  • Progression of Play: Each turn, all players select one of their cards and play face-down. Cards are revealed simultaneously. First, any players who selected Move get to move up to 2 spaces away in any direction(s), but they cannot turn and must continue to face the same direction they started the turn facing. Next, any players who selected Move/Turn may move up to 1 space and also change their facing by a single hex (60 degrees) in either the clockwise or counterclockwise direction. Next, any players who selected Turn can change their facing to any direction they want. Finally, any player who chose Fire immediately hits and kills any opponent(s) that they can see. Any player who is killed is eliminated from the game. After the turn, players collect the card they played. They may play this card or another one on the next turn.
  • Resolution: When one player is left standing, that player wins. If two or more players shoot and kill each other on the same turn simultaneously, the game is a draw.

Then you just draw up a quick hex map, maybe fill in a few hexes to represent obstacles that players cannot walk or shoot through, and play. Try it out!

And if you do try it out, you’ll immediately notice the game needs some iteration. For example, I didn’t define what a player “can see” so there is no way from the rules above to tell if a shot hits or not. You will have to define this more explicitly on your own (maybe it means in a straight line, or maybe within a certain range, or maybe something else). You may also notice that the game is not very deep; there are no respawns, power-ups, ammo, health packs, special weapons, or anything else. The game does not immediately support common variants like Capture-the-Flag or King-of-the-Hill. All of these things could be added, however, in just a few minutes.

What would this kind of prototype be useful for? You could use it to playtest a proposed level layout, before implementing it in the game’s level editing tools. If you add enemy monsters and play as a cooperative team, and you add limited ammunition and health as new mechanics, you could balance the number of monsters versus the amount of ammo and health on a level to get a pretty decent first stab at a level that would provide a desired level of challenge. If you add different weapon types with varying range, damage and accuracy, you could get a pretty good idea of which weapons would be the most powerful on a given map. You would still need to revisit these things if you turn it into a digital game, because things do not transition 100% perfectly from one medium to another… but you will have a better starting point, and a better understanding of the game’s mechanics and how they are likely to interact.

And maybe even if the digital game fails, you’ll still at least have a fun little tabletop game to play with your friends.

I hope this example serves to show you that most video games can have at least some of their elements prototyped in paper. And naturally, games that are meant to be released in non-digital form can be prototyped that way as well. Even some systems from tabletop RPGs and LARPs can be prototyped in this way, in their early stages.

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

As mentioned earlier, our First-Person Shooter prototype is just begging for extra features, such as health and ammo. 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.

In making an actual game, the next step after the physical prototype (once you’re happy with it) is to document it. These documents do not have to be 500-page Game Design Bibles. They can be small sets of rules and design and playtest notes that you’ve accumulated as you went through the iterative process, but formatted into something that is readable and understandable by someone who has not seen the project before. This documentation will be valuable reference material for later, if you ever forget what you were doing. Sometimes you have to put an idea to the side for a few months and return to it later, and I guarantee you will forget all of those details that used to seem second-nature to you when you were fiddling with the rules early on.


There are some additional readings this week:

  • Challenges for Game Designers, Chapter 4. This details the process of prototyping a video game in paper. Even if your interest is in board game design, note that many commercially-successful board games originated in the video game world (there are, for example, board-game versions of DOOM, Warcraft 3, Civilization, Age of Empires, and World of Warcraft, among many others). Some of them are even worth playing.
  • Don’t Be a Vidiot, by Greg Costikyan. If you want to be a video game designer, this article provides both an incentive to study board games, and also a starting point for the kinds of games that are out there beyond Monopoly and RISK.


Do Challenge 4-1 in the text. It does not have to be an Activision/Blizzard game. It cannot be a game that already has a commercially-available board game adaptation. (Check BoardGameGeek if in doubt.)

GreenCircleDesign a board-game adaptation of any video game. Post your complete rule set on the forums. Include a list of all components necessary to play. This game should be playable without the player having to design anything!

BlueSquareAs above, and once you’ve finished your design, make a playable prototype of the core systems in under an hour. On the forum, give a complete list of materials used.

BlackDiamondAs above, and the video game in question must be an adaptation of an Atari 2600 title. And make it more fun than the original!

I would ask this time that you stay within your experience level. For example, if you have no game design experience prior to this course, do the basic challenge, even if you are capable of doing the others, and post in the Green Circle forum. You can certainly tackle the more advanced constraints on your own, but I’d like to try it this way to see if you get superior peer feedback. Thank you for cooperating.

Make a post on the Forums before next Monday. Then, as with last time, find at least two peers at the same difficulty level, and (if you are Blue Square or Black Diamond) three people at the next lower difficulty level, and offer constructive feedback.


Here’s another quick thing you can try if you get through all of that. Propose a rule change to Battleship that will make it better than the original, and find a way to express it in less than 135 characters. Post to Twitter with the #GDCU tag. You have until Monday. One rule change per participant, please!

Additional Resources

While not required reading, I can recommend these two articles for their relevance to today’s topic:


37 Responses to “Level 4: The Early Stages of the Design Process”

  1. Ciro Continisio Says:

    Another looong post. They’re a nightmare to translate 🙂

    But of course it’s the right way, so no-one can say that the course is shallow because it’s on a blog.

  2. Jay Singh Says:

    For all interested parties, the following website:
    Allows printouts of several different types of graph paper, most notably square and hex. Other personal favorites include perspective, equilateral triangle, and Engineer’s paper, but those might have limited use here.

    • Jason Smith Says:

      You rock for posting that. Me and my wife are gonna make a paper prototype this weekend. The hex print out is perfect for what I need!

  3. SteveEG Says:

    Hi Ian,

    “It cannot be a game that already has a commercially-available board game adaptation. (Check BoardGameGeek if in doubt.)”

    Does this mean available and in print or any adaptation ever published?


    Steven Goodman

    • ai864 Says:

      Steven, my intent was no adaptation ever published. Just to make sure you start with an existing video game design and not an existing board game design.

      • SteveEG Says:

        Damn I thought so! There goes all my research on “Joust” back to square one!

        There are games for Atari games: Joust, Centipede, Asteroids, Defender, PacMan, Ms. PacMan … etc

        Before you do research go check at BoardGameGeek!

        Black Diamond games are going to be the more obsure Atari 2600 games.

        Cheers! & Good Hunting ;0)

        Steven Goodman

  4. Mendel Schmiedekamp Says:

    Could you be clearer about what experience levels you intend to assign to each level of difficulty? Are we talking about professional, amateur, novice?

    In any case though, I’d still expect the black diamond to be populated above the course statistics because more experienced designers will be generating a design within three days.

    On a separate note, for this homeplay, how well do we have to know the video game in question? Is it appropriate to design based off of reviews?

    I’m afraid I don’t have much video game experience to go on, although I don’t know if anyone else is in that same boat.

    • ai864 Says:

      Mendel, pretty much green = little or no experience in design (no matter how much you PLAY games), black diamond = working professional designer (or equivalent experience), blue square = somewhere in between (some exposure/experience but not enough to feel entirely comfortable.

      And yes, it’s very appropriate to do research on reviews. I’d also recommend looking for gameplay videos on YouTube if you’re unfamiliar with the game. Or, you could just choose a game that you are familiar with — it’s just as challenging (if not moreso) to make a decent board game about “Pong” than about “Gears of War” 🙂

  5. TimEdwards Says:

    I’m not sure how many people actually make a prototype of every game thus far, but I will say on behalf of anyone who suggested a card based game that there is a lot more balancing in the cards then anything else thus far that I have found.

    In my game idea I described the basis of the cards but even through playtesting those numbers have changed significantly and other elements have been replaced. Which is why in the initial design I laid out only a few examples so I would be able to modify from there.

    Yes some people may have just taken the easy route to “Oh this is a card game where this victory condition exists” but my recommendation is always to provide some examples. Also, I’m not sure how many of us here are building a portfolio from the things they design in the course, but it is definitiely one thing I am working on.

    Great job thus far on the class, I’d have to say my only complaint thus far is the size of the class. It allows us more interaction with other students and brainstorming, but I think feedback from the teacher in the forums on a smaller scale would be more noticable and effective. Not that you’re not trying, but there’s 1400 of us. We easily outnumber you!

    Thanks for the opportunity though, I am seriously enjoying the class!
    Tim Edwards

  6. Federico Fasce Says:

    To make things even more difficult for the black diamond, I probably would have chosen a more modern platform (Nintendo DS or maybe Playstation).
    Atari games look pretty easy to convert, because the mechanics are exposed and very easy to see.
    What do you think? Why did you choose Atari? Just curious 🙂

    • SteveEG Says:

      Simple for fast design, making it easier to play test! Iteration! Rapid Prototyping! Fail fast!

      Just off the top of my head.


      • Dr. Mike Reddy Says:

        Doesn’t this reinforce Ian’s excellent proposed thesis – REALLY an incredibly interesting analysis of the prediliction towards Black Diamond – that MORE constraints == EASIER!

        By easier, I don’t mean LAZY, I mean SIMPLER. Experienced designers will K.I.S.S. and a tighter constraint would appeal to their need for efficiency. It’s hard to be simple. Easy to be complicated (at least early on, when you are less experienced). So maybe the quoted ski resort classification needs addressing? Black Diamond = really polished, play tested and balanced; Green Circle = rough at the edges, not play tested, first iteration; Blue Square = somewhere in between.

        Ian has a clear idea about how he wants to run things, but imagine for yourselves (as a suggestion) starting with a mental submission to Green, then Blue, then possibly Black. When the deadline approaches, you can actually submit what you have FINISHED, rather than what you have; the last complete iterative cycle. That way, you can reflect on what stage you have got to, and then submit to the relevant slot. This reflects the iterative cycle and peer review that Lesson 4 discusses.

        If I run a similar structure with my students, I might allow up to three submissions, based on completeness, rather than the number of constraints. And I’d go Bottom Up: Submit Green; Review Green for at least one other; Submit Blue; Review Green AND Blue for one other; Submit Black; Review Green, Blue and Black for one other. However, as I said before, Ian is teach! He has a plan and a way forward. At this scale, it is huge experiment that needs our support. Certainly an academic paper in there somewhere, Ian.

    • ai864 Says:

      Since you asked, I did chose Atari for a reason.

      As you say, older games have simpler mechanics, so on the surface it should be easier to “translate” them to board games — less work to do, right? But look at the other constraint: make the board game BETTER than the video game. Here is where the difficulty comes in.

      Since the Atari didn’t have much on-board memory and was very limited in processing power, its games had to have tight rule sets that could deliver a lot of solid gameplay arising from very simple rules. Making a board game that is not only an adaptation of “Space Invaders” but that delivers superior gameplay is a pretty tall order, I think.

      On the flip side are the Atari games that were… um… not very good at all (these were mostly from the 1982-84 era). “E.T.” is often cited as one of the worst games ever made, in spite of being a pretty amazing job for the time constraints that the developer had to work under. I remember there being a Purina-branded game around then that was absolutely awful. Taking a “bad” game from that era that didn’t even start with solid core mechanics and then adapting that to a physical medium has its own embedded challenge: Take This Game And Make It Fun. Which is not trivial when you’re dealing with a very simple game.

      So, that was my original rationale for Atari. Though, as Dr. Mike points out, another useful property is that the simple rules mean it’s easier to generate a game within the time constraints of this project 🙂

      • Selene Says:

        Out of curiosity – I’m designing a game based on an Apple II title (Short Circuit). Can I post it in the black diamond board or should I stick with the blue square?

  7. Brandon Jeffries Says:

    Something I’ve always done while making card games is to buy colored back sleeves. Then I place a regular playing card backwards into the sleeve. This gives the cards a ‘real card-like feel’ while holding them, shuffling them, etc. The prototype itself is just scrap paper with the info stuffed into each sleeve.

    This allows quick modifications and for the initial prototype materials to be reused over and over. Different colored sleeves can either signify different card types (Events v Action) or to stop the mixing of several games in the same case.

    • ai864 Says:

      I agree that this can work, and makes them easy to shuffle, too. However, actually inserting cards into sleeves is tedious and makes it a little harder to modify them (since you have to take the paper out before you can write on it), so I usually reserve that for when a prototype is in a slightly more advanced form than just starting out.

  8. MrCactus Says:

    Must the homeplay challenge be a board game? Or can it fit into the larger category of non-digital games?

    • ai864 Says:

      Great point. Let’s say “board game” for now, with the understanding that you can explore many other different styles of play from the challenges that will come later on.

  9. Jeff_Wilson63 Says:

    One type of grid you didn’t mention was offset squares. Though functionally the same as hexes they have a lower geekiness factor and are much easier to create quickly.

  10. The_Hanged_Man Says:

    I was just reminded of a slogan that my old boss (we were in a rapid prototyping environment) liked to use from the newspaper industry.

    Don’t draw what you can trace.
    Don’t trace what you can copy.
    Don’t copy what you can steal.

    • MrCactus Says:

      Around the office, we often go with the mantra “steal with pride”. There’s no reason to reinvent the wheel if you don’t have to.

  11. rkoster Says:

    Enjoying watching the class. This week makes me want to dig out my strategy board game version of Pengo I did when I was a kid. 🙂

  12. Telka! Says:

    Maybe I’m playing Devil’s Advocate here… but I would find it rather interesting to see the results of everyone prototyping games offered from the first challenge (or future design challenge). 😛

    I thought of this while looking over some of the game ideas to critique. Some of them I can only wrap my head around if I attempted to play them (not necessarly the fault of anyone – I’m way more of a hands-on person and reading lines of text at 12:30 a.m. doesn’t help).

  13. Jason Tam Says:

    gg Ian. i have a question as usual =]
    In the real video gaming industry (i.e not indie) are you expected to produce a board game or a non digital prototype for your employers?

    • Ciro Continisio Says:

      I guess no. You are not “expected” to do it, and I dare say that only the most illuminated producers would allow this kind of “time waste” (I’m ironic). Most employees just want the programmers to start coding, which of course is a bad practice.

    • ai864 Says:

      Jason, depends on the company (and the game). This is not “expected” or “required” on every project. That said, if you walk into a random studio in the early stages of development, seeing a non-digital game prototype would not be out of the ordinary… at least, in my experience. Others may have different experiences, and I’d love to see them. That is why I post these things, after all — I only have my own experience to go on, and if my thoughts are not the norm, I want to know about it so I can stop teaching things that are irrelevant 🙂

  14. mr.cruet Says:

    Suspect this is one of those question where I will just have to plough on ahead.

    How literal a translation of the game is required? Take the starcraft board game – while an excellent board game and while it is themed like starcraft it’s not a direct translation of the computer game being more the strategy version of the stracraft universe then the tactical version which is what the computer game is.

    I suspect the intention is towards the literalist translation so I will aim for that but clarification would be useful.

    • ai864 Says:

      Great point. As it says in the text, there are many types of translation. You might start with the theme/backstory of the game, and create something that is otherwise unrelated but takes place in the same game world. Or you might start with the core mechanics of the game, and try to translate those as faithfully as possible. Or you might start with one small aspect or system of a larger game and expand it into a full game of its own. Choose the one that is the most suitable for the game that you chose.

  15. Raphael Aleixo Says:

    Hello, Ian.
    We are really enjoying the GDCU, but it´s kind of hard to take a summer course when it’s neither summer nor holidays here in Brazil. We are trying to save all the time we can to read and participate, but we need to understand a little bit better your expectations:

    You said that you “encourage us to make complete designs, when we are designing a game and not just a concept.”. It was a good clarification: I think we cannot have our game evaluated without having complete designs.

    But what exactly do you mean with “complete designs”? Does it mean just a complete playable set of rules and material, or an already extensively playtested system, which we think is really finished.

    We will post our game in the forums in a few hours, but we know the games may (and will) have mistakes: We, unfortunately, don’t have enough time to fault-proof the system with countinuous playtests.

    I know it’s not a issue of the course, obviously. But we really want to make the best of it. So, besides the clarification we asked for, we also would like to know what would you suggest us to do in order to get our “homeplay” games closer to your expectations.

    Thanks a lot, again.

    • ai864 Says:

      by “complete” what I should say is “playable” in the sense that you could theoretically take the game rules and all listed components and sit down and playtest, without having to go to the designer for rules clarifications.

      I understand that games will have mistakes, and there will be some “holes” in the rules that could be fixed by a more thorough playtest. And I understand that given the time constraints for these early projects, it may not be feasible to test your design very much, so some posts may be lacking in this respect. But get it as close as you can with the time that you have available.

  16. Green_eyes Says:

    In Soviet Russia the “battleship” plays you. *rimshot*

    I mean we have different rules from those you wrote about.
    There are more ships: 5 of 1 square long , 4 of 2 square long, 3 of3 square long, 2 of 4 square long and 1 5 square long ship. Each ‘hit’ allows another shot.

    Hope this helps (=

  17. Itai Raccah Says:

    Hello Ian,
    I want to thank you again for this wonderful course.
    I am in a little of a busy couple of weeks, but soon I’ll be able to participate more.
    One think I would like to ask is that you write the deadlines of home play as dates instead of “next Monday. It will help me keep track of it, in case I am late in reading the post.

    many thanks!

  18. Dave Matney Says:


    That’s my attempt at making a non-digital version of a video game. Admittedly, I failed (I may go back and revise my idea at a later date, ’cause I hate feeling like I failed), but I did learn some things.

    Keep it small, keep it simple. Focus on ONE mechanic first, make it work, move on.

  19. Chakan: The Forever Man | Dave Matney : Forward Says:

    […] telling you what I learned first, then what I should have done, finished with what I did. In Game Design Concepts Level 4, we were challenged to build a non-digital adaptation of a video game.  I chose Chakan: The […]

  20. Level 12: Solo Testing « Game Design Concepts Says:

    […] August 10, noon GMT, create a playable prototype of your game. You may find it useful to review the section of Level 4 on prototyping. Remember that you can make a prototype in about 15 minutes – it doesn’t have to be pretty and […]

  21. &nbsp Game Design Prototyping Awesomeness! » GBGames - Thoughts on Indie Game Development Says:

    […] the Game Design Concepts course that I’m taking online, there was a post early on about creating a prototyping kit. After messing around with paper cutouts which blow away too easily or stones from a wedding […]

  22. GBGames: Game Design Prototyping Awesomeness! | Games For You Says:

    […] the Game Design Concepts course that I’m taking online, there was a post early on about creating a prototyping kit. After messing around with paper cutouts which blow away too easily or stones from a wedding […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: