FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
Core Mechanics Design
Entia non sunt multiplicanda praeter necessitatem. (Do not create more entities than necessary.)
—Attributed to William of Occam
Designing the core mechanics consists of identifying the key entities and mechanics in the game and writing specifications to document the nature of the entities and the functioning of the mechanics. This is the very heart of the game designer's job, and the more complex the game, the longer it takes—sometimes weeks or months. Because you can make so many kinds of games, this book can describe the process only in general terms. Use your knowledge of existing games and of your chosen genre to fill in the details.
Reading this chapter alone gives you the tools to document your core mechanics, but it doesn't contain the information necessary to create a balanced game. Don't start designing your mechanics until you have also read Chapter 11, "Game Balancing."
Goals of Core Mechanics Design
Before looking into the question of how to go about designing the core mechanics, remember what you are actually trying to achieve with your design. Never forget that your ultimate goal is to create entertainment for the player—that's the point of the quote from Moliere at the beginning of the chapter. But in addition to this overarching objective, certain principles help you design an enjoyable game efficiently.
STRIVE FOR SIMPLICITY AND ELEGANCE
The most elegant games operate with the smallest number of rules. Some of the greatest games are those whose mechanics are extremely simple yet still manage to offer interesting variety. As the quote from William of Occam suggests, try to avoid making your mechanics too complex. Simple games are easier for players to learn, and that gives simple games a broader appeal than complicated ones.
You can maintain players' interest with a variety of content that explains a small number of mechanics in a large number of ways. As mentioned in the sidebar "The Rules and Core Mechanics of Monopoly," the general rules of Monopoly are simple, but the Chance and Community Chest cards create additional interest. The majority of these cards concern the transfer of money to or from the player who draws the card—a simple mechanic—but each card gives a different explanation for why the money is being transferred (such as "Income tax refund, collect $20"). The explanations are purely cosmetic, but they add variety. You can build similar features into your own game while still keeping the rules simple.
LOOK FOR PATTERNS, THEN GENERALIZE
Learn to recognize patterns in your ideas for your game and to convert them into generalized systems rather than trying to document dozens of individual cases. Here's an example. Suppose you decide that swamp leeches really belong in water and that a swamp leech should lose 10 points of health for every minute that it's out of the water. Later, you decide that a salamander (a mythical fire-loving creature) should lose 5 points of health for every minute that it's out of the fire. A pattern emerges: Certain creatures are dependent upon their native environment, and they lose health at a specified rate when they leave it. Instead of describing this mechanic over and over for each creature, explain the general case only once, for all environment-dependent creatures. Note that each creature in the game will need two attributes to support this mechanic: a symbolic attribute indicating what the creature's native environment is (water, fire, and so on, and be sure to include a special value to use if the creature is not dependent on any environment), and a numeric attribute stating the rate at which the creature loses health when out of its environment (the value should be zero if the creature is not environment-dependent).
Then, as you design each creature in your game, you can decide what values these attributes should have without having to document the whole mechanism again.
By designing general patterns rather than individual cases, you can more easily understand how your game will really work, and you will also make it easier for the programmers to program it. The programmers will write general-case code that applies most of the time, rather than having to write separate subroutines for each creature. You can still create a few special cases for variety or when circumstances require it. In Monopoly, the rules for collecting rent on colored properties (the ones named after streets) are the general case, while the railroads and utilities are special cases that create additional interest. But try to avoid creating large numbers of special cases.
DON’T TRY TO GET EVERYTHING PERFECT ON PAPER
Unless you're designing a trivially simple game, you won't get everything perfectly right on paper, because you won't be able to compute the effects of all your mechanics in your head. Designing core mechanics (and just about everything else in a video game, too) requires iterative refinement. Create a first draft of your mechanics and then build a prototype that implements them, either in a spreadsheet program or in software. Test and adjust your mechanics using the prototype. If you try to get everything exactly right on paper, you won't ever get the project finished. Although this may sound odd, it is more important to be clear and precise in your documentation than it is to be accurate. You will find it much easier to correct a mechanic that doesn't work quite the way you expected than to try to resolve ambiguous language late in the development process.
FIND THE RIGHT LEVEL OF DETAIL
You can design core mechanics at any level of detail, but there are tradeoffs. If you document the core mechanics minutely, with no detail left unaddressed, the programmers can turn your mechanics directly into code very quickly. That seems like a good idea in principle, but in practice you will almost certainly be swamped with work. Designers who try to document every single thing about the core mechanics delay their projects—or cause them to be canceled.
The problem at the opposite end of the spectrum, leaving too much unclear, is almost as bad. Either the programmers will have to come and ask you for further details, or they will make their best guess for themselves. If you have clearly communicated your vision to them, and you see eye to eye about how the game should work in principle, then their guesses may be good ones. But in practice, the programmers will often make assumptions other than what you intended, and you'll notice the mistake in the tuning phase. It can be time consuming to go back and correct bugs introduced by ambiguous design decisions.
To find a happy medium, use traditional gaming conventions where appropriate to avoid overloading yourself. If your game features some very ordinary scenarios and you are confident that the programmers will know what you mean, you can afford to use general language. You don't have to write, "When a car's number of laps
attribute goes over 500, set the eligible to win flag to TRUE for that car. Continuously check all cars to see if the location attributes of the cars that are eligible to win show that they are on or beyond the finish line. Set the winner entity with the number of the first car whose location attribute meets that condition." It's okay just to say,
"The first car that has completed all 500 laps and crosses the finish line is the winner," because this is a perfectly familiar situation.
The less familiar the mechanisms that you document, the more specific you need to be, especially if any of them run counter to convention. In the dart game 301, the player starts with a score and reduces that score by the amount that he hits on the dartboard. The object of the game is to be the first to achieve a score of exactly zero. Because this runs counter to convention, it's the sort of thing you have to explain more precisely. Similarly, the mechanic that describes the behavior of female dragons in the earlier sidebar "Analyzing a Mechanic" requires more detail because female dragons are entirely imaginary; nobody can count on his existing experience with dragons to know how they should behave.
If you know how to program even a little bit, you can write pseudo-code to document processes that you need to explain extremely carefully. Pseudo-code includes the if and while statements that indicate conditional or repeated operations but without exact variable names or the other syntactic features of a real programming language. Pseudo-code can be handy in circumstances that call for precise explanations, which is why potential designers would benefit by taking at least one class in programming. It doesn't much matter what language you study, as long as it includes the concepts of conditional and repeated execution.
