CAP 211 - Interactive Design and Game Development

On Game Design: Chapter 1


This lesson discusses material from chapter 1 of Rollings and Adams On Game Design. Objectives important to this lesson:

  1. Introduction points
  2. Describing game design
  3. Elements of games
  4. Core Mechanics
  5. Storytelling
  6. Interactivity
  7. Design documentation
  8. Skills needed by a game designer

In the introduction to the text, the authors tell us something about the content of each chapter of the text. They also sell the concept of game design as something that we already know something about. We learn something of game design every time we play a game and negotiate "house rules" with the other players, adapting parts of the game to our own desires or needs. We have all been game designers at times, and we can be better ones. The first step is to believe that we are game designers, and then to decide to become better ones.

This is not a new idea. William James wrote:

“If you want a quality, act as if you already had it.”

Kurt Vonnegut wrote:

"We are what we pretend to be, so we must be careful about what we pretend to be."

As an overview of the game design process, consider the following:

  • designing a game requires lots of decisions that may have to be made, tried out, reconsidered, improved upon, and incorporated into the game
  • basic design skills can be used for any kind of game, not just computer games
  • a designer has to deal with a game's story, rules, setting, and more aspects that are discussed in the text

The authors make an excellent point on page 3, that a game is dependent on our capacity to pretend, to see the game as a different reality, instead of as lights on a screen, or as plastic bits on a paper board.

Describing Game Design

Game design is presented as four bullet points on page 4:

  • imagining the game
  • defining how the game works
  • describing the elements of the game (which are defined later in the chapter)
  • communicating all of the above as information to the people who will build the game (artists, programmers, actors, etc.)

The authors proceed to argue that game design is not an art, because it depends on more than a great artist to make it work. This is true, as far as it goes, but it is a straw man they set up: we had no expectation that an artist alone would be interested in designing a game.

They continue to argue that game design is not a science, because it is not predictive (as science should be), nor does it "seek truth". They seem to be saying that a successful game designer is not following scientific formulae or principles to create the game.

Their best point in this section of the chapter may be that game design and creation is a collaborative process, as art can rarely be. It is a combination of the efforts of a group of artists, programmers, writers, and other talented (or untalented?) people that produces a successful game in the computer driven environments they will be discussing in the text. The authors point out that this can be a problem if your team does not work together well. Helping the team to do so is a job that falls on the team lead, or lead designer.

Elements of games

The text turns to elements commonly found in games: rules, game interface, player roles, and more are briefly mentioned. Before getting into specifics, the authors introduce a model that classifies game elements into three areas:

  • core mechanics - The rules of the game, how it is played regardless of it being on a computer, a game board, or just in the players' minds.

    The authors label this part the "heart and soul of the game" (page 9) and list three causes that can ruin a game: designer ignorance, marketing pressure, and conflict between demands for good technology and for good game play.
  • storytelling - The authors make a distinction between story and narrative. Most of us would consider these words to mean the same thing. The authors provide operational definitions for them to make a good point.

    In their terms, story is what happens in a game. Many players might consider Space Invaders, for example, to have no story, but they would be wrong. The story in this case is that the enemy figures appear on the screen, and the player must shoot them all or lose the game, while avoiding being shot. The player creates this story in the course of playing the game. This sounds like a game description, and it is.

    The authors use the word narrative to mean the dramatic or comedic events that unfold while playing the game: the plot. This is the part of the game that is like a book, or a movie, or life. Space Invaders has no narrative: the game designers and programmers provided only two words of back story for the game (its title) and provided no exposition, no dialog, no unfolding events to entertain the player.

    In these terms, all games have some story, but not all games have a narrative. Classic games like chess, baseball, and pong each have a story, but they do not need a narrative. Each of them would need a narrative added to them to make a good movie, and perhaps to make a more interesting computer game. For example, would you be more interested in playing chess on a computer, or playing a Harry Potter version of animated Wizard Chess in which the outcome of the game determined what would happen in a dramatic narrative? Some gamers want to be entertained in multiple ways by a game, some do not.

    The authors make some observations about narratives being linear by nature. It is difficult to tell a story well when the pieces of it are allowed to occur in any order, and some pieces may not occur at all. In the example above, there would need to be a fork in the plot. The story would take one fork for if you win the game, and a different fork if you do not.

    Some players play games with heavy narrative content many times to mine all the detail that they can find, while others feel a need to find the "best" narrative thread through the game, avoiding what they perceive as lesser threads. Both kinds of players are typically frustrated by too few choices in a game, too little player influence on outcomes, and too little satisfaction in the end game.
  • interactivity - This is described as everything the player sees, hears, and experiences while playing the game, as well as how the player interacts with the game. Some discussion of the user interface is provided, with examples of games that were done better than others. Unfortunately, the authors do not provide detail about what was better.

    The authors touch on an important measure of success for a game. When a player is so absorbed in the game that they become less aware of the interface, they are in what this text calls "a groove", and another text called a "sense of flow". They are feeling the abstract thing that is the game itself, not the actual interface they are using. When the interface ceases to be barrier, when the player has this feeling of immersion in the game, that is a very large compliment to the interface and game design.
Design documentation

The authors turn to the concept of game design documents, examples of which are provided in the book's appendix. They explain that it is easy to make a small game by yourself, without making notes about what you are doing as you go along. This is, however, not how major console and computer based games are made. Games are developed by groups, teams, or whatever aggregate word is used to denote a large number of people whose work must fit together to make a final product. Ideas must be developed and properly communicated to people whose work must include them, or your product will suffer, and probably fail.

Consider the gray sidebar at the bottom of page 14. In it, the authors provide an idea, expressed in one sentence: a type of character should do something, expressed as an abstract concept. They also provide a fully developed design decision based on that idea, which explains how the idea must be implemented as a set of behaviors for a type of character in their game, behavioral reactions to actions the player may take, and a specific rule that would lead to lethal combat. This is the sort of documentation that a team must have, must share, and must understand in order to produce work that will fit as a unified whole.

Three types of design documents are explained:

  • high concept - This is a concept pitch, and it is meant to cover many points relevant to getting someone interested in your game. It is a bullet list of talking points that you would cover in an initial presentation to the people who would approve or disapprove your project. The authors list things they would include in this short (two to four pages) document:
    • premise of the game
    • intended audience
    • genre of the game
    • what will be unique about the game
    • platforms the game will be made for
    • game storyline
    • game play description
    • hardware requirements to build and to play the game
  • game treatment - This is a more developed pitch. The bullet points in the high concept document should be developed and described in detail, to show that you have worked on each of them. Things to add:
    • what makes your game better than previous games of this type
    • descriptions of characters
    • screen mockups and concept art
  • game script (game bible) - This document is not a pitch. It is a record of all decisions made by the designer or the team, used for reference whenever there is a question about how the game is to work. It must include all the game mechanics, all the character descriptions and behaviors, all the technical specifications, and all other design decisions made about the game. This is a living document that continues to grow as long as development on the game continues.
Skills needed by a game designer

The authors continue with a discussion of several skills that a game designer should attain and continue to develop if they want to be a good game designer. They make a distinction between talent, which you are born with, and skill, which you can learn. Their point is that you should learn what skills you can, to be better at this job, or you must find someone on your team who has them or can develop them.

  • imagination - several types are suggested:
    • visual
    • auditory
    • dramatic
    • conceptual
    • lateral thinking
  • technical awareness - a designer must be familiar with how platforms work, to have an idea of what is possible and what is not on their platform of choice
  • analytical competence - a designer must be able to analyze the performance of their game, to make it better, to cut out bad pieces, and to make improvements that are not obvious without analysis
  • mathematical competence - the text discusses a need for a knowledge of statistics to make sure things are random that are meant to be random, and to make the game balanced where it should be
  • aesthetic competence - the authors discuss a designer's need for an appreciation of art, style, and novelty
  • general knowledge - It is not possible to know everything, but it is desirable to know a great deal about many things, and to know how to find out more about the things we do not know. A corollary to this idea is illustrated by an observation attributed to Will Rogers: 'It ain't so much what people don't know that gets 'em in trouble, as it is what they know that ain't so." For example, in this discussion, the authors tells us that real pirates never used a Jolly Roger flag. Looking on the Internet for confirmation, I found several depictions of such flags, as supposedly used by real pirates. Who is right? More research would be needed to determine the truth, and then a decision would need to be made about whether to go with the truth, or to "print the legend". (reference: The Man Who Shot Liberty Valence. You haven't seen it? Read the part of this discussion in the text again that talks about reading a lot of books and seeing a lot of movies.)
  • writing skills - more than what probably just came to mind, the text advises that you will need three kinds of writing skill:
    • technical writing - to document everything that goes in the game bible
    • fiction writing - to write the narrative of the game, the cut scenes, the cinematics, and everything else that is told to the player in the game
    • dialog writing - to create usable, believable dialog for every part of the game that needs it
  • drawing skills - concept art, blue sky art, polished art
  • ability to compromise - you must be able to create deals between creative forces that are in conflict, or the game will never be finished

This list of skills is not complete. In The Art of Game Design, Jesse Schell provides a list of twenty skills in his first chapter that a game designer might need to have. His list is unlikely to be complete either. The authors of our text propose that this is a good reason to accept that fact that you will not build a magnificent game alone, that you will need help to build it, and you must learn to work in a group to do it.

Assignment 1: Consider the list of skills that the authors say a game designer needs. Write a one page paper examining yourself in terms of these skills.

  • Rate yourself on a scale of 1 to 10 on each skill (10 being best), and state why you are that level.
  • State what you are doing or can do to become better at the skills that you did not give a 10.
  • If you gave yourself a 10 for every skill, do it over, and do it honestly this time.