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.

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

Readings

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.

Homeplay

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

Design 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!

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

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

Mini-Challenge

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:

• Veteran designer Raph Koster provides his own list of game bits that work well for prototypes.
• An article on paper prototyping, written for an audience of video game developers.