Book Summary: Practical Game Design – Creating Concept and Gameplay

The second book about game dev I’ve read this year is Practical Game Design by Adam Kramarzewski and Ennio De Nucci. This book touches numerous important topics from ideation to LiveOps. This time, I’ll try not to write a whole six posts about the book. The book has fifteen chapters and I’m going to condense them into 7 bullet points. This post contains the first three points.

Book Summary: Practical Game Design

1. Intro to Game Production Process

The first chapter of the book titled Introducing the Game Production Process broadly introduces how the gears turn in the game industry and how a game designer fits in it.

Not only the traditional production schedules and milestones that are brought up, the writer also provides one different example of how schedules/milestones can be customised. For example, from start to finish, the milestones are:

ideation,
preproduction,
market sizing,
internal prototyping,
alpha,
beta,
soft launch,
release, and
live ops.

Common game designer roles are mentioned;

generalist,
economy designer/monetization specialist,
level designer,
mission/content designer,
narrative designer,
systems designer, and
technical designer.

2. Game Concept: Creation, Scoping, and Documentation

The next three chapters talks about documenting the game design.

The Game Concept chapter covers how to communicate a game idea formally to the rest of the team with a game concept document. Any game concept document at least should deliver:

the hook/elevator pitch,
overview description,
a list of key features/unique selling points (USPs),
platform, genre, and target audience.

In this chapter, the writer lists good questions to help us compare our game concept with similar games that are already out there. The writer also introduces some ways to come up with ideas for mechanics and themes.

Once we have the idea for a game, we have to scope the game project to make sure this idea is feasible. In the third chapter, Scoping a Game Project, the writer shows a way to create estimates on the complexity and size of the game. Common game structures are mentioned as a starting point:

linear,
structured nonlinear,
open exploration,
endless, and
sandbox.

Then, the game designer can start breaking down the player’s path to “consume” the game by making documentation on:

content lifespan,
game flow, and
player progression flow.

From those documents, the game designer can tell which game assets are critical. These critical assets are highly related to the main mechanics of the game and other assets depend on them being made first.

After the concept and scope are documented, the game designer now moves on to the game design document (GDD). The goal of this document is to describe the game to the team in details. GDD doesn’t need to follow an exact format, but in the fourth chapter, Design Documentation, the writer enumerates what makes a good GDD:

modular,
starts with goals and requirements,
is a result of a discussion,
clear, brief, concise,
multimedia based,
leaves space for creativity and debate,
not bound by format, and
online.

3. Gameplay: Mechanics, Prototyping, and Level Design

In this section of the book, the writer explores the gameplay creation. Before trying to design mechanics for the game and calling it new, anyone should study the working mechanics in existing games. In the fifth chapter, Adaptation of Mechanics, the writer mentions common game mechanics from the seemingly simple jump to the time limit, turns, win/lose conditions, quick-time events, XPs, and so on. The game designer can customise the rule of the existing mechanics to try to create something new. Game dynamics emerge as the player interacts with the game with the provided mechanics. The game feature comprises a set of mechanics and the intended dynamics which emerge.

After learning to

deconstruct mechanics from existing games and
add or subtract a rule to create something new out of it,

in chapter five, in the next chapter: Invention of Mechanics, the readers can try to invent a novel game mechanics. Solving a problem in existing games can be a starting point for a game designer to create new mechanics. They may also try to create mechanics just for the sake of innovation.

To create something entirely new, a game designer should explore a game idea and translate it into a set of rules, mechanics, dynamics, and features that deliver an experience to the player. To help readers design the right dynamics for the target players, the writer mentions:

Richard Bartle’s types of players,
Nicole Lazzaro’s types of fun,
Jesse Schell’s taxonomy of game mechanics, i.e. space, objects+atributes+states, actions, rules, skills, and chances.

The writer also explains the game loop in this chapter. The game loop is a state in which the player takes an action that generates feedback from the game which in turn invokes the player to make another action in the game, and so on.

Another way of creating mechanics is to see games as systems of conflict. Conflicts can come up from the existence of opponents, obstacles, or dilemmas. One way to create depth and increase replayability is to design different approaches to the solution instead of just one best solution. Replayability might just be a nice thing to have in a puzzle game with optimal strategies to be discovered for each of its hundreds of levels. On the other hand, it is crucial in combat systems. The players should be able to explore combinations of mechanics to defeat an opponent. One way to add more options for strategies is to add more mechanics, but the game designer should introduce these mechanics in a way that is not giving out the impression of complexity.

Once the mechanics are documented, it’s time for the game designer to make sure the design is not only good on paper by making a prototype. In Chapter 7: Prototyping, the writer describes a step-by-step guide to prototyping and its case study.

Paper prototyping is one of the ways to start as it’s cheaper and quicker to get a higher number iteration. It strips the game to the mechanics’ abstraction. Adding art in a mechanics prototype can be distracting. Paper prototyping is hard for a complex, real-time scenario so game designers can go straight to the digital prototyping.

Digital prototyping is always necessary to avoid making permanent design flaws. In creating digital prototypes, game designers should not overdo the iteration of just one thing or adding more mechanics to compensate for the ones that don’t work. Art and effects are also kept to a minimal to make sure they don’t hide bad mechanics. Game designers need to be ready to drop some mechanics or the idea entirely if it doesn’t work. Game designers need to avoid creating systems that are too accurate to the design while sacrificing valuable time and instead just hard code the variables. As the prototype code is highly likely to be hacky, the game designer needs to understand that most of the prototype code base is bound to be thrown away.

The topic of Level Design is brought up in chapter 9. It comes after the chapter about narrative design because the levels can tightly entangle with the narration. The narration can also be independent or have little connection with the level progression. The writer mentions the widespread ways to convey narration in a game such as cutscenes or dialogues, and directly in the gameplay or in the level layout. Besides the connection between level and narrative design, the writer talks about the process and the common practices of level design in this chapter.

The following steps outline the process of level design.

Step one is setting up a compelling premise with a short paragraph that can be accompanied by a reference art.
The next step is making sketches that elaborate on the premise. Sketches can be dialogues and storyline, major gameplay events and branching, layout drawings, concept art or other references. In personal and low-risk projects, the designer can skip sketches and go straight to grey-boxing.
Grey-boxing means creating the level’s block-out; that is the actual layout of the level with simple geometry without artistic textures. The gameplay is tested in the grey-boxed level.
After the layout is tested and done, the artists can start the art implementation of the level.
The last step is the final polishing. Small improvements are added to the almost finished level to ensure its cohesion with other levels and features of the game.

Also in this chapter is the writer’s explanations of some of the common practices in level design. They are listed below.

How to make an environment believable by applying functional level design and realism.
How to “tell a story” of mechanics to the player. Mechanics are introduced in a way that is engaging by borrowing the structure of the narrative storytelling.
Keeping pacing in mind, just like storytelling.
Using the lock and key mechanism to control the progression.
Motivating the exploration of spaces by putting rewards in strategic points.
The writer refers to the prospect-refuge theory. It states that human love a small enclosed space (refuge) overlooking a wide and open space (prospect). Enclosed spaces can turn into a source of conflict if the enemy is inside (not a refuge) or that the player is not allowed to get out (no prospect). On the other hand, open spaces alone can mean that enemies can attack the player from any direction (no refuge).
Height evokes emotions according to how grave is the consequence of falling.
Light and shadows can play a huge role in giving navigational cues to the player. The writer also mentions other roles of lighting that may become part of the mechanics of the game.
Using vision as mechanics.

Then, the writer brings up some common practices in multiplayer action games such as:

avoiding dead-ends,
keeping players moving,
creating a heatmap of important statistics such as death locations, and so on.

The next post will be about creating narration and characters, UI, tutorials, localisation, and the last 90% of the game design: play-testing, balancing and polishing.

A Not-Too-Secret Diary