Realism from Reduction: Successful Abstraction in Game Design

In the world of game design, the idea of abstraction tends to be misunderstood, conflated with a genre/categorization, viewed as a pejorative, or some combination of the three. The truth is, abstraction in game design is relatively easy to understand, when viewed with the proper mind frame; abstraction and the genre/categorization of games called "abstract" are mutually exclusive; and by no means is abstraction a negative process/result. By gaining clarity and digging deeper into the idea of abstraction, we discover one of the most powerful tools for use in crafting a game design that is successfully both more immersive and more engaging.

Understanding Abstraction

For point of reference, let us consider a couple of accepted general definitions of the concept, "abstraction":

In game design, the process of abstraction leverages both of the above concepts—where the latter concept is an empirical act in service of accomplishing the former concept. Specifically, we take away (or condense together) rules/mechanisms in effort to boil a design down to its most poignant expression of a real world idea or experience. This is where a lot of designers get tripped up—I have discussed this topic with many people, and it is not uncommon to learn that someone either confuses abstraction with the process of removing dressing (graphics and other visceral elements), or removing simulation elements—when, in fact, it is neither. Abstraction is not an effort to remove luster and realism, or a consequence of doing so. In fact, proper abstraction serves to add more realism to a game design. "Whaaat?" Yes, that is correct: Successful abstraction increases realism in a game design.

Inviting Immersion

Let us consider what is the "most poignant expression" of a real world idea/experience. In general, poignancy—the state of being strongly mentally appealing or moving the emotions—results from an experience fully captivating, immersing, our thought and emotional processes. Following this line of reasoning, we come to the understanding that the most poignant expression of a such a model is that which sees players fully "believing in" the model, becoming convinced and immersed in targeted decision making, abandoning their emotions to the narrative being woven all around them. Whether or not a game design achieves an experience such as this is fully under a designer's control—a designer must invite immersion in order for immersion to set in.

One of the principle actions a designer can take to "invite immersion" is removing impediments to clear understanding of, and effortless decision making within, a model—that is, to employ abstraction with a singular aim. We take away/condense rules, portions of rules, mechanisms, and portions of mechanisms that cause the player consternation, or require the player to engage a part of their brain not dedicated to decision making—something such as checking a rule book, asking another player about a rule, becoming fatigued by process, or even having to think about a rule as a game rule. In our efforts to accomplish this goal, however, we are specifically careful to ensure that we do not strip away expression of the ideas being modeled—we are not removing ideas, we are removing impediments to consuming ideas. By removing such impediments, while maintaining expression of the ideas, we increase the potential for the player believing in the model—that is, finding the model to be "realistic" and immersive.

A Case Study

Consider an example from one of my own game design's: Warline's model for terrain, and interactions with terrain, went from a more cumbersome simulation to an elegant and believable set of systems, through the effectiveness of abstraction. (I am choosing to dissect the use of abstraction in a game design of my own, since it is impossible for me to know exactly how another designer reasoned through the process of abstraction within any of her own game designs.) For context, my primary design goal for Warline is to offer players tools for coming to understand, and to fully explore the Maneuver Warfare Theory argument. Maneuver Warfare (as executed according to the Theory) requires intricately coordinated interaction among space, time, resources, actors, and geography. Failing to believably express any one of those models would result in failure to accomplish my goal: Players would not have all of the tools necessary for understanding and exploring the argument—any conclusion they might come to would be falsely informed, and therefore not hold much weight.

The terrain (geography) component of the Maneuver Warfare Theory macro-model was particularly tricky to nail. According to the Theory, movement in relation to the opposition has dramatic effects on the progression of, and concurrent/subsequent decisions within, battle. Consequently, utilization of terrain to manipulate the opposition's movement is also a critical component of decision making. Moreover, directly affecting/transforming terrain is an additional key tactic for influencing movement on both sides. I needed the game to express each of these weighty ideas. But, that is a lot of complex (and complicated in some aspects) dynamics to map to a single systems set.

In beginning to commit these ideas to paper and prototype, I decided to take the "kitchen sink" approach and see what sort of foundation that would give me to work with. For terrain, the primary mechanisms that were initially planned out were:

Mechanisms B and C are two that caused me some consternation during the first half of development. Both mechanisms were easy to implement after I had locked down the system for expressing energy exhaustion: Marching into a terrain costs some number of energy, while marching out of the terrain costs some other number of energy. These mechanisms were communicated simply by two numbers boldly displayed on a terrain—easy to read, easy to understand. This all felt pretty cogent to play, and brought some interesting life to the battlefield. However, the two separate rules prompted some amount of mental stress in players trying to parse the battlefield, understand the time/space relationship between actors, and make an informed, confident decision. It was frustrating to watch people squirm at times, or check and recheck the two energy costs for multiple terrains. It bothered me to hear people either asking, "What is the difference between these numbers, again?" or stating with a defeated air, "Awe, damn, I forgot that the terrain costs more to march out of." While these occurrences were infrequent enough, they did crop up—and when they did, they were immersion-breaking. The terrain mechanisms were not inviting immersion, even though they were a quite realistic expression of an important idea—at times, players were finding themselves more involved in operating a game than in commanding and exploring the Maneuver Warfare argument.

Abstraction != Streamlining

Before continuing into discussion of my solution to this problem, I would like to build a perspective backbone. There are two possible manners in which a problem similar to that in question can be solved: 1) through the use of abstraction, or 2) by employing streamlining. It is very important to understand that abstraction and streamlining are not the same thing—and if you take away anything from this article, I hope that this concept is the one that sticks most, because it is a keystone understanding in learning to successfully wield abstraction. While abstraction is the action of reduction/consolidation with purpose to enhance expression and poignancy; streamlining is, differently, reduction and consolidation purely to enhance usability and/or accessibility. Streamlining does not care if expression is lost as a consequence: All that matters is that the user experience is smoothed out and simplified.

I could have streamlined Warline's terrain system by, for example, reducing the system down to only two types of terrain—flatland and rugged—done away altogether with the rule for marching out of the terrain, and assigned each terrain one of only two energy costs to march into: one energy for flatland and two (or perhaps three, for more palpable contrast) energy for rugged terrain marching. In this streamlined incarnation, the system would still prompt plenty of engaging dynamics and be catalyst to interesting decision making. The system would, by nature, be more accessible and relatively less complicated. However, the system would lack the texture, nuance, and credibility that arises as a product of expressing more varied terrain, mapped closer to real world geographical concepts and interactions. Streamlining would have resulted in failure to achieve my design goal: Players would lack the necessary tools for exploring the Theory and argument.

I instead chose abstraction as the solution. I consolidated the march into and march out of terrain rules into a single mechanism that still expressed both ideas. By collapsing to a single cost that acts somewhat like the average of the two energy costs, the expression for both can still be felt, and this expression is quite realistic. Both efforts must still be considered when planning a maneuver. Additionally, this solution helped maintain the higher resolution necessary for expressing the benefits and challenges of a greater variety of geography (hills, mountains, valleys, marshland, and more). Most importantly, the solution further supported a simple user interface: Gone were two numbers on a terrain zone, replaced with a single icon that is easy to read and interpret at a glance—that is, the impediment of understanding terrain marching costs was entirely removed, allowing players to focus purely on decision making, and to become swept away in the realism of the geography.

Abstraction != Abstract Game

Before wrapping up, I want to touch on a matter that is important to understand, in order to fully grasp how one might successfully apply abstraction in a game design: The process of abstraction is not a tool for use in designing an "abstract game" (as a genre categorization). An abstract game starts and ends as an expression of a mathematical model (Chess or Go), not an expression of a real-world idea or experience—regardless of how much dressing is added to it (7 Wonders). There is no realism to retain or poignancy to strive for when designing an abstract game—streamlining is the only of the two tools one needs to accomplish the goal of expressing the mathematical model in the most convenient and smoothest manner possible. I have seen a number of designers balk when I mention that abstraction might be of help to them in solving some problem, because these designers are revolted by the idea of creating an abstract game. But, do not worry, folks, because by successfully employing abstraction, you will not end up with an abstract game—you will end up with a game that is more immersive and realistic than it otherwise could ever have become!

Of the many game types I frequently play, wargames and economics game designs seem to have had to go through the process of abstraction more than most others—since these games model real world historical or practical experiences. Games such as Twilight Struggle and Brass are highly poignant, while still being relatively uncomplicated. I can imagine the designers had a challenging, yet satisfactorily rewarding time finalizing these game designs and achieving the results that they have. Thank you, abstraction.