There, but certainly not back again.

It’s sometime around the late 1980s/early 1990s that some developers start talking about a “game engine” as a thing. Maybe not even using the term “engine” yet, but in the form of C/C++ libraries that can be linked or compiled into your project to provide you with ready-made solutions for problems. Color rendering for a particular screen, perhaps, or handling the input from a third-party joystick you want to support. The two Worlds of Ultima games are built on the Ultima VI: The False Prophet engine, as a decently early example.

When you put a bundle of these ready-made solutions together, it becomes an engine. In those days, the beating heart would usually be a bespoke renderer. Software that transforms data into moving pictures and handles the instruction set of whichever hardware it’s expected to run on.

What id Software perhaps revolutionised, if you are to believe John Romero in his autobiography Doom Guy: Life in First Person (an amazing book), was to make developer tools part of this process. To push for a more data-driven approach where the engine was simply the black box that you’d feed your levels and weapons and graphics into.

This is how we usually look at engines today: as an editor that you put data into and that makes a game happen. To give some context for this, I thought I’d summarise my personal software journey. One stumbling step at a time, and not all of it strictly engines.

QBASIC

When I grew up in the 80s/90s, I was often told that programming was simply too hard for Average Joe poor kids like myself. You had to be a maths genius and you had to have an IQ bordering on Einstein’s. At a minimum, you needed academic parents. If you had none of those, programming wasn’t for you. Sorry.

This is the mindset I adopted and it affected my early days of dabbling profoundly. Where I lived, in rural Sweden, there were no programmer role models to look up to, and there was no Internet brimming with tutorials and motivation either. Not yet. We didn’t have a local store with game-stocked shelves or even ready access to computers at school. Again, not yet.

But eventually, maybe around the age of 10 or so, I ran into QBASIC on the first home PC that was left over from my dad when he upgraded. Changing some values in the game Gorillas to see what happened was my introduction to programming in its most primitive form.

Ultimately, I made some very simple goto-based text adventures and even an attempt at an action game or two, but I didn’t have enough context and no learning resources to speak of, so in many ways this first attempt at dabbling was a deadend.

It’s clear to me today, looking back, that I always wanted to make games, and that I would probably have discovered programming earlier if I had been introduced to it properly.

Hex Editing

Even if I felt programming was too complicated, I did pull some games apart and attempt to change things under the hood. One way you could do this was by using a hex editor (hex for hexadecimal) to manipulate local files. This is something you can still use for many fun things, but back then hexadecimal was part of how games were packaged on disk. (Maybe it still is and I’m letting my ignorance show.)

The image below is from Ultima VII: The Black Gate seen through a modern (free) hex editor called HxD. As you can see, it shows how content is mapped in the game’s files.

Back then, my friends and I would do things like replace “ghoul” in Ultima VIII with “zombi” (because it has to be the same number of letters), or even attempt to translate some things to Swedish for some reason. (To be fair, the Swedish translation of Dungeon Keeper 2 is in every way superior to the English simply because of how hilariously cheesy it is.)

To grab this screenshot I could still find the file from memory, demonstrating just how spongy and powerful a kid’s brain really is…

Build Engine

With Duke Nukem 3D, and to a lesser extent DOOM, I discovered level editors. The Build Engine, powering the former, was a place where I spent countless hours. Some of the levels I made, I played with friends. I particularly remember a church level I built that had sneaky pig cops around corners, and how satisfying it was to see my friends get killed when they turned those corners.

How this engine mapped script messages to an unsigned byte, and memorising those tiny message codes and what they meant, were things I studied quite deeply at the time. I fondly remember a big level I downloaded at some point (via 28.8 modem I think) that was some kind of tribute level built to resemble Pompeii at the eruption of Vesuvius. It’s a powerful memory, and I’m quite actively not looking to find that level to get to keep the memory of it instead.

The fact that walls couldn’t overlap because it wasn’t actually a 3D engine were some of the first stumbling steps I took towards seeing how the sausage gets made.

Half-Life

Several years after playing around with the Build Editor, I discovered WorldCraft. I built a church here too for some reason, despite being a filthy secular Swede, and tried to work it into a level for the brilliant Wasteland Half-Life mod. This was much harder to do, since it was fully 3D, and you ran into the limitations of the day. The engine could only render about 30,000 polygons at a time, meaning that sightline optimisations and various types of load portals were necessary. Things I learned, but struggled with anyway. Mostly because Internet was still not that great as a resource. Had I been smarter, I would’ve started hanging around in level design forums. But level design never stuck with me the way programming eventually would.

During this time, I also learned a little about tools like 3D Studio Max, but as with programming in the past I thought you had to be much better than I was to actually work on anything. My tip to anyone who is starting out in game development: don’t bring yourself down before you even get started. It can deal lasting damage to your confidence.

DarkBASIC and DarkBASIC Pro

During the late 90s and early 2000s, something came along that finally “allowed me” to make games, at least in my head. At first it was DarkBASIC, which is a BASIC version with added 3D rendering capabilities produced at the time by the British company The Game Creators.

This discovery was amazing. Suddenly I was building little games and learning how to do things I had only dreamed of in the past. None of it was ever finished, and I always felt like I wasn’t as good as people from the online communities. It’s pretty cool, however, that Rami Ismail hung out in these forums and that I may even have competed against him in a text adventure competition once.

Along the way, I did learn to finish projects however. I made two or three text adventures using the DarkBASIC sequel, DarkBASIC Professional, and even won a text adventure competition all the way back in 2006 with a little game I called The Melody Machine.

RenderWare Studio

In 2005 I enrolled in a game development education in the town of Falun, Sweden, called Playground Squad. It was the first year that they held their expanded two-year vocational education for aspiring game designers, programmers, and artists. My choice was game design, since I didn’t feel comfortable with art or code.

This was a great learning experience, particularly meeting likeminded individuals, some who are still good friends today. It’s also when I started learning properly how the sausage gets made, and got to use things like RenderWare Studio. An early variant of an editor-focused game engine, where designers, programmers, and artists could cooperate more directly to build out and test games.

It was never a hit the way Unity or the UDK would become, but I remember it as being quite intuitive and fun to play around with. We made one project in it, that was a horde shooter thing. I made the 3D models for it in Maya, which isn’t something I’ve done much since.

SimBin Engine

I don’t remember what SimBin called their engine, but I got to work in two different iterations of it in my first real work at a game studio, as an intern starting in 2006. One engine was made for the older games, like RACE: The WTCC Game that became my first published credit. The other was deployed on consoles and was intended to be the next-generation version of SimBin technology. There I got to work on particle effects and other things, that were all scripted through Lua or XML if I recall correctly. Writing bugs in bug tools while performing light QA duties. To be honest, I’m not sure SimBin knew what they needed any designers for. But I was happy to get my foot in the door.

My best lesson from SimBin was how focused it was on the types of experiences they wanted. They could track the heat on individual brakes, the effects of the slipstream behind a car in front of you, and much more. They also focused their polygon budget on the rear of cars, since that’s the part that you see the most. You typically only see the front of a game model car in the mirror, rendered much smaller than you see the rear of the car in front of you.

This is an example I still use when talking about where to put your focus: consider what the player actually sees the most.

Unreal Development Kit (UDK)

I did work with the visual scripting tool Kismet (precursor to Blueprint) and Unreal’s then-intermediary scripting language UnrealScript in my spare time in 2006, for a year or so. It had so many strange quirks to it that I just never got into it properly.

First of all, Unreal at the time used a subtractive approach to level editing unlike the additive approach that everyone else was using, which meant that level design took some getting used to. With BSP-based rendering engines, the additive norm meant that you had an infinite void where you added brushes (like cubes, stairs, cones, etc.) and that was your level. In the UDK, the subtractive approach meant that you instead had a filled space (like being underground) where you subtracted brushes to make your level. The results could be the same, and maybe hardcore level designers can tell me why one is better than the other, but for me it just felt inconvenient.

Never got into UDK properly, because I always felt like you had to jump through hoops to get Unreal to do what you wanted it to. With Kismet strictly tied to levels (like a Level Blueprint today), making anything interesting was also quite messy, and you had to strictly adhere to Unreal’s structure.

Starbreeze Engine

My longest stint at a single company, still to this day, was with Starbreeze. This is the pre-Payday 2 Starbreeze that made The Chronicles of Riddick: Escape from Butcher Bay and The Darkness. The reason I wanted to go there was the first game, the best movie tie-in I had ever played. A game that really blew my mind when I played it with its clever hybridisation of action, adventure, and story.

Starbreeze was very good at making a particular kind of game. Highly cinematic elements mixed with first-person shooter. If this makes you think of the more recent Indiana Jones and The Great Circle, that’s because Machinegames was founded by some of the same people.

Starbreeze Engine was interesting to work with, with one foot firmly in the brushy BSP shenanigans of the 90s (additive, thankfully), and the other trying to push forward into the future. Its philosophies, including how to render a fully animated character for the player in a first-person game, and how scripting was primarily “target-based” in the words of the original Ogier programmer, Jens Andersson, are things I still carry with me.

But as far as the work goes, I’m happy that we don’t have to recompile our games for 20 minutes after moving a spawnpoint in a level anymore. (Or for 10-24 hours to bake production lighting…)

Nuclear Fusion

During my time at Starbreeze, I finally discovered programming and C++ and learned how to start debugging the Starbreeze Engine. Something that made my job (gameplay scripting) a lot easier and finally introduced me to programming in a more concrete way at the ripe age of 26.

At first, I tried to use the DarkBASIC-derived DarkGDK to build games in my spare time, since I understood the terminology and conventions, but soon enough I found another engine to use that felt more full-featured. It was called Nuclear Fusion. It was made by the American one-man company Nuclear Glory Entertainment Arts, and I spent some money supporting them during that time. Now they seem to be gone off the face of the Earth unfortunately, but I did recently discover some of the older versions of the software on a private laptop from those years.

As far as projects go, I never finished anything in this engine, but I ended up writing the official XInput plugin for some reason. Probably the only thing I ever wrote in plain C++ to be published in any form.

Unity

Having built many throwaway prototypes by this time, but never quite finished anything, I was still looking for that piece of technology that could bridge the gap between my lower understanding of programming and that coveted finished game project I wanted to make. At this point, I’m almost six years into my career as a game developer and my title is Gameplay Designer.

It’s in 2011-2012 that I discover Unity. On my lunch break and on weekends, I played around with it, and it’s probably the fastest results I’ve ever had in any game engine. The GameObject/Component relationship was the most intuitive thing I had ever seen, and my limited programming experience was an almost perfect match for what Unity required me to know.

Unity became my first introduction to teaching, as well, with some opportunities at game schools in Stockholm that came about because a school founder happened to be at the Starbreeze office on the lunch break one day and saw Unity over my shoulder. “Hey, could you teach that to students?” All of two weeks into using it, my gut response was “yes,” before my rational brain could catch up. But it turned out I just needed to know more than the students, and I had a few more weekends to prepare before course start. Teaching is something I’ve done off and on ever since—not just Unity—and something I love doing. Some of my students have gone on to have brilliant careers all across the globe, despite having the misfortune of getting me as their teacher at some point.

Since 2011, I’ve worked at four different companies using Unity professionally, and I have been both designer and programmer at different points in time, sometimes simultaneously. It’s probably the engine I’m most comfortable using, still to this day, after having been part of everything from gameplay through cross-platform deployment to hardware integration and tools development in it.

You can refer to Unity as a “frontier engine,” meaning that it’s early to adopt new technologies and its structure lends itself very well to adaptation. You set it up to build a “player” for the new target platform, and you’re set.

Today it’s more fragmented than it used to be, with multiple different solutions to the same problems, some of which are mutually exclusive. If you ask me if I think it’s the best engine, my answer would be no, but I’ll be revisiting its strengths and weaknesses in a different post.

Unreal Engine 4

The same person who pulled me in to teach Unity also introduced me to Unreal Engine 4 in the runup to its launch. I was offered an opportunity to help out on some projects, and though I accepted, I didn’t end up doing much work. It coincided with the birth of my first child (in 2013) and therefore didn’t work out as intended. I’ve still used Unreal Engine 4 quite a bit, including working on prototypes at a startup and teaching it to students.

It’s a huge leap forward compared to the UDK, maybe primarily in the form of Blueprint. Blueprint is the UE4 generation of Kismet and introduced the object form of Blueprints that you’d be used to today. Rather than locking the visual scripting to a level, Blueprints can be objects with inheritance. They are C++ behind the scenes and the engine can handle them easily and efficiently using all the performance tricks Unreal is known for.

Funnily enough, if you came from UDK, you can still find many of the Kismet helper classes and various UnrealScript template shenanigans are still there in Blueprint and Unreal C++ but wrapped into helper libraries. It’s clearly an engine with a lot of legacy, and the more of it you know before starting the better.

Toadman Stingray

Autodesk Stingray is an engine that was developed from the Swedish BitSquid engine after Autodesk purchased it and repurposed it for their own grand game engine schemes. BitSquid was a company founded by some of the developers that once made the Diesel engine, that was used at the long-since defunct Grin and later Starbreeze-merged Overkill game studios.

When I worked with it, Autodesk had discontinued the engine, but three studios were still using it and supporting it with internal engine teams. Those three were Arrowhead, Fatshark, and Toadman. I worked at Toadman, as Design Director.

As far as engines go, Stingray has some really interesting ideas. Two things struck me, specifically. The first is that everything in the engine is treated essentially as a plugin, making it incredibly modular. Animation tool? Plugin. Scripting VM? Plugin. The idea of a lightweight engine with high extensibility is solid. Not sure it was ever used that much in practice, but the intention is good.

Another thing I bring with me from those days isn’t strictly about Stingray, but about a fantastic data management tool called Hercules that Toadman used. It allowed you to make bulk changes to data, say doubling the damage of all weapons with a single command, and was an amazing tool for a system designer. It decoupled the data from the game client in ways that are still inspiring me to this day. Sadly, since earlier this year (2025), Toadman is no longer around.

Unreal Engine 5

The jump between Unreal Engine 4 and Unreal Engine 5 is not huge in terms of what the engine is capable of, even if Epic certainly wants you to think so (Lumen and Nanite come to mind). But there is one big difference and that’s the editor itself. The UE5 editor is much more extensible and powerful than its older sibling, and is both visually and functionally a complete overhaul.

There’s also a distribution of Unreal Engine 5 called Unreal Editor for Fortnite that uses its own custom scripting language called Verse, that is said to eventually be merged into the bigger engine. But I simply have no experience with that side of things. My amateur level designing days are long-since over.

Probably the biggest change between UDK and UE5 is that the latter wants to be a more generic engine. Something that can power any game you want to make. But in reality, the engine’s high end nature means that it’s tricky to use it for more lightweight projects on weaker hardware, and the legacy of Unreal Tournament still lives on in the engine’s core architecture and workflows.

As with Unity, I don’t think it’s the best engine. But I’ll get into what I consider its strengths and weaknesses in a future post. I’ve spent years working with UDK, UE4, and UE5, in large teams and small, but haven’t released any games with them thus far. Projects have been defunded, cancelled, or otherwise simply didn’t release for whatever reason.

Star Stable Engine

Imagine that you release a new update for your game every week, and you’ve been doing so consistently since 2013. This is Star Stable Online—a technical marvel simply for the absolutely insane amounts of data it handles. Not to mention the constant strain on pipelines when they’re always in motion.

My biggest takeaway from working alongside this engine last year (2024) is its brilliant snapshot feature that allows you to to save the game’s state at any moment and replay from that moment whenever you like. Even shared with other developers. This approach saves a ton of time and provides good grounds for testing the tens of thousands of quests that the game has in store for you after its 14 years (and counting) life span.

You may look at its graphics and think, “why don’t they build this in Unreal?”, but let’s just say that Unreal isn’t an engine built to handle such amounts of data. The visuals may improve, but porting it over would be a much larger undertaking than merely switching out the rendering.

Arrowhead Stingray

Can’t really talk about it. It’s Stingray, but at Arrowhead, and it powers Helldivers 2. Like the engine’s Fatshark and Toadman variants, it has some features and pipelines that are unique to Arrowhead.

Summary

• QBASIC (around ’89 or ’90?)
• Hex Editing (early 90s)
• Build Engine (early-mid 90s)
• WorldCraft/Hammer (late 90s, early 00s)
• DarkBASIC/DarkBASIC Pro (late 90s, early 00s)
• RenderWare Studio (’05 or ’06)
• SimBin Engine (’06) First professional work.
• UDK (’05-’07)
• Starbreeze Engine (’07-’12)
• DarkGDK/Nuclear Fusion (’09-’12)
• Unity (’12-today)
• Toadman Stingray (’17-’20)
• UE4 (’14-’21, sporadically)
• UE5 (’21-today)
• Star Stable Engine (2024)
• Arrowhead Stingray (2025-?)

Today

I hope I get to play around with even more engines than I already have. They all teach you something and expand your mind around how game development can be done.

At the end of the day, it doesn’t matter which engine you use, and it’s not often that you can make that decision yourself anyway if you’re not footing the bill.

Like an old colleague phrased it, “there’s no engine worse than the one you’re using right now.”

Fortunately, there’s also no better engine for getting the work done.

The object-rich world is crucial for making systemic games. Similarly, the state-space of your game can be used to describe the entirety of your design and to facilitate more holistic game development.

But it’s about time that we talked about data, since it keeps coming up. How to describe the smallest pieces of your simulation and the effects of this choice on your game.

This nicely rounds out the design space for systemic games.

State and Context

One of the key things I have long wanted to solve is how to handle data as an external element to a project to facilitate both modularity and extensibility. The engine will have to interface with the data, but you shouldn’t have to chase down specific objects in a level to modify them.

To better understand why this matters, let’s establish some terminology.

Data

We’ve defined data as almost everything a computer is operating on, and something we tend to bundle up and package as content using various tools. At this level, all data is more or less the same.

• Everything in a game is data.
• Data is often bundled up as content.

State

A person’s state of being or state of mind define data in the moment: how you are right now and what you are thinking about or feeling. In computer science, state is remembered data; things that are stored and can be referenced.

• State is data that is stored and can be referenced.
• Something’s ‘state’ is its value when checked in the moment.

Context

Context, in computing, is the minimum amount of state that needs to be saved to be able to restore the same state at a later point (where “context-switching” comes from). But for this post’s purposes, it’s more literal.

The local context is an object’s local state at a given moment in the simulation.

• Local context is an object’s local state at a given moment.

Once we start introducing more objects to the simulation, their relationships will result in relative context: object-relative state in a given moment. Comparisons expressed as state. For example, whether one object is moving faster or slower than another.

• Relative context is an object’s state in comparison to other objects.

State Properties

When you plan out your state, it’s also relevant to consider how and by who it will be used. If you change a value that only exists for a single-player game it’s probably fine to treat it more carelessly. If players decide to go in and change it, this will not amount to cheating since it’ll only change their local gameplay experience. It’ll functionally be modding.

But if you are building a multiplayer game with server-side authority and a network backend, you need to make different considerations and plan your data much more carefully.

• Hard-coded. Data is “hard-coded” when it’s written directly into program code and compiled, making it impossible to iterate on the data while the game is running and complicating knowledge sharing and tweaking. Initial test data, like move speeds or jump heights, can sometimes be hard-coded to make sure something works.
• Constant. A named variable that is available throughout a given scope. Pi and the gravitational constant, or your game’s easy mode damage baseline (see later) can be constants.
• Variable. A variable is a name for data that changes at runtime, or at least can change at runtime. Move speeds, jump heights, and other classics are examples of variables that may be manipulated during play.
• Tweakable. A number that developers can access readily and that may need several rounds of tweaking. This type of number benefits from templating (see later) and from being externalized from the object(s) it is affecting. Individual values for long lists of items, like the Damage value for all of your 250 guns, or the gold costs for your 1,000 items.
• Metric. A metric is something that gets sent to a backend and can be used to analyze how players engage with your game. It’s rarely a variable or even a tweakable that gets sent this way. May be something as simple as telling the backend which level is started or the duration of a challenge the player played.
• Optional. This is data, typically a variable, that is accessed directly by the player. The font scale, color of the UI, music volume, etc.; but it can also go deeper, as with the many customization options you have in a game like Civilization.
• Persistent. Data is ‘persistent’ when it needs to live across multiple game sessions. You don’t need to make constants persistent, for example, or really anything that is represented by content, but anything that should stay the same between play sessions will have to be persistent. Current health, current level, location of character in the game world, optional settings (like volume), etc., will usually be expected to be persistent.
• Visible. Whether a number or other point of data is player-facing is a crucial consideration. Anything that is player-facing will usually require filtering (e.g., Imperial vs Metric, or other localization), and needs to be more carefully designed than data that only exists in the simulation. Damage and health numbers, character names, dialogue subtitles, etc.
• Content. Usually when a game is referred to as data-driven, it’s because files on disk are defining how things get set up. Tweaking this data is about changing it, sometimes through an external tool or suite of tools. A premade level, an enemy with all its key data assigned through a registry file, or a 3D asset.
• Global. Data that is accessible everywhere in the game is global. This is generally the only scope consideration you need to do when you are designing your state space, since individual scopes are not as relevant or even automatic to the context you are working in. Quest facts, like if you have met Character Y before can be global, and optional and player-facing data is often global.
• Input. Data that comes from hardware input is a bit different, since you rarely want your game to access it directly. Rather, it’s good practice to use some kind of abstraction between the input and the gameplay action triggered by it. Analogue X/Y stick movement axes, touch gesture events, button presses and releases, etc.
• Replicated. Data that gets sent to clients across a network to simulate the same game state is said to be replicated. Which data a game replicates is an extremely important design consideration for multiplayer games and is therefore an important property to consider. Input sent to a server, timed events sent across peers in peer-to-peer networking, etc.
• Fuzzified. Data sets that has variable degrees of membership are referred to as “fuzzified” data, and we get into that later in this post. It’s a technique that can be used to turn tricky numbers into human-readable form and to allow computers to communicate in a way that somewhat resembles human conversation. How ‘warm’ a temperature is, how ‘damaged’ a character is, etc.
• Partial. If merely to track connections between pieces of data, it can be relevant to flag something as only part of a larger whole. If you separate data into base, attribute, and modifier, for example, noting that the data is partial and how can be very relevant. Any data that needs other data to be functional; maybe Strength is added to Damage and then multiplied by HitLocation; these three are then all partial pieces of data from the damage function.
• Temporary. Data that has a start and end time during the simulation and that isn’t technically variables. They can still be parts of key functions, but are not something that the developer is actively tweaking. Match points that are tossed out after tallying, score multipliers that are accumulated for just a single second, etc.

State Representation

All games represent state in some way, even if we may not think of it or plan it as such. There will be health numbers, speeds, and all manner of things to represent, and sometimes this grows organically from implementing the features we want.

“Eh,” the designer says to the programmer, “we need to add a Headshot Damage Multiplier to each enemy now that we have the helmeted one.” Additional state gets added, and often to every single object in the game, and not just to the ones that need it.

How we represent this state in our logic is what this section is about. It can be just a flat number in a spreadsheet somewhere; what Michael Sellers would call the “spreadsheet specific” layer of your data. But it can also use one of many existing ways for easy or efficient data representation.

Conceptual Separation

When you work with numbers in games the only thing that is certain is uncertainty. You will change the numbers down the line. But the great risk of any numeric system that changes it that you get cascading effects if you don’t plan for which levers you need beforehand.

To do this, you can separate the numbers up front into Baseline, Attributes, Modifiers, and Functions. You can read more about this in a previous post on gamification.

Spreadsheet Specific

King Arthur may have his Excalibur; as system designers we wield Excel! For many game designers it’s natural to gravitate towards spreadsheet tools for data management. To separate things into rows and columns and make any relevant changes as needed.

Because of this, you will find variations on spreadsheet support for most game engines. It’s quite common to use the comma-separated values (CSV) format to export them from spreadsheets and pull them directly into your game engine.

I use spreadsheets for a lot of things but very rarely for direct authoring of data. This is a preference, of course, but also comes from how spreadsheets represent data. Since it’s natural to simply add another column to represent a new feature for an object, even if it means that there’ll be an additional “0” in that column for every object that doesn’t use it. The risk for bloat is very high.

Some of the procedural implementations of features described in the post on building a systemic gun come from a spreadsheet specific line of thinking and is far more common than you’d expect.

XML

The Extensible Markup Language (XML) is sometimes used for registry files that can be compiled into game data, and sometimes in portable formats where the XML remains accessible for developers or players to change the values if they want. Variants of XML were extremely common in the past but is something I haven’t personally seen as much in recent years except in its XAML format for UI construction.

XML has a very readable and extensible format, with tags and closing tags that tell the parser what to expect. It can also be generated easily using custom tools.

<gameobject type="Character">
    <name>Goblin</name>
    <class>Fighter</class>
    <str>10</str>
    <hp>4</hp>
    <equipment>
        <item>Dagger</item>
        <item>Letter to home</item>
    </equipment>
</gameobject>

JSON

Probably more common today than XML, the JavaScript Object Notation (JSON) has pretty much the same benefits but is maybe slightly more readable. Which one you prefer, if any, is mostly down to preferences.

JSON is used extensively in web development and database formats, which is probably one of the reasons it’s become more and more common.

{
    "type": "Character",
    "name": "Goblin",
    "str": 10,
    "hp": 4,
    "equipment": [
        "Dagger",
        "Letter to home"
    ]
}

Lookup Tables

A lookup table is an array that contains all potential instances of some piece of data and allows it to be referenced by index. In any situation where you end up copying the same data over and over, potentially into hundreds or even thousands of instances of identical values, this can be a big way to save yourself from headaches (and memory waste).

Imagine a flow field, for example. A space that represents the vector force you’d apply to any unit walking a grid based on which grid cell it’s currently occupying. This could have each cell use its own Vector3D, with three separate floating point numbers per cell, or it could store a single byte with a lookup table index. The Vector3Ds would only be stored in a single place. This shrinks the amount of data you need to use by a lot and makes it easier to plan the data from a design perspective.

Since many types of state will repeat, lookup tables are a good way to represent them and can also provide a single location for developers to tweak values. For example, the damage modifier added from difficulty could live in a difficulty lookup table.

Array<Vector3D> FlowfieldVectors = 
{
    Vector3D::Zero,                                         // 0
    Vector3D::Up,                                           // 1
    Vector3D::Down,                                         // 2
    Vector3D::Left,                                         // 3
    Vector3D::Right,                                        // 4
    Vector3D::Normalize(Vector3D::Up + Vector3D::Right),    // 5
    Vector3D::Normalize(Vector3D::Up + Vector3D::Left),     // 6
    Vector3D::Normalize(Vector3D::Down + Vector3D::Right),  // 7
    Vector3D::Normalize(Vector3D::Down + Vector3D::Left),   // 8
};

Scripting Language

If you want more than just object representation in a serialised format, a good way to achieve it is by using an external scripting language. Where spreadsheets and object notation allow you to populate your game with data, a scripting language allows you to provide logic along with the data.

The below example is taken from the excellent book Programming Game AI by Example, by Mat Buckland, and shows a small Lua script defining a state (State_GoHome) for a state machine. A good example of what you can turn into data-driven parts of your game with a scripting language.

This is often within the realm of what a technical designer would be working with, since it allows behavior to be constructed outside the compiled game client and therefore makes iteration a lot faster.

State_GoHome = {}

State_GoHome["Enter"] = function(miner)
    print ("Walkin home in the hot n' thusty heat of the desert")
end

State_GoHome["Execute"] = function(miner)
    print ("Back at the shack. yer siree!")
    if miner:Fatigued() then
        miner:GetFSM():ChangeState(State_Sleep)
    else
        miner:GetFSM():ChangeState(State_GoToMine)
    end
end
  
State_GoHome["Exit"] = function(miner)
    print ("Puttin' mah boots on n' gettin' ready for a day at the mine")
end

If you push it even further, you can even make the scripting language a player-facing element, but then you’re obviously going into a different realm than data handling.

Key-Value Pairs

Context the way I refer to it in this post is inspired by Elan Ruskin’s approach to dialog on Left 4 Dead. In his own words (from the book Procedural Storytelling in Games), “A context is a single key-value pair such as PlayerHealth:72 or CurrentMap:Village5. For performance reasons it’s best to use numeric values as much as possible, so for string values such as names, consider internally replacing then with unique symbols or hashes.”

A key-value pair can be represented in many different ways in code and is often used in data structures like maps and dictionaries. You’ve probably already made use of them many times before.

template <typename KEY, typename VALUE>
struct KeyValuePair
{
    KEY key;
    VALUE value;
};

World Properties

Inspired by Jeff Orkin’s world state representation, one way you can represent state is by using a union in C++ or explicit memory layout in C#. Each piece of state will always take up the same amount of memory, you can pool it easily, and you can use it across your game to describe the state of individual objects.

In the case of Goal-Oriented Action Planning (GOAP), this state is used to represent the current setup of the world so that enemy AI can make up a plan to execute. The state is handled as nodes in a graph with the edges represent actions. A goal-first A* algorithm handles the planning.

This way of representing runtime state has other benefits too. One of them is that it can be decoupled from the objects that the data represents and can then be used for other intermediary operations as well.

How it looks in the paper:

struct SWorldProperty 
{    
    GAME_OBJECT_ID hSubjectID;    
    WORLD_PROP_KEY eKey;    

    union value    
    {       
        bool   bValue;       
        float  fValue;       
        int    nValue;       
        ...    
    }; 
};

And here is how the paper demonstrates the use of a world property:

SWorldProperty Prop; 
Prop.hSubjectID = hShooterID; 
Prop.eKey = kTargetIsDead; 
Prop.bValue = true; 

“If the planner is trying to satisfy the KillEnemy goal,” writes Jeff Orkin, “it does not need to know the shooter’s health, current location, or anything else. The planner does not even need to know whom the shooter is trying to kill! It just needs to find a sequence of actions that will lead to this shooter’s target getting killed, whomever that target may be.”

In other words, it’s enough to store exactly what you need right now as world properties, and not treat game state as a runtime database.

Tags

Tags have a lot in common with keywords in card and board game design. It’s the use of a single word or few-word sentence as shorthand for a game rule or exception. Some creatures in Magic: The Gathering deal their damage before other creatures get to deal theirs, for example. A rule effect referred to consistently as “First strike.”

This same principle can be applied to game state too. As a descriptor (“Elf”), for conditional reasons (“Immunity.Fire”), or as a modifier (“Burning”). Consider a concept such as damage types for example. Just a damage number is fine, but you may want to qualify certain types of damage. Maybe a Piercing weapon does less damage to skeletons, or is better protected against by a chainmail armor. Then Piercing can be a tag applied to all three: weapons, enemies, and armor.

Most game engines use tags in one way or another. They may be developer-facing strings that get hashed at compile-time or they can be sent as a stream. Some engines do none of this automatically, however, and may expect you as the developer to not do unnecessary string comparisons or other expensive things at runtime. (As a general rule you should always avoid comparing strings to each other: compare their hash, length, or other cheaper thing instead.)

struct Tag
{
    // A hash of the original string, used for fast comparisons.
    int32 Hash;

    // An index into a single array where all the strings can be found.
#ifdef _DEBUG
    int32 StringIndex;
#endif
};

With a tag specified, and the developer-facing strings present somewhere, you can then create a structure for comparing groups of tags against each other and to test if specific tags are present. Of course, you may want to make the strings player-facing too and expose it completely to the game, but that’s not a requirement.

struct TagCollection
{
    Array<Tag> Tags;

    void AddTags(Array<Tag>& NewTags);

    // Has this specific tag.
    bool HasTag(Tag& Tag);

    // Has any of the tags in the other collection.
    bool Any(TagCollection* Other);

    // Has all of the tags in the other collection.
    bool All(TagCollection* Other);

    // Has exactly the same tags as another collection.
    bool Exact(TagCollection* Other);
};

Maybe you want to do additive trait-matching, and check if an armor has Resistance.Piercing before you deal damage with a sword that has Damage.Piercing. Or you want to collect tags as context before you do fuzzy pattern-matching.

Simply put: tags are extremely useful.

Data Assets and Fuzzy Sets

Many struggle to remember the exact number 9.80665. But if we refer to it as Gravity we don’t have to use the number. We can also change it down the line in a single place if we suddenly want things to behave differently across our game. When we do this, we fuzzify the data. We use words to describe it, as with variables in code.

This can be done in a template (or C# generic), for example:

template <typename T>
class DataAsset
{
    T value;

public:
    DataAsset(T new_value) : value(new_value) {}
    T GetValue() const { return value; }
    void SetValue(T new_value) { value = new_value; }

    // Serialization and other fun stuff!
};

With a template like this, you can easily add saving and loading, comparison checks, and other handy ways of reusing the concept of data across your game. It’ll all just be added to the DataAsset class and you can make all of them live in a single place in memory, on disk, or whatever you want.

DataAsset<float> Gravity = DataAsset<float>(9.80665f);

It’s straightforward to use, even if this variant would still rely on hard-coded numbers, and it’s generally a better idea to use external JSON or other scripting methods that can be changed without having to recompile your code.

The real power of fuzzification is that you can start referring to numbers conceptually and not just as plain numbers. This doesn’t just simplify the conversation, it also means you don’t have to painstakingly change that price point for a gazillion individual items.

struct Prices
{
    DataAsset<int> cheap = DataAsset<int>(5);
    DataAsset<int> ok = DataAsset<int>(150);
    DataAsset<int> costly = DataAsset<int>(2200);
    DataAsset<int> expensive = DataAsset<int>(17000);
};

This same principle can be applied to sets with more than just one point of data. We will then want to define fuzzy sets where your input will have a degree of membership with each value in the set.

struct FuzzyKeyValue
{
    float key;
    float value;

    FuzzyKeyValue(float _key, float _value) 
    { key = _key; value = _value; }
};

template <typename T>
class FuzzySet
{
    T object;
    Array<FuzzyKeyValue> keys;
    
public:
    FuzzySet(T _object, Array<FuzzyKeyValue> _keys)
    {
        object = _object;
        keys = _keys;
    }

    T GetObject() { return object; }

    float Evaluate(float t)
    {
        // Assert that there are at least two keys; pointless if not

        for(auto i = 1; i < Keys.Num(); i++)
        {
            auto a = Keys[i-1];
           auto b = Keys[i];

            if(t >= a.Key && t <= b.Key)
            {
                // Return the 'degree of membership' of the supplied t
                return Lerp(a.Value, b.Value, (t-a.Key) / (b.Key-a.Key));
            }            
        }
    }
};

Let’s grab an example of something fuzzified from the Internet. In this case temperature:

To represent this in the simple code from before, it’d look something like this:

// Low
keys_low = {
    new FuzzyKeyValue(1f, 0),
    new FuzzyKeyValue(1f, 10),
    new FuzzyKeyValue(0f, 20)
};

FuzzySet<string>("Low", keys_low);

// Medium
keys_medium = {
    new FuzzyKeyValue(0f, 10),
    new FuzzyKeyValue(1f, 20),
    new FuzzyKeyValue(1f, 30),
    new FuzzyKeyValue(0f, 40),
};

FuzzySet<string>("Medium", keys_medium);

// High
keys_high = {
    new FuzzyKeyValue(0f, 30),
    new FuzzyKeyValue(1f, 35),
    new FuzzyKeyValue(1f, 60)
};

FuzzySet<string>("High", keys_high);

To finally make practical use of this data, we can wrap a number of sets together, like the example below, to find out how warm a certain temperature is.

struct FuzzyTemperature
{
    FuzzySet<string>[] Temperatures =
    {
        FuzzySet<string>("Low", keys_low),
        FuzzySet<string>("Medium", keys_medium),
        FuzzySet<string>("High", keys_high)
    };

    string Evaluate(float t)
    {
        string returnString = "";
        auto evaluation = 0.f;
        
        for(auto set : Temperatures)
        {
            auto eval = set.Evaluate(t);
            if(eval > evaluation)
            {
                evaluation = eval;
                returnString = set.GetObject();
            }
        }

        return returnString;
    }
};

Predicate functions

A predicate function is a function that returns a single boolean true or false from supplied parameters. It’s an excellent way to test the validity of different situations at runtime and graduates state into its relational equivalent, which we can call context.

Many world property unions will effectively do the same thing, such as the kTargetIsDead property example illustrating a desire for the target to be dead. A predicate function is where we learn what is true at runtime.

This can be simple and effectively reusable, for example if you have a resource object that can be reused for any number of resources:

bool ResourceCheck::ResourceBelowThreshold(const float Threshold) const
{
    return PlayerData.ResourcePercentage < Threshold;
}

Since predicates can be used for almost anything it can make a lot of sense to keep a bunch of them around in a gameplay-scope helper library. For the following examples, I was a bit lazy, but you can see how quickly this becomes useful. For example, if InFront and FacingSame are both true at the same time, it would be the contextual requirements for a classic video game stealth takedown.

static bool InFront(Transform* Self, Vector& TargetLocation)
{
    return Self->InverseTransformPosition(TargetLocation).Z > 0.f;
}

static bool Behind(Transform* Self, Vector& TargetLocation)
{
    return Self->InverseTransformPosition(TargetLocation).Z < 0.f;
}

static bool Left(Transform* Self, Vector& TargetLocation)
{
    return Self->InverseTransformPosition(TargetLocation).X < 0.f;
}

static bool Right(Transform* Self, Vector& TargetLocation)
{
    return Self->InverseTransformPosition(TargetLocation).X > 0.f;
}

static bool FacingSame(Transform* Self, Transform* Target)
{
    auto FacingDot = Vector::Dot(Self->Forward(), Target->Forward());
    return FacingDot > .9f;
}

Once you have these helper functions, you can use them in code to generate tags, populate bitmasks or lookup tables, or determine what happens when objects hit each other. You can use them to generate context queries for dialogue or to qualify gameplay interactions.

Bitmasks

A bitmask means using a variable’s individual memory bits as flags. With a byte, you can store 8 bits. With a 32-bit integer, you can surprisingly enough store 32 bits. Many tutorials you’ll find will become shock-full of boolean flags faster than you can blink. A “bool,” though it stores the equivalent of a bit, is still one byte of memory due to the smallest addressable thing in memory having that size. A bitmask is therefore a way to not fill your memory with unnecessary waste while only recording bits anyway.

For the purposes of data, it’s also a convenient way to bundle related information together. A good example is spawn points and spawning in general. If you have, say, five different game modes and you want to be able to support all five using different spawn points, you can use a bitmask to store this information for each spawn point.

enum GameMode
{
    assassinate = 1 << 1,
    infiltrate = 1 << 2,
    steal = 1 << 3,
    defend = 1 << 4,
    horde = 1 << 5
};

int32 CurrentState = assassinate | infiltrate | steal;

// Set a bit
CurrentState  |= 1 << defend;

// Clear a bit
CurrentState &= ~(1 << defend);

// Toggle a bit
CurrentState ^= 1 << defend;

if((CurrentState & GameMode.assassinate) == GameMode.assassinate)
{
    // 'assassinate' mode is supported.
}

Asset Data

Last, but certainly not least, there are many ingenious ways to use asset data to store information. I will mention just a few, to give you some pointers, but suffice it to say that one reason technical artists are in high demand is that clever solutions to pipeline problems can save considerable amounts of time and money even for small projects.

The same principles can be used in many different ways to store systemic data and state.

Keyframes

Animation keyframes are used to store the positions, rotations, and scales of bones that are weighted to skinned meshes. This doesn’t have to be an animated character but can just as easily be a piece of cloth or parchment, or even a whole level.

The latter was a way for Legacy of Kain: Soul Reaver to represent the two different worlds that the player could shift between. One keyframe per world (out of two).

Vertex Colors

Using vertex colors to paint objects is tried and true, but when you texture your objects you may no longer need it for this purpose. This opens up countless other opportunities to store data in your mesh objects. For example, Vagrant Story used vertex colors to store its baked lighting. A technique that worked quite well at the resolutions for that game.

Most game engines have support for one full RGB vertex color per vertex. It’s possible to store more than one vertex color per vertex too, such as is the case in The Last of Us Part 1, where the different vertex color channels are used as mask values for things like mould, dirt, and cracks.

Furthermore, vertex colors can be accessed at runtime as well, and can then be used for updated live information. Say, the heat or magnetism generated by an object. I don’t know that this is how Splinter Cell does its heat vision, but it could be.

U-Dimensions

Something that has been mentioned before is how Neon Giant used the “U-dimension” (UDim) workflow not as a means to map more textures to an object but as a way to create masks simply by the act of UV-mapping a mesh.

This technique is quite clever and relies on mesh UVs (which are simply coordinates; “XY” was taken) using normalised values as a standard. I.e., values between 0 and 1. So by storing coordinates at higher values, like 1-2 or 2-3, you can map more than one set of UVs to the same object.

You can use this for anything where you’d use a mask or map more than one texture to the same object. It could be the albedo and metallic of a PBR material, as for Neon Giant, or you could map it to other properties such as bounciness or Resistance.Piercing.

Which One?

When you pick which way to represent your data, you need to consider four factors:

• Which tools pipeline you are already familiar with. Using UDims and other mesh techniques only make sense if you feel at home in a 3D suite, working with meshes. Similarly, you should only use CSVs and spreadsheets if you’re already comfortable with them or want to learn.
• Which problems you are solving. If your game is tied to a backend, JSON makes a lot of practical sense since it’s already speaking the language of the web. But if you want players to customize your game, it may make more sense to use a scripting language.
• Which levers you will need for testing and balancing. This is the most important, and the one that requires most design and planning. If you need to go back to an external tool every time something must be changed, whether that’s Excel or Blender, some changes may become too cumbersome to test.
• How the data will be communicated. Both internally, between objects in your game, and towards the player. Some things will be developer-facing only, others will be player-facing. Making sure to have one source of truth is extremely important.

Hopefully those pointers can help you at least consider how to represent your data. There are many ways that these things are tied together ultimately. Objects, data, state-spaces, etc., and there are more ways than can ever be summarised in a post like this.

I will come back to this post to extend it when new things crop up. So if you have any suggestions for clever data representations, please send them to annander@gmail.com and I’ll consider adding them along with a thank you.

This post is the last post in a series on combat design.

There has been many attempts to classify storytelling. Georges Polti suggested The Thirty-Six Dramatic Situations in 1895. Vladimir Propp used a selection of 31 functions to illustrate similar things in the 1920s. There’s also the widely misused monomyth of Joseph Campbell, originally published in his book The Hero With a Thousand Faces in 1949. Stepping forward into our present day, Dan Harmon’s story circle and Christopher Booker’s Seven Basic Plots pop up.

Much of this work tries to take the nebulous concept of story and make it make sense. Sometimes through lenses such as folklore or mythology; today as attempts to make tools for screenwriters.

Screenwriting is the storytelling craft that seeps over into game development most often. But where gunplay and melee are technical challenges to solve, the design space for drama is something else. Without stakes, there is no drama. Without characters, goals, motivations, and risks, there is no drama. Some would say without conflict, there is no drama, and if we are not competing against other players, drama must come from somewhere else.

Let’s dive straight into the killing! We know we need to do violence in this combat game of ours, but we don’t yet know the details. The violence is also not what’s important for the drama to work.

Instead, there are five areas you can start with if you want to figure this out:

1. Where I am and what I’m doing.
2. Who I am, who I will be killing, who I care about, and why.
3. What happens if I don’t kill who I need to kill.
4. Which interesting choices I can make.
5. I need to know that I won’t break the game.

Background

Where I am and what I’m doing.

When someone draws their gun or sword in a movie it’s often the culmination of a longer storyline. It doesn’t have to be an on-screen culmination, however. It can just as easily be Inigo Montoya telling someone to prepare to die and detailing why in the same breath.

The crux is that this doesn’t work in video games, and the reason is simple: a game cannot control its audience’s intentions or how they feel. Cinematic storytelling works on empathy. This has been discussed before. To afford a player the same level of connection to their character, the only trick that exists is to try to make the player and their avatar occupy the same head space.

The player needs to know who are involved, what the stakes are, and what can be done about it, and the avatar needs to be someone who shares the goals of the player. This is one reason why obeying is such a common activity: a soldier following orders is strongly connected to a player following instructions. The fantasy and the activity become one and the same. Go here, destroy this, kill those sentries.

In a game, it’s not enough to have your character tell the opponent that they should prepare to die because they killed your father. You, the player, will have no idea what the character is talking about if they do.

To mitigate this, many games use one of two effective shortcuts: stereotypes and/or explicit connection.

Stereotypical Evil

Alien invaders. Bugs. Nazis. The living dead. Foreigners. It’s always easier to make someone kill those who look different or speak a different language. Though the symbolism can be quite problematic, games rarely engage with symbolism and instead use stereotypical enemies for the sake of having something to kill.

Mandatory Connection

The more ham-fisted way is to copy the form that film uses and simply tell the player what they should care about. Those polygons over there were your family, now proceed to gun down bad guys for 15 hours.

Or, even more lazily, you need to find a person who is gone. Now go off and find them and kill everyone who stands in your way. There’s no way for you to know how they look like, where they are, or anything else: you need to trust that the game tells you when you did right or wrong.

What makes the empathetic connection work in film is the cinematic authorship and the way film directs the audience through this empathy. With players of games, they may be skipping all cutscenes, taking a phone call during the exposition, or even just fiddle around with their inventory items while someone is talking. Those are the activities you need to capture.

Cast

Who I am, who I am killing, who I care about, and why.

Making believable characters is not always the goal. Some games, like puzzle games and sports games, may not have much story context at all that requires such things. But my personal passion is immersive and highly systemic games with a strong core fantasy. Such games benefit from characters.

• Protagonists are the main characters: usually who the player is portraying.
• Antagonists are the enemies of the main characters.
• Support is everyone else.

Characters

When you sketch out your cast and why they hate each other, you shouldn’t get too stuck thinking of individuals. A character will often be an individual, of course, but characters can also be horses, space ships, machines, weather phenomena, and many more.

A faction like “The Guards” will provide a good umbrella for presentations. If you present guards as corrupt and somewhat dull, this provides good information for the player whenever they encounter a guard. It also means that an individual guard that breaks from the stereotype becomes more interesting. Think of the Fable warden that reads poetry, for example; a character that plays off a warden trope and then has some fun with it.

Companions in games range from animals to disembodied voices talking through an earpiece. Something that becomes extra relevant since it’s harder to give the player’s character a voice when there’s no way to know what the player is thinking. Then it’s easier to express world information through companions. But movies do the same with sidekicks and other characters who can provide infodumps.

A Good Game Protagonist

If a game is primarily an action game where the player will shoot and stab things, it’s hard to make a pacifist main character. In the first Tomb Raider reboot, Lara Croft is seen lamenting her first kill in a cutscene. The player playing Lara then proceeds to kill many more, presumably without batting an eyelid.

This dissonance can only really be avoided by putting the main character (the player’s avatar) and the player as close to the same mental space as possible. Or in the words of then-Telltale game designer, Harrison Pink: “Spend the time to let your player build the same primary motivations as the character. Let them experience the events that kick the story off together.”

Few games do this better than Thief: The Dark Project. Players are wont to steal and loot things in all games, and Garrett is the master thief. A role that not only promotes but reinforces the player’s emotional space.

“The goal is to allow the player and their avatar to occupy the same emotional space,” said Pink. Making sure that the role you play and the activities you engage in carry the same motivation.

Intention and Obstacle

Screenwriter Aaron Sorkin refers to intention and obstacle as the drivers for a good script. “Somebody wants something. Something standing in their way of getting it,” he said in his Master Class on screenwriting. “They really want it bad, and whatever’s standing in their way has got to be formidable.”

If you were to make a roadtrip story that starts with a group of friends going to Las Vegas, and then continues when they get there, it wouldn’t be much of a roadtrip story. But going to Vegas is a clear intention.

To become a story worth telling—or, for a game, worth playing—something has to obstruct the trip, stir up a conflict in the group of friends that splits them up, or otherwise generate an obstacle. The more you can tie this to the individual characters, the better.

Character Development

One way to look at character development is from the perspective of flaws. Many stereotypes exist here. Alcoholism, avarice, jealousy, laziness; there’s a slew of flaws that a character may display. What you can take character development to mean is a character’s struggle to try to overcome their flaws.

If the character succumbs, it indulges in its flaw and sinks deeper. If it instead overcomes its flaw, it gets to show to the world how this improves everything, or how it leads to another flaw. Some characters have flaws as defining traits instead and the portrayal focuses on how they handle the problems it leads to. They will never succumb or overcome—there’s no redemption for them—but they will still struggle.

What’s important with flaws and character development is that they are made to matter. In games, you will sometimes fight against literal demons made to manifest flaws through the game’s other systems. In Condemned 2: Bloodshot, the main character Ethan struggles with alcoholism. You take a deep swig of hard liquor to steady your aim for a while. Throughout, the Alcohol Demon harasses you, until eventually, once the Alcohol Demon is defeated, Ethan’s aim when using firearms will no longer need to be steadied by consuming alcohol.

These kinds of explorations of how to make interactions matter in game development are still not fully mature. We have a lot left to explore in this space as game developers. How to allow players to bring their own mental models to games and experience personalised stories that don’t have to turn mental issues into bossfights.

Dissonance

When I played Red Dead Redemption 2, I wanted to shoot Micah in the back during the rescue mission or just leave him in his cell to rot. I spontaneously disliked the guy, without knowing how things would develop. It’s one of the worst cases of dissonance I’ve personally had between the character I’m playing’s reaction to another character and my personal reaction.

This type of dissonance, between the intentions of the character you are playing and your intentions as a player are quite common in games and come from the idea that you are telling a story to players rather than letting them experience one. Micah’s betrayal seemed inevitable to me, to the point that I groaned when it eventually happened. I could’ve prevented it without anyone ever being the wiser, by simply shooting him in the back during the rescue and dumping his corpse outside a bear cave somewhere.

Because of RDR2’s deep systems, I even know how I’d do it. But I’m not allowed to. Micah has plot armor—he’s arbitrarily immune to the game’s systems because he has a role to play in the narrative script. An authorial infringement on my mental model playing Arthur.

My canonical Arthur certainly shot Micah in the back.

Stakes

What happens if I don’t kill who I need to kill.

Games rarely deal with stakes. The only thing that tends to be at stake is the player’s time. If the player character gets killed, it fails the game and triggers a checkpoint reload.

In some types of games, the lack of any real stakes has consequences on the game’s emotional space. In horror games, the suspense often comes from uncertainty and from the fear of dying. Once you do die, the illusion crumbles, because you can see that all you ever risked was to have to redo some arbitrary part of the game. Dying becomes a fail state and part of a retry cycle, same as in any other kind of game.

To approach this, let’s look at stakes.

Premise

“It used the backdrop of an epic, but didn’t try to tell an epic,” said ex-Looking Glass art director Nate Wells about the Thief series. “I think that’s still one of the greatest mistakes games make. They set down all the proper names then proceed to show you the conflict at a kingdom versus kingdom level. What you have to do is just set that in the back and tell the story of one character. Tell the low-level story.”

The premise is where and when we find our cast. Whether this is revolutionary France or Epic Fantasyland, it will tell the player something about what is important. In a desert, they will probably find water precious, and a group of parched survivors fighting over a wellspring has a very clear stake: without the water, they die.

This is also why this isnt’ just setting. It needs to tell the player why something is worth fighting for and in as clear a way as possible.

Scale

In the tabletop role-playing game Trollbabe, by Ron Edwards, stakes are defined by a concept called Scale and “applies to the extent of actions and effects in the fiction. Low Scale means only a few or little things are changed; high Scale means whole communities, even continents, are changed.”

Scale ranges from 1 to 7, where 1 represents “[a] person’s or a few persons’ immediate well-being” while 7 represents “a large area identifiable by similar cultural practices and physical resources, including many communities across diverse geography.”

This starting point is helpful, since Trollbabe also doesn’t allow Scale to be reduced. So if you increase the stakes by saying that an army is threatening the village, you cannot then decrease the Scale to make it about a stall merchant’s stolen bread loaf. This type of rule is helpful when working within any game design context.

Urgency

Many stories, whether written or recorded, will present a sense that if things are not resolved now, then there will be dire consequences. But translated into game contexts, any sense of urgency often falls flat. Particularly in open world games where months can pass between you receiving the quest and actually completing it, while dialogue and other in-game copy will still imply said urgency.

This doesn’t have to be the case however. In games as old as The Hobbit, urgency has played an important role. Not always stated out loud, but that game’s dynamics affected where some characters could be found. Just like Dead Rising puts everything on a schedule and if you miss an event because you’re not there, then it is still resolved as if it happened. If you want to get on the chopper, you need to actually be there!

Frankly, if you don’t do urgency in a systemic way, it’s better to not do it. The player will understand that it’s not real.

Choices and Consequences

Opportunities to make interesting choices.

The concept of choices and consequences (sometimes “C&C”) has often been a talking point among gamers and game developers. Particularly for role-playing games.

When it comes to combat, your choices will be informed by your understanding of the characters and premise. If you decide to poison the desert wellspring that was mentioned earlier, everyone would die. But if the game has already established poison as a tool, this makes it an interesting choice to be able to make.

In Bob Case’s (“MrBtongue”) excellent YouTube video on choices and consequences, four things are brought up as how you can make choices work. The first three are highly relevant. If you also want the fourth you will simply have to watch Bob’s video.

Manage the Scale

“As your number of choices increases arithmetically, the number of possible game states increases exponentially, and if you are not careful you may inflict an impossible workload on yourself.”

Since my obsession is systemic games, scale is less about the state-space complexity Bob Case is talking about and more about the development overhead of your systems. You will design the objects and rules and the states will be consequences of how everything interacts.

The key to managing scale is to be careful with how many rules you establish and how many tools you provide the player with.

Failure is a Consequence

“[I]f your goal is simulation, then an action that would logically lead to failure in the real world should also lead to failure in your game.”

Games rarely have interesting consequences for failure and combat is usually the worst. Like we covered before, dying means you’re dead and you have to replay. A future post will go into scenario and mission design, but at this level it’s interesting to remember that failure is real and that it should be allowed to happen.

At the very least, your game should provide feedback that acknowledges the failure and builds forward on top of it. It can be to add scars or to have characters comment on it, but it needs to be a concrete thing.

Make Me Paranoid

“Keep us guessing. Keep us worrying about the possible consequences of everything we do, regardless of whether the game accounts for them or not. It will make for a more immersive experience.”

Bob Case mentions how, in the original Fallout, if you speak about the vault where you came from there may be bandits who go there to raid it. He mentions how this has affected how he looks at choices in every game he’s played since. Such a powerful consequence for speaking carelessly.

But remember that you don’t need content for everything. For many games, as long as you provide enough consequences, the player will read more things into it. Imagination does a great job filling in the blanks.

State-Space Stability

Trusting that the game remains stable.

Many players are not used to pushing the boundaries. It’s also quite comfortable to know that, whatever happens, the game will reset back to its default state so you can try again. For as long as gaming has had right and wrong choices, there’s also been save scumming. From the sharing of ready-made save files to “abuse” of the Quick Save/Quick Load keys.

Much of this comes down to stability. If a game has many interconnected systems, it can easily get out of control, and players may get frustrated or miss expensively produced pieces of content. This is one reason that killing the player’s avatar and resetting the state is so powerful: you know (as a developer) that the game state is being reset and that everything is now safe.

Escalation and Deescalation

Many games with stealth have a mechanic where being spotted and unable to stop the spotters will put the whole game into an alarm state. Turning off the alarm or disappearing for a while will have the enemies return to their previous state. There’s no checkpoint reload, but it kind of behaves the same as one.

Players will sometimes comment on this and talk about how unrealistic it is, but as a mechanic, it allows players to try and try again without having to save scum.

Combat Philosophy

This was a hard series of posts to write and mainly because they treaded a bit too far from practical implementation and into the realms of theory. Personally, I think this makes them lower quality than the posts I have on my blog that are more specifically tied to systemic design, and I intend to return to the practical because of this.

It’s been a good exercise in thinking through what combat can mean, and to inform my own projects too (more on those some day), but there are more systemic subjects to cover and those will be coming back next.

Until then, if you agree or disagree with anything, please do so in comments or via annander@gmail.com.

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

Sport can be used as a layer on top of your gunplay or melee. Perhaps as added fairness (a sense of “good balancing”) or as a focus on competition. It can also be the whole purpose of your project. A competitive game needs to have a space for players to git gud and to compare their results to that of other players. Or to be the first to figure out winning strategies that can give them an edge.

If you want to tell me I’m wrong or contact me for other reasons, do so in comments or to annander@gmail.com.

Now let’s dive into competition and how you can approach designing a “sport.”

Terminology

When designing anything, I find it helpful to first set up the terminology. This doesn’t have to be the exactly right words that other people use, necessarily. They’re here to help with the game design, not to become some type of definition.

Determinism

Chess is an incredible game design. It’s symmetrical, it has no random elements, and each pawn has its own clearly defined rules. Rook moves this way, bishop moves that way, grid has 8×8 individual square spaces, etc. This is what makes its game design deterministic. Doing a specific move under certain circumstances will always yield the same resulting game state.

Because of this, pitting two players against each other is a test of skill. Who can predict what the opponent will do, make the most compelling opening move, or think the farthest ahead. It becomes a contest of ability.

“In order to improve your game,” said legendary Cuban chess master José Capablanca, “you must study the endgame before everything else. For whereas the endings can be studied and mastered by themselves, the middle game and opening must be studied in relation to the end game.”

Chess is a great example of a game that must be studied and practiced. Because of its determinism (no random or otherwise unknown elements), yet deeply complex state-space, it’s often considered a hard game to be good at, and if you’re not good you will simply not win.

Player Uncertainty

Poker, another highly competitive game, adds elements of player uncertainty and randomisation and is therefore not deterministic. The card combinations that form your playable hands are all known and their relative values are also known, but because players hide their cards from each other in their respective hands, and because of the luck of the draw, you can’t be entirely certain what another player is up to. They may be bluffing with their all-in, or they may indeed have a royal straight flush to give them confidence.

As the game continues, more of the 52 cards from the deck will be revealed and you will have more “state” to consider, but you can’t be completely certain unless you already personally have the highest possible hand.

This uncertainty and randomisation adds an additional layer to the competition. It doesn’t make poker a better game than chess, but it alters the required skillset. It’s not enough to master each hand, you must also play the bluffing game and start considering the myriad options based on limited information and mathematical probabilities.

Exploitation

Chess and poker are incredibly mature games compared to most video games. They’ve been played for hundreds of years and countless kinks have been ironed out. Alternative ways of playing have come up that deal with common speed bumps and other issues. Video games, on the other hand, are released in the 100s every day, and because of this, some of them will come with unintended exploits.

I’m personally not a very competitive player. I often play competitive games anyway to study them, but I very rarely win and pretty much never come up with any winning strategies. In 30-some years as a gamer, there’s just been the one exception: Battlefleet Gothic Armada.

While playing the beta before launch, I realized that the Imperial ships with their heavily reinforced prows were almost immune to damage coming from the front. So I equipped some ships with weapons that didn’t require them to turn (many other weapons fire broadsides in the game), instructed them at the game’s start to only face forwards and to stay far away and fire these weapons near max range. They would sometimes move slowly towards their targets and then use a ramming action to deal the killing blow, but only against enemies that were already accelerating towards me.

At first, I didn’t lose a single match with this setup! My ships took little to no damage and were able to destroy enemy ships consistently. For various reasons, I never really kept playing the game after launch, but this still serves as a decent example of exploitation.

In game theory, a dominant strategy is a strategy that will always win, and that most players will eventually gravitate towards. It’s not clear whether my prow-forward approach was ultimately such a strategy, but consider it an example.

The opposite of a dominant strategy is a dominated strategy, which is any strategy that is always inferior and that players will quickly abandon for other strategies. No one in a competitive first-person shooter would stick to only the knife, for example, unless there’s such a massive skill disparity that it can be done for laughs.

It can be fine to have these strategies in a game, as long as you include them consciously and provide ways to mitigate them. Going for a knockout can be considered a dominant strategy in boxing, since it ends the match before the last round, but though it gives an edge to fighters that can consistently hit very hard it’s never guaranteed that they will end every match on a knockout, and hitting hard all the time may be more exhausting than playing a longer boxing game.

Game Blame

If you are terrible at chess, you are terrible at chess. There’s no way to sugar-coat it. Other players are simply better than you. It’s the same if you play StarCraft and can’t peak out at the actions per minute (APM) of the pro players, that may span 180-1,000 APM.

When games reach this level of competition, many players will bounce off. Psychologically, the knowledge that you are inferior and that there’s nothing you can do about it isn’t all that motivating. Some players will find motivation in this space anyway and push on.

But another way to get around it is to let players blame the game.

In competitive Magic: The Gathering, a common setup is to determine a winner by playing a best of three. This way, fewer players will feel that they lost because of a bad hand or lucky/unlucky draw. If they do end up losing anyway, they can still blame a bad hand or unlucky draw, however. If they had only played one more match, they may think.

This is similar to the “just one more time” mentality that can come up when you play a fast-paced fighting game, or other high-paced game. Your opponent was just lucky; you will get them next time. It wasn’t your fault, it was chance, luck, poor balancing, the sun in your eye, etc.

This is a good thing to have in a game design if you don’t want to cater it exclusively to potential hardcore players. It prevents beginners from bouncing off the game if they get to have a good run now and then, even without the skills the game would normally require.

Yomi

In the words of game designer and former competitive Street Fighter player David Sirlin, “Any decent competitive game needs to allow you to counter the opponent if you know what he will do. What happens, though, when your enemy knows that you know what he will do? He needs a way to counter you. He’s said to be on another level than you, or another ‘yomi layer.'”

Yomi (読み, and not 黄泉; the latter is the underworld) means ‘reading’ in the sense that you can read your opponent. In Sirlin’s book, Playing to Win, he describes Yomi layers as levels of knowledge. You know what your opponent will do (layer 1), but they also know that you know (layer 2), and you know that they know that you know (layer 3). Each layer requires the game design to provide a counter action so that players can act on the information they have (or think they have). “[T]here need only be support up to yomi layer 3,” continues Sirlin, “as yomi layer 4 loops back around to layer 0.”

Thinking in terms of yomi layers can help more areas than competition, however. If you look at a game enemy design in terms of yomi layers, you can design encounters that challenge players in more ways than the straightforward features they use and you can allow the player to feel clever about it along the way.

Blue Shells

The blue shell in the Mario Kart series has always been a bit contentious. It’s a knockout feature that specifically targets the leading kart and has ruined countless one-sided runs. According to interviews, the reason it was added was to keep races interesting up until the end, since it would often become a foregone conclusion who would finish first before its introduction. Especially in groups with high skill disparity, such as adults playing agaoinst young kids.

When we talk about it in game design, it’s usually as a balancing factor against runaway victory. If a player is so much better than everyone else, it’s just not as much fun anymore, and the blue shell puts a spin on that situation that can make it more interesting for everyone to finish a race.

Players Will Cheat

One part of competitive gaming, as in real-life sports, is that competitors are directly incentivised to search for some kind of edge. Such an edge can be completely against the rules and disqualify the competitor who does them if they are caught doing it. Then we don’t call it a strategy anymore. We call it cheating.

For professional sports, cheating and various forms of doping are illegal and enforcement of rules is continuous. Whole organizations are dedicated to assuring fairness. The bicycle race Tour de France, for example, has had instances of cyclists using electrical motors to give them a slight boost when cycling uphill. Muscle stimulants, growth hormones, anabolic steroids: professional sports have a long history of cheating.

In esports, the expression “edoping” refers to manipulations of hardware and/or software that provide an invisible edge to a competitor. Things like aim bots or code that reveals client-side information a player is not supposed to have. Similarly, many exploits may be either patched out of a game or become part of a rule set dictating professional competitions.

Take this lesson with you, if you want to make something competitive: players will cheat. Some because they want to win over other players, and others because they simply want to beat the system to prove that they can.

Scrub Mentality

A scrub is someone who “adamantly believes that their ‘house rules’ should apply to everyone to promote their view of ‘fair play.'” They are players who are quick to call foul or to call the way other players play boring or against the grain of a game. David Sirlin writes in his book that, “[a] common call of the scrub is to cry that the kind of play in which one tries to win at all costs is ‘boring’ or ‘not fun.'”

But if you really want to win, you can’t have this type of “scrub mentality.” You need to play to your strengths and use every avenue of success that the game may provide. As a game designer, you must similarly be aware what the rules you introduce will lead to.

In some competitive martial arts, for example, obstructing an opponent’s breathing by covering their mouth (called “smothering”) is legal according to the rules set out for the competition. Some will argue that it’s unethical, unfair, or makes for a dirtier sport: they would be the “scrubs.” Others make use of it where it fits, regardless of the scrub’s convictions.

Designing a Sport

The key element of any sport is how to win. But before we can know how to win we need to know what we are doing. This is where you can make use of the same verbs and systemic rules as you would when designing a systemic game.

Many sports revolve around activities that are easy to do but require a lot of practice to master. Kicking a ball isn’t all that hard in itself, but kicking it with accuracy and the right amount of force requires a lot of practice. This indicates that we want an activity with an analogue possibility space: it’s not enough with “success” or “failure.”

Sometimes, as with game design, sports designers have been lazy and added a stopwatch on top of an activity to create this space. Sure, you can finish the race, but can you also do it in the shortest time?

At other times, the analogue space is created by points scoring. It can be directly related to an activity in the game, such as kicking a soccer ball into a goal, or it can be indirect, such as the Technical Panel set out by the ISU Judging System used for figure skating. The use of an impartial judge or panel of judges is a common way to measure competitors against each other in individual sports.

Another solution is to include a sudden death alternative. An occasion within the rules of the sport that immediately ends the competition and awards victory to the person who triggered the sudden death or their opponent. Most sports use the term “sudden death” specifically for match tiebreakers, but death can be sudden under other circumstances as well. Say, a knockout, or a racer’s car getting wrecked.

There are also various forms of “no contest” conditions where a competition may end. If someone in a boxing match cannot defend themselves properly, for example. Some sports may also allow a competitor to voluntarily yield to their competition. Ragequitting fits in with this as well, since gamers can always decide to simply turn their game off.

• Add time. Pushing for the shortest time has the added benefit of providing better entertainment for spectators.
• Add score. Define an activity that scores, then award victory to the competitor with the highest score at the end of a game.
• Add points. Award points based on an impartial panel and the ability of competitors to match specified expectations.
• Add limits. A competitor can only use a limited number of attempts or resources (such as the number of arrows for a bow) and must perform as well as possible within those limits.
• Add ladders. An additional way to generate results is to have more than one competition to determine the full outcome. This can be an elimination-style tournament where only one out of a roster of competitors will claim the prize, for example.
• Sudden death. Rather than using time, or in addition to time, add a condition where the game ends in immediate victory for a competitor.
• Yielding. Allow a competitor to voluntarily call out their own defeat. Either so an only opponent wins or to drop out of a larger competition.

Teamwork

Team sports require group coordination and communication in ways that individual sports don’t. Whether you want teams or individuals compete affects a lot of things about your sport design. The combat reference here is the duel, which is fought one against one; the skirmish, which is smaller groups against each other; the battle, which pits whole armies against each other; and finally a whole war.

Online gaming has generated its own blend of team and solo sport: coopetition. It’s cooperative, because you are completing objectives together and won’t be successful if you don’t. But it’s also competitive, because each of you will want to get the points and rewards individually. This becomes very clear in games inspired by Left 4 Dead and other games designed around LAN dynamics. Because the dynamic changes drastically when players are playing “alone together” and cannot simply lean over and yell for their friend to help them out.

Symmetry

Throughout history, particularly in combat sports of different kinds, symmetry hasn’t always been relevant. Gladiators pitted against wild animals, or one with a trident and net pitted against another with a sword and shield, has been a recurring phenomenon. Usually either because someone has wanted to prove their ability under special circumstances, or because the competitors had no say in the matter to begin with.

Conceptually, it’s a lot easier to design something for symmetrical opponents that are all expected to do the same things during a competition. Symmetry means that all sides of a competition are following the same rules. This is what generates the many layers of matchmaking regulation that sports may have. Weight classes, for example.

Equipment

Some sports require costly equipment, creating a high barrier of entry. Though some can afford to field their own race cars in scrappy “folkrace” competitions, for example, motor sports like NASCAR and Formula 1 are prohibitively expensive. The rules in place for such sports mean that it’s reserved for competitors with large financial backing.

You may wonder how this ties into game design at all, much less combat. But it’s enough to think about games with items and character builds to see some parallells. In one particular Destiny raid, if you couldn’t show everyone that you packed an Ice Breaker and/or Gjallarhorn, you could be kicked out.

What equipment your sports design will require depends on many things, of course, but it can be well worth thinking about. From the quirky golden snitch of quidditch (probably set up to poke fun at real-world sports) to things like the lacrosse stick basket handle, the equipment used to perform a sport can both dictate how it’s played and serve as excellent icons representing the whole activity.

Crew

Though many sports may claim to be individual, they still allow competitors a crew to help them with all manner of things. This is of course similar to any form of stable, camp, or club, where the sum of the parts will affect how good your training is. But some sports allow this during a competition as well. Someone to patch you up between boxing rounds, or to check your tire pressure during pit stop.

Maybe you can even look at the remote operator in Robot Wars as crew, and the robot itself as the competitor.

Referees

Since we can’t really trust competitors to judge each other fairly or even to concede victory in cases where it’s a bit unclear who won, we may need a third party. Someone to call no context, to say when a goal scored or not, and to make sure we end our match on time. In digital games, computers can usually carry this burden, but in sports we use referees.

If you want someone to be the referee, you need to figure out what they know and what they do. Which powers they have. In the eras of game design post, the idea of an umpire was discussed. But an umpire or a Dungeon Master is usually present to make the game world fair and not to adjudicate competitive results.

Language and Narrative

Before you launch your design, you should consider how you want people to talk about the activities involved. Many sports have their own vernacular that tie the activities to what is happening in the sport. Inning, yardline, takedown; in digital games, deathmatch, kill, headshot, loot, powerup, zerg rush.

Some of these expressions you can’t really invent. They’ll come naturally from how players interact with and talk about your game while playing or strategising. But it’s a great exercise to try to simplify terms, mash them together, and consider all the different strategies that players may use and how they’ll describe them. Even to invent a silly expression and then use it to make sure that you remember the concept it represents.

Related to this is also the narrative of the game. Even if soccer is simply people chasing a ball across a field (if you are cynical about it) the story is one of a fight team against team where the winner takes all. The teams represent cities or clubs, and they are serving their fans; fighting for their fans. Not to mention that each player on each team may have their own fans and life struggles hyping up the competition.

The words you use and the story you tell should be easy say and unique to your game. It should also be relatable. Sports have the advantage here, since it’s much easier to identify with kicking a ball against a garage door just like your childhood hero did, than it is to imagine yourself shooting zerg on a distant planet.

What About Systems?

This post took me a long time to research and write. Part of that is that balancing is a form of authorship. Just as with a linear story, if you want a balanced competitive experience, you must use a heavy hand to make it so. Often against the grain of your community, who will be enjoying the exploits they find and quickly get used to the dominant strategies presented. They will therefore loudly voice their dissent when you change the things they have been exploiting.

Ultimately, though games like The Finals are trying, competitive games and a high degree of dynamics is very tricky to combine. The tools we use to balance our games are not very conducive of the right side of the master scale.

This doesn’t mean you shouldn’t try, however. Systems at a gameplay level, where they can be balanced against each other, can still be very useful. Just be prepared to iterate a lot before the play experience is tuned right.

The most consistent pushback I get when presenting my case for systemic design is against the idea that authorial games are not as interactive as more emergent games.

“They surely are interactive,” says the typical critic, “because you are pressing buttons; there’s gameplay.” Which is true at face value, since you are certainly pressing buttons and there definitely is gameplay. But pressing buttons or shooting virtual guns is not necessarily the same as interactivity.

Interactivity as the act of interacting is not enough. It must also generate relevant feedback and put the player into positions where they must choose one thing over another. Sid Meier’s comment on games being “a series of meaningful choices” comes in here. Pushing forward to progress to the next room or set piece is not a choice.

In this post I’ll try to elaborate on this line of argument. You don’t have to agree at the end of course, since game design is ultimately subjective, but you will hopefully understand where I’m coming from and how this fits into the dichotomy between authorship and emergence. Maybe you’ll also want to join me in dreaming of what games can be capable of on the interaction frontier.

If you do disagree, please do so in comments or to annander@gmail.com. The best conversations happen when we see things differently.

Interactivity

Games receive input that is transformed into output. If that output is a digital beep, a 2D sprite initiating a jumping animation, or a dice roll coming up a five, depends on the game and its interface. Interactivity is the common ground that separates games and play from other forms of media. How much interactivity we’re talking about and at which point in the game varies between games.

Fortunately, someone else has already phrased the larger framework more succinctly than I can. In Hitbox Team’s excellent article on game narrative, Terence Lee argues that storytelling can be broadly classified into three dimensions.

The first dimension is time. A novel is a story where you must read the second word after the first, and even if your imagination can turn a time-locked story into anything, and the story itself may tell its tale in countless disjointed or anachronistic ways, time is the only dimension it’s reliant on. It is a form of observation where you take part in whatever the creator is relaying to you through your imagination.

When you bring in other senses, such as your hearing and vision, you are adding this to the dimension of time. You get movies and theater. It’s a more passive observation than a novel that leaves everything to your imagination, but it expands the author’s control over time to also control your senses. It’s fundamentally its own thing. Telling stories with moving pictures and sound adds more considerations and tools to the storyteller’s toolbox.

Then we add interactivity. You are no longer a passive observer but a participant. Your actions are now those of a character in the story. Authorship comes in here with restrictions on what you can do as a participant. “It diminishes the importance of your actions,” writes Terence Lee of Hitbox Team, “if it feels like the game distrusts you with making the important ones.” For example when the third dimension is removed to show you a cutscene of how the protagonist defeats the antagonist after you whittled away its hit points in a ten-minute bossfight.

This, my friends, is where this argument takes off: finding the important actions and the interesting choices.

Game Feel

How it feels to play a game is sometimes referred to as game feel. In Steve Swink’s book named the same, six elements that affect this are Input, Response, Context, Rules, Polish, and Metaphor.

1. Physical input. You press a button, roll a die, or whatever you do.
2. A response to your interaction. From haptics on to witty barks, something will (or at least should) signal that the input was received.
3. The context of the game. Standing on flat ground allows the button to trigger a jump, for example.
4. Rules. How many extra lives, how much time you have, how gravity works and so on are applied to the now contextualized input.
5. Polish. Fleshes out the aural and visual experience and make it as clear and/or rewarding as possible what’s happening. This is separate from the response, because this is part of the game simulation and may therefore happen with some delay.
6. Metaphors of the virtual space. A character, the verb of jumping, etc. The piece of presentation that makes it all make sense to the player.

If we consider these six components relevant to how it feels to play a game, and we look at them as the key essentials of interactivity, we begin to see which actions can be considered important.

When the inimitable Josef Fares animatedly tells you that you never do the same thing twice in A Way Out, a jaded game designer like myself only sees the left analogue stick pressed forward but with 100s of animations on top. Crawling through a vent. Walking across the yard. Running from the guards. The first four of Swink’s game feel elements (input, response, context, and rules) do not change between these activities.

In a highly authored game, such as A Way Out, I can’t always know what the context means, which rules are currently in effect, or even what the response will be. There is a higher focus on metaphor and polish: I’m following the characters on the screen as an observer and not as a participant. I’m watching what they do: I have not become them.

There’s typically a specific outcome that has to be the result of the scene, such as the characters managing to steal something from a locked office. There may be some different routes to this that provide different visual feedback, different animations, but fundamentally it’s a cinematic experience. There’s also no way for me to fail and the story to adapt to my failure. If I do fail, the game state will reset and I’ll have to try again until I succeed.

Empathetic Connections

Focus on polish and metaphor is not by accident. As Nicole Lazzaro has said, “[F]ilm and cinema, they can’t do a lot of emotions because it’s simply an empathetic thing. […] The format doesn’t allow certain emotions nearly as well as games.”

Movie makers are experts of empathy. Creating and managing empathetic bonds between a viewer and an on-screen actor playing a role. If there would suddenly be instances where context or rules could subvert this polished outcome, for example because the viewer could switch out the soundtrack or skip a crucial piece of dialogue, it would ruin this precisely crafted connection. This is why they are not invited into the interaction, and why most of Swink’s elements are removed from games that strive for empathy.

This isn’t only clear in animation-heavy games that are closely directed, such as the games by Josef Fares. Similarly, Ian Bogost describes the protagonist of Gone Home as “a cursor you move to experience the story.” You are certainly controlling the input in that game: pressing forward, choosing which objects to interact with, which audio logs to listen to, and then gradually piecing the story together in your head. But you are not there to participate. The game is designed to make you empathize, not with the character you are playing, but the one game is telling you about.

This is functionally the same as point-and-click adventures in the later style. Games like Phantasmagoria, that attempted to simplify the interaction and minimize the style of feedback that those games were known for in favor of telling its story in a more cinematic fashion. To focus on spectacle, gore, even disgust, as empathetic emotions based on what the main character is forced to endure.

The main character of Phantasmagoria doesn’t say “won’t budge” about the door, but will instead fidget with the handle for a while in an animation before giving up. Something that felt detailed and potentially empathetic for players of the seven-CD horror adventure on release, but seems dated and almost comical when you play it today. Today, you want her to fiddle faster so you can keep playing. Also, few film makers would spend 30 precious seconds having an expensive actor fidget with a door handle. So rather than adding quality, it feels cheap. Like a bad interpretation of a movie more than an actual movie.

As another example, the same empathetic connection exists between the player and Joel’s daughter Sarah in the intro to The Last of Us. Functionally, she’s also just a cursor for activating sound bites and cutscenes in the environment until the story moves on outside of your control. My personal opinion is that the Sarah segment is meaningless as interactivity, and strongly exemplifies said empathy. We may care about Sarah because we are told that Joel cares about Sarah, and having her visually represented and voiced as a real character tells us that she is something more than a sad plot device once the next few plot beats takes her away.

In essence, we are told to care about Sarah, the same way a movie would tell us to care. But we have no choice in the matter and most of Swink’s elements and Meier’s golden rule are once more removed. There are no meaningful choices to be made when we are only moving a story cursor across a virtual space. In fact, and this is where the critics will usually jump in, other types of storytelling do empathy better than games, meaning that we don’t gain anything by turning these experiences into games. To approach empathy this way, games must restrict the impact of our interactions, and the only actions we get to do are the ones that can be safely stripped of meaning so that we, as players, can’t ruin the authored experience.

Murdering the Innocent

In an interview with Introversion’s Chris DeLay, he mentions a study where playing their game DEFCON—a game about global nuclear war—had a deeper impact on survey respondents than watching a documentary on the same topic. A result that implies the effects of interactivity on an emotional level.

Even by controlling Sarah, we may gain something from pushing forward even when our actions have limited meaning. But we can learn and feel more about something if we add elements from Swink’s game feel.

In gaming, we do have some darlings that often come up as examples of interactive storytelling. People will mention the plot twist in BioShock: would you kindly? Unfortunately, all this particular twist does is that it rubs our noses in the fact that we have no choice. It’s like making a point of how little interaction we have.

Another darling is Spec Ops: The Line. A game that asks you to commit war crimes and then rubs your nose in it in a similar way. Push the button, then we’ll make you feel bad for having pushed it. It’s pulled off in a better way than in BioShock (in my opinion) but still suffers from the same problems. I’m in for the ride already. I bought the game. Pushing the button is just a way to see if I will get a snack, like a rat in a Skinner box. It doesn’t make me complicit to anything where I can’t predict or at least understand the outcome.

But now this post has already devalued the game story darlings of the past decade and set my e-mail up for more pushback. There must be some point to make. Some reason that interactivity is worth having even for game developers that lean more heavily towards authorship. So far, it seems to argue for authorship, since authored stories demonstrably do empathy so much better.

To get a good example, let’s look at a board game that engages so deeply with its theme that it has courted real controversy. The game is John Company, by game designer Cole Wehrle, and it puts players in the shoes of family leaders trying their best to make money off the British East India Company. The game’s rulebook is illustrated with contemporary political satire, and the role you play and the actions you take are deeply exploitative and imperialistic. An interpretation through gameplay of what the real East India Company did to the peoples it oppressed. An interactive illustration of British imperialism at its height and how the British museum’s most precious Indian artifacts landed in its collections.

Not only does this game ask you to do heinous acts and reward you for them, it turns the vying for power and the exploitation itself into a game. The suffering is made abstract and turned into an inconvenience, while you try to maximize your gains and save up enough money to put your family members into the nicest retirement homes.

Some will of course say “it’s just a game.” This is always a bad take. John Company demonstrates how interactivity matters. Similarly to BioShock and Spec Ops: The Line, I can’t choose to be a good person and not engage in imperialism, of course. But by acting within the confines of the game’s premise and abstractions I will realise that the game I’m playing is probably quite similar to the game that was played above the heads of the oppressed.

It becomes more than “just a game.” It becomes experiential. Entirely thanks to interesting choices and interactivity.

Medial Regression

You are free to enjoy well-produced empathetic games. There’s nothing wrong with such games and there never will be. Developers should keep making them, and we’ll all keep playing them.

But the last point of this post is that they also don’t develop the art form of games. To be able to focus on empathy, they need to step back from the third dimension into the second one. They need to regress into linear media and disallow or restrict interactivity to some extent. This is what medial regression means: to put away the unique elements of your medium in favor of those of another medium.

Some players want exactly this and expect it. They want to be able to skip the gameplay moments so they can keep learning about the characters and building their relationships, and they enjoy non-interactive cutscenes for any of a number of reasons. This is okay. Too often, gameplay only means fail states or time sinks. Things that can feel like they’re obstacles to your enjoyment of the virtual world you’re engaged with.

Somehow, we’re less okay with medial regression for other types of media. Since movies have had a century to develop their own language, from cinematography to acting techniques, we look at a movie that becomes more theatrical as medial regression too. We notice the somewhat stilted and more clearly articulated manner of stage speech and may even resort to calling it “bad acting.”

If movies had never added audio, they could still be great silent films, but they would also never have explored how audio or soundtrack affects storytelling. Likewise, making our games cinematic and limiting interactivity so that our games can lead with empathy will never explore our own medium’s core strengths. It will never force us to develop our own tools for making the most of interactivity.

Medial regression puts us in a place where we no longer push our art form forward. It allows us to comfortably keep using methods from other art forms, without having to discover our own. It also easily transfers the mindsets of other media production into game development, even though game development is a deeply collaborative and iterative. We don’t benefit from auteur directors and we don’t treat production the same as film. A culture clash occurs, even beyond the product.

Like how Randy Smith described the culture of venerable game studio Looking Glass. “There were various individual superheroes,” he said. “Terri Brosius, Dan Thron, Doug Church, Mark LeBlanc. But somehow, the goal wasn’t to be like, ‘I’m Mark LeBlanc who made this system in the game, and everybody knows me’. You were measured against the game we all created together. The game’s as good as its weakest link. Ego wasn’t the focus.”

To get that kind of magic, you can’t have auteur directors and you must push for the thing that makes video games unique. When we actively do so, it leads us towards a more interesting future where we are better acquainted with the tools we use because we have made them for ourselves.

The Interaction Frontier

When discussing first-person cameras, CD Projekt Red’s research for Cyberpunk 2077 was brought up as an excellent first step in blending lessons we can learn from cinema with the unique needs of video games. Some of the questions that need to be answered, such as how to keep the player’s attention and making sure they get to experience interesting things, are questions that are guaranteed to have even more answers that we haven’t even discovered yet. This is what should be the real goal: figuring out how to factor interactivity into everything we do.

How a game like What Remains of Edith Finch lets you experience the horrifying fates of the Finch family members through playful yet morbid mini-games helps us understand what video games can do. Not because we are told about it or asked to empathise, but because we are ourselves living a part of the experience through gameplay. Sometimes whimsical, sometimes repetitive, always thought-provoking.

The way Dark Souls handles its non-player characters explores the concept of consequences. If you kill the blacksmith, the blacksmith is indeed dead. You’re not guarded from doing bad deeds and the systems of the game are consistently applied. The experience is yours to own. Similarly, if you choose to rescue Lautrec and leave him near the Firelink shrine, he will kill the keeper of that shrine later. A consequence that blew my mind on my first playthrough simply because games never do that. Betrayal is almost always clearly advertised in games. Yet here was a game where story was implied and never explicit, and there was no way to save scum my way to the “best” ending. What happened was predefined, but the circumstances were for me to figure out. No director in sight.

With Outer Wilds, the way the game handles the player’s own knowledge of the game space as a form of progression could only happen with a game. A small repeating cycle of events that you can interact with and that you must learn to interact with in the right order to be successful. There isn’t even a clear way initially to understand how things end. You are given tools and a dilemma, and then let loose to figure out what it all means.

Something that’s traditionally been very common is also the digital toy. Theme parks, railroad enterprises, and life simulators, have all seen their share of success. Some haven’t had any victory conditions or even goals for the player to achieve beyond what they can figure out on their own. This is another thing only games can achieve, where systems interact and combine in pleasing or compelling ways. Games like the beautiful and technically marvellous Tiny Glade does this in a modern context, and for generations that grew up with Toca Boca, Minecraft, and many of the most popular experiences on Roblox, desire for digital toys may signify a larger part of the gamer population than we may even be aware of yet.

Finally, there is a growing number of independent small developers that are working on “indie imsims.” Games that borrow, concretely or in spirit, from the Looking Glass classics that Randy Smith helped develop. Some of them go for the atmosphere, while others are more philosophical in how they approach their immersive qualities. In all cases, they focus on interactivity because it’s easier to do mechanics than to compete against bigger studios in visual fidelity.

End Notes

Hopefully, you can see where I’m coming from with this post. There is so much left unexplored in the interactive space that we should take every chance we have to figure things out. Solve problems. Look for new ways to engage.

Interactivity is the unique third dimension of games. We shouldn’t be afraid of it: we should embrace it. Let players kill the princess and rescue the dragon. Let them give the ring to Gollum and retire to the Shire to start a restaurant. Let them fail or choose poorly and handle the consequences.

• Interactivity is the unique third dimension of game storytelling.
• Interaction hinges on all six elements of game feel: input, response, context, rules, polish, and metaphor.
• Interactivity requires that you get to make the important actions in the metaphor.
• Games should present a series of interesting choices.

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.