Formal Abstract Design Tools

What is a modern computer game made of? It fuses a technical base with a vision for the player's experience. All of the disciplines involved (design, art, audio, levels, code, and so on) work together to achieve this synthesis.

In most disciplines, industry evolution is obvious: The machines we play on are far more powerful, screens have better resolution and more colors, paint and modeling tools are more sophisticated, audio processing is faster, and sound cards are more capable. Technical issues not even in our vocabulary ten years ago are solved and research continues with essentially infinite headroom. The technical base on which games stand (game code and content creation tools) is evolving.

Across all genres and companies, we build on our own and others' past ideas to expand technical limits, learn new techniques and explore possibilities. Ignoring an anomaly or two, no single company or team would be where it is now had it been forced to work in a vacuum.

Design, on the other hand, is the least understood aspect of computer game creation. It actualizes the vision, putting art, code, levels, and sound together into what players experience, minute to minute. Clever code, beautiful art, and stunning levels don't help if they're never encountered. Design tasks determine player goals and pacing. The design is the game; without it you would have a CD full of data, but no experience.

Sadly, design is also the aspect that has had the most trouble evolving. Not enough is done

to build on past discoveries, share concepts behind successes, and apply lessons learned in one domain or genre to another. Within genres (and certainly within specific design teams), particular lines have evolved significantly. But design evolution still lags far behind the evolution of overall game technology.

How Do We Talk About Games?

The primary inhibitor of design evolution is the lack of a common design vocabulary. Most professional disciplines have a fairly evolved language for discussion. Athletes know the language of their sport and of general physical conditioning, engineers know the technical jargon of their field, doctors know Latin names for body parts and how to scribble illegible prescriptions. In contrast, game designers can discuss "fun" or "not fun," but often the analysis stops there. Whether or not a game is fun is a good place to start understanding, but as designers, our job demands we go deeper.

We should be able to play a side-scrolling shooter on a Game Boy, figure out one cool aspect of it, and apply that idea to the 3D simulation we're building. Or take a game we'd love if it weren't for one annoying part, understand why that part is annoying, and make sure we don't make a similar mistake in our own games. If we reach this understanding, evolution of design across all genres will accelerate. But understanding requires that designers be able to communicate precisely and effectively with one another. In short, we need a shared language of game design.

A Language Without Borders

Our industry produces a wide variety of titles across a range of platforms for equally varied audiences. Any language we develop has to acknowledge this breadth and get at the common elements beneath seemingly disparate genres and products. We need to be able to put our lessons, innovations, and mistakes into a form we can all look at, remember, and benefit from.

A design vocabulary would allow us to do just that, as we could talk about the underlying components of a game. Instead of just saying, "That was fun," or "I don't know, that wasn't much fun," we could dissect a game into its components, and attempt to understand how these parts balance and fit together. A precise vocabulary would improve our understanding of and facility with game creation.

This is something we already do naturally with many technical innovations, since they are often much easier to isolate within a product or transfer to another project. A texture mapper or motion capture system is easily encapsulated. When everyone at the office gathers around some newly released game, major technical "evaluation" is done in the first five minutes: "Wow, nice texture mapping," or "Those figures rock" or "Still don't have a sub-pixel accurate mapper? What is their problem?" or "Man, we have to steal that special effect." But when the crowd disperses, few observations have been made as to what sorts of design leaps were in evidence and, more importantly, what worked and what didn't.

Design is hard to point at directly on a screen. Because of this, its evolutionary path is often stagnant. Within a given genre, design evolution often occurs through refinement. This year's real-time strategy (RTS) games clearly built on last year's RTS games. And that will continue, because design vocabulary today is essentially specific to individual games or genres. You can talk about balancing each race's unit costs, or unit count versus power trade-offs. But we would be hard pressed to show many examples of how innovations in RTS games have helped role-playing games (RPGs) get better. In fact, we might have a hard time describing what could be shared.

These concerns lead to the conclusion that a shared design vocabulary could be very useful. The notion of "Formal Abstract Design Tools" (or FADT, as they'll be referred to from here on) is an attempt to create a framework for such a vocabulary and a way of going about the process of building it.

Examining the phrase, we have: "formal," implying precise definition and the ability to explain it to someone else; "abstract," to emphasize the focus on underlying ideas, not specific genre constructs; "design," as in, well, we're designers; and "tools," since they'll form the common vocabulary we want to create.

"Design" and "tools" are both largely self-explanatory. However, some examples may help clarify "formal" and "abstract." For instance, claiming that "cool stuff" qualifies as a FADT violates the need for formality, since "cool" is not a precise word one can explain concretely — various people are likely to interpret it very differently. On the other hand, "player reward" is well defined and explainable, and thus works. Similarly, a "+2 Giant Slaying Sword" in an RPG is not abstract, but rather an element of one particular game. It doesn't qualify as a FADT because it isn't abstract. The general notion that a magic sword is based on — a mechanic for delivering more powerful equipment to the player — is, however, a good example of a FADT, so the idea of a "player power-up curve" might meet the definition above.

Let's Create a Design Vocabulary — What Could Possibly Go Wrong?

Before we start investigating tools in more detail and actually look at examples, some cautionary words. Abstract tools are not bricks to build a game out of. You don't build a house out of tools; you build it with tools. Games are the same way. Having a good "player power-up curve" won't make a game good. FADT are not magic ingredients you add and season to taste. You do not go into a product proposal meeting saying "this game is all about player power-up curves." As a designer, you still have to figure out what is fun, what your game is about, and what vision and goals you bring to it.

But a design vocabulary is our tool kit to pick apart games and take the parts which resonate with us to realize our own game vision, or refine how our own games work. Once you have thought out your design, you can investigate whether a given tool is used by your game already. If it is, are you using it well, or is it extraneous? If it isn't used, should it be, or is the tool not relevant for your game? Not every construction project needs a circular power saw (sadly), and every game doesn't need every tool. Using the right tools will help get the shape you want, the strength you need, and the right style.

Similarly, tools don't always work well together — sometimes they conflict. The goal isn't to always use every tool in every game. You can use an individual tool in different ways, and a given tool might just sit in a toolbox waiting to see if it is needed. You, the designer, wield the tools to make what you want — don't let them run the show.

Tools Would Be Useful — Where Do We Find Them?

So we need a design vocabulary, a set of tools underlying game design practice. There is no correct or official method to identify them. One easy way to start looking is to take a good game and describe concretely some of the things that work well. Then, from concrete examples of real game elements, we can attempt to abstract and formalize a few key aspects and maybe find ourselves a few tools.

There isn't enough space here to exhaustively analyze each tool or game — the goal here is to give an overview of the ideas behind and uses of FADT, not a complete view of everything. With that in mind, we'll start with a quick tour of some games, tools, and ideas. Since we are looking for examples of good game design, we'll start by examining Mario 64. Once we have explored some concrete aspects of the game itself, we'll step back and start looking for things to abstract and formalize that we can apply to other genres and titles.

Mario 64 Game Play

Mario 64 blends (apparent) open-ended exploration with continual and clear direction along most paths. Players always have lots to do but are given a lot of choice about which parts of the world they work on and which extra stars they go for. The game also avoids a lot of the super-linear, what's-on-the-next-screen feel of side-scrolling games and gives players a sense of control. In Mario, players spend most of their time deciding what they want to do next, not trying to get unstuck, or finding something to do.

A major decision made in the design was to have multiple goals in each of the worlds. The first time players arrive in a world, they mostly explore the paths and directions available. Often the first star (typically the easiest to get in each world) has been set up to encourage players to see most of the area. So even while getting that first star, players often see things they know they will need to use in a later trip. They notice inaccessible red coins, hat boxes, strange contraptions, and so on, while they work on the early goals in a world. When they return to that world for later goals, players already know their way around and have in their heads some idea about how their goals might be achieved, since they have already visited the world and seen many of its elements.

Mario's worlds are also fairly consistent and predictable (if at times a bit odd). Players are given a small, simple set of controls, which work at all times. Simple though the controls are, they are very expressive, allowing rich interaction through simple movement and a small selection of jumping moves. The controls always work (in that you can always perform each action) and players know what to expect from them (for example, a triple jump goes a certain distance, a hip drop may defeat opponents). Power-ups are introduced slowly, and are used consistently throughout (for example, metal Mario can always walk under water).

These simple, consistent controls, coupled with the very predictable physics (accurate for a Mario world), allow players to make good guesses about what will happen should they try something. Monsters and environments increase in complexity, but new and special elements are introduced slowly and usually build on an existing interaction principle. This makes game situations very discernable — it's easy for the players to plan for action. If players see a high ledge, a monster across the way, or a chest under water, they can start thinking about how they want to approach it.

This allows players to engage in a pretty sophisticated planning process. They have been presented (usually implicitly) with knowledge of how the world works, how they can move and interact with it, and what obstacle they must overcome. Then, often subconsciously, they evolve a plan for getting to where they want to go. While playing, players make thousands of these little plans, some of which work and some of which don't. The key is that when the plan doesn't succeed, players understand why. The world is so consistent that it's immediately obvious why a plan didn't work. This chasm requires a triple jump, not a standing jump; maybe there was more ice than the player thought; maybe the monster moves just a bit too fast. But players get to make a plan, try it out, and see the results as the game reacts. And since that reaction made sense, they can, if needed, make another plan using the information learned during the first attempt.

This involves players in the game, since they have some control over what they want to do and how they want to do it. Players rarely feel cheated, or like they wanted to try something the game didn't support. By offering a very limited set of actions, but supporting them completely, the world is made real for players. No one who plays Mario complains that they want to hollow out a cave and make a fire and cook fish, but cannot. The world is very simple and consistent. If something exists in the world, you can use it.

Great! But I'm Not Writing Mario 64. I Mean, It's Already Been Written.

So Mario has some cool game design decisions. In the context of Mario itself, we have examined briefly how they work together, what impact they have on the players' experience and how these design decisions, in general, push the player toward deeper involvement in the game world. But if you're developing a car-racing game, you can't just add a hip-drop and hope it will work as well as it does in Mario. So, it's time to start abstracting out some tools and defining them well enough to apply them to other games.

Looking back at the Mario example, what tools can we derive from these specific observations? First, we see there are many ways in which players are encouraged to form their own goals and act on them. The key is that players know what to expect from the world and thus are made to feel in control of the situation. Goals and control can be provided and created at multiple scales, from quick, low-level goals such as "get over the bridge in front of you" to long-term, higher-level goals such as "get all the red coins in the world." Often players work on several goals, at different levels, and on different time scales.

This process of accumulating goals, understanding the world, making a plan and then acting on it, is a powerful means to get the player invested and involved. We'll call this "intention," as it is, in essence, allowing and encouraging players to do things intentionally. Intention can operate at each level, from a quick plan to cross a river to a multi-step plan to solve a huge mystery. This is our first FADT.

INTENTION: Making an implementable plan of one's own creation in response to the current situation in the game world and one's understanding of the game play options.

The simplicity and solidity of Mario's world makes players feel more connected to, or responsible for, their actions. In particular, when players attempt to do something and it goes wrong, they are likely to realize why it went wrong. This leads to another tool, "perceivable consequence." The key is that not only did the game react to the player; its reaction was also apparent. When I make the jump, it either works or it doesn't. Mario uses this tool extensively at a low level (crossing a river, avoiding a rolling boulder, and so on). Any action you undertake results in direct, visible feedback.

PERCEIVABLE CONSEQUENCE: A clear reaction from the game world to the action of the player.

We have examined the ideas behind some parts of Mario and abstracted out two potential design tools. Note also how Mario uses these tools in conjunction; as players create and undertake a plan, they then see the results of the plan, and know (or can intuit) why these results occurred. The elements discussed are certainly not the only cool parts of Mario, nor the only tools that Mario uses, but hopefully this discussion gives an idea of how the process works. Later, we'll return to examine how multiple tools work with each other. But first, let's see if intention and perceivable consequence can be applied to some other games.

Same Tools, Different Games

Perceived consequence is a tool often used in RPGs, usually with plot or character development. A plot event will happen, in which the game (through characters or narration) essentially comes out and says, "Because of X, Y has happened." This is clearly a fairly pure form of perceived consequence.

Often, however, RPGs are less direct about consequence. For example, the player may decide to stay the night at an inn, and the next morning he may be ambushed. Now, it may be that the designers built this in the code or design of the game. ("We don't want people staying in town too much, so if they start staying at the inn too often, let's ambush them.") However, that causality is not perceivable by the player. While it may be an actual consequence, to the player it appears random.

There are also cases where the consequence is perceivable, but something still seems wrong. Perhaps there's a fork in the road, where players must choose a direction. As a player travels down the chosen path, an encounter with bandits occurs, and the bandit leader proclaims, "You have entered the valley of my people; face my wrath." This is clearly a consequence, but not of a decision players thought they were making. Players bemoan situations where they are forced into a consequence by the designers, where they are going along playing a game and suddenly are told, "You had no way of knowing, but doing thing X results in horrible thing Z."

Here we can look at how Mario uses the perceivable consequence tool in order to gain some insight into how to make it work for us without frustrating players. In Mario, consequences are usually the direct result of a player decision. Rarely do players following a path through the game suddenly find themselves in a situation where the game basically says, "Ha ha, you had no way of knowing, but you should have gone left," or "Dead end! Now you get crushed." Instead, they see they can try a dangerous jump or a long roundabout path or maybe a fight. And if it goes wrong, they understand why.

So it should come as no surprise that, in RPGs, often the best uses of consequence come when they are attached to intentional actions. Being given a real choice to do the evil wizard's bidding or resist and face the consequences has both intention and consequence. And when these tools work together, players are left feeling in control and responsible for whatever happens. However, being told "Now you must do the evil wizard's bidding" by the designer, and then being told, "As you did the evil wizard's bidding, the following horrible consequences have occurred," is far less involving for the player. So while both examples literally have perceived consequence, they don't cause the same reactions in the player.

Same Game, Different Tool

Of course, there are reasons why RPGs often force players into a given situation, even at the cost of removing some of the player's feeling of control. The usual reason is to give the designer greater control of the narrative flow of the game. It is clear that "story" is another abstract tool, used in various ways across all game styles in our industry. But it's important to remember that, although books tell stories, when we say "story" is an abstract tool in game design, we don't necessarily mean expository, pre-written text. In our field, "story" really refers to any narrative thread that is continued throughout the game.

The most obvious uses of story in computer and video games can be found in adventure-game plot lines. In this game category, the story has been written in advance by designers, and players have it revealed to them through interactions with characters, objects, and the world. While we often try to set up things to give players a sense of control, all players end up with the same plot.

But story comes into play in NBA Live, too. There, the story is what happens in the game. Maybe it ends up in overtime for a last-second three-pointer by a star player who hasn't been hitting his shots; maybe it is a total blowout from the beginning and at the end the user gets to put in the benchwarmers for their moment of glory. In either case, the player's actions during play created the story. Clearly, the story in basketball is less involved than that of most RPGs, but on the other hand it is a story that is the player's — not the designer's — to control. And as franchise and season modes are added to sports games and team rivalries and multi-game struggles begin, story takes on a larger role in such games.

STORY: The narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward toward completion of the game.

Using Multiple Tools: Cooperation, Conflict, Confusion

Adventure games often have little intention or perceivable consequence. Players know they will have to go everywhere, pick up everything, talk to everyone, use each thing on each other thing and basically figure out what the designer intended. At the lowest level, there is intention along the lines of, "I bet this object is the one I need," and just enough consequence that players can say, "That worked — the plot is advancing." But there is little overall creation of goals and expression of desires by players. While the player is doing things, it's usually obvious that only a few possibilities (the ones the designers pre-built) work, and that all players must do one of these or fail.

But as we've also seen, this loss of some consequence and most intention comes with a major gain in story. By taking control away from the player in some spaces, the designer is much freer to craft a world full of tuned-up moments in which the designer scripts exactly what will happen. This allows moments that are very powerful for players (moments that often feel as involving as player-directed actions, if not more so). So here is a space where tools conflict, where intention and story are at odds — the more we as designers want to cause particular situations, the less control we can afford to give players.

Once again, tools must be chosen to fit the task. Being aware of what game you want to develop allows you to pick the tools you want and suggests how to use them. You cannot simply start adding more of each tool and expect the game to work.

Concrete Cases of Multiple Tool Use

An interesting variant of the intention versus story conflict is found in traditional SquareSoft console RPGs (for example, the Final Fantasy series and ChronoTrigger). These games essentially give each tool its own domain in the game. The plot is usually linear, with maybe a few inconsequential branches. However, character and combat statistics are free-form, complex systems, which have a variety of items, statistics, and combo effects that are under player control. Players must learn about these systems and then manage the items and party members to create and evolve their party.

During exploration of the game world, the plot reveals itself to the player. The designer creates cool moments which are shown to players, in the game, but are not player-driven. Despite little intention in terms of the plot, players are given some control of the pacing as they explore. While exploring, however, players find objects and characters. These discoveries impact the combat aspects of the game. Combat in the game is entirely under the players' control, as they decide what each character does, which abilities and items to use, and handle other details. Thus, players explore the story while combat contains intention and consequence.

SquareSoft games are, essentially, storybooks. But to turn the page, you have to win in combat. And to win in combat, you have to use the characters and items that come up in the story. So the consequences of the story, while completely preset and identical for all players, are presented (usually) right after a very intentional combat sequence. The plot forces you to go and fight your former ally, but you are in complete control of the fight itself.

Rather than trying to use all three tools at once, the designers use intention and consequence in the combat system, and story and consequence in the actual unfolding of the story. So, the designers get to use all the tools they want and tie the usage together in the game. However, they make sure that tools can be strongly utilized when called on. They don't try to put them in places where it would be hard to make them work effectively.

With a bit of a stretch, one can say that sports and fighting games actually mix all three of the tools into one. The story in a game of NHL 99 is the scoring, the missed checks or the penalty shot. While this story is somewhat basic, it's completely owned by the player. Each player makes his or her own decision to go for the win by pulling the goalie, or not. And, most importantly, the decision and resulting action either works or does not, driving the game to a player-driven conclusion. Unlike adventure games, there is no trying to guess what the designer had in mind, no saving and loading the game 20 times until you click on the right object. You go in, you play the game, and it ends.

Similarly, in a fighting game, every controller action is completely consistent and visually represented by the character on-screen. In Tekken, when Eddy Gordo does a cartwheel kick, you know what you're going to get. As the player learns moves, this consistency allows planning — intention — and the reliability of the world's reactions makes for perceived consequence. If I watch someone play, I can see how and why they're better than I am, but all players begin the game on equal footing. The learning curve is in figuring out the controls and actions (in that it's player-learning alone that determines skill and ability in the game). The fact that actions have complete intention and consequence allows this.

In sports games, you direct players, select an action, and watch something happen in response to that action, which gives you feedback about what you tried to do. The player does direct the action — a cross-check missed, a slap shot deflected, a pass gone wrong — but one level removed. While watching the action on screen, one sees everything that happens, but can't be sure exactly why it happened. This is because the basis of most sports games is a statistical layer, and thus the same actions with the controller can lead to different results. When you combine the different player ratings with the die-rolling going on behind the scenes, the probabilities make sense, but may not be apparent to the player. The intention is still there, but the perceived consequence is much less immediate. This removal of direct control (and the entire issue of directing action) through a statistical layer, which the player can intuit but not directly see, is often present in RPG combat. Thus, in Tekken, I can't say, "Man, bad luck, if only I'd rolled better," or "Yeah, now that I'm a tenth-level ninja, I can do that move," but in NBA Live or an RPG, I often do.

Tool-Based Analysis

A fighter has a simple story ("I had just a sliver of health left, but I feinted a kick and then did my triple punch combo — barely finished him off"), but it's the player's story. There is no, "Man, I can't believe I missed that shot," or "Why did I go and do that?" or "How come my check didn't work?" A simple story, backed up by complete intention in a game that provides clear consequences, makes a very powerful experience for the player. So, both fighting games and, with some obfuscation of consequence, sports games attempt to fuse intention and consequence and from that allow the players' actions tell a story. The complete control provided by a fighter may make the game more real to the player, but the larger scale of a sports game may provide more sense of story. Or, it may be that the direct control of the fighter makes for a more personal story, and the large scale of a sports game makes for a more epic story. In either case, neither the fighter approach nor the sports simulation approach to story and intention is right or wrong. Each elicits a different set of reactions from the player. As a designer, you must understand the ramifications of tool usage if you're going to create the experience you intend.

Ahhh, So What?

Tools as a vocabulary for analysis present a way to focus on what player experience the designer wishes to create. In this high-level introduction to FADT, I have focused on intention and perceived consequence, with less attention to story. (And what story is mentioned is slanted toward the player-driven.) This is not because these are the only tools or even the best tools. However, as we start to analyze our designs and the player experience provided by the tools we use, it's vital we try to understand what our medium is good at.

Games are not books; games are not movies. In those media, the tools used (camera placement, cuts, zooms, music cues, switching narrators, and so on) are used to manipulate viewers or readers, to make them feel or react exactly the way the director or author wants them to. I believe the challenge and promise of computer game design is that our most important tools are the ones that involve and empower players to make their own decisions. That is something that allows each player to explore him or herself, which is something our medium is uniquely equipped to do.

So I look to tools to help me understand that aspect of game design and to maximize the player's feeling of involvement and self. But that's because that's the kind of game I want to make. Each designer must choose the game he or she wants to create and use the tools available to craft that experience.

Hopefully, I have presented enough examples of the tools and tool-based analysis process to provide a useful overview. Of course, I only mentioned a few tools, but, as stated previously, this article was not intended to be exhaustive or complete. It's a justification for us to begin to put together a vocabulary. For this to become genuinely useful, we must engage in discussion and analysis to get a set of tools we like and then refine those tools until they are well understood. With that, we can start to do more careful analysis of the stuff we like and don't like in current games and work to improve future ones. And we can talk to each other more about design innovations, not just technical ones.

We will have to invest a lot of time if we're to generate a full list of tools we've used (or should use) in our work. There are resource economies, learning, player power-up curves, punishment/reward and many others to consider. And each tool could have an article written just about it — how it has been used over time, what games use it particularly well or poorly, and different aspects of it. Similarly, it would be great to take a game such as Mario or Warcraft and really deconstruct it, perform as complete an analysis as possible to see if that would be useful. This article is simply a primer to scratch the surface and give examples of this sort of process.

I make no assumption that tools are necessarily useful. Many people may find them overly pedantic. And there's clearly a danger of people starting to use words such as "intention" and "consequence" in the same way that terms and phrases such as "non-linear," "endless variety," or "hundreds of hours of game play" are used meaninglessly. Not surprisingly, that's not the intent.

FADT offers a potential framework for moving the design discussion forward — no more, no less. Although it's no magic bullet, the hope is for this framework to be broadly useful and allow collaborative analysis and refinement of the game design practice, leading to better designs, more interesting products, and satisfied players. If they're not the right framework, we should figure out why and determine what is the right framework. And then we'll work to evolve and develop it together.

Doug Church values beta testers heavily. After a beta test of this article, he learned half the testers found the first two pages slow reading. If you're in that half, skip to the third page, read to the end, then read the intro. Hey, it's an interactive, multipath article.