The System Designer’s Checklist

I now place one trait of the system designer upon the highest of pedestals: the ability to improvise. Improvisation does not mean a lack of documentation – far from it. The best documentation you can prepare is a document that helps you to improvise. To steal the words of great dungeon masters around the world, you have to Prepare to Improvise.

Designers, as a group, tend to come down very hard on one side or another between Semantic based design, or Scenario based design. For a long time I was no exception, and I fell very heavily into the camp of Semantic Design. It WILL lead you to a strong, holistic vision of your product, but it is also true that it doesn’t help you understand your players. On the opposite side, an emphasis on Scenario based design helps me to see the world through the eyes of my players, but I always feel as if I am losing sight of the bigger picture.

The solution is one that blends BOTH philosophies. What follows is a checklist that I work through when designing a system, and this checklist is purpose built to solve two problems:

• How can I Prepare to Improvise, and
• How can I Put Myself Into the Mind of the Player.

These are problems that you WILL need to solve in your own production environment, and this checklist might help you; but, and I must stress this, the ultimate goal here is not to blindly utilize my process.

There are 6 steps in the checklist:

1. Review the Past and Present
2. Define the Problem
3. Research other games
4. Define the Introduction
5. Prepare your Scenarios
6. Define your Evaluations

Each of these steps is broken into two parts:

• Task List
• Questions to Reflect Upon

The tasks are the critical part of this tool. By putting them down on paper, you solidify those answers in your brain. The questions act as a bridge between the current step and the next step.

I must reiterate: this is not a “game design document.” The ultimate goal of this process is not to hand this off to someone and say, “here, make this.” The goal of this document is to force you, personally, to consider as many different potential issues you will face when building this system. It will prepare you for the job of deftly maneuvering the waters of development, and ensure your sails are still pointed in the correct direction.

Step 1: The Past and Present

Remind yourself what exists, and why

The first step is about review and verification. Before you begin designing any system, and usually any time you return to that system, you must reflect upon what already exists.

Task List

• Distill the essence of the game down to 2 sentences or less
• Write down every mechanic/system/feature of the player and game. Don’t get bogged down by definitions of what is a system, what is a mechanic, what is a feature… just write.

Questions to Reflect Upon

• What are our player’s Goals?
• What is fun right now?
• What isn’t fun right now?
• What purpose do the player’s mechanics serve? (A question that is easy to answer if you follow these steps)

The tasks list here is designed to get you reflecting upon the current state of the game. If you do this often, you might be surprised how your answers change over time. Two months ago, it made complete sense to call your game, “An action adventure combat game with samurai weasels.” Buuut... today you realize that weasels were cut from the game, and everyone decided they wanted pirates, not samurai….

The same is true for the mechanics of your game. A key aspect of improvising your systems is knowing what else you already have (or don’t have). Yes, writing down EVERY mechanic can be a tad laborious. This is not meant to be FUN, this is meant to be INFORMATIVE. However, it gets easier the more you do it.

We must start here, because what you’re about to design must fit within the current game like a jigsaw piece, and, as we will discuss below, you will have to FIGHT for your system's right to exist.

If you cannot justify a systems existence to yourself, you will never be able to justify its existence to others.

Which brings us to the next step.

Step 2: Define the Problem(s)

A clear purpose is the fuel of your engine

The second step is to clearly outline why this system exists. Why we are making it, and what purpose it serves for the game. For this, you have the following tasks you must do:

Task List

• Write down the purpose of this system.
• Write down any existing problems in the game that this system is solving.

Questions to Reflect Upon

• What need or fantasy is this fulfilling?
• What’s going to surprise the player?
• What other games have a similar system?

You cannot do these tasks without understanding how your system fits within the holistic image of the game, at least as it exists at this moment, which is why we Review the Past and Present in step 1. You will notice that most of the questions you were reflecting upon in Step 1 were designed to help you with this step.

A clear purpose for a system, with a clear understanding of what problems it is solving for the game, will be the greatest ammunition in your battle to improvise a system. The specifics of a system may not work the way you imagine, which may lead to you abandoning this system, but the problems it was trying to solve will still exist. Similarly, and just as important, yesterday’s problems may no longer exist! Always be vigilant about the problems in your game.

Let’s say you are giving a presentation of your new system to a programmer and artist on your team. After you are done, the programmer points out that it will be very difficult to implement this system as designed, and the artist shares additional concerns that it doesn’t really fit with the aesthetics of the final game. Normally, this would spell the death of your proposal, but the Improvisational Designer accepts this as a common step in the process. Your job is simple:

• Acknowledge their concerns
• Restate the problem you are trying to solve
• Ask for their help in finding a better idea that can solve your problems

That’s it! That easy!

What was once the death of your proposal has merely become a small bump in the road, and you were ready because you knew the root problem. Better yet, you can provide examples of places where you have seen this system in action, which brings us to step 3.

Step 3: Research

There is no reason why you must start from zero.

Research is a critical next step. There is NO REASON you have to design everything from scratch. If you do not learn from others, you are doomed to repeat their mistakes. Your task list here is seemingly simple, but will be difficult in practice.

Task List

• List 3 games, at least, with similar mechanics/systems.
• For each game:
  • Why is this system fun, or not?
  • What others systems in that game are dependent upon it? <— key task!

Questions to Reflect Upon

• Did I, or others, enjoy the system in that game?
• When and how was it introduced?
• How long did it take me to understand or master that system?

We will be using this information to help us design a system that avoids the pitfalls of the past, while also keeping an eye for what works, but that’s not the only reason. By doing your research you have armed yourself with strong references that you can point to, as not everyone will share the same vision for this system.

Let me repeat: every person will have their own vision for a system, until it is finally realized in the game — and sometimes even long after it’s been implemented.

Return to our example above, where your coworkers have pointed out potential issues and pitfalls of your design. The Improvisational Designer immediately points to other examples; not as a means to shut down their concerns (that’s rude), but as the opening of a conversation. You must ask how a similar design can be achieved, as those examples not only solve the problems that STILL EXIST in your own game, but give strong use-cases of a finished design.

Often, you will be stating examples from games that are not considered fun, or that have low metacritic scores — a metric that personally does not hold much weight, but I’ve had it thrown in my face when using a game as an example. Regardless, this should not concern the Improvisational Designer, as you have already reflected upon those examples.

By doing these steps, especially the next 3 steps, you will be able to clearly state why they worked, and why they didn’t. Your greatest ammunition, however, will be defining the player’s introduction to your system, which brings us to step number 4.

Step 4: A Strong Introduction

A first impression is everything

What do I mean by a strong introduction? Up until now, the previous three steps are fairly standard design advice, and there is parity with my previous articles, but now we are in uncharted waters.

This step is precisely what I meant above when I say your job is not done when you finish designing the system. You MUST think about the player’s introduction to that system. This will be important later when we get into Evaluation. For now, though, your tasks are simple.

Task List

• Define how far into the game your system will be introduced.
• Describe in 2 sentences or less what is surprising, or exciting, about this system.

Questions to Reflect Upon

• When else would this system be used in the game?
• What is the player’s impression of this system later in the game?
• What other systems in the game are tied to this system?

The last task is very important. Do not write, “because it’s awesome.” You need a powerfully short and motivating description, not just for the process of designing the system, but also for your ability to express its need to the rest of the team. A live production environment is one in which your job will involve a lot more “selling” of your ideas than just “coming up” with your ideas.

Game development is a carefully orchestrated dance of time and money, and you must always be aware of the following fact:

If you cannot sell, to others, why your system must be made, then it WILL NOT BE MADE.

No one cares if you think it’s important. You have to get them to agree, and being able to express your system in 2 sentences or less is SUPER IMPORTANT. Moreover, by understanding what YOU think is surprising or exciting about your system, you best understand what you want the PLAYER to think about your system. This is a key problem!

You must communicate the intent and “excitement factor” of your system to the player without talking to them directly. You need them to understand, in game, that your system is exciting. First impressions are everything.

Understanding the player’s first impression, and taking time to think of its position within the game’s experience is CRITICAL. I cannot enumerate the number of times I have felt my job was done, because I designed a system I thought was neat, only to realize later that not everyone shares the same “intuitive” vision for the system. I had not considered how to Introduce the system.

A quick example: Let’s say we are working on an action adventure game, and we have decided that the player needs a sense of progression, or growth. A classic system we could use is a talent tree. Let’s now employ our checklist!

How far in the game should this be introduced?

• After the player understands the basics of the character.

What is surprising or exciting about it?

• It lets me customize my player in powerful and interesting ways!

By stating what is “exciting” about the system, we have clearly laid out the problem. We must get the player to feel that as well, and it has to be done as soon as the system is introduced! If you design the initial options of your talent tree to be lame crap like “+0.5% crit chance” the player will not be impressed. That’s boring. No one will care that you’ve put really cool talents deeper in the tree. Their first impression is everything!

To give you an even more concrete example, I’d like to showcase something from own past. I must preface this with the note that any shortcomings I’m about to point out are solely my responsibility. That’s the point I’m trying to make! The introduction is YOUR JOB to design.

With that out of the way, this is how the player was introduced to a system I designed for Sunset Overdrive:

Awful

• It bounces between menus
• It gives no context.
• The first upgrade given is lame and boring

I designed a system that meets the needs, aesthetics, and intent of the game… I had, in fact, followed all of the advice that I liked to give back then… But… BUT, and this is important… I hadn’t thought about the system’s introduction.

Allow my failure to be your lesson. I ruined what I feel is a good design by failing to explain to the player why they should care. There is no way you’d come out the other side of that introduction and have ANY idea what was surprising or exciting about it. In fact, I would posit that more than half of all players had no idea what it was talking about, and never gave it another thought.

That last point brings us to the next 2 steps. The introduction of your system is critical, but the next thing you must consider is how the player thinks and feels about your system 20 hours later. This brings us to Scenarios and Evaluation.

Step 5: Describe Scenarios

An example is worth a thousand words.

A first impression is critical, but what comes next? How is the system used after 5 hours? 15 hours? 100 hours?

This step is about describing use case examples of your system within various contexts of the game. I can’t give you rules on how many scenarios to write, or how many different contexts to consider. Every game is unique, and this will be one of the more difficult tasks in this list, but do NOT let that stop you.

Task List

• List out as many different contexts of your game. Some examples:
  • Early Game, Mid Game, Late Game
  • Single Player, Multiplayer, Coop
  • What class is the player? What class is the player facing?
  • How many enemies are they facing? Single opponent, multi-opponent?
  • What skill level is the player?
  • Is the player close or far from their opponent?
• For each context that is relevant to your system, describe the scenario and how the system is used.

Questions to Reflect Upon

• How will the player know when and when not to use this system?
• What strategies can the player form out of this system?

The greatest power of this step comes when we get to Evaluation, below, but before we get there I want to call back up to our example above where you are pitching this system to coworkers. Pitching a system is all about proving its need, and about coalescing a consistent vision to each person in the room. You cannot do this without examples, which is why this step is so important.

If you say, “we need to add a talent tree to the game.” You will have every person in the room picturing a COMPLETELY different interpretation of that. The number of talent trees that have existed in games is innumerable, and each one is different. How can you possibly expect your coworkers to have any idea what you are picturing for the game? You must lay out clear examples, so that everyone’s vision begins to funnel towards consistency. Your use cases should be no more than a few sentences. Just enough to set the context. If you were writing about player’s abilities, an example you might write:

The player is playing as a warrior and is facing off against 2 grunt style enemies. The player sees that these two grunts are carrying shields, so they activate their smash attack to destroy those shields.

There are several contexts overlapping in this example: The player is a specific class. They are facing off against more than one type of enemy. That enemy has some special property. The player is using some special ability. Overlaying contexts is the intent. However, this example creates a powerful question. How did the player KNOW they needed to use their smash attack to destroy those shields? Enter step 6.

Step 6: Define your Evaluations

How will the player understand this?

We come to the meat and potatoes of the stew. As I said above, there were two purposes to this checklist: To Prepare for Improvisation, and to Put Yourself into the Mind of the Player. Everything up until this point has been heavily leaning to the former. This step is about the latter.

Switching to an Evaluation based mindset has been the greatest switch in my design philosophy. For a more detailed look into this you should read the new article: Designing for Evaluation. For now we have to jump into your Tasks.

Task List

• Make a grid with 7 columns. (Often I will break this up into more than one table, as 7 column can be a lot to fit into a single page)
  • Act – Data – Actions/Mechanics – Danger – Shock – Clues – Speed
• For each scenario, write the following:
  • Act — Where in the game does this scenario take place.
  • Data — What information did the player use to choose the right strategy
  • Actions/Mechanics — What did the player do in order to win?
  • Danger — On a scale from 1-5, how dangerous was this scenario.
  • Shock — What condition caused the player to evaluate the scene, and was it a Mild, Routine, or Extreme?
  • Clues — What information did the player use to analyze from the scene, and were they Primary, Secondary, or Tertiary clues?
  • Speed — How quickly was the player expected to make this evaluation?

Questions to Reflect Upon

• How will the player know when and when not to use this strategy?
• Are there other strategies that are similar?
• Are the shock conditions and clues powerful enough for the importance of this strategy?
• Do two completely different scenarios have very similar shocks, or clues?
• Is there is critical knowledge that we are failing to teach the player?
• Are some of our clues are too similar, or not primary enough?
• Does the player go a long time before being asked to change their strategy?

This one is a bit more than the others, but that’s ok. This step forces you to HEAVILY commit to your understanding of how the player is MEANT to perceive your game. All of these final questions there to help you see the problems and spot the patterns that are emerging.

Will doing this ANSWER these questions for you? No, of course not. I can’t give you a tool that answers your questions, because every game is different, and the problems of that game will be unique. I can, however, give you a tool that forces you to consider the game from the proper angle.

In Closing

In summation, the 6 steps in the checklist:

1. Review the Past and Present
2. Define the Problem(s)
3. Research other games
4. Define the Introduction
5. Prepare your Scenarios
6. Define your Evaluations

The Improvisational Designer is about accepting that there are no easy answers. But more than that, it’s about understanding that our job is not done once your pencil leaves the page. As I’ve shown you above, designing a system that is “neat” is only half the job.

This Checklist can be worked through in a notebook, or on scratch paper, and in some cases you may not need every step. That’s ok! It will not solve everything for you, as there is no way to know the future – that’s my entire point! But maybe, with a little preparation, you can be ready for Monday morning’s meeting, and that’s really what all of us are trying to do.