Jacob Davenport

When I finally learned about Extreme Programming, it made lots of sense, and I wanted to apply it to my computer programming immediately. Then I realized why it was so familiar. I have been applying every aspect of its methods to board and card game design for several years. The essence of Extreme Programming is to take all good computer software design practices and do them all the time, not just occasionally. The translation to game design is straightforward.

Rules

Games are collections of rules. By knowing the rules, we know what game we are playing. Game designers communicate their ideas by suggesting rules, changing rules, dropping rules, and testing rules. Designers may discuss higher aspects of design patterns or design philosophy, but the essential and clear discussion is through the rules. A written version of the rule set is required for game development, and constant revision of them is necessary.

Metaphor

Game design usually starts with an idea for a game, and that idea is a metaphor for some other competition or conflict. Chess is a metaphor for war. Monopoly is a metaphor for real estate control. By starting with a metaphor, your game design is directed. If you find yourself designing for a different metaphor than you started with, you should explicitly change your metaphor to properly describe your new direction. Some games are so abstract that no metaphor presents itself, but you should still have an overarching method of competition. When you teach a game, you usually start with the metaphor.

Sometimes you start with a few design goals, perhaps a game mechanic that you wish to expand upon, and thus no metaphor. As your game matures, a metaphor or short description of the game should suggest itself. Sometimes you start simply with game components and neither metaphor nor design goals, but in that case you will need a game mechanic or a metaphor before you can really start to design.

The Planning Game

Once you have your metaphor, you should decide on some of your game design goals. If they are numerous, write down each one on a card, and then organize them by importance, attempting to hit them in priority order. You do not need to plan the entire project, and in fact you cannot possibly do so. Do not let a design goal be too complicated, and break down any large ones into smaller pieces. As you design, old design goals may prove less important than originally expected, while new design goals may present themselves. These goals further direct your design, and help you avoid lots of time spent on unimportant aspects of your game.

Simple Design

Your game is done when everything extraneous is taken out and it still works. A game can still be rich with detail, but those details need to meet design goals. If you find that play tests are just as much fun without a rule as with, it probably should be struck.

Testing

Until a game is tested, it is all speculation. Very experienced game designers often have a better intuition about what rule set will work than an inexperienced game designer, but their intuition is still not very good. Only by play testing a rule set can the designers know for sure. Game designers spend most of their time testing rule sets, little time actually doing design. Sometimes a game will show that the rule set does not work, and it should be aborted. Sometimes a rule can be fixed with a game in progress, but often a new game needs to be played before the fix can be declared correct. Games with luck, or particularly subtle rules, may require several play tests before a reasonable conclusion can be made. The more you can test your game, and the wider your play testing group, the better your game will become.

Your play testers are valuable, and must feel that way. If they do not like a game, you cannot ignore their concerns. Often game players are ineffective game designers, and will offer bad suggestions for improvements. You should still listen to them, because their suggestions communicate where the problem lies. You must encourage brutally honest criticism from your play testers. You do not want them to save your feelings and tell you that a bad game is good, because you cannot design with that kind of feedback. Play testers that enjoy your game may often also suggest improvements, and these suggestions often communicate what aspects of the game they enjoyed most.

While successful playtesting is required for a good game, it is not sufficient. The rules must also be simple and elegant. When your playtesters say they enjoy the game, you are on the right track, but you are not necessarily done. Continue to explore and design, because you may make an even better game.

Refactoring

As you work on a game, you may find two rules both achieve the same design goal. Usually, the two rules have some common thread and need to be worked together into one rule. This work may make very little difference to the game itself. The game may play the same, it may be about as easy to teach, but it will gain many benefits. The rule set will be more cohesive and make more sense. Unintended consequences from refactoring often improve the game. Adding other rules will be easier because the rule set is thinner. Time spent refactoring often shortens the entire design time.

Pair or Team Designing

Work with partners, as many as you need to test the game. Bounce ideas off your partners, find ways of working their ideas into the game, and suggest solutions to their problems. Find ways of breaking their suggested rule sets, either in a play test or outside of it. The team lives on communication, mostly through suggesting and discussing particular rules, feedback from game tests, revision of rule sets to make them simpler, and the courage to try something new.

Most game designers work alone, bringing in play testers after they finish a design, and then becoming hermits again while redesigning. This is a mistake, and good designers are always faster and more successful when they work together. Why do they work alone? Perhaps they do not respect or trust the judgment of other designers. For team designing to work, you must find, and sometimes train, a team of designers whom you can respect and trust.

Ownership Without Design Restrictions

If there is any expectation that a game may become viable, then the team should discuss ownership of the game as soon as that expectation becomes known. Once ownership is established, then proceed to let everyone in the team have the ability to suggest any change at all to the rule set. The owners of the game should not feel restricted from accepting suggestions from other designers. The owners are still responsible for the final product, and it is their decisions about which suggestions to take that make it still their game. Do not be afraid of incorporate other people’s good ideas into the game. It will not make the game any less your own.

Continuous Integration

Avoid putting too many rules into the rule set before testing. Game designers often start with a very simple game that may be too simple to enjoy, but still play test it to see if the core rules work before adding anything on top. As a game matures, you will need to tweak the rules, and you need to carefully balance how many tweaks you make before you play test, because you might find that the tweaked game does not work but not be entirely sure which change caused the failure. When a rule set seems improved from the previous version, make that rule set your current version. Make sure the written version of the rules is updated after every gaming session, if not more often. You may need to keep several older copies of the rules, so you can explore an interesting direction, but then be able to come back to a previous version in case you decide that the direction you took was wrong.

Designing Environment

You need to be comfortable and well rested to design well. Have food handy. Toys can often distracts a person’s conscious mind so his unconscious mind may work through the infinite design space and find useful solutions, something for which the unconscious mind is far superior. Short deadlines can sometimes stimulate ideas. Take a break when people feel exhausted. Play other games. Keep it fun, exciting, and rewarding.

Finishing

Usually a game just does not come together, and needs to be scrapped. This is not only common, but also shows good design sense to allow it to happen. Each game teaches you several lessons about game design, and the time spent on them is not wasted. Perhaps a bad game had a good element or two that can be saved for some other game. Perhaps the metaphor or game design goals are simply not being met on this game, but a different mix of them might succeed. Have courage to throw out your game.

Sometimes you have a winner. Your rules are consistent and simple, the game presents interesting choices or situations to the players, the game designs are met, and the design feels right. Your play testers want to play again and again. Congratulations, your design work is done!