14 What is Game Design?
We use the word “design” a lot in this text, and unfortunately it is a term that is a bit overused, so we must clarify what we mean by design. As Ian Schreiber and Brenda Braithwaite say in their book Challenges for Game Designers, game design is the creation of the rules and content of a game. It does not involve programming, art or animation, or marketing, or any of the other myriad tasks required to make a game. All of these tasks collectively can be called “game development” and game design is one part of development.
Multiple Types of Game Design
As mentioned in Challenges, there are many tasks associated with game design: system design, level design, content design, user interface design, world building, and story writing. You could fill several textbooks with any one of these, so this text will not be a full treatment of the entire range of game design. The majority of this course focuses on system design (also sometimes called “systems design” or “core systems design”).
System design is about defining the basic rules of the game. What are the pieces? What can you control? What actions can you take on your turn (if there are “turns” at all)? What happens when you take each action, and how does it affect the game state? In general, system design is the creation of three things:
- Rules for setup. How does the game begin?
- Rules for progression of play. Once the game begins, what can the players do, and what happens when they do things?
- Rules for resolution. What, if anything, causes the game to end? If the game has an outcome (such as winning or losing), how is that outcome determined?
What is a Game Designer?
As you may have noticed, game design is an incredibly broad field. Professional game designers sometimes have trouble explaining what they do to their families and friends. Part of the reason for this is that they do so many things. Here are some analogies I’ve seen when trying to explain what it is like to be a game designer:
- Game designers are artists. The term “art” is just as difficult to define as the word “game”… but if games can be a form of art (as we saw in Costikyan’s definition, at least), then designers would be artists.
- Game designers are architects. Architects do not build physical structures; they create blueprints. Video game designers also create “blueprints” which are referred to as “design docs.” Board game designers create “blueprints” as well — in the form of prototypes — which are then mass-produced by publishers.
- Game designers are party hosts. As designers, we invite players into our space and try our best to show them a good time.
- Game designers are research scientists. As I will discuss later in this chapter, we create games in a manner that is very close to the scientific method.
- Game designers are gods. We create worlds, and we create the physical rules that govern those worlds.
- Game designers are lawyers. We create a set of rules that others must follow.
- Game designers are educators. As we will see later when we start reading Theory of Fun, entertainment and education are strongly linked, and games are (at least sometimes) fun because they involve learning new skills.
If game design is all these things, where would it fit in a college curriculum? It could be justified in the school of education, or art, or architecture, or theology, or recreation management, or law, or engineering, or applied sciences, or half a dozen other things.
Is a game designer all of these things? None of them? It is open for discussion, but it seems clear that game design has elements of many other fields, but it is still its own field. And you can see just how broad the field is! As the field of game design advances, we may see a day where game designers are so specialized that “game design” will be like the field of “science” — students will need to pick a specialty (Chemistry, Biology, Physics, etc.) rather than just “majoring in Science.”
Speaking of Science…
How is a game designed? There are many methods.
Historically, the first design methodology was known as the waterfall method: first you design the entire game on paper, then you implement it (using programming in a video game, or creating the board and pieces for a non-digital game), then you test it to make sure the rules work properly, add some graphical polish to make it look nice, and then you ship it.
Waterfall is so named because, like water in a waterfall, you can only move in one direction. If you’re busy making the final art for the game and it occurs to you that one of the rules needs to change, too bad — the methodology does not include a way to go back to the design step once you are done.
At some point, someone figured out that it might be a good idea to at least have the option of going back and fixing things in earlier steps, and created what is sometimes known as the iterative approach. As with waterfall, you first design the game, then implement it, and then make sure it works. But after this you add an extra step of evaluating the game. Play it, decide what is good and what needs to change. And then, make a decision: are you done, or should you go back to the design step and make some changes? If you decide the game is good enough, then that is that. But if you identify some changes, you now go back to the design step, find ways to address the identified problems, implement those changes, and then evaluate again. Continue doing this until the game is ready.
If this sounds familiar, it is because this is more or less the Scientific Method:
- Make an observation. (“My experience in playing/making games has shown me that certain types of mechanics are fun.”)
- Make a hypothesis. (“I think that this particular set of rules I am writing will make a fun game.”)
- Create an experiment to prove or disprove the hypothesis. (“Let’s organize a playtest of this game and see if it is fun or not.”)
- Perform the experiment. (“Let’s play!”)
- Interpret the results of the experiment, forming a new set of observations. Go back to the first step.
With non-digital (card and board) games, this process works fine, because it can be done quickly. With video games, there is still one problem: implementation (i.e. programming and debugging) is expensive and takes a long time. If it takes 18 months to code the game the first time and you only have two years, you will not get a lot of time to playtest and modify the game.
In general, the more times you iterate, the better your final game will be.
Therefore, any game design process should involve iterating (that is, going through an entire cycle of designing, implementing and evaluating) as much as possible, and anything you can do that lets you iterate faster will usually lead to a better game in the end. Because of this, video game designers will often prototype on paper first, and then only get the programmers involved when they are confident that the core rules are fun. We call this rapid prototyping.
Iteration and Risk
Games have many kinds of risk associated with them. There is design risk, the risk that the game will not be fun and people won’t like it. There is implementation risk, the possibility that the development team will not be able to build the game at all, even if the rules are solid. There is market risk, the chance that the game will be wonderful and no one will buy it anyway. And so on.
The purpose of iteration is to lower design risk. The more times you iterate, the more you can be certain that the rules of your game are effective.
This all comes down to one important point: the greater the design risk of your game (that is, if your rules are untested and unproven), the more you need iteration. An iterative method is not as critical for games where the mechanics are largely lifted from another successful game; sequels and expansion sets to popular games are examples of situations where a Waterfall approach may work fine.
That said, most game designers have aspirations of making games that are new, creative, and innovative.
Why This Course is Non-Digital…
Some of you would rather make board games anyway, so you don’t care how video games are made. But for those of you who would love to make video games, you may have wondered why this text is focused on making board and card games. Now you know: it is because iteration is faster and cheaper with cardboard.
Later in this text, we will discuss in detail methods of paper prototyping, both for traditional board games and also for various types of video games.
There is another reason why we will concentrate primarily on board and card games. This is a course in systems design, that is, creating the rules of the game. In board games, the rules are laid bare. There may be some physical components, sure, but the play experience is almost entirely determined by the rules and the player interactions. If the rules are not compelling, the game will not be fun, so working in this medium makes a clear connection between the rules and the player experience.
This is not as true in video games. Many video games have impressive technology (such as realistic physics engines) and graphics and sound, which can obscure the fact that the gameplay is stale. Video games also take much longer to make due to programming and art/audio asset creation.
The connection between rules and player experience is also muddied in tabletop role-playing games. Keep in mind that an RPG is essentially a collaborative story-telling exercise (with a rules system in place to set boundaries for what can and can’t happen). As such, a wonderful system can be ruined by players who have poor story-telling and improv skills, and a weak system can be salvaged by skillful players. As such, we will stay away from these game genres.
This chapter was adapted from Level 2 of Ian Schreiber’s Game Design Concepts course.
