Game Design - Theory And Practice: The Elements of Gameplay

By Richard Rouse III

This excerpt from Richard Rouse III's Game Design: Theory & Practice, covers several key game design issues, which contribute to what Rouse calls "The Elements of Gameplay." The book covers all aspects of game design, from coming up with a solid idea to writing the design document, from implementing the gameplay to playtesting the final product.

"We ended up with a game that I didn't know how to win. I didn't know which were the best strategies or tactics, even though I designed all the game's systems. That is what makes a good strategy game."
—Julian Gollop, talking about his game X-Com: UFO Defense

What are the game design elements that make up a really good game? Of course, there is no definitive answer to such a question. Nonetheless, as a game designer you will be expected to intuitively know exactly what the answer is. Understanding game design, as with any art form, is very much an internalized understanding, a "gut" reaction, a "feeling" you might have. It may be that you will not be able to form that answer into words, but you will need to understand what aspects of a game are strong and which are weak, and how the latter can be replaced with more of the former. Experience plays a big part in understanding what makes a game fun, experience both as a game designer and as a game player.
Over my years of playing and creating games, I have come up with my own answers for what makes a game great, and in this chapter I discuss some of those qualities. Some of these topics may seem fairly distinct from each other, yet to my mind they all play a crucial role in making a good game. Certainly, I cannot hope to list all of the knowledge I have, since, as I mentioned, much of my understanding is more akin to a "sixth sense" than anything I could hope to write down in a book. But the ideas contained in this chapter should help to give you a starting point.

Unique Solutions

For me, one of the most exciting moments of being a game designer is when I hear someone talking about playing one of my games, and they explain a successful tactic for a given situation that I had never considered. This could be a solution to a specific puzzle, a way to incapacitate challenging enemies, or a method for maneuvering a perilous canyon. I see the games I develop as creating situations in which game players can utilize their own creativity to succeed. When the player's creativity can lead them to solutions, which I had not envisioned, it shows me that my game is doing its job.

Anticipatory versus Complex Systems
Good designers will try to guess what players are going to attempt to do and make their game respond well to those actions. For instance, take an RPG that features a puzzle that involves placing weights on a series of pressure plates. (Having put such a puzzle in a game of my own, I would like to implore game designers to be a bit more creative than that, as pressure plates are surely one of the most overdone puzzle devices still in use. But I digress.) Suppose the designer leaves a conspicuous pile of rocks a few rooms over from the pressure plate puzzle. The obvious solution to the puzzle is to use those rocks on the pressure plates to achieve the desired results. But what if the player tries dropping his various weapons on the plates instead? This is a perfectly valid solution which should work equally well, provided the player has weaponry of the appropriate weights. What if the player has the Summon Minor Threat spell which allows him to summon a variety of different small monsters? If the player summons those monsters onto the pressure plates, they might do the trick too.
Now the designer, having thought through the puzzle fully, can have the programmer add in code where the game reacts correctly if either rocks, weapons, or monsters are on the plates. This is the anticipatory school of game design, where the designer thinks what the player might do and hardwires the game to work well with those actions. I agree that this tactic is surely better than allowing for just one solution. However, what if the player thinks of some other weight he can place on the pressure plates? What if the player uses his Berkshire Blizzard spell on the pressure plates, causing snow to fall on them? Enough snow could conceivably pile up on the plates to have a significant weight. However, if the game has been hardwired only for rocks, weapons, or monsters, the game will not react appropriately. The player will have thought of a perfectly reasonable solution and the game will fail to recognize it.
Instead of hardwiring, however, what if the designer had the programmer come up with a system where every object in the game had a weight associated with it? This would include rocks, weapons, monsters, weather effects, blood, and anything else found in the game-world. If the programmer then made the pressure plates simply get the weight of all of the objects on top of them, regardless of their type, then this one, global solution would work for all objects. If each object was set up with a reasonable weighting, it would not matter what object the player tried to place on the pressure plates, as they would all work automatically.
This latter method is less of an anticipatory system of game design; it is more holistic in its approach. It relies more on creating reliable, consistent systems with which your game will function. Then, for a puzzle such as the pressure plate one described above, the designer and programmer come up with a series of success conditions for that puzzle. Instead of "the puzzle is solved if the player uses rocks, weapons, or monsters to offset the plates," the rule is "the puzzle is solved when the plates are offset by the correct weight being placed on top of them." Certainly, the example of this puzzle is a simple one, but the same techniques can be applied to much more sophisticated and interesting systems which engender a wide variety of successful playing styles.


The Civilization games are some of the best examples of complex gameplay emerging out of multiple consistent systems running in parallel. Pictured here: Civilization II.

It is the development of numerous robust and logical systems that leads to player-unique solutions to situations in the game. One could describe these solutions as "emergent" from the systems design of the game, a popular buzzword in game design circles. Establishing a game universe that functions in accordance with logical rules the player can easily understand and use to his advantage allows players to come up with their own solutions to the problems the game presents. Nothing can be more rewarding for the player than when he tries some obtuse, unobvious method for solving a puzzle or a combat situation and it actually works. The more complex systems that work correctly and concurrently with each other, the more interesting and varied the solutions to situations become. Consider the game Civilization, with its numerous systems running in parallel. These systems work together to create some of the most compelling gameplay ever pressed to disk.
Another example of this sort of emergent strategy can be found in the original Centipede. Anyone who has ever played the game knows that the piling up of mushrooms is one of the greatest impediments to a long game, and many players understand the importance of keeping the play-field as clear as possible. As the devotees of the game pumped quarter after quarter into the game, they began to notice some patterns. First, they recognized that the flea is responsible for dropping most of the problematic mushrooms, though destroyed centipede segments also drop them. Second, they saw that the flea does not come out on the game's first wave. Third, it was observed that the flea is triggered by the absence of mushrooms in the bottom half of the screen. Thus the famous blob strategy was developed, one that the game's designer, Ed Logg, never anticipated. To use the blob strategy, the player would clear all of the mushrooms from the board on the first wave, and then allow mushrooms to survive only on the bottom-right quadrant of the screen. If, through careful destruction of the centipede, the player only allows mushrooms to be created in that section of the screen, the flea will never come out, making the game much simpler indeed. This is an emergent solution to racking up a high score at Centipede, one which players no doubt felt quite proud of when it was discovered. Furthermore, it was a discovery that Logg, as the game's creator, did not even know was there to be found. That is good game design.


Non-linearity is another buzzword in the game industry, and well it should be. Non-linearity is what interesting gameplay is all about, and many designers forget this in their work. Non-linearity gives interactivity meaning, and without non-linearity, game developers might as well be working on movies instead. The more parts of your game that you can make non-linear, the better your game will be.
In general, when someone says something is linear they mean that it follows a line. A line is a series of points connected in either two- or three-dimensional space, where one can find any point on that line using a specific equation, such as, in a 2D case, y = mx + b. In layman's terms, this means that a line must be straight. If one considers any two points on that line, say A and B, there is only one way to navigate that line from A to B. There are no choices to be made; one simply must navigate all of the points between A and B. Outside the world of mathematics, we can consider reading a book to be a linear experience. If one is reading a 323-page book and if one does not skip pages or chapters, there is only one way to read the book: by starting on page 1 and reading all of the pages leading up to page 323.
Games, however, are non-linear works. In playing chess, there are multiple ways to capture the opponent's king, to move from the game's predetermined starting state to its conclusion. Indeed, there are a vast number of different ways to be victorious in chess, and that variety is what keeps the game interesting. These choices make chess non-linear. Suppose the chessboard were one-dimensional instead of two, each player's pieces could only move in one direction, and each player had only one piece. This version of chess is a linear one, since there are no meaningful choices for the player to make and the outcome of every game is completely predetermined. And, of course, it is not a whole lot of fun either.

Types of Non-Linearity
So when we say we want our games to be non-linear, we mean we want them to provide choices for the player to make, different paths they can take to get from point A to point B, from the games beginning to its end. We can mean this in a number of ways: in terms of the game's story, in terms of how the player solves the game's challenges, in terms of the order in which the player tackles the challenges, and in which challenges the player chooses to engage. All of these components can contribute to making a game non-linear, and the more non-linearity the developer creates, the more unique each player's experience can be. Furthermore, the different non-linear components can interact with each other to make the whole far greater than the sum of its parts.


Return to the full version of this article
Copyright © UBM Tech, All rights reserved