Something that has been missing from this blog is how players will experience playing your systemic games. What the inputs and outputs represent and what kind of game they help make. So that’s what this post is about.

Also, please, if I’m wrong about something or you want to book a talk or just chat about systemic design, don’t hesitate to e-mail me at annander@gmail.com.

Inputs, Outputs, and Feedback

A system is defined by inputs and outputs. What will be discussed in this post is what these inputs and outputs can be. There’s also a third layer, player feedback, that will be kept for a future post.

The five nodes illustrated below can be used to represent most systems. If you want a more in-depth explanation, I highly recommend that you get the book Advanced Game Design A Systems Approach, by Michael Sellers, or that you play around with Machinations.io.

These five nodes are used in all of the examples in this post to illustrate how different types of inputs and outputs can be represented. The focus is on what the player is contributing to the system. Nodes where the player is involved use a dashed green outline instead of a solid black outline.

Accumulation

Many game systems are built around the concept of accumulation. You collect things or points and you push towards higher and higher tiers of something. This has been discussed before as the subject of gamification. But accumulation is more than just the slow rise of a progress bar. Where it gets interesting is what you decide to award points for and how fast.

Read the linked article if you want more on this subject, however. It’s a good illustration of a simple system, but it’s not terribly hard to design.

Modular Functions

Modular approaches are likely the most common way to implement systemics, from Sim City in the late 1980s onwards to Factorio in the 2010s. Whether you think of the state, component, or decorator patterns, there are many good programmatic ways to separate logic into modules, and to then allow the modules to do their thing individually while contributing to a more complex behavior. In fact, this blog has covered modular systemic guns in the past (it remains one of the most viewed posts).

In Bad Piggies, for example, you are given a grid where you can freely place the vehicle parts you have access to. In the early game, these are simple. Boxes to build the frame, wheels that will roll against solid ground, and things like the bellows in the screenshot below, that will give you a slight push if you tap it during play.

The goal of the game is to get the little green piggie to the goal flag. You’re free to set the components any way you want, as long as you include the little piggie, and the game provides this as a sort of puzzle for you to solve.

Many levels will also have bonus stars or different styles of pickups or environment dangers (like explosives) that will affect the behavior of your vehicle.

What’s interesting is that the behavior of each individual part is very specific. A wheel will roll. A frame will hold things together. Bellows provide a small amount of force in the opposite direction of the nozzle when you tap it. As a developer, this is a big strength, because you can work out how each part functions in isolation and then let the parts interact to produce the vehicle.

We get something like the following as the systemic representation of Bad Piggies. The player is responsible mostly for putting the different vehicle parts together, but also provides some measure of realtime input for parts like the bellows.

We could go into more detail of course, and look at each part as a separate system. The bellows has a position within the vehicle and it has a nozzle direction where it will apply its force, for example. It takes player input and generates force output. This is certainly an exercise that may be more useful if you are documenting a full game, for your own benefit, but let’s keep it at this high level in this post.

In the later game, there are springs, fans, engines, propellers, explosives, and many other vehicle parts that each provide a specific effect. The strength of this type of approach is that you can design each module separately and the design becomes incredibly scalable as a result. You can go with just the minimum parts needed to make vehicles, or you can invent hundreds of different parts with dynamic effects, all using the same setup but making new types of vehicles possible.

Roles

Something related to the modular approach is to give roles to whole objects. This is what Lemmings does with its skills. In Lemmings, the goal is to get as many of your titular lemmings to the level’s exit as you can. The more you get to the exit, the higher your score.

Unfortunately, the average lemming is only walking mindlessly forward and won’t make any decisions on its own. You must instead assign skills to lemmings that change their behavior in order for you to redirect the tide of suicidal rodents towards the exit.

For this purpose, at the bottom of the screen you see a number of different skills that the lemmings can be given. This is the primary resource you have available. In the first level, there’s really just one of them, and that’s the Digger. The game will later expand to include a whole range of skills that must be used in combination if you want to successfully lead your lemmings through the increasingly tricky levels.

Once a lemming is given a skill it will keep repeating it with the same singular focus as the other lemmings. If the skill has a completion state, such as falling through the finished downward tunnel of the Digger, it will revert back to its skilless form and you need to spend another Digger resource if you need to.

The levels in Lemmings become increasingly hard and you must be careful about how you use the resources you have. The fewer the better, and the more lemmings you can bring to the end without having them fall into an abyss, burn, get crushed, etc., the better!

Illustrated as a system (below) you will see that there’s not that much the player is taking part in. Rather, the player is assigning skills (“roles”) based on the movement of the lemmings as a group and the context of the level played.

Item Interaction

A popular intent-based dynamic is how resource collection items are handled in many survival games. If your goal is to build a house, for example, you may have to go through a chain of items that represent different stages in an upgrade process before you can finally build the wall you wanted. In many ways, it’s functionally the same as accumulation (above), but it’s representing each stage with items and equipment instead of points and progress bars. Each stage is usually connected to diminishing returns, as well, where you may first need just a few resources and will then gradually need more and more.

In Conan Exiles, for example, you need a Construction Hammer to be able to build the pieces of your house. It requires accumulation of XP before you can build this hammer, but let’s put that to the side for a moment. Accumulation is a comparatively simple system. Instead, let’s look at the crafting.

To get Wood, you need to first have a Stone Hatchet. Crafting this requires Stone and Branches, both of which you can find lying on the ground:

Once you have the required resources, you can then craft the hatchet through the game’s crafting menu:

You also need Twine to make the Construction Hammer, and Twine must also be crafted. In this case, you need only one resource: Plant Fiber. You can collect this from bushes that can be found in the game world. Once you have enough (3), you can craft Twine as well.

If we simplify this into a system and highlight the parts where the player interacts with the system, we get something like the following diagram. Note that the consistent thing with all systems we’re looking at is that the Sinks make sure that you always lose more than you gain. This is often what we talk about when we talk about “engagement mechanics” in game design: things that keep the player occupied.

Once you have the axe, you can partake in the next step of the system, which is the collection of Wood. You can find this by chopping down trees, and once you have enough Wood (20) combined with enough Twine (5), you are ready to craft your Construction Hammer.

Of course, there are progress bars at each crafting stage as well, and what you will immediately realize once you want to build your house is that you’ll need quite a lot of stone to build the parts. It’s like the classic hill climber illustration, where you crest the first hill only to find a taller hill behind it. This means that Time is realistically the most restricted of all the resources you are working with, and it’s incidentally a resource we sometimes forget to take into account as game designers because while we develop our games it’s not as transparent as the others.

Player Interaction

Something that the Ultima games explored in the early 90s was the use of in-world objects as representations of actions. Below is a series of images from Ultima VII: The Black Gate, where the Avatar (the game’s protagonist) is going through the process of baking bread.

This isn’t a realistic representation of the process of baking bread, by a longshot, but it’s close enough that it feels realistic. You need to go through the motions one by one and you need access to the right equipment and resources.

In systemic terms, its stocks are containers in the game world, its sources are ingredients gained from those stocks, and its converters are interactive objects also represented in the game world. This same way of representing systems through direct interaction is quite common in Roblox experiences today. Good game design lives on!

Some games will also have failure states, such as a risk that you burn the bread if you don’t take it out of the oven quickly enough and you get a “charred bread” item instead of the loaf you really wanted. The key thing is that the systemic transitions are player actions. You need to interact directly with the flour sack to put flour on the table. This time around, Time also comes from its own functionally infinite Stock. This is an important input for many games, because it’s one of those numbers you have a decent amount of control over as a designer. Increasing or decreasing how much time is needed to reach certain thresholds is a very important lever.

If we boil the baking of bread down into nodes, we get something like this:

Build Min-Maxing

Some games are played as much via spreadsheet functions as within the game itself. The system interaction in such a game is often called “min-maxing” because you’re minimizing the bad and maximizing the good with the intent of providing the best possible outcome from a given set of numbers. Causing highest possible amount of damage, for example.

The example here will be from Diablo III. One key element to how you plan a build in this game is the item sets. Each set provides a specific bonus dependent on how many of the set items you manage to equip.

Below is the full set bonus provided by the Wizard set called “Delsere’s Magnum Opus:”

There’s a lot happening here, but we can quickly tell that Slow Time is an important feature. This is one of the defensive spells you have access to as a wizard. So with this build, some extra items can also be equipped to synergize with this spell:

Crown of the Primus makes it so that Slow Time gains all of the different rune effects that can be customized, with one exception, and also that there’s a constant Slow Time effect centered on your character. Gesture of Orpheus makes it so you can have more Slow Time bubbles active at the same time, by decreasing the cooldown of the effect itself.

The next one is a bit different, but ties into the last power of the item set. It’s an off-hand item held by the wizard and increases damage of the Arcane Orb spell quite considerably:

There are more items in the complete build as well, but you can see the theme by now: equip a set and then try to figure out which other items that enhance the set’s features.

As always when it comes down to numbers, the results can be somewhat hilarious. Mind you that this build was also limited to what was available at the time the screenshots were taken. There are builds that are far more optimized than this example. There are also nuances lost here. For one thing, all of the blue text in the screenshots vary between “drops” of the same item, motivating you to keep playing to get better versions of the items in your build. (In other words, Time rears its head once more.)

You can set things up to deal a lot of damage by combining the right items. But there are also some interesting effects on how you play. Teleport synergizes well with the set items, since it can be used much faster between Slow Time bubbles. This implies that you should be flitting back and forth between bubbles and dealing damage to enemies caught inside them or near them.

As a player, your role is to combine the right items at the build stage, and then play to maximize their return. You interact with the system by selecting items in the inventory and by playing the game correctly based on the items you selected.

Conclusions

The reason I wrote this post was the realization that the player’s part in a system isn’t always obvious. It turned out to be a useful experiment, and I am now trying to use these simplified graphs as reference points for other projects.

They’re not exhaustive analyses, by far, but hopefully they can provide some food for thought.

Note: this post has been revisited and expanded a few times, going from four scales to six to provide a more holistic set of scales.

A big part of what makes systemic design work is your own design mindset. The relationship you imagine between yourself as the designer and the player who will be playing your game. I’ve talked about this before, in the third of the immersive simulation posts, and thought it’d be good to expand on it a little bit.

Imagine a scale between authorship and emergence. As an author-designer, you have a specific thing in mind, and anything that risks deviating from this picture in your head must be removed or restricted. As an emergence designer, you look at your game as objects, states, and rules—the things I keep rambling about in this blog—and it’s up to the players to discover what the tools you’ve made for them can accomplish.

This is simple enough to wrap your head around, but it’s also not very helpful. Few games fit squarely into one or the other. Instead, we can look at it as six scales and a master scale. These are what I will present in this post.

As always, if you disagree, have opinions, or want to contact me for other reasons, you can do so by commenting or via annander@gmail.com.

Core-based vs Exception-based

Many argue whether game design should start from theme or from mechanics. But you can argue just as much about the prevalence of a core loop versus an exception-based design.

Core-based

There’s something cynical about the boiling down of game design into a “core loop.” But it’s also incredibly useful. It may have been the misrepresentation of a quote by Halo 2 designer Jaime Griesemer that led to the prevalence of the “core loop” in modern game design.

“In Halo 1,” he said in the Halo 2 behind the scenes video, “there was maybe 30 seconds of fun that happened over and over and over and over again. And so, if you can get 30 seconds of fun, you can pretty much stretch that out to be an entire game.”

What he really meant was more nuanced than this. “[T]he worst part is, everyone uses it to mean exactly the opposite of what I meant when I said it! […] There was a whole second half of the quote […] where I talked about taking that 30 seconds of fun and playing it in different environments, with different weapons, different vehicles, against different enemies, against different combinations of enemies, sometimes against enemies that are fighting each other.”

This longer quote is a perfect distillation of a core-based game. You have a strong functional core—usually made with features rather than systems—and you repeat this core in different contexts throughout your game. It’s carefully paced, impeccably directed, and focused on its strengths.

Exception-based

Most exception-based designs still rely on a core of sorts, but it tends to be much smaller and more consistent. The key elements that form the game come from exceptions to the core.

Good examples of exception-based designs are Metroidvania games, where each ability adds a unique new touch to the gameplay; card games, where each card provides an exception in its own right; and survival games, where the things you can craft and the objects you can collect generate a panoply of interacting exceptions.

In the words of Magic: The Gathering design veteran Mark Rosewater, “What we’re trying to do is give our players a whole bunch of tools that they then can explore and do things with. It’s not our job to find the solutions. It’s our job to make the tools that they get to find them with.” Designers make the exceptions—players find out what they’re for.

Exception-based games may break down because the players find dominant strategies or ways to abuse certain exceptions. But if you are a true believer, this lack of guardrails can actually be the perfect expression of emergence. As with the developers of Slay the Spire, who allow players to use the most powerful combinations of rules exceptions when they come up so they can have fun while breaking the game. It happens rarely enough that it’s a fun exception to the game’s overall style of play.

Direction vs Agency

Whether you lean more towards a predefined core feature set or a more systemic set of exceptions, another thing you need to consider is direction versus agency.

Direction

A game that is closely directed will always play out the same. It may provide the illusion of choice, or even ask the player to make active tradeoffs, but all of it is an illusion. Smoke and mirrors. You are not going to save the character that dies a tragic death, nor are you going to defeat the enemy that will come back in a bossfight later.

Direction can provide players with impressive awe-inspiring moments—it’s the strength that direction gains from its cinematic heritage. Maybe said best by someone with a movie background, such as Josef Fares talking about A Way Out: “A scene that is only playable for you for about 60 seconds. I’d say over 300 animations, only playable for you for 60 seconds, and it’s never coming back.” Scripts, storyboards, and motion capture animations: all products of direction.

Though those 300 animations are certainly unique, the gameplay of interacting with them in A Way Out is rarely more interactive than pressing forward on the left stick. The spectacle is amazing, and the direction is what makes it valuable, but the player has very limited agency.

Agency

Speaking about player agency is tricky. Some players will take it to mean that everything they attempt should be rewarded, and if it’s not, the game doesn’t give them enough agency. Let’s use a slightly less stringent definition and consider agency a factor of the game respecting player intent.

If a game with high agency gives you a gun and shows you that you can kill characters with this gun, then this is a permission that the game needs to respect. If the player later decides to shoot the game world’s chosen one in the face, this should be perfectly fine. The chosen one should die. It follows the rules of the game, and it follows player intent. If your game applies rules this consistently, it also provides a high degree of player agency.

Quite obviously, agency is the opposite of direction. The moment a plainly killable chosen one cannot be killed because the game designer decides that it’s so, they have exercised authorship and have directed the outcome against player agency.

Content vs Experience

I have complained in the past about our industry’s (and our fans’) use of the word “content,” and will probably keep complaining until we start making games in smarter ways. But content has its place, and when it comes to authorship it’s many times easier to plan content than to build experiences.

Content

“We do level design. We do art. We do new mission packs. We do new power ups that are basically variations on old power ups,” said Daniel Cook in his talk on creating new genres. “[E]ssentially we’re a content industry and we sell content.”

One more asset. One more level. One more character model or weapon prop. We know how this works, so we can plan it and we can take our script and list all the things required to realise it. Whether we build 15 or 1,500 is a matter of budget and staffing. There is very little unpredictability for the development process itself. (Unless we change things mid-production, of course, but that’s a separate discussion.)

Many times, this is exactly what players want. A feature-rich game with a compelling narrative and plenty of optional side missions to engage with. If you buy the latest AAAA single-player blockbuster, it’s often what you expect and hope to put your next 100 hours into. Then you want the DLC, the expansion, and the sequel, to provide you with even more content.

Experience

Then-CEO of Starbreeze, Mikael Nermark (R.I.P.), said in an interview in 2012 that, “We don’t talk about games, we don’t talk about genres, we just talk about building the best experience, whatever that means for that particular project.”

I have personal opinions on whether this was true at the time, which I will save for another day, but the sentiment of Nermark’s statement is compelling. An experience can be something where you are an active participant. Something where your personal input matters, where elements like immersion and role-play can happen. It can come from games like DayZ, where the experience grows out of dynamic player-player interactions.

Rather than burning through content, you’re taking the same content and doing more things with it. Sometimes because of your own vivid imagination as a player, and sometimes because you wanted to try to play the game a different way. It’s what you do when you set the sliders differently in a new session of Civilization, or replay Dishonored with high chaos. The same content, but a new experience.

Determinism vs Uncertainty

Many words in game development have different meanings to different developers. They may even have individual meaning. One such word is “randomness.” We often use randomness to be a negative thing, because something happened that we didn’t want to happen. But it can be equally important for what makes a game interesting.

Determinism

The most deterministic a game will ever get (in this context) is when it shows you an unskippable cutscene. Every player will see the same cutscene, paced the same, focused the same. The moment you allow even a modicum of interaction, the player can go against your intentions. Controlling the camera, for example, may make the player miss a crucial on-screen event because they were looking the wrong way.

This is probably why games with strong authorship often rely on cutscenes to convey their narrative elements, and maybe also why Hideo Kojima allegedly said, “The human body is supposed to be 70 percent water. I consider myself 70 percent film.”

Other ways to achieve determinism is limitations of different kinds. Having to open a specific door to progress, walk through a certain hallway in a specific direction, and so on. Level design can assure that players see certain sights and scenes in a predetermined order.

Uncertainty

“Games are uncertain and must be so to remain interesting,” concludes Greg Costikyan in his book Uncertainty in Games. “[B]ut sources of uncertainty are manifold.” In this book, many different sources of uncertainty are explored, from simple randomization to player interaction. Will I roll the 6 I need? Is my poker opponent bluffing when they go all-in?

Whenever you can’t fully know the outcome of an event, there is uncertainty at play, and it’s one of the key ingredients for emergence. Uncertainty can come from the physics system that yields crazy results in Goat Simulator; or the dynamics of orc politics in Shadow of Mordor.

This end of the scale is for you if you embrace this uncertainty. It’s not the one thing that makes a game interesting (which is part of Costikyan’s conclusions), but considering which forms of uncertainty you want to include is a fruitful design space.

Top-down vs Bottom-up

When you have ideas for your game and start implementing it, a common way to begin is to translate the high level concept directly into objects. You will have characters, so of course there’s going to be a Character base class. Some engines will provide these expected classes out of the box. Let’s look at this top-down approach, and also its opposite, the bottom-up approach.

Top-down

A high level concept or “core fantasy” is the narrative or conceptual layer that can be used to inform your whole design. But it can also be used to inform your fans—not just you as the developer. Days Gone game director Jeff Ross said in an interview; “My design philosophy is you’ve got to stick with your core fantasy. So whatever core fantasy your IP is trying to create, if players are buying into it, they want it delivered upon.”

This focus at the high level means that you will construct a game top-down. This core fantasy will be used to make decisions and anything that may go against it will be either downplayed or removed. If a player can go off the beaten path implied by the core fantasy, they won’t be able to stray far. Deacon St. John—the protagonist of Days Gone—can’t be made to stop sulking or searching for his lost wife, for example. Those are fundamental parts of the high level concept and character writing.

Bottom-up

In his book, Creation: Life and How to Make It, Steve Grand discusses how to construct emergent behavior, stating “[t]he mistake is to start with the outward behaviour you want to see, and work back towards some equation that produces it, rather than start with the fundamental physical processes that are at work, and from them build outwards to generate the behaviour.”

The solutions used in Steve Grand’s life sim game, Creatures, is to emulate how real life works using sensory input, neurones, and actions, as well as the inputs of the player to punish or reward the creatures as they go about trying to understand their world. There’s no principal high level concept to start from, beyond an idea of emulating life. No model for the detailed behaviour. Instead, the behaviour is a consequence of the parts.

Jeff Orkin’s classic Goal-Oriented Action Planning becomes a similar type of model, where actions and state describe possibilities, and the plan that comes out of the planner is the actual behaviour. The opposite of something like a behavior tree that strictly defines the whens and hows.

Spectacle vs Fantasy

In self-determination theory, you talk about extrinsic and intrinsic motivation. An extrinsic motivation comes from without in the form of rewards or other stimuli, while an intrinsic motivation is something that comes from within yourself. If we want, we can look at the next scale’s two extremes as a similar thing. Spectacle is an extrinsic thrill; fantasy is an intrinsic thrill.

Spectacle

A spectacle is an occurrence regarded in terms of its visual impact. Something striking, awe-inspiring, and compelling. When the nuclear bomb goes off in Call of Duty: Modern Warfare, or when you realise the outcome of each of the different interactive set pieces in What Remains of Edith Finch. Fireworks displays are spectacles. Absurd bossfights are spectacles.

In video games, spectacles are expensive to make and tend to require either explanation or staging. Spectacle therefore dovetails nicely with direction and determinism, since it’s hard to guarantee that the player will experience the spectacle as intended if this is not assured somehow.

Fantasy

Immersion is incredibly powerful. To visit another world and become another character. Conjure up an image of a virtual persona that becomes so real that you may even shed its tears and feel its anger.

Games are “fantasy first” when they present a strong fictional grounding for their premise. When they ask the player to play out a role, such as a liber-tea delivering helldiver in Helldivers 2, or a thief in Thief: The Dark Project. The first is an example of the game presenting a fiction and asking you to immerse yourself in it; the second is better described in the words of Paul Neurath, one of the founders of Looking Glass.

“We want a more singular experience that’s focused on a role,” he said. “We know what thieves do. Players know what thieves do. It creates an immediate context, which is especially important if you’re doing an innovative game.” The player fantasy as a means to inform the player of what to expect.

Authorship vs Emergence

After these six segues, we’re ready to look at the master scale again. The scale that goes between Neil Druckmann and Warren Spector; between Authorship and Emergence.

Authorship

Anyone who has ever had an amazing thing appear to their mind’s eye and desperately wanted to convey it through art has desired to author something. To convey specific emotions to another person. We may choose writing, painting, or game development, as our avenue of communication, but the artistic urge is still the same: to make people feel something.

“My thing I always go back to,” said Cory Barlog. “[I]s that sense of finishing ‘Castlevania: Symphony of the Night,’ and that castle flipping over, and just going, ‘Oh my God, that was amazing! I have so much more to play!’ It was astounding. I think I’ve always been chasing that. I think my entire career, I have been like, ‘I want that kind of epiphany.'”

Flipping the castle for the player, giving the player a pivotal moment that gives something value. Supposedly it’s what drove the narrative twists in the 2018 rendition of God of War that Barlog was the director for.

This is authorship. Having a strong vision where the stars align to bring something to the player playing your game, and making sure that this strong vision comes through to everyone that plays the same game.

Emergence

In his memoir, Sid Meier tells the reader about his storied game development career. The concept of interactivity and the focus on the player’s experience of playing your game is consistent throughout. One comment he makes in describing game design is that “[l]ike chess, each piece’s function was easily understood, and only after you began looking at moves in combination did the really interesting paths emerge.”

This approach is the complete opposite of having a deterministic pre-defined turn of events in mind. You’re now building the pieces that will form the whole and then handing them over to the players. This leaves plenty of room for emergence to happen, and often it will be things you never even intended that provides the most value.

Sid Meier’s approach isn’t better than Cory Barlog’s, it’s just based on different priorities, and you need to know where you want to take your own projects. Emergence happens when you let go of authorial control.

The Scales

Put it all together and you get six scales where you can put your design intentions, and a seventh scale to serve as their umbrella. We can look at the left side as authored and the right side as emergent.

Systemic games invariably benefit from a right-leaning design space, but as you will probably realize, very few games even among immersive sims and other highly systemic games are leaning completely into one side or the other.

Thief: The Dark Project has plenty of direction in its narrative and plenty of content in its level design and storytelling. The same goes for The Legend of Zelda: Tears of the Kingdom, and most definitely for Baldur’s Gate III.

By adding more exceptions, more agency, more focus on experience, more uncertainty, and designing it all in a bottom-up manner, you will be pushing your game towards the emergent end of the spectrum. Just make sure to be honest both about what you want to achieve and what fits your game best.

What I hope you can take with you from this post isn’t that you should skew everything towards the right, even if I’d certainly play your game if you did. It’s that you need to be aware of your intentions and consciously choose where on these scales you place your own game design. Once you’ve done that, you need to stick to it.

This post is a continuation on a previous combat design post.

How to build a gun has already been discussed. We’ll now explore what happens after the trigger has been pulled and who you are shooting.

We’ll be touching on projectile simulation and game physics, since those are systems that will solve (or cause) your problems here, but we will also touch on some game design philosophies that become highly relevant.

As with the melee combat post, this is mostly a repository of useful related concepts that attempts to boil down the various elements of firearm conflicts in games. Skim it, read what you find most useful, and then go out there and make systemic games.

Or disagree in the comments, or to annander@gmail.com.

Realism

Let’s first cover one of the favourite words of many gamers: realism. That thing is realistic; this thing is not. There’s sometimes an implied value attached to realism, even when our notion of what’s realistic is rarely on point.

The popular miniatures wargame Warhammer 40,000 (40K) is played at 1:64 scale. This means that one centimeter on a model is roughly 64 centimeters in real life.

Knowing this, if we go to the 10th edition (current newest) Space Marine army book, we’ll find that a Tactical Squad Space Marine’s trusted boltgun has a range of 24 inches. At 1:64 scale, this means 1,536 inches, or 39 meters.

As a point of reference, we can look to the Swedish infantry manual, Soldaten i fält (“The soldier in the field”), from 2001. The Royal Swedish Army used two infantry assault rifles at the time, the AK4 and AK5. Their present day boltgun analogs. Recommendations in SoldF provides the maximum engagement ranges for these rifles as 500 meters against an enemy in the open and 300 meters against an enemy in cover. If we convert the last number (300) back to the 1:64 scale inches, it’d give an assault rifle a range of 185 inches. Almost eight times that of the boltgun.

You can see the same “clash” of engagement distances between for example Overwatch and Arma 3. The first needs to make it clear where you are getting shot from and how, in the interest of balance, while the other aspires to provide a simulation—a realistic simulation—which means you can get shot and killed without even knowing where the shot came from. If the distance is long enough, you may not even hear the shot.

All of these designs—40K, Overwatch, and Arma 3—are adapted to the play styles and circumstances of the individual games. 40K is suggested to be played on a table area from 44″ x 30″ up to 44″ by 90″. This means that the 24″ range actually matters and that the 72″ inch range of a tank cannon effectively covers the whole battlefield. These are conscious designs used to enhance their relative circumstances.

You can certainly argue that Arma 3 is “more realistic” than 40K, of course, but it’s like comparing apples to oranges. “Realism” is not what’s important, it’s how well the game achieves what it sets out to do. Making things more like they are in real life has no inherent value.

Projectiles

Ballistics is the field of mechanics concerned with projectiles and how they move. But as with so many other things, games need to make use of abstractions. Using real-world mechanics calculations is too computationally intense, and tracking all of the variables of the real world gets even worse.

So now that we have covered realism at least fleetingly, we can take a look at how our guns behave when we pull the trigger.

Projectile Lifetime

Let’s assume that we’re not interested in simulating real-world ballistics accurately. This still leaves us with a bunch of inspiration to take from the real world.

Launch

Many of the things that would happen at projectile launch are technically handled by the systemic gun already. Things like recoil and potential target acquisition are represented as constraints, for example. But launch is still relevant for spawning not just the projectiles themselves but any particle effects, camera effects, sounds, and other feedback.

Some games will spawn particles, lines, or other indicators of where a projectile will hit, or even show a visual trajectory.

• Player feedback.

Flight

This is where you can really change how a projectile behaves at a fundamental level, even going so far as to make a custom set of the Trigger-Constraint-Effect trinity used for the systemic gun, but focused on the characteristics of projectiles.

Of course, “flight” as a concept only matters if the projectile has a lifetime. At most ranges where video games take place, a real-life bullet would hit nearly instantaneously. Which is why we get things like slow-moving energy projectiles in games, since it gives us enough time to react and provides interesting gameplay opportunities.

• Targeting, for example for homing missiles.
• Gravity, which generates dropoff.
• Proximity detection, like for a proximity fuze.
• Separation into submunitions.
• Timed fuzes detonating.
• Min and max distance checks.
• In-flight player control.

Impact

Projectiles that are transfering energy from the blast into a tiny area on a target are kinetic projectiles. Bullets, balls, etc. There have even been proposals to put large tungsten rods in space and use them to destroy underground nuclear silos.

For our purposes, impact means that we can safely recycle the projectile in memory, and that we will probably have to tell the object that was hit that we hit it.

• Object-object communication: projectile needs to communicate the impact and any required details about it, but it should be up to the object that gets hit to implement its own logic for handling it. At the simplest level, this is where you could tell an object to take X points of damage.
• Projectile tests. Whether the impact should cause the projectile’s lifetime to extend, for example as a ricochet, or if there are material checks that could determine things like wall penetration or destruction.

Projectile Simulation

Games can represent projectiles in many different ways and will often separate the player-facing visuals from what happens under the hood. A system may use line intersections to detect hits, for example, but still render a visible glowing laser beam to give the player strong feedback.

This is a core concept in game development of course: smoke and mirrors. Make the player believe things are awesome, but solve the issues under the hood in the most efficient way you can.

Line Intersections

The simplest way to represent a projectile is using a line, and the simplest (and cheapest) way to represent a line is using a line intersection. Some will refer to this as “hit scan,” and it will use the fastest shapes available mathematically—spheres or boxes (technically, either AABBs or OBBs)—particularly in games on computationally constrained platforms.

This is of course totally unrealistic, but often good enough. Particularly for fast-paced games.

bool LineSphereIntersection(Vector3 Origin, Vector3 Direction, Vector3 Center, float Radius, Vector3& ContactPoint)
{
    const auto W = Center - Origin;
    const auto WSq = W.Dot(W);
    const auto Projection = W.Dot(Direction);
    const auto RadiusSq = Radius * Radius;

    // If sphere is behind ray, no intersection
    if(Projection < 0.f && WSq > RadiusSq)
        return false;

    const auto VSq = Direction.Dot(Direction);

    // Diff vs radius
    const auto bIntersects = (VSq * WSq - Projection * Projection <= VSq * Radius * Radius);

    if(bIntersects)
    {
        const auto B = 2.f * Projection;
	const auto C = WSq - Radius * Radius;
	const auto Discriminant = B * B - 4 * VSq * C;
	const auto T = (B - Sqrt(Discriminant)) / (2.f * VSq);

	if(Discriminant < 0)
	    ContactPoint = Origin + (Direction * -1.f);
        else
            ContactPoint = Origin + (Direction * T);
    }
		
    return bIntersects;
}

Physics Intersections

With the same reasoning as intersections, but using a physics engine, you can “trace” or “cast” a ray or line into the physics simulation to test if any collisions occur along the ray or line. A ray has an origin and a direction, and may have a maximum range; a line has one start and one end point. They will usually return the first collider or all colliders hit by the ray or line. Most physics engines also provide filtering capabilities such as different layers or channels that can be used to only test against some colliders and not the entire simulation.

For the player, this will be nearly indistinguishable from the intersection type of “hit scan.”

struct RayHit
{
    Vector3 Point;
    Vector3 Normal;
}

bool RayTrace(Vector3 Origin, Vector3 Direction, RayHit& HitResult)
{
    return PhysicsEngine::RayTrace(Origin, Direction, HitResult);
}

Point Simulation

One step up from “hit scan,” we find point simulation. We’re now launching a simulated particle through our game world and checking if it hits something. When working with point simulations, it’s handy to compare points to spheres since this is the cheapest test we can do.

Technically, this lets you simulate every object as a point or group of points (a “point mass”) tied together with constraints. If you go back 20+ years in time, you will find some early 3D games that did exactly this. Hitman: Codename 47 for example.

This type of physics simulation uses Verlet integration as opposed to the more commonly used Euler integration.

struct VerletPoint
{
    Vector3 Position;
    Vector3 OldPosition;
}

void Verlet::Simulate(const float DeltaTime)
{
    for (auto i = 0; i < Points.Length(); i++)
    {
        const auto Temp = Nodes[i]->Position;
	Nodes[i].Position += (Nodes[i]->Position- Nodes[i]->OldPosition) + Gravity * DeltaTime * DeltaTime;
	Nodes[i]->OldPosition= Temp;
    }
}

Physics Simulation

If you don’t think points are enough, you can go with fully dynamic physics. There are many physics engines available out there, if you don’t want to write your own. Even ones in the public domain, like Bullet3.

What you gain from fully dynamic physics is that you can have many more properties act on the projectiles involved. However, game physics engines are often unreliable.

Projectile World

The projectile or intersection test that you fire with your gun, and all of its various fireworks, is just one side of the ballistic coin. The other side is how to represent the thing you are shooting at. As with projectiles, this will always be a tradeoff between accuracy and game feel. Many of the more abstract and cheaper solutions will be less “realistic,” but may also serve your purpose a lot better.

Hit Boxes

Gamers have very strong opinions about hit boxes. Engines handle these slightly differently, but for various reasons an OBB that aligns to bones in the animated skeleton are cheap to make comparisons against and therefore comparatively cheap to replicate across a network and quick to test.

That we may still rely on them today is for the same reasons, and also because tests against complex geometry (particularly animated complex geometry) can be quite expensive. The neat thing with a box is that it’s mathematically simple to describe and therefore very easy to test against, especially for point simulations and intersection tests.

Some physics engines may use a simple box intersection test against an axis-aligned box instead of an OBB as a way to eliminate unecessary tests before making any more expensive but more accurate tests. So even if your end result isn’t generated from a hit box, it can still be good to have.

Materials

One common way to distinguish physics engine behaviors is to attach different material properties to game world surfaces. In a physics engine, the combined material properties of two colliding objects will often provide friction, restitution (“bounciness,” or how much energy is given back on collision), and information to sound and particle systems. This lets you use physics materials to create slippery ice, bouncy mushrooms, tough metals, and so on.

Material properties can be more programmatic as well, making a static object player-physics only or AI-navigation only. But whether this is set per-object or per-material is based on the game engine’s solutions.

Wall Penetration

One thing you can use materials to determine is wall penetration. Maybe wood can always be shot through with guns, while sheet metal requires an assault rifle and concrete a sniper rifle. Simple rules to setup and communicate, even if they are totally unrealistic.

Of course, manipulating properties such as wall penetration is excellent territory for systemic gameplay. Like if you can add the “penetrable” property to any object in the game world using one of your tools.

Cover

Physical objects serve two immediate purposes in many action game simulations: blocking line of sight, and blocking fire. This can sometimes take the form of “sticky” cover, where the player’s avatar enters an entirely separate game state glued to pieces of cover in the environment, but it can also require clever uses of the environment to break line of sight or keep your head down.

Destruction

In urban warfare, if someone is taking cover in a building somewhere and laying down fire to keep you away, the best way to approach them is to simply destroy the entire building they’re holed up in. This means you don’t need to risk anything at all. At the very least, you shouldn’t use the front door but make your own entrance using breaching charges or other explosives.

Destruction is a popular component of action games, ranging from the dynamic voxel-based destruction of Teardown to the effects-hidden mesh replacement or animated destruction of something like Battlefield: Bad Company 2. Leaving the field of battle remodeled after an intense firefight has a very strong feedback element, of course. But allowing its use as a tactical component adds an additional layer.

However, none of it is really up to the particle system itself. It’ll be the physics or other systems that allow you to shatter glass and raze buildings.

Damage

When a bullet hits, most games will handle it as a temporary loss of hit points or health points (something “spreadsheet specific,” if you recall). You can either walk over a medpack (which is not allowed to use the symbol of the Red Cross, by the way) or just wait for your regeneration to kick in. But it’s interesting to consider what damage means, in human terms.

For a role-playing game scenario I once wrote (unfortunately in Swedish), the inspiration was to study how German soldiers during World War 2 spoke about injuries and to use that as the basis for the rules. Based on the journals and other accounts I read, these soldiers seemed to talk in terms of three levels of injury: flesh wounds, “home shots,” or death.

Flesh Wound

If the wound is mostly superficial and doesn’t damage your capabilities too severely, you’ll get bandaged or band-aided, maybe a few stitches and some rest, then get ordered back into the fight. Not much of an injury at all.

Home Shot

The home shot (heimatschuss in the original german) is the middle ground. You’re too injured to continue, but you won’t be crippled for life and you won’t die. This is the ideal injury as a soldier, since you actually get to go home mostly in one piece. But you also don’t want a home shot that’s too severe, like losing your main hand, or your eyes, etc.

In one instance, a soldier is mentioned who gets shot in his right hand and loses the index and long finger, then proceeds to raise that hand to show his friends and smile. A home shot. Whether this is true, I can’t know, but it certaily paints a picture.

Death

Death is final and absolute, even if it’s also the “place of greater safety” referred to by Hilary Mantel’s book of that name. But for the soldier, though death can be a regular part of daily existence, it’s still the worst possible outcome. In games, it’ll usually be a checkpoint reload or timed respawn. Death is usually, at most, an inconvenience.

Design for Effect

The last part of this post deals with the people you are fighting against and how the bullets affect them and does this by going into a whole paradigm of game design philosophy: designing for effect.

While developing the seminal board game Squad Leader, designer John Hill figured there were only three relevant outcomes from infantry taking fire and how he reached this conclusion is the paradigm:

“Once we centered the thinking on ‘effect,’ it became clear that no matter what actually happened on the infantry battlefield in terms of the participants, the possible ‘outcomes’ were really quite limited. For example, it made no difference whether a squad was fired on by another squad, racked with a machine gun, shelled by a mortar, blasted by a hand grenade, overrun by armor, or ‘shocked’ by the death of a veteran officer. One of three things would always occur. Either there would be no effect, they would be eliminated, or they would be discomfited.” (Emphases mine.)

It’s incredibly rare for a real world military engagement to lead to the 100% deaths you typically see in video games. Rather, some people will “break,” hiding behind something until the engagement dies down or panicking; some will be wounded—lightly or not; and others again will get knocked out, run off, or even abandon their comrades entirely (deserting). Some also die, of course, but for the purposes of the effect, the distinction isn’t important.

It’s not terribly important in war either; a ‘casualty‘ isn’t exclusively a combat death. It’s anyone who becomes unfit for active duty. Whether they died, went missing, or were temporarily hospitalised isn’t relevant to the immediate war effort: they won’t be fighting anymore.

However, this abstraction—or design for effect—is important. Focusing on the potential outcomes of a situation allows you to step backwards to figure out how your systems are connected and allow you to get there through multiple means.

It also means we can find our inspirations in the real world and in different kinds of situations, rather than focusing entirely on how things are resolved in other games.

Combatants and Civilians

The terrifying abuses that are perpetrated against civilians, particularly when wars are fought in urban areas, are too much to bear. The horrific consequences of indiscriminate terror bombing remains an all-too frequent news item.

For obvious reasons, most wargames gloss over the concept of civilians. Houses are empty and abandoned cars are left by the roadside. Occasionally, we may see a baby stroller, a café, or something else that hints at the regular sprawl of a civilian town or city, but everything that moves is either a target or an ally: a combatant.

Rules of Engagement

Do not fire until fired upon. Use minimum force. No artillery shelling in the area near the medieval church, as it’s considered a cultural treasure. No-fire zones around schools and train stations. Maybe more tonally interesting, no live fire allowed because you’re underneath a huge fusion reactor; collect all the magazines.

Games rarely involve rules of engagement. You can kill the critters on the StarCraft map without repercussions, and you can bomb things to bits in most games because you feel like it and want to watch the fireworks.

Maybe this is what some loud segments of game fandom says they want when they say we should keep politics out of games. In reality, it’s hard to depict war without politics.

It’s strange that we don’t have a wargame with some representation of rules of engagement. Or, at least I personally never played one.

Opposing Forces

Let’s assume that we know who is a civilian and who is a combatant. We should also know who the enemy is. Except this is very rarely as clear-cut as we may wish.

The opposition may be a revolutionary force dressed like civilians, separated only by the red armbands of a combatant. It may be people you went to school with, or your colleagues just last week. It may even change from one day to the next, such as in the Lapland War, where Germany and Finland, who had fought side by side against Soviet, fought a brief war.

This is a space with a lot of interesting territory for scenario design but many ethical and moral gray areas. However, with games a medium that never shies away from gruesome violence, “moral gray areas” have already become our bread and butter.

Operator Fatigue

Contrary to how most games portray soldiering, it’s a pretty dull affair for the most part. The adage is, “hurry up and wait.” Receive orders to get someplace really fast, then wait for new orders. Two days later, having finally finished digging in, you’re now moving a few kilometers north to do the same thing again. Only some estimated 15% of soldiers ever “see action,” and for many of those 15% it’ll just be a fleeting moment in their tours of duty.

When an attack does happen, it can come at any moment. The enemy doesn’t schedule a combat appointment at your convenience. As Anders Puck Nielsen talks about around the sinking of the Moskva, extended combat readiness leads to operator fatigue.

Friendly Fire

Firefights are chaotic and weapons of war are highly indiscriminate. For single-player games with projectile weapons, this won’t come up unless the player has AI-controlled allies. But for cooperative games and team-based multiplayer games it’s important. Many will make allies immune to friendly fire.

Suppression

Small unit infantry tactics often revolve around the concept of bounding overwatch where units alternate between moving and firing. Volumes of fire from the firing teams are concentrated against enemy positions to make them keep their heads down while the moving teams push forward to take ground or retreat.

Suppression is common in various forms in board wargames and tactical games, but not quite as common in first-person shooters. When you are shot at and take cover, you are of course effectively being suppressed, but in many video games it can be a valid strategy to simply run towards your enemy, jump on the spot, or perform other athletic feats that would be unreasonable in a firefight.

Instead, some games employ camera shake, blur, and other effects to simulate the player avatar’s mental state when being targeted by concentrated fire. A sort of mechanical way to “suppress” a player.

Conclusions

The most important takeaway from this post should be the design for effect paradigm and how it lets you design “backwards” from the effects that you want your game to provide. Whether that’s suppression and home shots or friendly fire is of course dependent on your design.

There’s a lot more to say about gunplay, and some of the subjects in this post will be expanded in future posts on level design, artificial intelligence, and more. But for now, I hope you could find some inspiration here!

This post is a continuation on a previous combat design post.

Shooting, stabbing, strangling nazis; or just quick-meleeing with knives to humiliate PvP opponents that didn’t see us coming. Melee combat is a big deal in video games and has been since forever.

This post will try to break down how you turn a traditionally feature-rich game design like melee combat into an object-rich one instead.

But before we do that, let’s look at standard representations of melee combat in video games.

Types of Melee Gameplay

I will start by going through a number of gameplay types that you see repeatedly for melee combat, and I will give them strange names that you may or may not agree with. This is for the sake of argument. You don’t need to agree on how I classify any of this. It’s also not a reflection of which games are good or bad—only how they solve common problems and which verbs they focus on for the player.

Note that, for preferential reasons, I’m mostly talking about 3D animation. There are many 2D games, from Hollow Knight to Nidhogg and beyond that do incredibly interesting things with melee combat, but I’m not talking about them here.

Feature-Rich Melee

You have the heavy attack and the quick attack. You can parry. You can also riposte if you time the parry right. You have throwing knives, shuriken, caltrops, wire traps, and javelins; each with a special role in the combat simulation. A feature-rich combat system is something like Ryse: Son of Rome, the 2018 God of War and its sequel, or Ghost of Tsushima. Production values are often through the roof, the story is in focus, and most of the game’s challenges rely on cycles of retries until you succeed the way the script demands.

These types of games are very expensive to produce and even more expensive to fill with content. They are also the complete opposite of what will be discussed in this post, since they are entirely content-driven and do not rely on any simulation or systems. Since they can’t be described using rules, they must often rely on visual or aural cues and will often focus on repetition and timing because of this. Look for the hint, and time your button press based on it.

Player Activities

• Unlocking new tools.
• Learning which tool works when.
• Looking or listening for gameplay signals.
• Retrying until successful.
• Finishing the story.
• Waiting for animations to complete.

Content-Based Melee

The next common type of combat is mostly about timing, but it’s also about learning the nuances of the game’s content. Games like Street Fighter do things this way, but so do the Soulsborne titles. Each character or weapon has a defined set of animations and behaviors, and you need to learn things like which strike comes after each other strike, how far each strike’s reach is, which frames reduce damage during a dodge, and so on. There’s no way for you to know these things when going into the game: they must be learned.

Good games of this type are tuned to perfection, providing a high degree of satisfaction when you start mastering the techniques involved. But they are also strictly tied to their content patterns, whether this is an AI whose wide axe swing is always telegraphed by an overhead swing, or the longsword the player finds which’s quick attack is a swing and heavy attack is a thrust.

If we assume that Raph Koster’s theory of fun holds true, which is that fun comes from learning, this style of melee combat is extremely successful at providing it. In fact, I’d argue it’s one of the best styles for this type of fun and likely has a great deal to do with their success.

Player Activities

• Learning the controls.
• Learning the content (timing, reach, etc.).
• Anticipating your opponent.
• Finding new learning opportunities.
• Exploring what has been learned.
• Mastering what has been learned.
• Overcoming patterned challenges.
• Retrying failed challenges.

Freeflow Melee

Allegedly, the first tentative steps towards what would become the oft-plagiarized “freeflow” style of combat was in the Catwoman video game released in 2004. But it really hit off with Batman: Arkham Asylum (AA) in 2009.

You have three actions in AA: attack, stun, and counter. Though this plays as a mix of feature-rich and content-based, it’s not about critical timing or even following prompts, but about getting into a certain “flow.” The protagonist is directed in roughly the right direction to take out the strategically right enemy in the moment. If you fail to execute it right, you are taken out of this flow state.

One common criticism against this style of combat is that it’s just button-mashing or at least feels like it. It can also be criticised for being too easy. This is of course completely valid opinions, but challenge is not the goal. It can certainly be part of it, and later iterations on a similar formula—like Spider-Man and Shadow of Mordor—add enough features to dip more into Feature-Rich Melee than Freeflow. But for the original freeflow games, the goal is to make you feel like Batman. You see a group of thugs and you think, “I can knock those out.”

Freeflow is a great type of combat system to let you build character confidence.

Player Activities

• Lining up attacks.
• Maintaining flow.
• Neutralising critical threats (with correct timing).
• Building character confidence (narrative connection).
• Planning, while waiting for animations to complete.

GUI-Based Melee

The next type of combat is probably more contentious to define. At its most extreme end, you have the knife fight in Resident Evil 4 that is a cutscene with quicktime events added. At the other end, you have games with specific context-sensitive interactions that represent more complex actions that the player has no interaction with. For example, a special combo that can be triggered under certain circumstances.

Player Activities

• Anticipating the UI.
• Reacting within the correct window of opportunity, or failing.
• Retrying failed sequences.
• Learning the cues through repetition.
• Waiting for animations to complete.

Semi-Freeform Melee

I will refer to this as “semi-freeform,” because though you have more direct control than in purely content-based melee combat games, you must still spend some time learning the game’s animation content.

The two most prominent examples of games that solve melee this way are Chivalry and Mount & Blade. The first uses animation content to direct an attack based on how you are aiming, but lets you retain control throughout the attack; the second has you provide directional input before the attack and places your weapon in a warmup position before you release to deliver the blow. In both games, you are free to aim to guide the weapon.

What these games do really well is model the differences between various weapons. In Chivalry, you can use a chained weapon to get behind someone’s shield. You can use a lance to deal tremendous damage if you time it right as you ride your horse, in Mount & Blade.

Player Activities

• Aiming where to hit.
• Moving to position yourself better.
• Guiding the direction of attack.
• Judging distance to make the most of each attack.

Body-Control Melee

Some games have tried to give us control over the physical extremities or positioning of our protagonists. It’s an uncommon way to do combat and probably for good reasons. Most of the time when you played Die by the Sword using its mouse-based “VSIM” controls, you ended up repeating a horisontal swing over and over while moving towards your enemy. More like a lawnmower than a fighter.

But there’s certainly something compelling about the idea of controlling your avatar’s virtual arms. The Fight Night boxing games have a very distinct control setup using flicks of the analogue sticks.

The probably coolest thing about this type of interface is that it slightly resembles the process of learning to fight in the real world, even if it’s just a digital representation. Picking up the sword not knowing what to do, and gradually mastering the horisontal flailing, just like a real warrior.

Player Activities

• Learning the interface.
• Practicing the interface.
• Applying your knowledge of the interface.

Peripheral Melee

With VR, we’ve had games like Blade & Sorcery that does freeform melee using VR controls. But even before then, we had the Wii console, and titles like the yanky Red Steel and The Legend of Zelda: Twilight Princess. But the Wii games that did melee combat mostly boiled down to wiggling or waggling the controller and didn’t amount to the incredible immersive duels that many probably hoped for when the Wii was released.

The issue that no peripheral-based melee game has quite managed to solve (yet) is how to handle the physical properties of your weapon in case of things like parries, and how to handle judging distances and enemy proximity. The disconnect between simulation and peripheral is still too great.

Some of these games are still a ton of fun, however. There’s a quiet promise in the idea of a peripheral-based melee combat game.

Player Activities

• Learning the physical controls.
• Learning the content.
• Learning the concessions between controls and content.
• Judging distance.

Freeform Melee

What can be considered “freeform” in this context is when you have direct action control. Your actions as a player are to slice and dice; not to trigger animations doing it for you. This gets very tricky with characters and animations, since there’s no room for them to play their animations without knowing something about the game’s context beforehand, but it can be extremely satisfying as gameplay.

When we see these types of melee combat in games, it’s usually in a more abstract form that doesn’t portray characters at all and doesn’t need animation. From Fruit Ninja to melee-themed rail shooters.

Player Activities

• Perform actions analoguous to in-game actions.
• Apply intent to the game simulation.

Finishing Moves

Maybe most iconically from Mortal Kombat, a finishing move is a way to mark beyond a shadow of a doubt that an enemy is defeated and to create a potentially gratifying moment of feedback to the player. Some games use this entirely for flavor, while others make finishing moves an integrated part of the game’s balancing. Consider Doom (2016) and its glory kills, that provide you with a health boost.

Player Activities

• Learning context-sensitive cues (usually as icons in UI or flashing textures in world space).
• Timing context-sensitive cues.
• Managing resource requirements (e.g., Doom‘s chainsaw gasoline, Space Marine‘s health).
• Waiting for animations to complete.

Quick Melee Attack

Primarily in first-person shooters, you have a tendency to move towards your opponents or them towards you. The distance closes as you fire your weapons, you get close enough to stare at each other viciously, and then the first of you who realises that there’s a quick melee-button will win the day.

A variation on the quick melee attack is what you find in games like Vermintide, where there’s a push attack that lets you gain some distance from enemies without dealing much damage.

One common way to animate these attacks is to start from the impact frame and then animate back to the idle pose. Either directly or with one or two tweening frames to smooth the strike transition. The reason for this is that it feels very close to the direct action shooting you are engaged in most of the time in a FPS.

Player Activities

• Learning to time the attack right.
• Learning the balance of how much damage the attack deals and when to use it.
• Triggering the attack at the right time.
• Waiting for animations to complete.

Immediate-Mode Melee

As the complete opposite of content-based melee, let’s call this style of melee “immediate-mode,” from the UI method of directly updating graphical elements when data changes. The principle here is the same: to immediately provide player feedback by executing the triggered melee attack. Games that need to feel responsive and fast often utilise this type of mode.

Picture how the Barbarian in Diablo III starts an attack by snapping straight to the peak of the animation’s telegraphing pose and then executing the strike extremely fast; often faster than you can see. It’s responding the moment of the click rather than by using the click as a trigger.

By not having to learn animation content, you free up your mental bandwidth to focus on the battlefield instead.

Player Activities

• Assessing threats.
• Killing enemies.
• Timing critical (often statistical) abilities represented as targeted or area attacks.
• Waiting for cooldowns to finish.

“Realistic” Melee

For some reason, realism tends to mean that things slow down and become animation-driven. It seemingly comes more from swordplay motion capture and attempts at detailed physics simulation than from any investigations into what makes a swordfight a swordfight.

It’s certainly the most confusing mix of combat as sport and as war. On the war hand, many such games allow you to come up with unorthodox plans. But on the sport hand, it’s still a points chase, with experience and kill counts and objectives to complete.

It’s hard to really know how to evaluate these types of games. The quotation marks are in the headline because they tend to be very selectively realistic. There’s no Arma 3-equivalent simulation for melee games. At least not yet.

Player Activities

• Learning the length and reach of animations.
• Learning the rules for different arms and armor.
• Waiting for animations to complete.

Takedown Melee

A close relative of finishing moves is the takedown. Where a takedown in martial arts tends to mean a method to take your opponent to the ground, its use in game design is usually as a way to disable an opponent. It can be to choke them unconscious or to stab them to death with a sharp object.

Player Activities

• Learning which takedown options are available.
• Planning when to use a takedown.
• Waiting for animations to complete.

Melee as a Tool

Sometimes the melee combat is not the main attraction but merely one of several tools in a complex toolbox. This is the type of melee employed by games like Thief: The Dark Project and Dishonored. But it’s also similar to what you get in survival games. Say, Rust.

In such a game, the utility of the melee weapon is clearly defined and you can learn its rules and then make use of the tool when you find it necessary. In some games, it’s a backup. In other games, you’re a highly competent killer but you can decide not to be.

Player Activities

• Learning the tool’s rules.
• Learning how the tool complements the game’s other tools.
• Deciding when to use the tool.
• Waiting for animations to complete.

Ragdoll Melee

Video game physics can be employed in many different ways but is actually very rarely used to model melee combat. It can be used as an additive effect that detect if your blade hits a wall and that causes you to stagger or lose your balance if this happens, or it can be used to turn slain foes into ragdolls. But it’s surprisingly rarely used for the combat itself.

There are of course exceptions, with comically dynamic games like Gang Beasts and more aspirational titles like Exanima being two of them, but game physics are generally too unreliable to provide the kinds of balanced experiences we usually want from our games.

Player Activities

• Learning the game’s actions.
• Learning the rules of the game’s simulation.
• Waiting for the simulation to generate results.

Systemic Melee Combat

One thing covers melee combat in video games like a wet blanket: character animation. You are often trying to learn the specific timing of an animation, waiting for an animation to complete, or both. Not always, but often enough that the rest of this already long post will discuss animation.

If we want to make any kind of melee combat with characters fighting, we need to start from character representation and animation. How it works, how it’s used, and how we can break it down into modular systems.

Skeletal Animation

We’ll have to make concessions in the names of stability, playability, performance, and many other things affected by how animation systems work under the hood. Which concessions we make will have a profound impact on how our combat is played. It may even restrict or reaffirm the design choices we make.

Firstly, content is expensive to make. This is just as true for animations. Animator is a full-time job, or rather a whole department with many full-time jobs.

Secondly, there is a great risk that we get stuck with technology we can’t use for our intended purposes, particularly if we choose a game engine with solutions that don’t fit with our goals.

Skinned Mesh

First of all, you have your mesh. The 3D object that the game engine will be pushing out to the GPU. This is just like any other mesh, with vertices, edges, triangles, UV mapping, vertex colors, and so on. But it incorporates some extra data in the form of skin weights. More on those soon.

Skeleton

Just as with real people, an animation system has a skeleton under the skin. This skeleton is what will actually be animating. What’s neat about skeletons is also that meshes that share the same skeleton can all use the same animations.

Skin Weights

Skin weight settings can usually be painted onto a mesh and is expressed as a range between 0 and 1 that is used to determine how much a vertex is affected by the transformation of a specific bone. Zero means not at all, while one means it follows the bone exactly. Traditionally, zero is blue and one is red.

Keyframe

When the skin weights have been painted in, you can start manipulating the skeleton to be able to pose the mesh. You can then store this as keyframes and export it from your tool of choice either along with the mesh or as separate animation assets, depending on your game engine.

Blending

Once you have two or more keyframes, you can blend them together into animations over time. Under the hood, this can use any kind of interpolation. Linear, curves, easing, or some combination.

Types of Blending

Once you have the frames, you can do lots of fun stuff with them. Blending them can be done using manually assigned curves, programmatic easing functions, or any of a wide range of other methods.

Interpolation Combat: Bumping

This is actually the point where we can introduce our first type of melee combat! Bumping happens when an animated attack enters an enemy space, usually a grid space or hex. It can either result in the occupant being removed (“killed”) and the attacker taking over the space, that the attacker is removed, or that the attacker bounces back because of a successful defense.

In-Place Animation

When we build an animation loop and play it in our game engine with little regard to how the animation behaves inside the game, this can be called in-place animation or animating in place. The mesh and animation are simply loaded and rendered and left to do what they do best. Gameplay may control when a certain animation is triggered, and we may also want to use state machines or other graph tools to blend based on gameplay data. Maybe go from crouching to standing, or from walking to running.

Animated Combat: Fire-and-Forget Animation

This is the second type of combat that is extremely common. Just play the swing or thrust animation you’ve made and let it play out no matter what. Just parent a weapon to the character’s main hand and use the frame information to turn the weapon “on” for impact calculations. It can be just a single line intersection between the handle and point of the sword being swung.

Of course, this is where animations will intersect and not really respect any boundaries of the meshes involved, since that information is simply unknown.

For what it’s worth, this is often good enough.

Root Motion Animation

The issue with in-place animation is that it assumes that other systems will take care of moving the character, and this movement won’t reflect the animation. An alternative is to let the animation also drive movement using root motion. This takes the animation information on the root bone (often a hip bone or a point between the character’s feet) and lets it drive the parent transform for the character being animated. If you have something like a zombie that’s staggering, causing asymmetrical movement between different steps, this is a great way to make a character move exactly as the animation is indicating without having to painstakingly tweak numbers in a state machine.

Animated Combat: Synchronized Animation

Since we now add movement to the mix, we often need to take better care of our attacks. If a root motion-animated character attacks, there may be a forward step or lunge as part of the animation, and we could risk overstepping the actual position of our enemy. If you have played Red Dead Redemption 2 and accidentally stepped past a hitch post, only to have to turn on the spot and flail around to get the right angle to interact with it, root motion is part of the cause.

To resolve this, we can either manipulate the positions involved by moving either the attacker or defender to where it needs to be to get hit (many games do this), or we can play an opposing matching animation on the defender and synchronize the results between attack and defense. This means that we need to make a lot of animations, but it’s also a predictable way to represent our fighting and a very common way to represent melee in content-driven games. Attacker swings from the right mid-step; defender parries to the left and takes a short step back. Looks great, and solves many of our problems for us.

Motion Matching

Imagine that you don’t have just a few root motion animations, but a whole library of them. Thousands, maybe tens of thousands. If you do, you can put them into a giant search tree and feed player controls directly into this search tree to generate a matching animation based on exactly the data being fed into the search over time. At a very high level, supplemented by neural networks and other code shenanigans, this is how motion matching works. A marvellous technology, but its applications for melee combat seem somewhat dubious.

Layering

If we could only use one animation at a time, that would be problematic. If the character is carrying some kind of mission item in their off-hand while fending off attackers, we’d suddenly have to make a whole new set of animations to be able to fight while holding that item. Enter animation layers. Game engines can usually blend animations together from multiple sources using some kind of masking or layer blend weights. That way, we could override the off-hand completely to hold that mission item, but keep the rest of the animation as-is.

This sometimes leads to artifacts that don’t look great, such as weird hip rotations because of an upper/lower body blend, but it saves us from duplicating work unnecessarily.

Kinematics

Since the skeletal animation we use is limited to the premade content we have made, no matter how much or little we actually have access to, we sometimes need to compensate programmatically. This is typically done using a combination of the original source animation and additive kinematic logic. It can be used on feet to make sure that they follow the ground, or it can be used on hands to make sure that they pull the leaver or pick up the thing correctly. You can look at it as taking the source animation and making post-process adjustments to it.

There is a whole range of techniques used to achieve this, with Inverse Kinematics (IK), Forward Kinematics (FK), and Forward And Backward Reaching Inverse Kinematics (FABRIK) being the most common.

Animation Events

Something most game engines allow us to add are script cues called animation events. These can be manually placed and given functional names to let us hook into them. Commonly to provide hooks for when a foot hits the ground, so we can add footstep sounds and road dust particles, or to say that the sword swing is reaching its apex at this point and we should turn the blade “on” for impact detection.

Animation-driven Gameplay

The simple fact is: if we want animated characters, we need to start from the animation and we need to work from the limitations of that content. Some games accept this as design fact and they let the animation drive gameplay. The result of this choice is that production becomes more predictable, because we can plan out all the animations we will need, but it’s also the reason why we have to wait for animations to complete in so many types of melee combat gameplay.

Gamepay-driven Animation

If you reverse the relationship, you can drive animation with player input instead. If you think back to the root motion-type of animation, which is the exact opposite of this, imagine what would happen if the root keyframes were dictated by player input. You’d be controlling the “hip” of the character, perhaps, and then the rest of the animationw would have to adapt. It would force the animation content to be blended based on how fast the player moves and which direction they are moving in.

This is sometimes seen in certain types of games, like Carrion for example, where you play a blob that is adapted to its surroundings. But it would be interesting to see more of it.

The Dark Side of Skeletal Animation

Animation systems are amazing. But here’s a tricky fact: they’re made for animating individual objects. If an object suddenly holds or attempts to synchronise with another object, we are opening up for a million gameplay problems. If you’re crazy enough to have one of your characters sit in a chair or opening a door, it’s practically armageddon.

This is because animation systems are isolated. Anything you may want a character to hold or interact with, you pin it or parent it to a part of that skeleton. But the skeleton doesn’t care. It’ll just play back its keyframes as if nothing happened. No matter how much layering or transform parenting you do, you will always have to contend with this. Not to mention that the animation has no awareness at all about the game environment it is part of.

This clash is what sometimes gives us everything from “clipping” to the many common collision problems that we’ve simply learned to live with. It’s something you will have to be aware of if you make melee combat games.

Character Representation

With all of that animation nonsense in mind, we can figure out how to represent our character. We know that it’ll have a skeletal mesh with skin and skeleton. We know that it’ll have keyframes of animation that we can blend between.

Humanoid

A bipedal humanoid is the default for most game engines. Many animation systems use this assumption for some of the built-in functionality, such as being able to retarget one keyframe onto another skeleton. What this means in practice is that any character you want to represent that isn’t bipedal will most likely have to have its very own systems for everything.

You may also want to make humanoid variations, for example with long hair that is skinned and represented in the skeleton, or characters that miss one arm or leg. Anything that breaks the standard needs to be built or accounted for programmatically.

So ask yourself some questions.

• How many legs?
• How many variations, and which variations?
• How many poses?

Attachments

With the character represented, you have to consider what attachments you want for it. The most common ones are probably weapons and armor.

Some skeletons, you’ll add special bones for these attachments and make sure that they are animated correctly. A “right_hand_prop” bone, for example, that you can always attach weapons to. Others, you’ll animate the weapon as an integral part of the character.

The easiest is to make as few changes to the skeleton as possible and instead make exceptions on the engine-side, which is where many of the problems noted before come from. Figure out how much overlap and clipping you can accept, and then figure out which attachments you want to make.

Hit Detection

Lastly, at least for our purposes now, we need to figure out how we want to do hit detection. We’ll revisit this again later, from the weapon’s perspective, but for now you need to figure out which areas of a character can be hit and a way to communicate this.

Some ways you can represent weak points on a character’s mesh:

• Vertex colors. Maybe red represents bleeding, green represents bone damage, and blue represents armor.
• Texture mask. Same line of thinking as with vertex colors, but using an external asset.
• Collision volumes (“hit boxes”) attached to the bones.
• Joint proximity (a ‘joint’ being the intersection between two bones).
• Attack direction (inspired by something like the diagram below), where you can use an attack’s angle against a theoretical centerpoint mid-torso (near the navel) to determine hits.
• Mesh collision. Something you can also resort to, even if accuracy won’t be what you want it to be: just do a mesh intersection test between the character mesh and the weapon hitting it.

Weapon Representation

We know who we will be stabbing by now. Next is to figure out what we’re stabbing with. The implement of destruction. The weapon that you see is very rarely accurately represented.

Frame Time

One of the most common ways to represent a melee weapon is to use not the weapon itself but the frame time of the attack animation. When the animation is about to reach its apex, you turn the weapon “on” for damage purposes and if whichever other system you chose to use detects a hit, you deal damage with it.

If an attack animation is 120 frames long (four seconds at 30 FPS; animated frames, not game frame rate), maybe frames 78 to 94 are turned “on” this way, leaving the telegraphing and idle return as-is.

This can be used for more things than damage, as well. Maybe frames 94 to 110 allow you to string a second attack into a combo of attacks, and maybe you are yourself extra vulnerable to damage at frames 100 to 120 when you are returning to the idle state.

Frame time gives you a lot of room for balancing, and is a very common way to represent melee attacks.

Trace or Cast

A slightly more in-depth version of melee attack representation is to use intersection tests. Physics engines usually call these traces or casts. You can use a single line intersection test from the handle to the tip of the blade of your sword, or multiple rays out from your mace head. What they all have in common is that, when an intersection is detected, this causes a hit to be registered.

In most cases, since we tend to make really fast animations with few frames, intersection tests like these must be predicted forward in time or risk suffering from the same accuracy losses as fast-moving physics objects. For higher reliability, you can perform sweeps based on attack velocity and weapon shape rather than multiple traces.

Furthermore, what actually starts and stops the intersection test is still often frame time.

Collision Volume

We can replace the traces or sweeps with a simulated physics collider if we want. It can be a compound object, where all parts of the weapon are individually represented (crossguard, blade, pommel, etc) and individual collisions are handled differently, or it can be a single box or even mesh collider enveloping the blade.

This method is very common in rapid prototyping, since it’s typically fast to implement in popular third-party engines and makes intuitive sense. But it’s one of the most unreliable ways to represent a weapon because of the inherent unreliability of physics engines.

One potential advantage is that we can use the collider for our sweeps, since we then have a ready-made shape available. Another potential advantage is that we can gain other benefits from the physics system, such as enforcing zero-penetration or applying sliding collision against armor etc. We can also detect when to play sounds, different material properties of impacts, and so on. So it’s certainly not without its benefits.

Defense

We now have characters and weapons. The next thing to represent is defense, since no one willingly just stands there and gets stabbed. At least no one sane.

Some games don’t actually care about defense. Defense is just a flat number (like Dungeons & Dragons‘ Armor Class), and then we take turns (IGOUGO) attacking with all our fighters while you wait for your turn and keep your fingers crossed that you will have some units left to hit back with.

This is fine, if it’s what you want. But if we want to make realtime gameplay, we need to consider other aspects of defense.

Guards and Stances

Many games differentiate between “stances” based on player choice. You can switch to the X stance or the Y stance, sometimes as a counter against specific enemies or to get access to special attacks. It can also be the defensive stance and the offensive stance, for example.

It’s a good place to start since it can be part of telegraphing a character’s intent in a way that’s hard to do in a fast-paced action game. If an enemy switches to a certain stand, I can know what to expect.

Parry

Using my own weapon to defend against an opponent’s weapon is really the norm for most melee combat. It’s what fencing is all about. In games, it can be completely automatic, based on a held state (like holding the direction away from your opponent in many fighting games), or it can be an active interaction I must do with correct timing. It usually requires that switch from offense to defense actively in one way or another.

Block

Using a shield, chair, or whatever you may find and that you can put between yourself and your opponent can be referred to as blocking. Blocking attacks is not the same as parrying, since you’re not using your own weapon.

Interrupt

Hitting someone with a quick attack to stop them from finishing their heavy attack is a common feature in melee combat games. Particularly content-driven games, where you can learn which attacks are faster. Whether this means cutting them down or merely forcing them to pick a new strategy varies between games.

Riposte

In fencing, a riposte means (roughly) parrying and then hitting the opponent back using the successful parry as an opportunity. Many games, probably as popularised by Demon’s Souls and later Dark Souls, place the riposte at a specific skill-based moment between animations. If you execute a successful parry, you can then step forward with timing to execute a riposte.

Dodge

It makes sense that one of the best ways to not get hit is to avoid getting hit. Dodging means stepping out of the way of an attack before it connects. In boxing, moving your upper body away is called a fade. You can fade back from a punch and then use the distance to lean into a punch of your own.

In the Soulsborne vein, many games use a long animated dodge roll where the character throws themselves out of the way of an attack almost like a soccer goalie trying to catch the ball before it hits the net. This makes great sense in games where stamina economy is a thing, since it’s a clearly exhausting maneuver, but real world melee combat is a lot more subtle than this.

Footwork

We still haven’t attacked anyone. But we’ll get to that in due time. We now have stances, defenses, and representation of weapons and armor. Next we need to know how we move. Before we do, we need to know what the environment looks like, but I will touch more on that in a future post on combat drama since staging and therefore level design is more tightly connected to a game’s narrative context. Assuming it has one, of course.

Push and Pull

The most fundamental layer of any melee combat in games is push and pull. Push means moving towards an enemy, pushing them before you and taking the ground they previously held, while pull is backing away from an enemy and pulling them towards you. These different situations are often tied to content, and the boundaries of the arena where you are fighting will play a central role in how much of each you can do. Push too far, and you back your enemy into a wall. Pull too far, and you get backed into a wall yourself.

As you can tell, if we have a long dodge roll we need the space for, getting backed into a wall is not great. Likewise, if the enemy has a huge shield they can use to block our attacks, pushing them into a wall probably won’t do us much good as it doesn’t provide us with an angle of attack.

Note that by having different enemies require different measures of push and pull, you can easily create variation.

Circling

A common game design trope for melee combat is circling. You will lock on to a target and your sideways movement will then be relative to that opponent, effectively letting you move in a circle around them. This can be a way to communicate information by displaying the selected enemy’s health bar and armor values, or it can be a way to eliminate directional input from the combat. I.e., you don’t need to point in a direction if the game’s lock-on system is doing it for you.

Circling can also be more systemic, for example if you side-step in such a way that an enemy’s main hand can’t swing a weapon because of a wall that gets in the way (something you can do in Dishonored). It’s an interesting feature and one that is often used in film to provide room for one-liners and storytelling.

Positioning

Lastly, footwork allows you to improve your positioning. What this means depends on the game, but it can be anything from closing the distance to get close enough to use a powerful finishing move, or far enough away to use your much longer spear from a safe distance. It can also be to place yourself behind an enemy to backstab them, or above an enemy to do a drop takedown; and so on. There are many games that provide combat advantages based on positioning.

It’s not uncommon for a melee combat gameplay loop to look something like Circling->Push/Pull->Positioning->Attack; then back to Circling against the same now slightly wounded opponent or a new opponent.

Which tools you have for this and how long each exchange is depends on the game. Some games will have sprint mechanics, forward lunges or jump attacks, and other ways to change positining very quickly or to incporate positioning into the attacks themselves. For example when you attack with the energy sword in Halo: Reach, and the validity of the lunge attack is communicated by your reticule turning red.

Offense

Finally, we get to the stabbing and strangling. Just a friendly reminder that we’re still stuck with skeletal animations at this point. We’re talking about design now, but the artifacts of game engine choices from our ancient past still haunt us.

Punching

There are games that default to fisticuffs when the player has no gun ammo or lost all their other weapons. But there are also games, like The Chronicles of Riddick: Escape from Butcher Bay and Breakdown that focus a lot more attention on the punching. If you want some good inspiration, these games are excellent places to start.

Kicking

Kicks have a special place in gaming and I bet if you did a graph of current indie immersive sims underway, there’d be a higher number of them with kicking features than without. Maybe the best kicking game is Dark Messiah of Might and Magic. One of the innovative gems that acted as a precursor to the Dishonored series. In that game, the world was full of spikes and hazards that you could kick your opponents into.

But at the same time, few things are as hilarious as kicking with both legs at the same time in Duke Nukem 3D.

Swinging

Swinging includes the standard modus operandi for swords, axes, halberds, and many others. You sweep the weapon with the dangerous end intent on impacting your foe. It can be a quick attack hefting the weight of the weapon itself, or a long overhead swing like the sword equivalent of a haymaker. Many games allow you to put more or less power into your swing attack by holding a button.

Thrusting

Thrusting with the intent of pushing the pointy end of your weapon into your opponent’s body. This can be the point of your sword, the tip of a spear, or something else. Games tend to portray this as a more lethal but trickier attack to time right. Maybe partly because it’s a hard attack to do well with synchronized animation. It’s easier to just let it intersect and deal a bunch of damage.

Throwing

If you have weapons like throwing axes, javelins (throwing spears), shuriken, molotov cocktails, and so on, the act of throwing them will have to be simulated as well. Games generally don’t use physics here but interpolate between throw and hit instead, guaranteeing that a knife hits blade-first for example.

Grappling

Grabbing on to an opponent is another melee combat staple. In boxing, thaiboxing, and variations of those, you’ll see the “clinch,” where the fighters hold on to each other both as defense and offense, to deliver knee strikes or headbutts, or to block the same. With the takedowns we’ve mentioned, this can also be a way to drag an enemy close to stab them with a knife, or to hold on to their weapon and disarm them.

It’s rarely seen in video games beyond those modelling the aforementioned martial arts, since it’s a very tricky thing to do well. Synchronizing animations between characters at a distance from each other is hard enough; if you push them into immediate proximity you’re multiplying all the clipping and physics intersection issues by 100.

Hit Detection and Effect

We have pushed forward, the opponent has failed to dodge, and we’ve swung our sword against their neck. This is where we end it all! Detecting that the weapon has hit, and making something of it.

Hit Point Bashing

The probably most common way to represent melee attacks is to simply count some math at this point. We know from the frame time or intersection test that the weapon has hit, we hand over to the gameplay mathematics to deal with the rest.

Maybe the calculation is [((Strength + WeaponDamage) – Armor) * NormalizedVelocity]. Character has some strength value, the weapon deals a certain amount of damage, and we then multiply by the normalized velocity of the weapon. The total is deducted from the enemy’s hit points, health, or whatever we call it.

We can add as much as we want here. Maybe we have damage types, with different resistances and immunitie. An enemy that is immune to Piercing attacks doesn’t take any damage from the thrust we just did. An enemy wearing a specific armor maybe reduces our Chrushing damage by half.

The reason this type of system is so extremely common is that it’s simple. We can take all of the complex subtleties of our combat gameplay and externalize it from the engine. We can balance all the numbers in a neat spreadsheet with all of the formulas represensted, and we can then use whatever tools we prefer to simply put it in the game and know that it works.

Systemic

What we can do instead of simply deducting points using a formula is tap into the Stim/Response-relationship between our objects, or some other model we prefer. The weapon “injects” its stim, state, or however you prefer to represent it, and has then done its job. Whether this leads to a bounce against armor, a thud against hard wood, or a deep bleeding gash is up to the object that gets hit.

As with all systemic approaches, this requires that we have more than just the contact system in place. We need other systems to pick it up, do something with it, and also be clear enough to show the player what happened.

These complexities are why we don’t get as many of these solutions in our games. It’s harder to predict, and it’s harder to balance. But on the plus side, it’s also much more modular and using the same kinds of principles as I presented in the Building a Systemic Gun post, you can make a highly dynamic melee combat system come to life as well.

Damage

The widely played Dungeons & Dragons tabletop role-platying game got its start in wargaming during a time where simulation was a big deal. Many games model damage not just as a loss in points but as a set of consequences.

What follows here is some inspiration you can consider, no matter if you prefer a systemic approach or hit point bashing.

• Balance: damage dealt to balance won’t kill, but will make the enemy fall.
• Morale: damage to morale may make an enemy yield, surrender, or flee.
• Move speed: damage to move speed could be based on hitting the legs, and would make positioning easier against the enemy.
• Stun: temporarily stunning the enemy may mean blinding them, dazing them, forcing them to perform a delaying action (such as removing a caltrop stuck in their feet), etc.
• Feature damage: can allow you to attack the enemy’s features in one way or another. Cut off the dragon’s tail and it can’t lash you with it; disarm the enemy and it can’t hit you with the weapon, and so on.
• Bleeding: cause the enemy to bleed, suffering damage over time. According to longsword fencing instructors I talked to, this was what you often died from on the battlefield, and you weren’t always aware of it until it was too late. E.g., you were technically “dead” already, but you’d keep fighting for several more minutes until succumbing to the circulatory shock.
• Movement: feeds back into the push/pull and positioning dynamics, but many games will have weapon impacts that allow you to push enemies back or pull them towards you.
• Dismemberment: cutting off limbs is often a visceral animated response to when you kill an enemy, but some games use it as a feature damage of sorts. You cut off the right arm, they don’t have the sword anymore. It can be brutal and gruesome, or it can be the black knight from Monty Python’s Holy Grail.
• Death: of course, death is the typical outcome of damage. But it can also be more specific, like if you hit an enemy in the head, heart, or neck, and they instantly die without you having to whittle them down.
• Lasting effects: some damage could be stored and given lasting effects. If you keep cutting your enemies’ heads off, and they learn about it, maybe they’ll start wearing gorgets. They should!

Style

You may feel by now that we haven’t really talked design yet, just technology. But it must be reiterated that the technology will be what sets the boundaries for your designs and this is why it’s relevant.

But what style of melee do we want to have? We can take inspiration from the types of melee in the first half of this post, but let’s also fit the gameplay into our design. Why do we use melee?

Control

Some games use melee as a way to exert control over the field of battle, or to gain access to the next area in a level. You must kill the guards before you can open the door, or you may kill the guard so that no one will be monitoring the security cameras.

Control works best when it’s an optional feature. A permission with clear restrictions that may affect the conditions of the currently played level or even a future level you haven’t played yet.

Duelling

With animations the way they are, it’s often easier to animate combat between only two characters, or at least two characters at a time. This makes duelling a great fit, and everything from the brilliant jedi duels of Star Wars: Dark Forces II — Jedi Knight to the intense one-on-one fights of Severance: Blade of Darkness, this is a deep well of inspiration.

You can include pretty much every fighting game in the same context, and the player’s pursuit of understanding not just of the content in the game but of the spirit and skill of their physical real world opponent.

Mass Combat

If you care less about synchronizing your animations correctly, and you want volume of enemies, you can let the player be Sauron from the intro of the first Lord of the Rings film: one swing, and dozens of enemies are defeated!

Impact effect may become less important and instead you may model the morale and effect of whole warbands clashing against each other. Mount & Blade has these types of fights, where each fight is certainly tense and interesting, but the massed battle as a whole is the focus.

Choreography

The next thing you can consider is more choreographed play. A single hero fighting multiple foes and winning the day with neat cinematographic tricks, and often comedy as well. This lends itself well for content-driven games where you can have contextual animation triggers.

Imagine a well in the center of a market square, and when you kick someone they fall into it with a nice animation while playing the Wilhelm scream. That’s the kind of thing that’s choreographed, and though it can certainly be triggered by a system, it’s not systemic in any practical sense.

Flynning

The style of fencing developed for Errol Flynn’s old adventure movies, like Captain Blood that was mentioned in the post on combat philosophy, is still called Flynning. It’s melee combat that isn’t about the combat at all but a way to portray characters in an action-filled environment. Rather than trying to kill each other, the actors are actively hitting each others’ swords to the loud classic clangs of blade on blade that we still use for swordfights in cinema.

Games don’t do this as much, but the insult-based swordfighting of The Curse of Monkey Island is probably the best version of it that we have in games!

Conclusions

This post got a life of its own somehow and extended way beyond the comparatively simple and more pseudocode-heavy outline I originally had. But I think there are good reasons for this. Just like video game dialogue is essentially the same now as it was 30+ years ago, melee combat in games has become somewhat predictable.

As with so many other things in game design, we forget that we can do anything we want and end up copying the tried and true solutions from the past five years’ financial successes. This means that a new more systemic way to do melee combat would have to start from design.

My hope in finishing this post is that it may inspire someone to do something and then go ahead and release cool games that innovate game melee combat!

Or, as usual, you can disagree with me in the comments, or e-mail me at annander@gmail.com.

The biggest difference between designing a systemic game and designing its opposite (a content-driven game) is that you can’t know the exact outcome of every system and you must consider this state of mutability a strength. You must be willing to let go of your authorial control.

You can certainly define interesting interactions in advance, but a good systemic game will generate synergies that you didn’t expect. Some you will like, others you may not like. This means that designing a systemic game is about making things that follow a broad creative direction rather than a script or the whims of an auteur director. It’s a type of game where you want the player to have all the fun: not the developer or the computer (paraphrasing Sid Meier).

The following is a method I’m trying to use myself and wanted to share. It’s based on practical experience, some theorising, some experimentation, and a long line of past failures. It’s also being used right now on the first project I want to release as a solo developer, so let’s look at it as a work in progress.

The idea is to waste as little time as possible and to do away with as many assumptions as possible. Hopefully, this comes through.

Goal

Let’s first mention what the goal with our design is. There are two closely related things you’re after when designing a systemic game—synergies, and what they may lead to, emergence.

Synergies happen at the point of convergence between systems. This is the height of any systemic game—the point at which the game gains a life all its own. Once a game has enough synergies, usually by providing tools and consistent rules to players, it may achieve emergence. Unfortunately, there’s no magic sign or sudden revelation that will tell you that you have achieved this. Rather, you will need to test your game with a discovery mindset to be able to determine if there are enough synergies to reach critical mass.

Emergence is a scientific concept that we have borrowed into game design. “An emergent behavior is something that is a nonobvious side effect of bringing together a new combination of capabilities,” says Science Direct. If you look at individual cards in Magic: The Gathering, their effects seem isolated. For example Enduring Renewal, which among other effects puts any creature that gets discarded back into your hand. It’s neat to be able to play them again, but nothing game-breaking.

But combining this effect with a creature that costs nothing to play (like Ornithopter) and another card that gives you resources when you discard one of your own creatures (Ashnod’s Altar), you can suddenly generate infinite amounts of mana by continuously playing, discarding, and getting the zero-cost creature back to play to discard again. Ad infinitum. This is an example of emergence that players could discover based on the synergies of separate rules, but that were probably not intended by the developers. (Clearly demonstrated by the card Enduring Renewal quickly becoming Restricted in tournaments, limiting you to a single copy of the card in a deck.)

Words

When the following words are used in this article, this is what I’m referring to. It’s critical to keep track them, because all of them are things you can get stuck on that don’t actually makes your game any better without careful planning.

A feature is something that always behaves as expected, because it’s isolated from other features except where expressly implemented. A feature has very clear boundaries and clearly defined specific interactions that a player can learn to make use of. The biggest issue with a feature is that it’s systemically dull because it doesn’t provide any interesting interactions with other elements of the game except where the code expressly allows for it. This means that feature-rich games must generally keep introducing new features and/or provide other forms of content to keep the player interested. It’s the bread and butter of content-driven games, but completely antithetical to systemic design. Unfortunately, features are what we most often design.

A technology is primarily developer-facing. Confusingly, you can still refer to technology as “systems,” but a technology rarely solves any product-level problems. It’s the character system that renders and animates characters, or the procedural generator that spits out playable levels. It may be required to make your game happen, but technology requires tools and extra work before it can produce any tangible player-facing results. It’s therefore risky to work primarily with technology if your goal is to make a game.

A tool is something that packages a system or technology. But the tool itself is never going to make anything better. There needs to be a plan for who will work in the tool and what the output of the tool is supposed to be. If not, you will be accumulating what I call “work debt,” where you are pushing the actual work forward while you make the tool.

Furthermore, a system on its own can behave much like a feature does, except it’s usually harder to make and therefore makes little sense on paper. The real magic doesn’t happen until you combine systems in interesting ways, meaning that a systemic design will only be worth it when you have multiple systems interacting. Building just one system on its own becomes just another name for technology or feature.

TL;DR: Features can be listed and planned for but provide zero overlap. Technology won’t give you anything without additional data. Tools are usually necessary but won’t do anything if no one works in them. Systems can only achieve anything when combined with other systems. You will have to address the shortcomings of all four if you want to develop systemic games.

Components

We must also know what our design needs to deliver. Since it’s more or less impossible to design synergies directly, we’ll be designing for synergies instead. This is different from writing specifications or feature lists. To design for synergies we need to set everything up in such a way that it can interact and that all those interactions point in interesting directions.

Verbs

It’s almost cliché to talk about verbs in game design, but for good reasons. Verbs represent the fiction we’re presenting to our players. They’re not pressing or clicking buttons; they’re dancing, jumping, fighting, kicking, biting, eating, building, and so on.

An important part of designing verbs in modern game design is that it doesn’t imply control schemes. Instead, you should describe the actions represented in the game and you can then map that to whatever input your target platforms support or your users customize. If that’s touch input, controllers, mouse and keyboard, something like the Microsoft Adaptive Controller, or something else, this can remain abstract while you design the game.

Setting and Locations

You don’t learn all that much about Tatooine when you watch Episode IV. It’s a desert planet, there are moisture farmers and there’s a limited Imperial presence because it’s in the Outer Rim. This is part of the setting of Star Wars. The cantina where Han shoots first is a location.

Think of the setting as the frame and the canvas of the painting as the location. In a game like Tetris, the setting is a vague Russian theme implied by the artwork while the location is the boundaries of the area where you can place playing pieces. In something like Gothic, the setting is a fantasy world with orcs and swords, while the locations are specific cities, roads, clearings, etc.

Oh, and for Thief: The Dark Project, since I always fall back on it anyway, the setting is The City, and the locations you play are the individual levels.

Objects

Systemic design is object-rich. Object is the broad category of every interactive thing that exists in the game’s simulation. The high level object in your game engine can be a GameObject, an Actor, an Item, a Token, and so on. I call them simply “objects” here because it’s a neutral term, but many engines reserve this specific word for engine-side shenanigans so it can be helpful to come up with another term for your specific game.

Characters

Characters don’t have to be standing on two legs or talking. They can be animals, space ships, suicidal scifi-doors, a metal crate with a heart on it, or something else. All of them are characters.

Captain Reynolds in the Firefly show is a character, but so is the space ship Serenity. An individual guard can be a character, but in most functional ways (such as who likes who) the City Watch faction is also a character. It helps you to think of it this way because it will help you define rules later on.

• Objects that can interact with and react to other objects in meaningful ways.

Props

Props have no agency. They are the levers, items, guns, refrigerators, and inanimate mining blocks that characters interact with. How your design relates characters to props can be interesting, since it runs a wide range from simple MacGuffins that are never actually interacted with but merely sought after, to utility items. Props can be possessed by characters, activated by characters, destroyed, etc. More on this type of stuff here.

• Objects that can only act on other objects by being triggered by a character.

Devices

A plot device is also an object. A piece of state that may inform a game’s narrative layer, such as “the king is dead,” or stated facts such as “the roof is on fire.” The difference between a device and other objects is that a device doesn’t have the same type of representation in the game world. It’s something that informs the simulation but isn’t manipulated by characters directly.

• Objects that have no representative form but still affect the game’s state-space.

States

The state-space is something I’ve covered in various forms multiple times. This is because it’s what makes a game happen. I won’t be reiterating things stated elsewhere, but will repeat an image from the linked post:

Rules

“Every complex system starts as a simple system that works.”

Amy Jo Kim

When you have all the components, you need to decide how they interact and you do this by writing rules. Unlike a board game, we won’t require our players to read the rules. Instead, we must make the rules so clear that they make intuitive sense.

Thief: The Dark Project has its rule that rope arrows attach to wooden surfaces, for example, while The Legend of Zelda: Breath of the Wild (BotW) takes its cues from “natural phenomena or basic science facts,” according to its developers; wood burns, metal leads electricity, wet rock gets slippery, etc.

Rules can be divided at a high level into permissions, restrictions, and conditions.

Permissions

A permission allows something. Permission to move into new rooms. Permission to climb ledges. Permission to collect gold. Permission to jump, open doors, kick people in the chest, build kitchens, train horses, respawn after getting killed, and/or eat hot dogs.

Each permission also has a defined outcome. It’s like an “if”-statement in programming. If you activate the door, the door will open. This is an object-level interaction; a character (your player avatar) activating a prop (the door).

• Permissions define character-prop or character-character interactions.
• Permissions define outcomes to said interactions.

Restrictions

A restriction can be an exception to a permission, such as being unable to open locked doors without unlocking them first, or it can be a more general restriction such as not being able to open doors that are locked at all or having to stay inside the boxing ring or you get disqualified.

This last part is important, because a restriction also needs consequences. The consequence can be that the game simply disallows the restricted thing, but it gets more interesting if the consequence has a playable effect. You can climb wet rock faces in BotW all you want, but it will be a frustrating and Stamina-draining experience compared to waiting until the rain passes.

• Restrictions define exceptions to permissions.
• Restrictions define consequences to attempts going against them.

Conditions

Lastly, conditions are the rules that frame everything else. Things like how a game starts or ends, or how you win or lose. This isn’t always tied into the permissions or restrictions of your game, but it can be. For example, it could be that after you’ve opened all the doors the game tells you its narrative secret and is then over. A condition can also be the rain in BotW, that modifies the state-space on a global level.

• Conditions define framing for permissions and/or restrictions.
• Conditions define high level rules for the game state.

Designing Systems

“It’s not about how clever and creative you are as a designer—it’s about how clever and creative players can be in interacting with the game world, the problems, and the situations you create.”

Warren Spector

Game design risks becoming a kind of introspective navel-gazing at its worst. To prevent this, one way is to divide it into six separate stages with clear practical deliverables at each stage. You can meander a bit between stages, but you can never go back to the first three stages once you have passed the Commitment stage. Then you must stop entirely with the “fluffy” parts of design.

One reason is that you actually need all these stages. If a coworker asks you to deliver a finished design before you have been able to pass through Exploration properly, you are likely to commit to something half-baked that may have to change down the line. This costs time and money, and easily causes frustration.

Stage 1: Ideation

In ideation, we ideate. For a systemic game, this is about identifying the components and rules we think that our game needs. Contrary to most developers’ gut instinct, this isn’t the time to write code or build prototypes—it’s a time to figure out what systems you need. Writing the code is about turning a design into something concrete, but if you do this too early you will miss important pieces of the puzzle and you are likely to waste a lot of time on things you don’t actually need. This is where a heavy emphasis on technology often comes from.

Core Idea

Whatever concept you choose should be used to inform the rest of your game. Part of Thief: The Dark Project‘s genius is that you can adopt the game’s mental model straight from the title. You’re a thief—you will pick pockets, steal valuables, burglarise manors, etc. All of it makes sense.

The core idea can start from many different types of concepts but will be informing everything you do and therefore needs to answer the 5W+H questions around your concept. It needs to tell a story, not as a narrative but to provide a mental model for the player.

Some examples of what you can start from:

• A conflict: winning the race, the tournament, championship, etc. Not always as clear-cut as this. Many survival games fall into this, since you’re competing against nature from the perspective of classical literary conflicts.
• A role: the thief, the bodyguard, the soldier, the news reporter, the paladin, the cat lady; whichever role you set, it’s one of the most powerful core ideas you can have and will help you figure out all the other things much more easily. Think of what mindset you want the player to have; what role-play you want them to get into.
• A goal: finding your missing parent, delivering your dead wife’s ashes, avenging your murdered family; you can let a strong goal define much of what your game is about. A game about vengeance is likely to be violent, for example.
• A story: starting from a narrative core idea is actually quite dangerous for systemic games, because there’s a great risk that you start writing scripts and having assumptions about what the players will be doing, feeling, etc. But having a few central beats, factions, etc., that you start from can definitely help, and is also where you’re bound to begin if you are using an existing IP. Approach it how you can write an adventure for tabletop role-playing games: prepare the premise, but don’t prepare the plot.

Activities and Resources

Given the core idea, you need to figure out what the main activities are. The things you do all the time as the foundation for the game. Avoid making this a list of features, however. Write verbs at a fairly high level at first. “Fight,” for example; not “Quick Attack, Heavy Attack, Low Attack,” etc.

You’re working from a fiction to start with and should avoid contaminating your vision with game parlance for as long as you can. Most definitely avoid genre labels at this stage, because the conversation that follows convention will always be one about definitions, and this conversation won’t help your game design.

Connected to your activities, you want to figure out the key resources of your game and how they are handled. A resource can be health, time, stamina, gold, or something else. Every game has some kind of resource.

With activities and resources summed up, you move on to the rules. Permissions, restrictions, and conditions. What happens if you run out of the resource, or gain too much of it. How the resource is regained if it’s lost, if it can be regained at all. How the game ends, how it begins, how the resources designed progress through that flow. Once you know what can go wrong, you figure out what happens when things don’t go wrong and how that can be used to incentivise the player.

Systems

To be able to start exploring you need to sum up all the systems that must be tested. Keep this simple at first. If your game is a driving game, it’s likely to have a system for car customisation (a Car System), one for driving (a Driving System) and another for the track (a Track System). That can be good enough to start with, even if you know that there’ll have to be a Competition System to keep track of the score and lap count, as well as an Opponent System that drives AI cars on the track.

Also note that systems aren’t exclusively about gameplay. Depending on the size of your team, you will also want to explore technical art systems, animation systems, sound systems, and systems related to all other areas of your game

• A list of high-level systems that you will be trying out in Exploration.

Stage 2: Exploration

Once we know what we want to be immersed in, we can move forward into exploration. The trickiest part of all comes up here: it’s impossible to test synergies without multiple systems to synergise. This means that exploration will take longer for a systemic design than for most other types of games. It also means that you can’t test things in isolation, because it won’t tell you anything about the validity of your design.

Many game projects plan the bulk of their time for production. Making levels, assets, content. For a systemic game, since exploration and preproduction are more time-intensive, you need to put a much bigger emphasis on exactly those areas.

My ideal is to put 50% of your time into prototyping/preproduction and wait until the second 50% to do any production. In reality, this is rarely feasible because of hard deadlines or stakeholder demands. (Incidentally, one of the many reasons I think gaming has been afraid of systemic development for a couple of decades.) But at the very least, make sure to put a lot of time into testing your assumptions. Because some of them will be wrong, and you don’t want to find this out after having already spent all your time and money.

Analogue Prototyping

Some of the fastest prototyping you can ever do is analogue prototyping. Using wooden cubes, dice, and perhaps some printed cards or tables to represent dynamics you want from your systemic game.

What’s great about analogue prototypes is that you can represent complex processes using very simple mechanics. If you want a few different outcomes from a fight, for example, or want guards or animals or something else to behave intelligently, you can simply use another player to represent the choices they make. Give that player a card or sheet of paper that lists their options, and you’ll be able to try things out within five minutes.

You can make role-playing games that rely more heavily on imagination, or you can make playable board game prototypes. For same games, such as digital card games, you can prototype the whole game in analogue form and get a fairly accurate representation of how it’ll work once finished.

Prototyping

You can put something together in exploration that demonstrates a very specific mechanic and nothing else, or explores just a couple of different systems. What’s important is that you do not keep this around after it has proven what it was made to prove.

A throwaway prototype should never take more than a day to build. Preferably even less. On one project, I had an idea to make a camera that would automatically make sure that all important points of interest remained on-screen. My idea for doing this was to have the camera automatically keep a bounding volume’s min and max corners on-screen and to adapt camera placement and zoom if the size of this bounding volume changed. When points of interest were added or removed, the bounds would be resized to encapsulate all relevant points of interest.

This took an hour to write and demonstrated the idea. Whether it was successful or not was a discussion with the team. It still clearly demonstrated what I had in mind.

One reason to do things this way is that it’s not speculative. Even something obviously broken or half-baked can sometimes prove an idea, whereas a long meeting can’t really prove anything and more easily boils down into a polarised argument.

Have an idea? Try it, evaluate it, make a decision on it, and move on. This is what exploration is really about.

Proofing

In printing, a proof shows you an accurate representation of how a design will look like when professionally printed. This is done to make sure that the material feels right, the colors look right, and so on.

The same line of thinking can be applied to systemic design, where a proof demonstrates the validity of a specific system. You shouldn’t delve into the synergies or other properties of the system at this stage. Only the system itself.

If a system proof takes more than a week to build (maybe up to a month for something that’s bigger or more complex) you’ve probably moved into tooling or even production without noticing and should move on to the next proof. But before you move on from a proof, you need to agree on how and where it fits and also list all of the improvements you will need to make during production. This is where technical literacy becomes a prerequisite, because many of the improvements that are needed will be immediately obvious to the disciplines involved but can be deeply esoteric for everyone else.

Let’s say you’ve built an animation system and it’s working mostly as intended, but it still looks glitchy, doesn’t always transition as intended, and feet are sliding across the ground. Most of the solutions to these problems are self-evident, even if they will need work. At this point, you shouldn’t fix them. Not yet. Start building your production backlog, so you don’t forget them. That foot sliding will be handled using root motion and inverse kinematics on the feet, maybe. Note that down. Just don’t get stuck. You want to prove all the systems you have intended for your game before you can fully grasp what you are making.

Build a proof to “good enough,” then move on to the next one.

Merge Checkpoints

Because developers sometimes get tunnel vision and go on mental journeys both far and wide, it’s important to focus back on the product you’re making now and then. A merge checkpoint means a couple of weeks of putting everything done so far together into a cohesive whole. This exercise is always useful, and doing it semi-regularly is crucial to avoid project fragmentation during a long preproduction. It can also help avoid buildup of unnecessary technical debt, since unrelated proofs may start straying too much in different directions if they are left isolated.

The most important part of this, and why it needs to be part of exploration, is that it reminds you of the product you’re working on. It’s too easy in game development to get stuck watching nothing but what’s on your own screen.

Stage 3: Commitment

You will spend a lot of time bouncing back and forth between Ideation and Exploration, until you feel that you finally understand the game you’re building (or time runs out). Then it’s high time to commit to what you are making. To finalise your design.

When the commitment stage is done, you can never go back. What you’re committing to is the product that you will be building. There are many reasons to put a hard line between ideation/exploration and what comes next, not least of all that many game designers have a really hard time stopping.

Facts

With prototypes thrown away and systems proofed, it’s easier to reach conclusions. The smallest possible unit of agreement is the fact, where we can say something like, “the player kills enemies using guns” or “the player character is a llama whose name is Lola,” because those are things everyone on the team has agreed on. But it needs to be specific enough to be workable.

Once your list of facts gets longer and longer, you’ll realise that you’ve suddenly designed your game one tiny incremental decision at a time. There will also be synergies coming up just from the associations you can make from individual facts.

Pillars

A pillar can be likened to an Internet meme. The idea is that you can have stated goals with your design that can be communicated across your team and used to validate every single decision that gets made. It can’t be too generic (“fast-paced”), but must be continuously reinforced and referred back to until everyone understands what it’s about.

Twenty (!) years ago, when we worked on a small school project, we used the term “high-tech low-tech” to talk about a science fiction setting where we’d mix Mayan influences with space ships. This meme stuck to the point that it almost became a joke, but that was good for the project since it meant everyone could align around it. So don’t feel bad if your cool grimdark design pillar gets laughed at. In fact, it can actually be even better than the opposite.

Object Map

These games are object-rich, as we know. A large part of systemic design is to be able to apply conceptual models to objects in a simulated world. To be able to do this, you need to map out all of the objects you will have in your game.

If you want, you can do a bit of object-oriented thinking here as well. Consider if something is-a or has-a. A goblin is an enemy, for example. The goblin also has a weapon, a helmet, and maybe a dream about retiring to live with their family on a remote farm some day.

You can also add some character and/or story context by adding what characters may want. This way, you will often be able to spot conflicts and the like completely naturally, or fill them in where they are missing. If only one character wants a thing, there’s no conflict there, so maybe you can just skip the thing or add conflict.

Just remember to keep things short and to the point.

State-Space

With all of the objects mapped out, you can also map out all the states that these objects can be in. I like doing this as part of the prototyping, because it means both that I can respect encapsulation in code and that I can build things fairly rapidly. It’s also a good way to enable layering, so I can turn things on and off and test other things in isolation.

When you map a systemic game’s state-space, you can’t be too specific however. Leave room for inputs and outputs; allow the state-space to be flexible. For example, even if the player is in the Vaulting state as illustrated below, it should probably still be possible to get shot, hit by a trap, decide to fire a gun yourself, or whatever else the game may have on offer. You will start seeing many of these cases when you map your states.

Rules

With all of the exploration you’ve done by now, you should be ready to write out all of those permissions, restrictions, and conditions that we talked about. At this point in your exploration you know what your game is about and you know how this can be communicated to players.

A rule can be, as was alluded to previously, “you can always fire your weapon.” Clever readers among you will of course understand that this is really close to a fact, so the first thing you should do when you try to finalise your game’s rules is to go through all of your facts and see which ones are also rules. Some of them often are.

The difference is that a fact is merely an agreed-upon thing in the game design, while a rule is something we need to teach the player. A player-facing fact, in a way.

Possibility Space

With the object list, state-space and rules designed, you will see the full game emerge. What can be called the game’s possibility space is the combination of the rules interacting with all the objects and their states. Since we’re about to commit to this game and push it into production, it’s highly likely that you will want to control this process.

For example, “you can always fire your weapon” clashes with the two-handed carry heavy object state. Also, something needs to happen if you don’t have a weapon and try to fire it. In many of these cases, you will want to make exceptions. They can be for visual reasons, for example that it doesn’t look good to have someone fire their pistol while carrying a heavy object. It can also be for reasons of “nerfing,” and that you feel it will become too good or not good enough.

But here’s a crucial truth with systemic design: you need to let go of this authorship. Let go. Let the possibility space be an amorphous thing that you can’t quite control, because it’s the players who should be having the fun.

One-Page Designs

One of the best game design talks I’ve ever seen is Stone Librande’s talk on one-page designs. For systemic design, this pairs incredibly well with Aleissia Laidacker’s talk on systems if you want even more background for how this all comes together.

This is, finally, what your output should be at the commitment stage. You should write one one-pager for each system and for each component, rule, and so on, until you’ve covered all of the facts, resources, inputs, outputs, and feedback hooks in your game design.

While writing one-pagers, it helps to establish a standard. Maybe you’ll capitalise words to show that those words are the headlines of other one-pagers. The neat thing about this is that you can quickly iterate on your one-pagers down the line, by simply bumping up the version number and/or update date and replacing it with the new one. By keeping every responsible developer referenced on the one-pager, you will also facilitate information sharing and work process.

I personally swear by one-page designs, but it’s really important that you don’t rush into making them. Do the ideation and exploration properly, then you can sum it up as one-page designs.

One nice touch to make it more visible when something is changed is to add a colored line to the edge of a one-page design paper each time it’s upgraded. This way, people can quickly see that the previous one-line design suddenly has two lines and that they should take a new look.

The Design Board

A design board is a whole mosaic of one-page designs that describe all object interactions in your game. It can be added to, updated, and used as a live document more easily and much more visibly than most other methods of immortalising game designs.

In an ideal world, you can have all of the one-page designs printed out and placed on a wall somewhere, but something like a Miro board is often more practical.

How you place your designs on a board is a science in itself, since the relationship between one-page designs isn’t always clear-cut. If you have Prop as a design, and Weapon is a type of prop, how do you then place the Rocket Launcher that both is a weapon and spawns rockets that are potentially also pawns?

As with so many other things in game design, how you prefer to organise your design board will be up to preferences, space, and some experimentation. But once you have this board completed and you feel that everything is present that will be a part of your game design, you’re done committing, and it’s time to make and deliver this game of yours.

Next Steps

The savvy reader will notice that we’re only covering the first three of the six stages. We’ve talked about letting go and learning to love it, and we’ve gone through a whole slew of terminology that will aid you in designing systemic games.

Unfortunately, there are no shortcuts for the next step. To learn how to make systemic games, you must make systemic games. Designing, planning, and finishing systemic games. I will get into the delivery aspect of this process, and the three remaining design stages, in a future article. But for now, you need to get out there and make systemic games.

Unless you send me an e-mail at annander@gmail.com and ask to pay me to do it for you, of course. Or simply to tell me how wrong I am. But I want to play more systemic games, so hopefully you’re now running off to make them!

This is an unplanned Part 3 in my series on gamification and goes into loot. Itemised rewards. Maybe the most compelling of all reward systems that games have yet to use, so it’s possible that it was simply too obvious to be included the first time around.

Designing a reward system is a ton of fun, but not easy. Particularly since players will often chew through what they’re offered much faster than our predictions say.

Here I’m hoping to provide you with the pieces you can use to make your own.

Loot

Whether you look at Wizardry, or any other early game with items in them, inspiration was often taken directly from the first few editions of Dungeons & Dragons. These set a standard of common items with simple numeric differences, like the amount of damage dealt, paired with magical items that provide bonuses on top of these differences or introduce unique features.

Many of the staples of OD&D are still common. Including the +X modifiers to weapons and armor, the Bag of Holding, and so on. Items players have looted from the pockets and treasure troves of dead monsters since 1974.

This is ostensibly where the word “loot” comes from, as well. You killed the kobold and then looted its corpse. It’s not a great word from an ethical perspective, but neither is murder, so we’ll let that slide for now. Some words in gaming lingo are simply here to stay.

Operant Conditioning

We can’t talk about loot without mentioning B.F. Skinner’s experiments and what many refer to as the “Skinner box.” This box is actually a complex contraption with multiple options. It can have levers, buttons, blinking lights, electrified surfaces; all of them intended to test various ways to see how animals like rats and pigeons react to various types of stimuli.

One interesting thing with this box is that it has demonstrated the addictive qualities of random rewards. The so-called variable ratio reinforcement schedule is a type of operant conditioning where random rewards creates an incentive to keep playing, because just one more pull may give you a reward.

This is far from the only thing Skinner demonstrated using his box, but it’s the one thing that video game designers tend to focus on, and also in many ways the most problematic one.

Gambling

We also can’t talk about loot without mentioning its relationship to the design of gambling games. Slot machines, one-armed bandits; you know of them even if you don’t know them. Gambling games are built to make money for the casino that hosts them. The “house.”

Out of all the money put into something like a slot machine, around 5% is kept by the house. This means the Return To Player (RTP) is 95% of the money spent. Winning has the interesting effect on human psychology that we think we’re “lucky,” or maybe even on a “winning streak.” But you’re only getting 95% back over time—so that psychology will push you into losing 5% over and over until you run out of money. You can definitely make money gambling, but it requires you to go against the impulse to keep going when you’re doing well. It goes against your operant conditioning.

For video games, this same dynamic is not always tied to monetary value, since many countries have special regulations around gambling, but is instead tied to your time. You will play the game hoping for some specific reward popping out of the variable ratio schedule, but you will ultimately only get 95% of your time’s worth. Never quite what you hoped for. Why? Because “just one more game” or “just one more dungeon” is what the design is there to make you feel.

What to Award

Most of us probably think of items, like guns or armor or potions, when we think of loot. But when you work with a reward system it helps to think less of the visual representation and consider what you are providing the player with instead.

Progress

Gamification thrives on progression systems. Nothing new there. This means the cheapest reward we can give our players is some more points towards one of their several progress bars. It can also be unlocks of additional world areas, more rewarding variable schedules, or something else.

You typically want to have at least three levels of progress going: one tied to your second-to-second micro progression, another to your minute-to-minute macro progression, and a third to the hour-to-hour meta progression.

That way, the player always has something that’s close to unlocking. Not only to keep them playing but also to make them come back after ending the play session.

Biscuits

Some games have collectables or other types of “biscuits” that you can pick up that don’t really provide any value except for completionists. It can be fun to discover them but they won’t give you anything substantial beyond the brief satisfaction of finding them. Many games will pad their reward systems with biscuits as foiling for more substantial rewards.

Score

One type of reward that can feed into external systems is point scores. It can be competitive, for example as a high score system, or it can be entirely for your own benefit. It doesn’t have any impact on the game itself, which makes score a fairly cheap type of reward. The trickiest thing is to balance the scoring itself so that it feels rewarding and isn’t just an abstract layer of numbers on top of everything else.

Currency

Currency that has no tie to real-world money is usually referred to as virtual currency or soft currency. This is your gold and silver coins that are part of the game’s closed economy and usually balanced so that it follows the general progression curve of the rest of the game. In other words, buying the most expensive items will happen in the later stages of the game.

Many modern service games also have a premium currency or hard currency, which is tied to real money. Not all games hand these out as rewards and games that do usually hand them out in tiny amounts that won’t let players purchase anything but are designed to incentivise players to buy more.

Modifiers

In a system with balanced mathematics, you usually have several different layers of numbers. First, you have your baseline number which you can use for balancing purposes. Then you have the attributes applied to something like a character class or enemy. Thirdly, and what is usually represented by items in a loot system, you have your modifiers.

A modifier is something that gives you an extra boost in a specific area. Say, lots of fire damage, or an increased chance of finding more virtual currency. These items can become very attractive for players wanting to maximise the efficiency of a specific build. Maybe their gold farming build in the case of the additional virtual currency example.

Features

Beyond having only the numeric differences of a modifier, rewards can also provide unique features. Many games that have this type of reward will reserve it for their highest reward tiers. It’s also often combined with other rewards, but we’ll come back to the concept of combination later.

Boosters

A booster is something that provides a considerable advantage to something else, usually on a limited timer. The traditional form is the video game powerup—think of quad damage in Quake that makes you deal four times as much damage for 30 seconds—but modern service games often tie it more strictly to progression.

Double XP for 24 hours. Increased drop rates for one hour. An extra 25% experience from kills for two minutes. Since they are limited, they represent a type of reward that can be handed out in identical form more than once and is therefore good from a development standpoint. Make once—use forever.

Collections

There are many types of collections, including the item sets of some MMORPGs that provide stronger bonuses or unique features if you manage to collect all of the items in a set. There are also collections where you have empty slots clearly displayed and your reward as a player is to fill those slots one by one.

Improvement

Sometimes, what you find isn’t a thing in itself but a means to make a thing you already have better. An improvement. This reward may allow you to choose what gets better, letting you specialise on something you enjoy doing, or lift something up that is lagging behind in your character build.

Reagents

In the Ultima games, you used reagents to learn new spells, so I’ll use the term here to represent any type of item collection that has no immediate use except as a smaller part of a larger puzzle. Once you manage to collect all of the reagents you need, you can make something from them.

Early in Minecraft‘s history, you had to play the game and experiment to find the different shapes to craft different items. Today, you have a book of recipes included in the game. The first creates interesting exploration while the second provides goals to aim for while playing—both are ways to incentivise collection.

Flavor

Some rewards are for fun, as world-building, or provide other types of flavor. The many books and scrolls that you can read in the Elder Scrolls games are an example of this, since only specific ones are needed to finish the game’s quests. Flavor can be combined with other reward types, of course. But it can also be a reward on its own.

Cosmetics

Some items make no concrete difference on the game, have no playable effect at all, or have the same playable effect as other items. In many free-to-play games this is a popular model because it isn’t pay-to-win; and games with considerable content churn often rely heavily on cosmetics since it’s “just” art and usually doesn’t require any dedicated code support.

Handing out this type of reward is sometimes controversial, since it can feel for some players that they get less value. It’s also not cheap necessarily, for you as a developer, since you will still have to make the content before you can offer it and offering lots of cosmetic rewards has a sizeable overhead. But it is safe in terms of affecting your game’s balancing.

Sources

The next step is where to get all of these rewards. How they are awarded. We need some ways for the player to figure out the sources.

Containers

You open the chest, then grab what’s inside. Some games may have specific interactions or even require resources, like keys, to allow the opening of some containers. Others pepper containers all over the place.

Piñatas

A piñata is a paper animal that you hit with a stick until it breaks and its candy stuffing falls out. In other words, it’s the exact same thing as enemies in games with loot. You hit them until their stuffing falls out. Think of it as a container with a health bar instead of an interaction prompt.

Vendors

Strictly speaking, a vendor is merely another type of container that also has a sink attached to it. They may charge you money for something, or require that you progress far enough in one of the game’s systems. Say, a reputation or quest requirement. The neat thing about them is that they can be upfront with what they are offering.

Quests

Thank you for liberating our village, adventurer. Here’s 25 Gold for your trouble. Also, feel free to peruse my shop. Health Potion? That’ll be 10,000 Gold. Completing quests is a very common way to get rewards, but games handle the rewards very differently. Some games give you their biggest rewards for completing “milestone” quests that wrap up whole stories. Maybe most prominently older Infinity Engine games, like the first two Baldur’s Gate games. Other games hardly give you anything.

It’s common in service games to lock specific types of rewards—like endgame currencies—to quests or missions of a specific type. You may have to do blacksmith quests to get iron, for example.

Scheduling

Welcome back! Here’s [500 Gold] and [Common Sharpened Stick] because we love you so much, dear [insert name here]. These types of sources are extremely common on mobile games and usually have a 30-day schedule, where each day beyond the 30th may continue handing out rewards but not of the same substance.

This format comes straight from 1-7-30 retention ideas. That you need to put extra effort into having players come back to your game after the first day, first week, and first month. This used to be an integral part of the strategy in early mobile game design but isn’t always part of it anymore since the life cycle can be much shorter now. But it’s there to create a kind of scheduling effect to get players to return to the game.

Ladders

Another type of scheduling source is tied to in-game activities rather than time or to both at the same time, and can be likened to a ladder. This is functionally the same thing as unlocking things with level progression but has become tied more to external rewards and longer durations. Things like season passes and battle passes are examples of popular ladders.

A ladder can run for a limited time, be tied to your selection of character class, or something else. The important part of it is that it gives you something to strive for down the line. You can plan what activities to engage in to get there faster. There’s also often a monetary aspect where you can pay real money for faster progress or access to greater rewards.

Packs

Some games have had different kinds of packs for decades. Few Magic: The Gathering or Pokémon fans would get mad because you’re selling them packs of cards. Maybe most of all because the printing process is quite candid. You know that you will get 15 cards in a Magic booster and exactly how many of those cards will be rare, uncommon, or common.

In the digital space it gets trickier and easily gets much closer to gambling when players are able to spend real money on virtual items. This is a controversial space and for good reason. Because at the end of the day, that random stuff you’re paying money to get is already on the disk or in the download. It’s already embedded in your software. For a big box collector such as myself, this sale of stuff that’s already part of the game I paid for feels somewhat unnatural. Even unethical. But it’s definitely here to stay.

Gathering

One type of source that’s common in role-playing and survival games today is the concept of gathering. Picking flowers, collecting hides, bones, and all manner of natural resources that you can then transmute into something else using a recipe of some kind.

Gathering as an activity can be tedious, but is also one of those user patterns that feeds our primal hunter-gatherer instincts and can actually provide a brief sense of satisfaction even after hours upon hours of extended play.

Sinks

Any economy system in game design that only adds resources and never takes them away will generally run into one of three broad categories of problems:

• The player runs out of things to do,
• The value of the resources is diminished almost to uselessness, or
• Something they find is so good they don’t care about any other things after that.

The first often leads to the second. When you see that the players burn through everything at a rapid rate, you decrease the rewards, you increase the health numbers, and you introduce other types of friction to prevent the player from causing the first problem. This has a very high risk of making the game boring to play. A good reward system shouldn’t make it this obvious.

The third problem may happen in any game where what you get is tightly bound to how far you have progressed. Many other types of games suffer from this same effect. In almost every edition of Warhammer 40,000, for example, fans will complain that the most recent army book (called a Codex) is the coolest and weighs the balance towards the new kits players will now need to buy.

What you can do to decrease the chance of these problems is to add sinks of different kinds. Friction built into the design to drain your resources using different types of patterns or relationships to other resources.

Cost

You must spend some accumulated resource in order to make use of the reward. Can be to pay to identify the newly found magic item, or a cost in time to get to a specific location in an open world to have it properly unlocked.

Usage

Usage wears the thing down. This category includes ammo, durability, fuel, spell slots, and so on. But not consumables! Those are their own category of items. This is about having the active use of an item consuming the usage of that item over time, sometimes to the point that the item’s use is diminished, becomes useless, or even that the item is destroyed if you push it too far.

Cooldown

This amazing new thing you just received can only be used once every 30 seconds, hour, day, or week. Then it becomes inaccessible or its effect greatly diminished until that timer has run its course. This is largely an artifact of server latency and putting balancing ahead of immersion. More so than it’s good design. But it works, and it can definitely be the right solution for some types of games.

Diminished Returns

If every use of a reward is equal then use of the reward will usually stay linear. Diminished returns means that the first use will be powerful but that every subsequent use will provide slightly less. Imagine a gun that does full damage on the first shot, but then each shot after that does only 95% of the damage of the previous shot. Over time, shooting becomes almost completely useless. This pushes the player to shoot more in order to get the same effect, draining additional resources.

Conversion

You need three flawless gems and some gold to create one square gem, and then three of those to create one flawless square gem, and so on. Conversion sinks will generally use more of X to make fewer of Y, which is what makes it such an effective sink.

This serves two purposes:

• It funnels your early game items into the late game, by simply trashing the early game drops and pushing them forward.
• It always costs more than it gives, meaning that it’s an effective resource sink.

Progress Churn

Finding an amazing early game weapon means little once you’ve progressed further into the game and made it useless next to its higher-level equivalents. This may not feel like a sink, in reality, but it’s definitely a sink. As with all progress, it doesn’t have to be about resource sinks however but can also be about teaching the player how to play the game.

All or Nothing

In many games with multiple types of resources, such as free-to-play PvE giant Warframe, it can be valuable to play modes that lets you push further. Play just a little bit more to potentially get even bigger rewards. This sets the stage for a kind of game show situation, where you can choose to push on but will then risk losing everything. This is an amazing sink, since players will often overestimate their skills. But it also requires careful balancing, since it may also risk pushing them out entirely.

Rarity

Rarity is one of the most common ways to limit resource accumulation. It works in two ways. Firstly, it plugs directly into that Skinner-boxed variable-ratio reinforcement schedule we mentioned way back at the start. It may therefore make us want to play more. Second, trash items serves the purpose of making us want the cool items more. Finding all of those common things before we find our first rare one makes the dopamine high higher.

Seen as a sink, rarity means we don’t have to give you as much of the better stuff as we give you of the trash stuff. It means we can sit on the cool stuff for longer and therefore make sure that it doesn’t even enter the game loop in the first place.

Time

One common sink today is time. Making something time-limited and then removing it. This can be a season that runs for a couple of months, or it can be a booster that stays active for a minute. They’ve all been mentioned before, and they’re very common sinks because they can be arbitrarily added by us as developers to anything we feel like.

Consumables

You can also consume the rewards on use. They are your health or mana potions, magical scrolls, hand grenades, and other one-time effects. Once used, the consumable is gone. It means you need to hoard whole stacks of them to retain access to whatever it is they unlock.

Consumables may have one-time effects, like the Town Portal in the image. They can also be boosters, for example doubling your XP for 24 hours, and so on. They can really be almost anything as long as they are spent on use.

Conclusions

What’s good about listing things like this is that you can start thinking about ways to hybridise them and to mix and match things for your specific game. How about a system that awards boosters via containers and has currency that grows over time but must be paid to unlock seasonal rewards? The sky is the limit.

It’s not uncommon for some card games to treat their primary feature drops, the cards, as both set collections and reagents, for example. Collect up to four of the same card and then combine multiples of the same card into upgraded versions of itself. Rage of Bahamut is an example of this.

There are probably many things we haven’t discovered yet when it comes to rewards, and I would love to hear what you come up with in your own designs!

Never hesitate to throw me an e-mail at annander@gmail.com if you want to share such designs, or just tell me how wrong I am in general. The latter is something the Internet seems quite fond of.

This blog is primarily dedicated to musings around systemic design. How we can give more power to the players and generate emergent experiences. One of the things that countless games have done in various ways is combat. Yet, no matter how many combat-driven games gets made, we’re likely to see more of them.

Before we get into the systemic design, however, we need to know how we treat our combat. We need to figure out our combat design philosophy. Is it the type of combat where limbs are cut off and all that happens is that the black knight shrugs and says “just a flesh wound?” Or is it the kind where the enemy you just shot is writhing in pain and crying for several seconds before finally perishing?

In this article, I will look at combat in games from a general high level perspective. In four separate future articles I will go into how to implement systemic versions of them. Exactly when those see the light of day, we’ll just have to wait and see. They’ve turned out to be a lot more complex to write than my other systemic articles.

War and Peace

In the tabletop role-playing community, or more specifically the Dungeons & Dragons community, two kinds of combat philosophy are generally acknowledged and/or the strong preference of different groups.

In Combat as Sport, players want to put their efforts against non-player characters or other players. Balancing is crucial, even if asymmetry is often added to create an interesting possibility space. All of the fighting happens in relative safety with clear conditions for who wins and who loses. It’s more about the number crunching, optimisation, and competitive elements than it is about lethality or the fight itself.

In Combat as War, the ends justify the means and getting the upper hand through strategic decisions and logistics is more important than the act of fighting. It’s implicitly more “realistic,” since it doesn’t care about balancing and is often more dangerous to its participants. It’s less about defeating the enemy in the most effective way possible and more about achieving strategic or tactical objectives at minimal risk and expense.

A third kind of combat is used in games designed for passive observation, and it’s the kind of combat that Hollywood makes frequent use of.

In Combat as Drama, the winning is never as important as the struggle. Knowing who to vie for, knowing what’s at stake and to whom, and understanding how the situation escalates from beat to beat and culminates in a pivotal climax. Stories need endings, and few endings are as definitive as the death, condemnation, or even redemption of an enemy.

To understand what we are trying to achieve with systemic combat, let’s explore these three some more.

Anatomy of a Sport

Sport can be contentious to define, but there are some common features that we can consider. They’re not common to all sports, but common enough to provide us with a framework.

Rules

Sports have rules for many reasons. Some to make the game itself balanced and competitive, others to guarantee competitor safety or even competition legality. Things like the general banning of anabolic steroids and the prohibition of electrical motors from Tour de France bicycles are rules same as any other. Many countries have whole organisations dedicated to the approval and policing of athletic regulations, with the purpose of maintaining the integrity of the sport.

Fouls

With rules in place, there also needs to be ways to detect and punish participants who cheat. A boxer who falls out of the ring gets a 20-second count where spectators and others are not allowed to help the boxer back in. If the count runs its course, the match is ceded to the ring-leaver’s opponent. In other words: breaking the rule to stay in the ring can cost you the match. There’s also a weigh-in prior to the match, and medical examinations like blood tests designed to discover use of prohibited substances.

Competition

Clear rules with clearly defined consequences for breaking them means that you can train for a sport. You can learn the rules and work hard to achieve better results against other participants respecting the same rules.

Working to improve your track record, knockout punch, or cardio, is directly tied to your performance in the sport. Skill is about being better than your competitors. Rules mean you can become the best.

But competition is also about trying, failing, and coming back later to try again. Though the winner usually takes it all, there can be consolation prizes, participation awards, and there are not just gold but also silver and bronze medals awarded to those who place second or third. There is also the next competition, and the next one after that.

Entertainment

Many sports are tailored not just for participants to compete on equal terms, but also to provide entertainment. Large arenas are built to house their fields, courts, and rings. Sports can draw crowds of hundreds of thousands—even millions in the digital and broadcast realms—that will celebrate or suffer alongside their favorite athletes.

This adds more requirements. Not only must the sport have rules for the sake of competition and legality; now it must also have rules that can be clearly understood by spectators. Rules must be consistent. Unlike board and role-playing game communities, where house rules and custom exceptions are fairly common, a sport must remain strictly rules as written (RAW), and the use of referees becomes crucial. Some sports even use multiple referees and average or majority scoring to minimise the risks that unwelcome biases may affect the outcome.

Sportsmanship

Since all competitors are competing on equal terms and may very well compete against the same opposition again in the future, it’s important to exercise good sportsmanship.

Good sportsmanship is about being polite towards your opponents and not exhibiting the characteristics of a sore loser or bad winner. Don’t yell, don’t throw stuff, don’t kick your horse or vehicle. Whether you come in first or last, you should do so in a dignified manner. Even more important for a spectator sport, since everyone needs to be a good role model for both up and coming athletes and for the spectators and are not just representing themselves anymore.

Fairness

Losing without tantrums and winning without gloating. Following the rules and relying on them to treat everyone equally. Doing what the nice referee says. Competing on equal terms. All of it comes down to one thing: fairness. Let’s use that single word to describe the concept of a sport in the game combat context. Fairness.

Anatomy of War

In a war, if you can leverage a technological advantage against an enemy, you can defeat them without suffering as many casualties. If you can trick them into an ambush or march your army into a position they don’t expect, you can push for a decisive end without a single rifle shot or sword swing. No one except the Hague will try to reinforce any rules.

War is unfair, even deeply so. A war is defined by other things.

Context

“The belief in the possibility of a short decisive war appears to be one of the most ancient and dangerous of human illusions.”

Robert Wilson Lynd

Wars are usually fought for reasons other than murder. Political, religious, cultural, and opportunistic reasons. For example, the idea of a “short victorious war” to improve the spirits of a declining nation has been proposed by multiple leaders throughout history. (It’s never worked.)

Before revolutionary France invented general conscription and patriotism, soldiering tended to be a paid job. Professional soldiers fought in wars, whether as the standing levies of feudal lords, as mercenaries, or something else. They did it because it was their job. Later, they did it for king and country. Or because they were compelled to, through conscription, and on pain of death.

But you can also be holed up trying to defend your home from invasion, or forced to take up arms against your neighbours in a historically charged religious conflict. The common ground is that there is something you fight for that is external to yourself and typically completely outside of your control.

However. It can just as easily be that you want to get into the compound and steal the treasure, and there are guards standing in your way.

Objectives

Unlike how most games portray objectives, wartime objectivs are rarely about killing your opposition. Killing enough of the opposition may cause the enemy to retreat or surrender, and this can definitely be the goal sometimes, but combat engagements in a war are typically a consequence of one side opposing the intended strategic objectives of the other side. Either as part of its own strategy or as a consequence of patrolling the same region or as a counter-strategy.

Sometimes, as with Maskirovka, it’s not even clear what a military force is trying to do because they’re not actually trying anything. Just acting like it with the intention of confusing you or making you look away while something else is underway.

If you look at the physical battlefield, an objective can be some kind of significant asset, like a factory, storage facility, or bridge needed to cross a wide river with heavy equipment. It can also be a person of note, a cache of fuel, the maps and charts used in an invasion plan, etc. Even just a high hill, tall building, or deep ravine that can provide a tactical advantage.

Given any of those, military forces will usually try to hold, to take and then hold, or simply destroy the objectives. Engagements only happen if these attempts encounter an opposing force.

In fact, most fighting forces only spend a tiny fraction of their time fighting. Only about 15% of enlisted personnel is expected to “see combat.” The rest of their time is spent waiting for orders, moving around, or moving and waiting. Some jokingly refer to this as “hurry up and wait.”

Morale

There are multiple layers of morale in a war.

First of all, the morale of the fighting forces. Mounting casualties, negative rumours, bad communications, unreasonable orders from commanding officers, and other factors, all affect morale negatively. Victories and an idea that you are fighting the good fight can affect it positively.

Second, the morale of the staff in charge of the war. If they don’t believe in it anymore, it’ll be hard for them to make the best of their situations. If the monarch is slain, or there are factional disputes among staff, there’s a great risk that this trickles down to the rank and file.

Thirdly, the morale of the nation or alliance that supports the war. The regular people whose tax money or crops are feeding the hungry maws of the fighting forces. If there’s a political revolution back home, a workers’ strike, or massive demonstrations, this is likely to affect the morale of both staff and fighting forces. Particularly in modern democratic countries.

This is the morale that terrorism, including state-sanctioned terror bombing, is targeting.

Terrorism — “the unlawful use of violence and intimidation, especially against civilians, in the pursuit of political aims.”

Oxford Dictionary

Fighting

When it comes to the actual fighting, there’s simply no substitute for victory. You will want to win no matter what. You may invent new weapons, device new surprise tactics, or employ far-reaching propaganda campaigns that coerces your opponent into standing down before anyone has to die.

There’s no reason to risk your life in a fight if you don’t have to, meaning that bombs, artillery, mustard gas, napalm, and all manner of technological marvels have been invented with the intention of destroying an opponent or an opponent’s morale without any risks to your own troops. The same goes in combat as war.

You may flood the dungeon so all the goblins drown, rather than risking your life by confronting them. You may ambush the king in his privy as he’s about to arrive in the capital, rather than fighting the lines upon lines of royal guards escorting him. As the saying goes, all is fair in love and war.

Aftermath

You can win almost every battle and still lose the war because of a disadvantage in numbers, equipment, morale, or some combination of all three. Conversely, you can lose every battle and still win the war because of a decisive final engagement.

For the soldier on the field, the aftermath of war can be disastrous. A white cross on a memorial cemetary, a crippling injury, or psychological trauma that makes it hard to lead a normal life. Unlike a sport, where you can usually just get back in the saddle, there’s no way back from death or losing both arms.

Because of this, you want to win decisively. You want to make sure there’s not even a risk that you may lose.

Strategy and Tactics

If you want to win decisively and minimise your losses in personnel, materiel, and morale, you must outsmart or overwhelm the opposition. You must have a better strategy at the staff level, and better tactics at the grunt level. These are the two words that define combat as war: strategy and tactics.

Anatomy of Drama

Drama uses combat for effect. The risk of death is more important than actual death, even if some dramas don’t shy away from boosting the bodycount.

Show, Don’t Tell

Dramatic combat has many unspoken rules. Before you can hurt or even kill anyone, you must first establish that they somehow deserve it and you need to introduce the instrument that does the dark deed. Enemies need to be clearly despicable dog-kicking villains, even if they may be tragic or misunderstood as well. The whole concept of a villain stems from the narrative need to know who not to vouch for.

To make good drama, you need to make people care and you need to establish who they should care about and why. In film and television, the adage is “show, don’t tell.” You want the viewer to understand who’s the hero and who’s the villain without having to explicitly say it. Establishing what’s true, who’s bad, etc. This is where you will see the villain kick a dog, for example. In any media with pictures, it stirs more emotions to see the dog get kicked than it does to hear someone tell you that a dog was kicked.

Stakes

If the dog-kicking villan isn’t stopped, they will kick more dogs, end the world; maybe both. Often highlighted by a sense of urgency. If the hero doesn’t stop them NOW, they will kick a dog and end the world!

Once it’s established who we should vouch for and who’s the villain, we need to make everything as personal as possible. The hero’s child is kidnapped or their dog murdered. The villain isn’t just threatening life as the hero knows it, but something deeply personal to the hero. Something we, as viewers, can gasp at. We now need to know the stakes involved.

This is where all the MacGuffins come from. If we know that something is important and why, we can also know that of course the hero must get to it before the villain does. Or something awful will happen.

Escalation

A character that brandishes a blade or gun is upping the ante. They are showing that there’s now a lethal threat in action. Some escalation is much more subtle than this, with a glance to the wall-mounted rifle or other way to tell us that the escalation is happening.

It can also be to introduce or increase the stakes. If that precious MacGuffin that the villain needs to power their doomsday device is now in the taloned hand of the villain, the end must surely be near!

Showmanship

Unlike sportsmanship, where it’s about being respectful, showmanship is about putting on a good show. “Flynning” is the choreographed fencing style of early adventure movies where the combatants are not even trying to kill each other but actively hitting each others’ swords instead. It’s so iconic that the sound of a movie swordfight has remained the same ever since.

One-liners, theatrical body language, angry tirades, and comments on which things belong in museums are all showmanship used to reinforce the characters involved.

Character Development

If a sport revolves around fairness and war is deeply unfair but demands strategy and tactics, drama is about characters. Drama wants us to care. It wants us to see characters try, fail, then try again and succeed.

Conflict Types

Combat as sport, as war, or as drama. Games often jumble these together in different ways, even if they tend towards a combination of sport and drama. Considering how often war serves as the backdrop for video game combat, it’s very rarely informing how combat works. The simple fact that you can often retry skill-based moments until you get them right puts a game’s combat in the sport camp quite squarely.

Games that allow single-death hardcore modes of different kinds come closer to emulating combat as war, since it will often cause you to play more carefully and use any means necessary to push through.

Player vs Player (PvP)

The closest a game gets to sports is in player versus player environments. Whether you’re talking about The Finals, with a sports context in its narrative, or Rocket League, or even Chess, or anything else, it’s a balanced, skill-based and decidedly fair experience. If it’s not fair, or if the players feel that it’s not fair, you can rest assured that they will tell you. Games like these are never done. There will almost always be some fine-tuning left to do.

Player vs Environment (PvE)

Kratos in the remake of God of War (2018) is definitely portrayed as a badass who cannot lose, with combat as drama for framing. But the gameplay treats combat as a skill that must be learned and dying means replaying parts of the game until you are skilled enough to push through; combat as sport. This mix of sport and drama can probably be considered the default for many single-player and cooperative games, but it’s also the source of most, if not all, ludonarrative dissonance.

Player vs Player vs Environment (PvPvE)

In games like Hunt: Showdown, and other extraction shooters, we get a little bit of combat as war into our games. Once you have felled your bounty in Hunt, other players can come in to deprive you of your kill. If they do, you will lose the potential points. Large part of what makes this more war than other types of games is because it’s often quite unfair. There’s nothing that balances the skill level of the assaulting players with you or makes sure that the playing field is leveled out. Of course, there’s still plenty of balancing and fairness to this experience, so it’s not entirely combat as war, but it’s closer than most.

Another subset of PvPvE is coopetition games, where you are fundamentally cooperating with your team but also in it for your own score in a competition against them. Something like the Firefight game mode in Halo 3 O.D.S.T, for example. This turns the PvPvE into sport once more.

Players vs Designers (PvD)

This isn’t a genre or definition anyone ever uses, but it’s still highly relevant. When you as a designer start restricting a game space because you feel that a player’s interactions “break” that space, you have pitted yourself against your player. As the player stretches the boundaries, you will constrict them further.

In many cases, this is exactly where features come from. By defining exactly what a player can and can’t do with this thing in your game, you are making your own development of the game more stable and you are eliminating unknowns. But what you are also doing is that you are creating a design space where you need to keep up a constant whack-a-mole against player discovery. Unintended uses of your features is now a problem. If the wall-climbing leads to players finding out-of-bounds areas, you will put some invisible walls there or maybe arbitrarily make some walls unclimbable, for example.

Systemic games often disregard this type of balancing. The player is allowed to be more clever than the designers and when they are, the designers celebrate it. Sometimes by merely allowing it, and at other times by turning the discovered behavior into an integral part of the game design.

In a way, systemic design is easier in this case, because as a designer you are simply resigning to the player’s imagination and letting them have the experience they already imagined. The issues come from the combinatorial explosion it can result in.

Next Steps

Combat is a huge topic, it turns out. There will be four followup posts to this one, sporadically released during the rest of 2024 between other monthly blog posts.

They will specifically deal with:

• Combat Melee: the dynamics and challenges of video game combat and why most games we get follow certain formulas.
• Combat Gunplay: a continuation of the Building a Systemic Gun article that deals with the full cycle of gunplay, including projectile dynamics, and more.
• Combat as Sport: scoring, competition, and fairness within sports and how you can go about designing them.
• Combat as Drama: a short treatise on five things you can consider when presenting your combat.

And as always, if you disagree or you want me to come and inspire your studio to work on more systemic stuff, you can do either (or both) via annander@gmail.com.

Systemic design isn’t really where most of game development traditionally puts its effort. Instead, a word you often hear repeated, rather than “system,” is content. Yelled from the battlements and printed on the plaques.

I’ll quote randomly from comment threads, reviews and interviews to illustrate what I mean. Each of them grabbed from the first few searches I could think of but anonymised because the goal is to make a point.

“This is a good step forward for [game]. Hopefully they keep adding more content and anything that was lacking from initial release.”

“Not worth the price for how little content you receive. It should have been $4.99-$9.99 at most.”

“Most polished game of all time. In a league of its own in so many classes including story, voice acting, music, world building, detail and it’s [sic] incredible level of content“

“I can’t recommend the game due to the shear [sic] lack of content.”

“For the price, the amount of content just isn’t worth it.”

Content. It’s an expression that seems to permeate every kind of modern conversation. Even to the point that many streamers and game developers talk about their interactions with fans as “content.” If you’re not putting out content, you’re not being productive. Content, content, content.

But coming out of 2023, where systemic singleplayer games like Baldur’s Gate III and The Legend of Zelda: Tears of the Kingdom have made a noticeable splash, it’s important to try to objectively measure the difference it makes to build systems and not just more content. To make some effort to see what we’re actually making when we make content. Not to say that the two games mentioned aren’t filled to the brim with content—they definitely are—but to try to get at something else: the real tangible value of the things we decide to make.

Let’s take a look at what content in games actually is, on a practical level, why we get on the content treadmill, and finally an experimental way to measure the concrete value of different kinds of content for people playing our games based on that content’s level of exposure.

Hopefully, it can help illustrate the reason you want to make systems and not just more of everything else.

The Content Treadmill

Michael Sellers, in his excellent book Advanced Game Design A Systems Approach, wrote about the standard mode of game development as the content treadmill. We get on this treadmill because it “makes for a more predictable development process.” Sellers even argues that a “content-driven” game is the production opposite of a systemic game.

Put this content treadmill on repeat for a couple of decades, and you land where we are now, with teams that can involve 2,000 people or more, pushing out massive virtual worlds with hours of cutscenes and intense closely directed set piece environments.

The polar opposite of systemic design.

“Designers can add more gameplay to content-driven games by creating a new level or other object, but the game is fundamentally content-limited because it is so directly authored by the designers. The creation of content itself becomes a bottleneck for the developers, as players can consume new content faster than the developers can create it, and adding new content becomes an increasingly expensive proposition.”

Michael Sellers, Advanced Game Design A Systems Approach

Why are we so bad at seeing the value of a smarter art pipeline, procedural tool, or emergent system? Why have we fetishised content to such a radical degree?

To illustrate why, let’s segue into blood spatter for a moment.

One-Hour Blood Spatter

In the Dark Ages (the year 2014), I was working on a spare-time project for my recently purchased Ipad 3 tablet. After optimising the game for some time I could have 100 simultaneous enemies and do lots of other fun stuff at 60 FPS at full resolution. The idea was some kind of mix between Geometry Wars: Retro Evolved and Moonstone: A Hard Days Knight. It had some promise, particularly after the help of a clever sound designer with really interesting Kabuki-inspired ideas.

Then, as now, I was completely useless at making graphics. So I went to places like Polycount searching for an artist that would be willing to help me for the sum total of no money. This had predictable results (no one cared), but it did lead to some interesting conversations.

I once showed videos from a tech demo to a prospective artist. Videos I was quite excited to share since much of the work was technically complex and held lots of systemic promise in its (I thought) obvious ingenuity.

The artist’s response was, “I thought you’d have come much farther by now,” or something to that effect. I was a bit stunned at first, since I had overcome some serious hurdles to be able to do what I was doing and had probably secretly expected validation. It admittedly didn’t look like much, but that was why I was searching for artists in the first place.

Spurred on by this response, the next thing I did was start implementing some visual effects. Blood spatter, to be specific. As you killed enemies, it would spawn blood, and blood would stick to the environment. It took less than an hour to add, but since I was on parental leave while working on this project it was a couple of weeks before I showed it to the skeptical artist. The response was, “now it’s starting to look like something!”

This stunned me even more. Plugging standard content into an existing game in an established third-party engine was no big deal at all; it was a trivial undertaking. Getting 100 3D-animated AIs to run at 60 FPS at native resolution had been a huge deal! Systemic complexity seemed to be of very little value for presentation purposes.

Measuring Value

This experience has stayed with me ever since. It serves as a reminder that it’s hard to get people excited about technology. No one gets excited by the description of a system, and no plan can provide estimates for emergent effects or lists of player-facing features that are based on emergence rather than forward planning. It’s just not possible to measure such things. It’s even counterproductive to measure them, since listing expected synergies will turn them into features rather than means of discovery. They’re the kinds of things that must come from combinations of systems, and systems take time to build.

In the words of Tom Leonard, from his Thief: The Dark Project postmortem, while describing the methods and philosophies of Looking Glass, “[I]mmersive gameplay emerges from an object-rich world governed by high-quality, self-consistent simulation systems,” which I have explored in detail before. “[This] requires a lot of faith, as such systems take considerable time to develop, do not always arrive on time, and require substantial tuning once in place.”

Many stakeholders will want you to prove the work you do and will require proof they can relate to on their own terms. Systems and tools pipelines are not that kind of proof. Same as 100 AIs on an Ipad wasn’t, but a one-hour blood effect was.

As is also talked about by Leonard, the clash between building the systems and proving them often causes serious problems for developers. When external stakeholders start demanding specific things, rather than seeing the value in the systems as systems.

“[A]ll work had to stop in order to pull together an emergency proof-of-concept demo by the end of December to quell outside concerns that the team lacked a sound vision of the game. […] During this time the only option was to hack features as best we could into the existing AI. While better than losing our funding, constructing these demos was not good for the project.”

In other words, the bean counters of our industry have the same perspective as the artist who felt that the one-hour blood spatter “proved” what the six-month AI optimisation could not. They want you to show them things they can quantify. This forces you to use systems and tools that aren’t ready, or eschew the systemic approach altogether in favor of something more predictable and more readily demonstrable. In other words, content is much easier to demonstrate than systems. Or even more directly: quantity is much easier to demonstrate than systems.

This isn’t reaching the full reason why we get on the treadmill just yet, but the shorter trust cycle matters. It means it’s far easier to make things reminiscent of other things, because we already understand those things. We can keep the comparisons flowing and measure what we get done between deliverables against things we already know.

If our game has more levels, more weapons, or higher resolution textures than some other game, those are measurable points of improvement. A fancy system is not.

The Games We Make

It almost doesn’t matter which big-budget game you play today, you’ll find some kind of abstract progression system with points, node trees, and/or other gamification. It’s usually tied to features, but it can also be cosmetics or rare or exclusive items that you unlock through play. It can be tied to gameplay, like defeating X enemies, or it can be tied to activities, like finishing Y matches. There are season passes to tread through and there are many other ways to unlock, progress, and to revel in on-screen pizzazz.

These can all be referred to as variations of reinforcing loops, empowering the player through repeated play, thereby reinforcing the features available. They lead to interactive repetition, often to a silly degree. Perform actions, gain points, unlock improvements, perform better actions, repeat. Usually in forms that are both short- and long-term, and provide reasons to play “just one more,” as you see the reward bar(s) inch forward.

The key thing about this setup is that these systems are externalised from the core gameplay. The gameplay will provide hooks, like the number of killed enemies or finished objectives, but it won’t work directly with the reinforcing loop. Content and system can be kept separated from each other. They can also be built around operant conditioning (colloquially known as “Skinner boxes“), including random rewards.

“In most games, there is an overall predominance of reinforcing loops. This enables player gain and progression, where the player’s in-game avatar or representation becomes more powerful over the course of the game.”

Michael Sellers, Advanced Game Design A Systems Approach

One side effect of this heavy reliance on reinforcement is that it works through content at a rapid rate. When you have defeated Enemy X using Ability Y enough times, the game gives you a new shiny thing and some new enemies to defeat in the interest of keeping things fresh. Then you do that for a while, and the cycle repeats. When players have burned through it all, you must provide more content, or they will have exhausted what you have on offer and leave your game for the next one.

All of this together means that it makes complete sense to step up on the content treadmill. Hire more artists to make more enemy variations, more designers to build encounters, more programmers to implement feature variations, and so on. Even more so if you can keep the content and systems separated by for example having the content in 3D and the systems relegated to modal windows where the designers can play with numbers, such as reward scores and experience thresholds, in relative safety.

Yes, a practical concrete reason for all the upgrade and quest screens.

How We Market Games

In his still-relevant 2004 DICE Summit talk, Jason Rubin summarized his main points as “Video games are currently sold like packaged goods; talent is not respected.”

The way you market packaged goods, you have to sell something other than the product. One brand is made different from another by being the same but more so or by packaging identity or other factors into its sales pitch. Pepsi vs Coke or PlayStation vs Xbox are both marketing ploys—not actual statements.

Video games tie into this by getting bigger, better, faster, harder, etc. By having more. More scary, more levels, more weapons, better graphics, tougher challenges, larger maps, and so on. This ties directly into the reinforcing loops and makes us run even faster on the content treadmill. Teams balloon to multiple 1,000s of developers to be able to keep up with the rate that our reinforcing loops push players through the content, and to be able to compete with that other game that has only half as much content as we want to offer. It’s even common that we say players want or even demand this, and that’s why we have to make it.

Play the new DLC. Join the new season. Get the sequel. Burn through it, then move on to the next one. This is how we’ve taught gamers to consume games and content in existing games. The new thing must be a produced thing, it can’t just be a new experience or discovery in an existing game. No matter how many hours some players can put into games like Civilization, where variations in the game experience are much less about content and more about the play experience itself, we still operate on the notion that we must produce more content.

It speaks for itself that the word “content” is a traditional marketing term. Marketing language so effective that the consumers have come to use it.

How We Make Games

Where I stand in this dilemma should be obvious: I think we focus on the wrong things. But the industry’s drive towards more content is just as obvious. Sellers mentioned predictability before, but what predictability actually means may not be entirely obvious.

In an interview with The Game Design Roundtable, Darren Yeomans talked about the value of doing things you know instead of taking unnecessary technical risks.

“Just build a different map,” he said. “Build three maps. Schedule that in. You know how to do that—you know how that works. You’re not going to gain anything spectacular on top of what you are doing otherwise.”

This comes from the pure scheduling benefits of doing things you already know how much they cost and how long they take. Because if the opposite of what you know is what you don’t know there will never be a strong argument for more systemic development. The only way you make that happen is by building whole teams focused on systems. Predictability saves money in the short term. It’s much easier for an external stakeholder to look at a hockey stick curve of added content—perceived value for money—than to try to decipher the tech jargon of an excited programmer building a system.

This is the conclusion that has to be made: we can intuitively understand what saving money in the short term means, but can’t quantify the value of making 100 AIs optimised on a Retina screen when it only looks like a bunch of capsules. If you look at the choice of whether to use six months to build a single system, or to use the same time to add more blood effects, the math will be simple and straightforward: let’s add 960 blood effects!

This, in summary, is why we get on the content treadmill. It’s because of how we’ve taught players to play, how we make our games, how we market them, and plan them. We’ve turned a fundamentally creative industry into an assembly line that is always several steps behind a demand that we have artificially created.

Measuring the Value of Content

We’ve had our reasons for getting on the content treadmill. We’ve marketed ourselves into a corner where we continuously sell “bigger and better” to our audience, to the point where they are using marketing terms to express demand. We brought this on ourselves by preferring predictability and by riding the tailwind of constant fiscal growth.

But no, games are not more expensive to make, and no one requires us to keep churning out this content. There is another way. Systemic design, of course! The same opposite that Michael Sellers presents in his book.

A New Systemic Golden Age?

The Legend of Zelda: Tears of the Kingdom broke records on launch. Baldur’s Gate III demonstrated that players love a good premium singleplayer CRPG more than ever. Starfield reinforced this further, though not achieving the fanfares of BG3. In 2023, we got the remade System Shock, the brilliant Amnesia: The Bunker, Hitman 3, and many more games that were decidedly not content-driven or even primarily multiplayer.

On the other end, many service games died the quiet death of server shutdown. From the recently launched Vampire: The Masquerade – Bloodhunt to the unreleased Hyenas. Bungie’s seemingly endless font of gold, Destiny 2, saw team downsizing as a consequence of shrinking revenues.

Coming out of 2023, it’s clear that content isn’t the only thing players want. Players want more kinds of games. Games that used to belong to small niches, such as turnbased singleplayer CRPGs, can “suddenly” sell tens of millions of copies, to the abject shock of many publishers who haven’t seen the value in such launches in years. Also, the idea that what you make must be free-to-play is demonstrably untrue. But the real question is how to measure and demonstrate the value of what you are making.

For this purpose, I have toyed with a measurement that tries to take many factors into account when we consider the value of the content we produce. I’ll present it here, so you can toy with it too. If you have suggestions for additional metrics, then please send them to annander@gmail.com.

Expense

The easiest thing to pinpoint is the expense tied to a piece of content. In budget pitching, we often calculate this using months. I’ll call them devmonths (for developer months).

A devmonth is the cost of a single developer working fulltime for a month. It also includes other running costs for said developer. Licensing fees, vacation, office rent, and so on, all rolled into one number. A game budget in its simplest form can be expressed as a multiple of devmonths. Say, 10,000 devmonths, 100 devmonths, or even 12 devmonths if you’re a solo developer for a year. Of course, if you took a month of vacation in those twelve months, it’d still cost 12 devmonths, it’s just that it’d be 11 devmonths that could be planned for.

For the sake of this post we’ll grab the number $10,000 as the cost for a single devmonth. In today’s studio landscape, this is somewhere in the mid-range of what a budget would assume, but it’s a nice number that’s easy to work with. If you pay salaries in some cheaper countries, this can be much lower. If you pay San Fransisco salaries it climbs much higher.

Now, if you want to make a AAA-quality character model, for example, you will most likely need several people:

• An art director that comes up with the overall direction for all art production.
• A concept artist, who first conceptualizes the character until the direction is satisfied, and then produces a model sheet or other reference materials that can be used as the foundation for building the 3D asset.
• A character artist, who sculpts the high-poly mesh, bakes the low-poly mesh, and textures the character with all applicable maps for your renderer. The texturing can sometimes be a separate developer, depending on company size and culture, but we’ll wrap all of that into this one character artist for simplicity.
• A technical animator, who rigs and skins the character and preps it for animators after the character artist is done.
• An animator, who keyframes animations or records animation using motion capture equipment and then targets it for the technical animator’s rig.

Five people, each responsible for a separate area of the work. For the sake of our example, we’ll skip the director, and assume that we need each of the other developers roughly this much:

• Concept artist, two weeks.
• Character artist, full month.
• Technical animator, two weeks.
• Animator, full month.

That’s a total of three devmonths (or $30,000) as the expense required to create this character.

Just for the record: an asset like this can be much more expensive, but it can also be much cheaper through use of stock assets, good generative tools, and other solutions. This is a very rough estimate for the sake of argument and doesn’t reflect the complex subjective realities of game development in general.

Exposure

How prominently each piece of content is shown to a player can be thought of as the content’s exposure. By comparing expense to exposure we can calculate a kind of consumer value for our content.

To illustrate how this can be calculated, let’s use a few sample metrics. Each is a value between 0 and 1 so they can be easily combined.

Timeline

Add this variable to content that appears after the game’s marketing or splash screen.

At what point in the game a piece of content will appear. If it’s at the start, there’s a much higher exposure. At the end, fewer players will ever get to see it. After the end, say in an endgame or similar, very few players will engage with it.

The following timeline numbers are based on a cross-section of Steam Achievement statistics for single-player games. Around 10% of the people who buy a game on Steam never start the game or finish the tutorial, and only about 30% of players who start playing a single-player game actually reach the end.

0.9 = the very beginning of the game
0.5 = the midpoint of the game
0.3 = the end of the game

Frequency

Add this variable to content that appears infrequently in your game.

Some content, like a third-person main character or menu theme, will be used every time the game is played. Other content will only be presented once and will therefore score much lower on frequency. Many games will reuse content for this very reason, since it’s fairly obvious that six weeks spent on something that’s only seen for a second isn’t an effective use of time (or money).

1 = multiple times every game session
0.75 = once every game session
0.25 = once every few sessions
0.1 = once, ever

Interactivity

Add this variable to content that isn’t directly interactive.

If you assume that players engage more with feedback, content’s grade of interactivity becomes relevant. Some content—you can call it “pizzazz” or “juice”—is made as direct feedback, while other content is passively observed. Content that the player must actively seek out will score higher in interactivity, but will of course score lower in frequency (see previous metric).

A gun in a first-person shooter provides direct feedback to player interaction, while a cutscene is passively observed.

1 = direct feedback
0.5 = restricted feedback
0.1 = passively observed

Exclusivity

Add this variable to content that is exclusive to consumer subsets or timed events.

In certain cases, like with modern season passes, Christmas specials, paid DLC, and so on, there is a factor of limitation added to the content. Content that’s limited will have lower exposure, since you must pass the bar of entry before you can peruse said content.

Some edge cases are relevant, such as multiplayer skins, since they may be seen by you, but not interacted with, but you’ve technically still been exposed to the content in question even if you didn’t interact with it yourself (why the Interactivity metric above is necessary for differentiation).

1 = available to everyone
0.5 = only available to subset of players
0.25 = strict but temporary limitations (say, Halloween content accessible every Halloween)
0.1 = strict permanent limitations

Targeting

Add this variable to content that is made less for players and more for developers.

Some of the things we do in development only benefit developers. Tools, technical pipeline work, concept art, and so on. Many of the things that go on behind the scenes have a much lower exposure value because it’s not actually intended for exposure.

It’s important to note that developer-facing content is fairly rare. Systems, logic, gameplay, and architecture can all be primarily developer-facing, but that’s not really content. Rather, it’s what makes the production of content possible to begin with.

So before you add the Targeting variable, consider whether this developer-facing thing you want to score is actually content or simply the cost of doing business.

1 = player-facing
0.75 = optional UGC content
0.5 = modding-specific content
0.1 = developer-exclusive

Identification

Add this variable to content that is limited in identification and breadth.

In certain cases, content can be limited because of identification. In games where you can select to play as male or female, the male-identified option will be selected fewer times, since up to a third of male-identifying players will play the female character but only 7% of female-identifying players will opt for the male alternative if they can choose. This goes farther too, with color blindness, arachnophobia, a lack of beards in customisation, and a long list of other identifying traits may decrease exposure because of decreased interest due to limited representation.

At its worst, poor identification means no one buys the game to begin with. The issue with this metric is that specific content can be extremely restricted in identification (say, beards) but still empower a game’s wider representation by adding to a library of representative content. It’s therefore a tricky metric to apply to any one specific piece of content, unless that piece is something that’s very rarely seen in the type of game you are making.

To reflect this, you can inverse the Identification metric to make it about diversity instead of breadth.

1 = everyone can identify with this content (e.g., cartoon faces)
0.5 = stereotypical or restricted identification (e.g., realistic faces with content-derived custom variation)
0.1 = only a specific subgroup of your audience will identify with this content (e.g., realistic and clearly identified faces)

Entertainment

Add this variable to content that is difficult to engage with through secondary channels.

Streaming, let’s plays, video reviews and video essays. Ours is the age of video! Some of the content you make for your game may have little obvious value for the game itself but may have huge value for influencers or people watching streams of the game. Or vice versa.

It can therefore be relevant to consider a potential secondary audience and the entertainment value of the content you make.

1 = high secondary entertainment value
0.5 = difficult to understand without explanation or requires gating (e.g., age restrictions)
0.1 = won’t be seen by a wider audience (e.g., complex UI or other unengaging content)

Generosity

Add this variable to content that the consumer base would expect to get free of charge.

In this day and age of free games, something that has changed from the traditional view of what’s valuable is players’ views on levels and other downloadable content. Today, many players expect this content to be free. This gives some types of content a higher perceived value than other content. A new game level has low perceived value generally, while a new story mission or customization option may have high perceived value. It’s a tricky dynamic, because age groups will have very different opinions as well.

This is what drives many games to hire hundreds of artists and designers to produce more content, since it’s basically impossible to produce content as fast as it’s consumed. But it’s also impossible to keep up with this and risks forcing you to work in unsustainable ways for your employees. I.e., stepping on the content treadmill.

1 = high perceived value: considerable expansion DLC, game characters, features
0.5 = low perceived value: consumables, unlocks
0.1 = things that players expect to be free: game levels, variations, bug fixes, and patches

Loss

Add this variable to content that doesn’t persist throughout the lifetime of your game.

Some types of content are subject to conversion loss. Between starting the work and ending it, you lose some of the developer time to iterations, bugs, or other phenomena. How prone content is to this effect depends largely on which area it’s used in. As a rule of thumb, the more content-driven your game is, the more you will lose along the way, and the more you end up iterating on production content, the more you’ll lose on top of that.

The reason for this is that you will eventually drown the individual pieces of content under the mass of content. When you hit your 50th season, the value of content you made specifically for the first season will have diminished to almost nothing. Not least of all because the team’s skills in producing such content improves over time. Particularly if you end up rebalancing your game with the lessons learned as a live product. Basically, the Loss metric is a kind of lifetime metric.

With the character example from before, the concept art can be considered a loss, since it’s not player-facing at all. But this can be mitigated by using it in promotional material, art books, or the like.

You can scale the Loss metric against a concrete lifetime if you want to. For example, five years. Then consider if this specific piece of content will still be relevant five years into the game’s lifecycle, and just how relevant it will be.

1 = all of the content will be used over time
0.5 = half the content will be used over time
0.1 = only parts of the content will be used over time

Continuity

Add this variable to content that requires updating, patching, or complementing during its lifetime.

In certain cases, you will need to maintain your content and it retains its exposure only for a short while. With live games, this can be the special rewards for finishing a certain season pass, or something like a Halloween or Christmas special. Some of them will be possible to use intermittently–like how Halloween tends to happen once a year–but some will be more restricted.

These types of offerings are usually done for marketing reasons, and marketing of course has its own value. But we’re talking about exposure here, and in such a case these types of restrictions may devalue your content over time even if they serve a marketing purpose.

1 = made once, used as-is forever
0.5 = can be used regularly, for example once per year
0.1 = requires regular updates

Cross-Media Intent

Add this variable to content that could be pulling more of the marketing or sales weight.

For some types of companies, games are merely parts of a larger whole. You want the characters plushable, the messages actionable, and the symbols tattooable. An app for the phone, a TV show, board games, merchandise, and paraphernalia. Preferably all of it at once.

Considering your content’s cross-media potential is tricky. A nice font that you can use on posters has cross-media potential and so does a compelling character design. But much of it can’t really be measured in advance. You can’t plan that a narrative plot beat gets virally memed, for example. Rather, this metric will measure your cross-media intent.

1 = high cross-media potential; easy to share, easy to make actionable, easily recognised, etc.
0.5 = narrow cross-media potential; too specific, too unwieldy (e.g., performance-intensive), etc.
0.1 = no cross-media potential; it’s an asphalt texture; not much you can do with it but asphalt.

Priority

Add this variable to content as a way to factor purely subjective priority into its value.

We know. Sometimes there’s a story moment that’s important for a certain character’s development or a set piece asset that’s desperately required for one reason or another. This variable lets you skew numbers a little bit for creative reasons by adding your own subjective value-based judgment as a single metric.

Don’t overuse this, however. The point of this exercise is to get a rough estimate of how much value you’re getting from the money you’re spending on content.

1 = absolutely essential to the game
0.5 = important, but not strictly required
0.1 = incidental to the game

How To Use Exposure

Multiply all the exposure numbers together to find a final exposure value. We now have a cool average! (Or possibly a terrible one.)

High Exposure (>0,8)

Content with high exposure is seen often and repeatedly by a larger group of consumers and will provide an increased sense of value because of it. But on the dark side of exposure you have content fatigue that kicks in when you’ve seen or heard the same content so many times that it makes you roll your eyes or make memes out of it.

High exposure shows you areas where the players will get more bang for your buck. This means you can spend more bucks on similar content and know that it will almost always be worth it. Record more alts. Build more variants. Investing a larger chunk of your budget where your high exposure takes you is almost always a good idea.

Average Exposure (~0,5)

This is all your bog standard run of the mill common milquetoast content. It may need to be there to flesh out your game, but no one will write home about it and chances are that you could save some money by cutting some of it out, reusing more of it, or moving these investments to higher exposure content.

There may also be something wrong about your variables, of course, and you can tweak them to see how that affects the average. But content that scores near 0,5 exposure is most likely not as important as you may have thought.

Low Exposure (<0,2)

If the content you’re making has marketing value or other player- or consumer-facing significance it may hold some merit even if it has very low exposure. But the argument to be made is that you maybe shouldn’t use too many resources to make low exposure content. A coffee stain texture for a table you run past at breakneck speed is probably not worth your time. But if the same coffee stain is also used elsewhere, maybe 100 times spread across the entire game, it will get a higher exposure.

So rather than blanketly saying “cut it out” because something has a low exposure, consider how you can increase exposure for your low exposure content. If it’s only used once, can it be used more times? If it’s reserved for the late game, can you move it to earlier in the game’s progression as foreshadowing? One good way to use the metrics is to see what happens if you add more of them than you initially thought necessary.

There’s allegedly an expression among airforce bomber crews, “polishing bombs,” that demonstrates something functionally useless. The smileys or spit polish you do on your bomb won’t matter at all to anyone ever, since the bomb will just explode. The explosion is the thing. This is a good way to analyse your low exposure content if you spend considerable time on it—adding this content may actually be the game development equivalent of polishing bombs.

E*E

Now we have two numbers: expense and exposure. Multiply expense by exposure and you’ll see what you get for your money in terms of consumer value. This is the asset’s E*E. The argument made here is that exposure directly affects value and should therefore be considered when you make the expense.

Every game will have different needs and variations on what players perceive as value but thinking of your content’s player exposure in terms of value for your money will help you get closer to the player’s mindset and maybe even waste less money on content that maybe isn’t as important as you originally thought.

In a production environment there should be a more rigorous process for finding these numbers. A process that is more directly related to the game you’re making. But the least the E*E can do is challenge your assumptions and make you consider how you can increase the perceived value of your content.

That’s a lot of history and not a lot of substance. Systemic design requires substance (though we can argue whether it requires gamification). Let’s go through som pseudocode that turns all the nonsense in the previous post into practice.

Note that there are many different styles of best practice around these subjects. It also varies which numbers you may want to tweak and how you want to work with them. As always, there’s no one size that fits all.

Also as always, if you disagree or you want to discuss these subjects with yours truly, do so via annander@gmail.com.

Scope

For any gamification design, you need to consider who the gamification is relevant for. The two standard variations are that the gamification is for the player or for the player’s avatar. It’s not uncommon for games to incorporate both layers of gamification, for example having achievements for the player and experience levels for the player’s currently selected character.

Very few games treat the gamification as a diegetic layer, however. There is no in-world reasoning behind levelling up or gaining achievements. It’s purely in the realm of the “gamey,” even if some games may refer to levelling up semi-diegetically through tutorial dialogue.

Player

In the first case, gamification is global and tied to the game itself. To do this persistently, you may need some type of backend, even if that backend simply amounts to the Steam API or other platform layer that does most of the work for you.

In a modern roguelike dynamic, this is the space where you unlock things between deaths. In a massively multiplayer setting, it’s the stuff tied to your account. Maybe your shared inventory slots and gold stash.

Avatar

In the second case, gamification is assigned to a specific avatar. It can be a dragon you breed in Dragonvale, or it can be your own instance of Geralt in your most recent playthrough of The Witcher 3: Wild Hunt. All of the experience point levels and unlocks are tied to this character. It’s still player-facing, but it’s tied to a specific avatar in the game world.

As previously discussed, some of this is about time investment. If you make a specific unlock for one character, that means you need to create a new character to make another specific unlock, pushing you to spend more time with the game.

This doesn’t have to be a character necessarily. You can put this style of gamification on a piece of gear, vehicle, or anything else. All it means is that it’s tied to a specific instance of something and not to a global scope.

Gamification Container

It doesn’t matter that much where you put the gamification, structurally. But anything that’s completely player-centered will usually be expected to be persistent and to count across any and all separate avatars, while avatar gamification is accepted to be restricted per avatar. These are not rules but rather established design tropes that many players are likely to expect.

If you want to put a container on each magical weapon, game vendor, and island city, then that’s entirely up to you. There are guaranteed to be many interesting and unique ways to make use of gamification that we haven’t seen yet, and it may start as simple as putting this container where it’s not usually placed.

Imagine a container something like this:

class GamificationContainer : public IPersistentObject
{
  // The experience system itself (see later)
  ExperienceSystem* pExperienceSystem;

  // Any systems that care about experience can be handled as listeners or observers.
  Array<ExperienceListener*> ExperienceListeners;

public:
  // Add or remove listeners.
  void AddListener(ExperienceListener* NewListener);
  void RemoveListener(ExperienceListener* Listener);

  // Persistent object things; saved to your profile backend or local save file as appropriate.
  void Save()
  {
    // Store the state of the experience system (total XP).
    // Store the state of all listeners.
  }

  void Load()
  {
    // Restore whatever you saved in Save().
  }
}

And then the ExperienceListener could be something like this:

class ExperienceListener
{
  ExperienceSystem* ExperienceSystem;

protected:
  // Anything inheriting from ExperienceListener will use this
  virtual void OnLevelUp(const int32 NewLevel) = 0;

public:
  ExperienceListener(const ExperienceSystem* System)
  {
    ExperienceSystem = System;
  }

  void Activate()
  {
    // Subscribe to the ExperienceSystem's OnLevelUp.
  }

  void Deactivate()
  {
    // Unsubscribe from ExperienceSystem's OnLevelUp.
  }
}

This setup is enough to cover most possible use cases tied to experience leveling. None of this needs to be complicated.

Basic Experience System

Next up: the system for accumulating experience and gaining levels. The simplest form of this uses a linear function. We’ll use the function XP = Y * L * (L + 1), where XP is the required amount of experience points needed to reach the next level, Y is a baseline number used to scale the system and its rewards, and L is the current level of the entity accumulating experience. You can use any function you want, your engine’s curve interpolation variable, or something else. This specific formula is borrowed from the third edition of Dungeons & Dragons.

I really like having some variables as assets on disk that can be accessed externally from runtime objects. In Unreal, this would be your UDataAsset; in Unity it would be a ScriptableObject. Particularly baseline values benefit greatly from this approach, since you can access them without having to chase for the specific objects where they are tied into the systems.

Some developers prefer to use comma-separated values (CSVs) and collect them in spreadsheets that can export them handily. But as with everything in development, how you construct your process is up to you.

Imagine that we have an interface that lets us store and tweak variables on disk (CSV origin or not):

struct IntVariable : public ITweakableAsset
{
    int32 Value;
};

Then the actual experience system can look something like this:

class ExperienceSystem
{
    // Total XP is used to calculate your current level on return
    int32 iTotalXP;

    // Current experience level
    int32 iCurrentLevel;

    // Current experience accumulation, since last level up
    // Zeroed when you gain a level
    int32 iCurrentXP;

    // Temporarily stores xp that you just gained
    int32 iXPGain;

    void CheckLevelUp()
    {
        auto bDidLevelUp = false;

        if (iXPGain > 0) 
        {
            auto xpcalc = iCurrentXP + xpGain;

            if (xpcalc >= TargetXP(iCurrentLevel))
            {
                while (xpcalc >= TargetXP(iCurrentLevel))
                {
                    iCurrentXP = xpcalc - TargetXP(iCurrentLevel);
                    ++iCurrentLevel;

                    // Tell any observers that you levelled up
                    OnLevelUp->Broadcast(iCurrentLevel);
                }

                bDidLevelUp = true;
            } 
            else 
            {
                iCurrentXP += iXPGain;
            }

            iTotalXP += iXPGain;
            iXPGain = 0;
        }

        return bDidLevelUp;
    };

    int32 TargetXP(int32 Level) 
    {
        return XPBaseLine.Value * Level * (Level + 1);
    }

    void CalcCurrentLevel() 
    {
        auto xpcalc = iTotalXP;
        auto CurrentCalc = xpcalc;

        while (xpcalc >= TargetXP(currentLevel)) 
        {
            CurrentCalc -= TargetXP(currentLevel);
            ++iCurrentLevel;
        }

        iCurrentXP = CurrentCalc;
    }

public:
    FLevelUpSignature* OnLevelUp;

    IntVariable XPBaseLine;

    // For displaying progression
    float GetNormalized()
    {
         return (float)iCurrentXP / TargetXP(iCurrentLevel);
    }

    // For any addition of xp
    bool AddXP(int32 XP)
    {
        iXPGain += XP;
        return CheckLevelUp();
    };
};

Awarding Experience

The neat thing about this system is that the baseline and level already provide a standardised reward structure out of the box. Rather than awarding experience arbitrarily, you can award it as some multiple of the baseline.

Let’s say that we use the Dungeons & Dragons third edition baseline, which is 500. This means that XP = 500 * level * (level + 1). At level 5, you therefore need to have accumulated 15,000 xp to hit level 6. This means you need to gain 5,000 experience points above what you needed to reach level 5 from level 4.

Using this knowledge, we can set up rewards that only use the baseline and nothing else:

• Easy award is worth a tenth of the baseline: 50 xp. 100 awards required to reach level 6 from level 5.
• Medium award is worth a quarter of the baseline: 125 xp. 40 required for level 6.
• Hard award is worth half the baseline: 250 xp. 20 of these required.
• Milestone award, same as the baseline: 500 xp. 10 of these required.

If we also multiply these award tiers by current level, we get a simple style of scaling:

• Easy award becomes 250 xp at level 5. You need 20 to go from level 5 to level 6.
• Medium award becomes 625 xp. You need 8.
• Hard award is worth half the baseline: 1,250 xp. You need 4.
• Milestone award: 2,500 xp. You need just 2.

Of course, we can easily do this the other way too—by dividing the award further by current level. This could become relevant if we don’t want players to “farm” low-level enemies for easy xp, for example. Or if we don’t want our game to feel the same at each level. The easiest way to do that is to factor in the level of the opposition. For example, by dividing the lower level by the higher and then using the result as a multiplier on the final award.

For example, if your level 10 murder hobo delivers the deathblow to some lowly level 6 kobold, this would yield just 60% of the award (6/10). If that kobold was then easy to begin with, the resulting math would look like this:

With scaling, (50 * 10 = 500) * 0.6 = 300. Or, if you scale using the opposition’s level instead, which probably makes more sense; (50 * 6 = 300) * 0.6 = 180.

Without scaling, 50 * 0.6 = 30.

Scaling at all is of course a matter of taste. Some players strongly dislike level scaling; other players enjoy the consistency it can provide. Some games apply scaling across everything, while others may scale some encounters but not others. Say, scale encounters in the wild, but keep dungeons or milestones without scaling. You do you. These are just the dials you can choose to turn.

Specific Experience

Another variant is to specify the xp numbers for each level in a table. That way, you can get more satisfying power scaling for the player and you can more carefully gate the features that the player gets access to. Personally, I quite like using a function because it means there’s no practical level cap unless I set one manually.

A table requires that you specify the flow of levels manually. Of course, nothing stops you from using a function to calculate the numbers you’re putting into the table, but it’s not as neat and not as easy to tweak.

One example of the table-based approach is the fifth edition of Dungeons & Dragons, where the experience point requirements start at 300 and multiplies by three for the first couple of levels, before decreasing slightly. For most of the game’s character classes, the player is making a significant choice at third level, making this change noticeable for the player. They can learn the new features of their class gradually and will then be able to put them to good use at their own pace. There are strengths to both approaches.

Level-Based Unlocks

We already have the OnLevelUp provider tell us when a level was gained. This means that we can set up observers to easily make things happen on level up. Level-based unlocks is the most straightforward example, but will usually need a data-driven way to figure out boundaries.

In the following example, it’s manually added in the code, which isn’t great if you don’t use some kind of externally parsed scripting language:

class FighterUnlocks : public ExperienceListener
{
  struct Unlock
  {
    int32 Level;
    void* Ability; 

    Unlock(int32 UnlockedAtLevel, void* UnlockedAbility)
    {
       Level = UnlockedAtLevel;
       Ability = UnlockedAbility;
    }

    // Does whatever "unlocking" means in your system.
    void Unlock();
  }

  Array<Unlock> LevelUnlocks
  {
    new Unlock(1, new ClassAbility()),
    new Unlock(3, new SpecialAbility()),
    new Unlock(5, new SuperAbility()),
    new Unlock(10, new GodlikeAbility()),
    new Unlock(15, new AbsurdAbility()),
    new Unlock(30, new GameCrashingAbility()),
    new Unlock(50, new DesignerImaginationRunsOutAbility())
  }

protected:
  virtual void OnLevelUp(const int32 NewLevel) override
  {
    for(const auto Entry : LevelUnlocks)
    {
      if(NewLevel <= Entry.Level)
        Entry.Unlock();
    }
  }
}

Dealing With Numbers

Bret Victor said in a talk I didn’t manage to find again on YouTube, “show the data; show comparisons.” In any UI design with numbers, you need to know what’s going on, and you need to be able to compare the outcome of different choices.

Since gamification is largely mathematical, this is crucial for any game with gamification. It starts with how to represent the math to begin with.

Displaying Numbers

Many games put the numbers on the screen explicitly. When you hit an enemy in the head, a red number jumps out telling you exactly how many points of damage you did to that enemy. This combines style and information and works really well for some types of game. It’s also immediate feedback for any changes you’ve made to your gear or character build. If you see the numbers go up, you probably did something right.

Games often make a visual difference between regular hits, critical hits, various damage types, and other nuances. They may use color, type, font size, and many other tweakable elements to achieve this.

Comparing Numbers

There are essentially three schools of thought when it comes to representing the numbers in a game. Then there are infinite variations between them, of course, but if we look at it as three separate schools it’s easier to talk about.

We can call the first school the simulation school. This is where there’s no player-facing representation at all. You simply have to learn the difference between one material and another, the duration of burning between one wood type and the next, and so on. Some games will have whole wikis filled out with this data in no-time after launch. But keeping the numbers away from the player is a conscious decision in this type of game, often because it’s aiming more for immersion than number crunching.

The next school we can call the utility school. It’s where you can see representative comparisons that try to boil down a tradeoff’s relative utility in the given moment. A good example is the Diablo III item comparisons that were introduced later in the game’s life cycle.

By showing you the difference in damage, toughness, healing, or even just green or red arrows based on which is statistically better overall, it means you won’t have to go into every single number in detail or crunch it in your head. You can see roughly what tactical difference the item will make from a glance and make a quick decision.

Of course, to truly master your build customisation you may have to go into the numbers anyway. But mastery isn’t everyone’s jam.

Thirdly, we have the spreadsheet school, where having perfect information on all the data that goes into and out of the game isn’t just important but absolutely essential to the game experience. Some games will require you to use actual spreadsheets by exporting their data as CSVs that you can import into your spreadsheet tool of choice. Others will provide all that information inside the game. Management games often belong to this school of thought.

Number Containers

Anything in your game can contain numbers. Having a generic way to handle those numbers is therefore a good thing. Whether you want to use templates or write specific code for each type of number management is of course dependent on the project—there’s no factual best practice here.

Personally, I prefer if a system can be as small as possible and then defined through data more as exceptions. In other words, a data-driven and exception-based design. (More on these things in the future.)

One way to achieve this is to define a type of data that’s common for anything that affects the same object, like a character’s stats:

struct CharacterStats : public ITweakableAsset
{
  int32 Strength;
  int32 Dexterity;
  int32 Constitution;
  int32 Wisdom;
  int32 Intelligence;
  int32 Charisma;

  // Operator overloads so a container can do things with stats
  ICharacterStats operator+(const CharacterStats& Other);
  ICharacterStats operator+=(const CharacterStats& Other);
  ICharacterStats operator-(const CharacterStats& Other);
  ICharacterStats operator-=(const CharacterStats& Other);
  ICharacterStats operator*(const CharacterStats& Other);
  ICharacterStats operator*=(const CharacterStats& Other);
};

This object can be turned into an asset on disk as well, for easier access and tweaking. In games that rely heavily on data management, decoupling assets from their objects is a good core principle.

On the character or other object that will then use these stats, you add a StatContainer that can own all of the data references depending on what they should do.

template<struct T>
class StatContainer
{
  Array<T> AddStats;
  Array<T> SubStats;
  Array<T> MulStats;

public:
  // Bundles all of the added interfaces together and returns total
  T GetTotal()
  {
    T Total = new T();

    // Addition first? Not mathematically accurate, but let's do it.
    for(const auto Add : AddStats)
      Total += Add;

    // Subtraction second? Vicious, but why not?
    for(const auto Sub : SubStats)
      Total -= Sub;

    // Cumulative multiplication? Wow ...
    for(const auto Mul : MulStats)
      Total *= Mul;

    return Total;
  }
}

This approach does have some disadvantages, however. You will probably end up having a lot of objects with zeroes in them. For example, the bracelet that provides a +10 Strength will have zeroes in the other five D&D attributes.

It makes most sense to do complete stat bundles for things like level up bonuses and other effects that do affect everything. For others, you can use the same line of thinking but provide a StatContainer for each individual stat instead of the whole stat-driven object. As you can tell from the above, this doesn’t really matter from the pseudocode’s perspective.

Baseline, Attributes, and Modifiers

Stat-driven games can quickly becomes unwieldy. We’re already talking about baseline, level, stats, modifiers, etc, and we’ve barely scratched the surface! Because of this veritable explosion of numbers, it helps to set up some terminology to work with in your team.

Personally, I really like to separate game system math into four parts.

• Baseline values can be used for broad rebalancing. Baseline jump height, damage, experience, etc. It’s the type of thing you can change when setting up different difficulties for example, or if you feel that enemies deal too much damage in broad terms.
• Attributes are per-object variables. Your character’s extra damage, or an individual enemy’s increased jump height. What’s important with attributes is that you try to avoid the phenomenon of the “dump stat,” which is the attribute no one cares about because it doesn’t affect the game enough. It’s equally important to avoid having a single attribute affect too much.
• Modifiers can be contextual, optional, customisable, or applied some other way. When you equip a new item or move around on the slippery ice, you’re applying modifiers.
• Lastly, Functions are how you actually make use of all the other numbers. It determines how you weight the value of baseline vs attribute, for example, and at what point you include modifiers in the calculation. It makes a pretty big difference if you add numbers together before multiplying or after, for example.

By decoupling numbers into these separate categories, you can structure your project and its balancing in a much clearer way. Whether you use external files or spreadsheets for all of these is of course more about taste. Functions are generally easier to put into code, but there may be instances where even they are turned into external objects for easy access.

Global Stats

You will often want to keep track of global statistics that are also tied to an account or avatar. Things like total number of kills, total time played, and so on. This is easily implemented with the same reasoning—just add StatContainer that bundles all the relevant information together and is updated from whichever events you may need.

Such a StatContainer can also have an internal checklist for whenever a stat changes where you can check achievement unlocks and other high level changes. For example, whenever a kill is scored and an event is sent, this global StatContainer could unlock the 100,000 kills achievement if you just hit 100,000.

Player-Facing or Not

We now have the number containers and we’ve separated them for easier development. But one thing still remains, even though we already talked briefly about displaying numbers earlier: which numbers are player-facing?

There are many different schools around this, and though many games will allow you to indirectly change the baseline damage and health numbers through your choice of difficulty, some games expose everything about the underlying numbers.

Personally, I prefer more immersive systemic games, and they rarely put numbers up front. But there’s a decision here that you need to make for all of your own designs.

Rules

Which numbers you want in your game is a giant undertaking to figure out. But it gets really complex when it gets to the Functions column of the previously used table. I will go through some of the considerations you will have to make setting up rules for your gamification math. But this is merely scratching the surface.

Point Spending

Any system where you want the player to spend points must make a number of important decisions from early on.

• Points can be player-facing—which is very common—where you get X number of actual points and you spend them on various costs. Maybe the first unlock costs 1, second costs 2, etc. But points can also be abstracted, so that you get one practical unlock and you can pick either one node or the other. This is just another potential dial, if you think you need it.
• How many points the player will have spent when fully maxed out. This is the high extreme of the system and should represent the peak of what the character can ever become.
• Whether things are completely locked until activated, or are improved by point spending. If you have zero points in Double-Jump, this may mean that it has a longer cooldown or that you don’t have access to it at all, for example.
• Which things are unlocked first and how you can use that to teach the player how to play. If you unlock the Super-Murder Smash, you will most likely want to play with it. This will teach it to you before you spend points upon reaching next level to unlock the Triple-Kill Ultra-Suplex. Etc.
• If you should be able to see all the options before you have access to them. Tree structures are good for this, since you can aim for some specific character build and then start “marching” through the nodes one unlock at a time.
• “Respeccing” needs to be considered. Some games will allow it for free, others may charge for it, and others again will require you to start a new character completely from scratch if you want to make different decisions.

Combining Multipliers

Multipliers are common. We like to double our critical hits, halve our fire damage, zero things we’re immune to, and so on. Mathematically, multipliers are fairly straightforward. Multiplying 4 by 6 gives you 24; 3 by 15 gives you 45, and so on. But game design tends to make things much more complicated.

In the game All Flesh Must Be Eaten, multipliers are used to create a damage model that tries to give you an approximation of reality. You shoot a zombie by rolling D10 and adding one skill and one attribute. You must then hit a target number. Let’s say you roll high, and you score the system’s equivalent of a critical hit. Your shot was with a .44 magnum.

A .44 magnum deals D6 x 6 damage in the game. You roll the d6 and you score a 4, meaning 24 points of damage. But it doesn’t end there. You must now consider armor. Armor is deducted from the hit at this point, and the result after armor is doubled since this is a bullet wound.

Let’s say the zombie is wearing the Class II vest of the police officer it used to be. This will absorb D6 x 2. A 2 is rolled for the zombie, absorbing 4 points total. Now 20 points remain, which would be doubled to 40 points normally because it’s a bullet wound. But we rolled a critical remember? This means the multiplier is increased from 2 to 3, for a total of 60 points of damage.

This directly illustrates a couple of design considerations with multiplayers.

• Additive multipliers are stacked together. Like the critical hit effect in the previous example. The difference between turning a X*2 into a X*3 is very different from multiplicative multipliers.
• Multiplicative multipliers means multiplying several times, like the pseudocode previously. In such a case, each multiplier is applied individually, and the result will climb exponentially. It could be X*2*2.
• You can combine multiplicative and additive together as well, by separating additive multipliers into “buckets” and then multiplying those buckets with each other. For example, having one multiplier calculated from your character, another from your gear, and the third one from your opponent.

Combining Percentages

I’m not personally fond of small-scale percentage modifiers. Even if a +5% Sneak may sound interesting, the difference it makes is usually negligible. It easily becomes too trivial a choice to have an interesting impact and it gets hard to understand intuitively. But with games that rely heavily on gamification, this type of modifier is very common.

The one thing you need to consider with percentages is how they are added together. But overall, percentages are easier to work with than multipliers.

Using the Numbers

There are attributes and modifiers all around by now—let’s look into what you can use them for. This is probably the most obvious part of any gamified structure, but it’s easy to get lost in the weeds. It’s also easy to lose track of the balancing if you didn’t start from the highest possible extreme.

Some common ways to use numbers:

• Unlocks: Probably the most common way to use points in gamification is to unlock things. If you have ten points in Combat you get the triple-strike; if you reach Level 40 you get a mount.
• Container Values: Another very common restriction based on leveling up. How many things you can carry, how many times you can do a thing, how many units you can have, and so on. This is an area where you can often add considerable friction to a game. Either by restricting it and allowing players to pay for additional uses, or by having a game loop that assumes players circle back to some hub area or similar to “fill up.”
• Actions: Jump higher, run faster, slide longer, make quicker turns, brake faster; this is usually that +X%-style thing, but it can also represent the existence (or not) of a certain action. For example in a metroidvania dynamic. You have or you don’t have the unlocked super-jump boots.
• Combat: Deal more damage, absorb more damage, attack faster, etc. If you want to dive into this type of math, you need only look at any service-based first-person shooter. Like Destiny 2. Particularly after a few seasons of additions, the ways you can affect numbers in such a game climbs.
• Threshold Values: Many games, from Citizen Sleeper to Baldur’s Gate III, have plenty of dialogue that’s conditioned on specific variables. If you have the right dice roll in the first, or the right attribute value in the second, you are allowed to pick certain options. Games will treat this slightly differently. In Cyberpunk 2077, you can save your points and then allocate them at any point in a dialogue to sort of “spot-unlock” the dialogue responses you want to take.
• Comparisons: Some other numbers that climb, such as ratings values, kill counts, match counts, and the like, are not directly tied to gameplay but provide a good way to compare your own game performance to that of other players.
• Build Optimisation: If you mount gun X on your mech, it changes its performance from mounting gun Y. Learning the differences in such cases is very important. Optimising your build for things like endgame engagement can be a whole artform.

Beyond

There is a near infinite number of things you can do with numbers and the systems around numbers that are used in games today. These two pieces only scratch the surface. You can read Part 3: Loot if you want, but these still just scratch the surface.

But I wanted to touch on gamification from a simple implementation standpoint to demonstrate that it’s not very complex to implement and it can usually be kept decoupled from a game’s core logic using events and containers.

The question of whether you should use gamification is a much trickier one, and one I won’t engage with at all. As always in game development, you do you.