- How Do You Even Start?
- Designing Systemic Games
- Analyzing Games from a Systems View
- Prototyping and Playtesting
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Designing Systemic Games
As a way to approach designing games as systems, we can look at the properties of effective systems in games and how they affect the process of game design.
Qualities of Game Systems
Achterman (2011) has provided helpful guidelines for building game systems. In his view, five qualities are the hallmarks of effective game systems:
Comprehensible: As a designer, you have to understand your game as a system and the systems within it. Of course, your players have to be able to comprehend it, too. This is why both design documentation (for you) and presenting the game in such a way that players can build a mental model of it are so important.
Consistent: Achterman points out the importance of having “rules and content [that] function the same in all areas of your game.” It can be tempting to add an exception or a special case to fix a problem, but doing so tends to decrease the resilience of the system (which sets up the game for later problems) and makes it more difficult to learn. (This is similar to the discussion in Chapter 3, “Foundations of Games and Game Design,” on elegance.)
Predictable: Game systems should have predictable outputs for given inputs. While making games predictable helps players build mental models of the games, it can also be somewhat at odds with designing systems for emergence. Being predictable should not be taken as meaning that game systems should be obviously or boringly mechanistic. However, neither should your systems produce wildly different results for similar inputs, much less become brittle and break down due to unforeseen circumstances. You should at least be able to know that you have accounted for any edge cases that might hurt a player’s experience or provide them with a gap in the system to exploit to their advantage.
Extensible: Building games systemically typically makes them highly extensible. Rather than depend on custom-created content “set pieces” (e.g., expensive hand-created levels), as much as possible you should create game systems such that content can be reused in new ways or created procedurally. You want to create parts and loops that can be used in multiple ways, not a single-use arc that makes for a complicated rather than complex set of relationships. While in a loop the parts affect each other cyclically, as veteran game designer Daniel Cook said, “An arc is a broken loop that you exit immediately” (Cook 2012). Designing in terms of loops rather than arcs also makes it easier to take a system and add it to a new game or put it in a new context, where it acts as a part in a new larger system. For example, you may decide that you want to add a whole new class of buildings for players to construct; if you have a general “building construction” system in the game, this is much easier to do than if you have to hand-craft another one. By designing game systems carefully, with only the needed parts and sufficient loops between them, you will be able to extend the systems internally or extend their use externally far more easily than if you rely on more static content or fractured, separated systems in the game.
Elegant: As discussed in earlier chapters, elegance is often a hallmark of systems. This quality sums up the ones above. It goes beyond but is related to the quality of consistency discussed above. The following are some examples of elegance:
Creating a diverse space for players to explore based on only a few rules (Again, Go is the archetypal example of this.)
Having systemic rules with few exceptions that are easy to learn, where both predictable and emergent behaviors are possible
Enabling the system to be used within multiple contexts or to have new parts added within it
Tabletop and Digital Games
This book uses examples from both tabletop games—also called analog games, board games, physical games, and so on—and digital games—those played on a computer, console, tablet, or phone. From a game design point of view, there is a great deal of commonality between these types of games, no matter their genre or other differentiating attributes.
There is a great deal to be learned from studying tabletop games, even if you never plan to design one. Designing for situations in which the only “computing power” is in the players’ heads and where all interaction must happen using tokens the players can physically manipulate presents a significant challenge. It constrains what you as a designer can do to bring a game concept to life and highlights the relationships between the game’s tokens and rules, loops, and overall experience. Digital games can hide a lot of game-designer laziness behind flashy graphics and narrative cut-scenes; tabletop games do not have that luxury.
In speaking to university theatre students, actor Terrence Mann said, “Movies make you famous, television will make you rich; but theatre will make you good” (Gilbert 2017). There is an analogy here to game design (not that any particular type of game design will necessarily make you rich or famous): designing tabletop games has the same sort of relationship to designing digital games that acting in theatre does to acting in movies. Like theatre, tabletop games are closer to the audience; you as a game designer can hide less, and must hone your craft in designing for this environment.
This is not to say that all game designers must design board or tabletop games, though it is good practice. But if at times you wonder why so many board games are used as examples when “modern” games are typically played on computer, this is the reason. Tabletop games have undergone every bit as much of a renaissance in the early 21st century as have digital games. As a systemic game designer, you can learn from both, and you may well find that designing tabletop games challenges your skills in ways that designing for games run on the computer does not.
The Process of Designing Games as Systems
Stepping down a bit from the abstract qualities we hope to find in game systems, we can look at the overall design process common to systemic game design (whether tabletop or digital).
This is necessarily an iterative process between designing the parts, the loops, and the whole. At first, this process may be iterative in your head, on a whiteboard, and on scraps of paper and then in documents and spreadsheets. Once the game begins to take shape, the iterative cycle of prototyping and playtesting discussed briefly below (and in more detail in Chapter 12, “Making Your Game Real”) becomes important: it is far better to prototype fast and playtest early than to hope the idea you have in your head will spring forth fully formed like Athena from Zeus’s skull. (They never do.) This process is the game designer’s loop shown in Figure 5.1 (which is the same as Figure 4.3).
){kind=link}
As stated earlier, it is possible to begin at any point in the systemic structure: with parts, loops, or the whole experience—as long as, having started with one, you move to the others so that they mutually support each other. With that reminder, for convenience here we will start with the whole, the architectural and thematic elements, and then move to the functional looping aspects, and finally move to the parts.
)
Figure 5.1 The game designer’s loop enables you to iteratively design and test your designs
The Whole Experience: Thematic Architecture
As discussed in Chapter 3, the high-level design of a game has to do with the player’s overall experience. We can separate this into architectural and thematic elements—the technical aspects of the user experience (how the game looks and feels) and the more ethereal, sometimes tacit qualities that define what the game is about. Understanding the whole of the game answers the question What is the point of the game (or a system within the game)?
As one example, in a recent conversation, Jason VandenBerghe, creative director on the game For Honor, said, “I believe that combat is an art form. The game sprung from that belief” (personal communication, December 2016). His desire was for the player to experience hand-to-hand combat as a lethal, dance-like form of art. While that desire is not enough on its own to support the game design, it is a compelling vision, a star to guide the game’s developers and from which all the interactions and details of the game eventually arise.
Many times, game designers or entire development teams will launch themselves into the game development process without stopping to entirely clarify what the “whole experience” is that they want in their game. Questions of theme and vision seem frivolous; the team wants to get to making the game! However, as you will see in Chapter 11, “Working as a Team,” having a shared, coherent vision of the game your team is making is the single most important indicator of success.
There are multiple aspects of any overarching vision, as discussed in the following sections. These aspects represent and point to more detailed elements that have to be articulated to get an idea of what the game will be.
The Game’s World and History
To begin with, what is the world, and what is the player’s point of view within it? You may be thinking of a gritty, cold-hearted world of spies and double-dealing—but is the player a spy working their way up in this world? A spy-master overseeing and pulling the strings on a sometimes wayward team of spies? Or possibly an old spy coming out of retirement for one last vengeful mission? Each of these paints a different picture and will take your game design in a different direction.
To fill in the world somewhat, what are the major events in its history—those that are applicable to the players? If you’re a storyteller, you may have to resist the urge to write 100 pages of world lore. If you have the time and money, and especially the experience to know what’s useful and what’s not, then you can indulge yourself in this; you will likely add important details to the game world that make it come to life all the more vividly. But if you have any time or budget constraints, or if you’re just starting out, you should avoid the siren song of diving too deeply into the backstory. You need to know what the world is and what it’s about, but to start with, you can do this in a page or two of text. You shouldn’t write any more than you need to support the rest of the design. Later, as the game is beginning to come together, you can flesh out the deep, tragic history of the city where the streets hold a million secrets.
Narrative, Progression, and Key Moments
The game world’s history is its past. Its present and future are contained in the game narrative. Does your game have a predefined story the player has to work within? Are there larger events happening around the player that grow out of the large-scale history but that leave room for the player to make their own decisions? Or is the game’s history a jumping-off point for the player, where what’s past is prologue, and there is little in the way of continuing narrative to guide the player’s actions?
Understanding your game’s world and (some) of its history will also help you begin to define major events that happen in the game, the player’s goals and progression through it, and “key moments”—short moments or stories that you can tell that help communicate meaningful, climactic points for the player.
Art, Monetization, and Other Whole-Experience Concerns
There are a variety of questions to work through at the level of the whole-game experience: Will the game’s art style be 2D or 3D? Painterly, cel-shaded, or super-realistic? How does your choice reflect the game’s heart and theme to the player? Closely aligned with this is the way the player interacts with the game—the user interface and user experience, often referred to as UI/UX. Even monetization design—how your game makes money—is something you have to consider at this stage.
In Chapter 6 we will look in more detail at the process of designing and documenting the gameplay experience as a whole. For now, keep in mind that it doesn’t matter so much whether you start with a high-level, blue-sky creative vision that you then support with underlying loops and parts or whether you arrive here after first nailing down those dynamic and specific aspects; either way, you will iterate back and forth between them as you refine your ideas. What matters is that before you begin developing your game—before you assure yourself that you know what the game is—you have this theme and vision, the whole of the player’s experience, clearly articulated and shared by your team.
Systemic Loops and Creating a Space for Play
Chapters 3 and 4, “Interactivity and Fun,” discuss the game’s loops: the game’s dynamic model of its world, the player’s mental model of the game, and the interactions that happen between the player and the game. Designing and building these loops and the structures that support them is the heart of being what is often loosely referred to as a “systems designer.” In addition to the overview here, this topic is explored in detail in Chapter 7.
In creating a space for the player to explore and inhabit—rather than a singular path for them to follow through the game—you need to define the game’s systems. These systems need to support the theme and desired player experience, and they must work interactively between the game and the player. You need to specify and create (via iterative prototyping and playtesting) the player’s core loops, explicit goals, and the way they progress through the game.
Creating systems like this may be the most difficult part of game design: it requires that you envision the system as it uses the game’s tokens and rules to create an experience that is hard to see clearly in advance. Of course, you don’t have to do this all at once—which is why prototyping and playtesting are so important—but being able to imagine multiple looping systems well enough to record their designs and implement them is nevertheless a daunting task. For example, in many games, the systems controlling resource production, crafting, wealth production, and combat all have their own internal workings, and all interact with each other and the player to create the player’s experience. Getting all these to work on their own and contribute to a systemic whole requires skill, patience, and resilience in the face of repeated attempts when something just doesn’t quite work.
Balancing Game Systems
Part of making game systems is ensuring that all parts defined by the game are used and balanced against each other and that every system in the game has a clear purpose. If you add a quest system to your game and players ignore it, you need to understand why it isn’t contributing to their experience and determine whether to remove it or fix it so that it does. Chapter 9, “Game Balance Methods,” and Chapter 10, “Game Balance Practice,” go into this process in detail.
The Structural Parts: Tokens, Values, and Rules
It may be that you started the game design process with an idea for a fun looping mechanism or interaction. Or maybe you started with the kind of experience and feeling you want the players to have, and so you’re defining the game and interactive loops. Or in some cases you may start with an idea for the building blocks out of which you want to construct your game. In any case, before the game is really a game, you need to situate the game’s functional loops into the context of the whole—the game experience—and also create the structural parts of the game’s systems.
You first read about the tokens, values, and rules in a game in Chapter 3. You will see them again in detail in Chapter 8. For now, in terms of working as a systemic designer, you should understand that the process of nailing down exactly what is going on in a game—getting past the hand-waving descriptive stage and being able to implement the game—is vital. You don’t have a game without it.
This aspect of game design is sometimes called “detailed design,” and it is where the game design becomes entirely specific. Does that sword have a weight of 3 or 4? A cost of 10 or 12? How many types of troops, or horses, or flower petals are there in the game, and what differences do these numbers make to the overall gameplay? Tracking and specifying these structural parts of the game has been called the “spreadsheet-specific” part of game design. This is a crucial part of systemic design; it is in many ways how the game becomes real. Such specific design is needed for balancing the different tokenized parts against each other to make the game a cohesive whole rather than allow it to become separate systems that can fly apart.
The issues you need to think about here are how to specify tokens that represent the objects in the game—the player, other people, nations, creatures, spaceships, or whatever the operative units are within your game—and give each of them sufficient attributes, values, and behaviors to define them. One way to think of this is to answer the question What is the smallest number of attributes, states, and behaviors you can use to support the game’s systems and provide the overall gameplay experience you want?
Related to this are the issues of how to make obvious to the player what the tokens in the game are, what they do, and how the player can affect them. This in turn feeds into the game’s UI/UX—how the board or screen is laid out to present the necessary information about the game to the player. This cannot be specified until you know what the necessary information is. At the same time, approaching this issue by asking what sorts of information you think the player needs to know to play the game can itself help clarify the tokenizing process.
Chapter 8 talks about this process in more detail, including how to create complex objects, game pieces, or tokens by having a small number of general attributes that interact with each other to create their own subsystems within the larger game systems. Chapter 8 also discusses the importance of inter-object behaviors and how to avoid “easy win” or other gameplay-killing tokens in your games.
Revisiting the Systemic Design Process
As a systemic game designer, your loop—the designer’s loop—involves cycling between seeing the game as a whole, as systems, or as individuated parts (see Figure 5.2). You need to be able to see them all at the same time and how they affect each other. You also need to be able to dive into any one in detail, depending on what’s needed by the game design. It’s important that you not focus on any one level to the exclusion of the others; you also don’t want to continue to work ineffectively on any one of them. When you find yourself pushing on one level without any real effect, it can often help to switch and work from the point of view of the other levels to help reveal what you need in another. If you can’t quite get the experience down, explore the tokens and how they work; see how they inform the experience. Or if you have the experience clearly in mind but can’t quite specify the tokens, see what the systems tell you about how those have to work. At the same time, don’t let yourself avoid tokenizing your systems, making sure there are interesting interactions, or ensuring a cohesive theme because one or more of these aren’t in your comfort zone as a game designer. All of these are necessary for any working game, and all are necessary activities for a systemic game designer.
)
Figure 5.2 As a game designer, you need to be able to see the parts, the loops, and the game’s whole experience all at the same time and zoom in on any one of them as needed