Recently in a game I was running, I had an amazing combat planned. The players were confronting a villain from their past- a pyromancer who used to lead a gang the players had wiped out. I made some really fun stat blocks and mechanics for tracking the burning buildings as the fire spread. The combat went without a hitch. The players had fun, I had a great time running the enemy, but then at the end, one of the players looked at me and asked “so who was that?”
In that moment, I realized I had completely forgotten to sprinkle in the lines of dialog I’d written that would remind the players of who she was. We rolled back and did some flashbacks to the banter that I had wanted to happen, and it worked out ok, but I was frustrated that I’d completely forgotten an important part of the encounter that could have made it so much more impactful.
I can’t count how many times as a player I’ve looked at my sheet at the end of a session and realized I’d completely forgotten a spell or piece of gear that could have solved a problem two hours ago. It’s infuriating and disappointing and can dampen a moment that should be fun to know that it could have been better if only I’d remembered.
As a game master, I think a lot about how to help my players have fun, and as a player, I get frustrated when I’m not having as much fun with a game or system as I could. There are a lot of things that can get in the way of that. As a designer, we try to build systems that will help everyone at the table find the fun and create the type of experience we want, but the systems only work as intended if the players (and the game master is also a player) actually engage with it.
So, what can stop a player from engaging with part of a game? Well, the first step is just remembering that it exists.
This is part 1 of a series where I’ll talk about what can prevent players from using the mechanics you build, with a focus on the various solutions to each problem as deployed in the games that inspire me.
Cognitive load
What is cognitive load?
When designing or reading a game, it can be easy to hold all the systems in your head because you’re only dealing with the system at a mechanical level. However, at the table there’s a lot more going on- tracking social dynamics, spotlight management, narrative flow, role-playing, and maintaining the game state all add cognitive burdens that will cause things to slip. These all add to the cognitive load of the game.
“Cognitive load” is a term that describes how much mental effort it takes to learn something or perform a task, including memory and problem-solving. Basically, everyone has a finite amount of things they can hold in their brain at a time, and so we have to prioritize. In tabletop games, every mechanic adds to the cognitive load of a game, and if a mechanic isn’t important, frequently used, and memorable, it’s going to slip off the plate.
Cognitive load is often broken down into three categories:
Intrinsic load
How difficult is it to understand the new information?
Germane load
How difficult is it to integrate the new information into our existing knowledge?
Extraneous load
How much junk is there getting in the way?
Why does cognitive load matter?
Cognitive load has been on my mind a lot recently. There are certain things I enjoy a lot as a game master, and things that I struggle with. I have a hard time inventing NPCs to fill the world, and no amount of random tables or prepared characters seem to help. But the history, politics, and geography of the world is as easy as breathing for me, even where I’ve left blank space to fill in later. Running complex mechanics in bespoke puzzle combats is thrilling and engaging, but I get so focused on them I forget to slot in the narrative beats I’d planned to make the story tick.
It’s frustratingly easy for the parts of a game that are more challenging for me to take up the majority of my cognitive bandwidth at the table. They just take up more space. The things that are fun seem to happen automatically because they require less conscious effort, but they still demand mental resources.
When all my bandwidth is dedicated to parts of the game that are heavier on my mental scales, the fun parts start to slip away from me. Conversely, when I’m too sucked into the fun parts of the game in the moment, I’ll forget to employ important mechanics that will keep it fun long-term. I want to be able to do everything! But with a finite amount of resources, the brain prioritizes, and it doesn’t always prioritize the way I prefer.
As a game master and a designer, I want to get more of what I enjoy in a game by reducing the cognitive load of the parts I don’t.
So how can we help people remember?
Solution 1: Reference sheets.
I can’t tell you how often in a game a player knows there’s a mechanic for something but can’t remember the specifics. In a lot of games, this either means digging through the book to find the official rule, or making a ruling on the spot (and I almost always recommend the latter). With a reference sheet, though, players can look down at what’s already on the table and see it’s right there.
Reference sheets are important for any game. They reduce the extraneous load of the game by presenting the information you need free of surrounding clutter. The simplified language of a reference sheet can also reduce the intrinsic load.
But most importantly to me, It frees up space to remember other things. When a player knows they can look down at the sheet when they need that mechanic, they don’t have to keep it in their active memory at all times. This means players only have to remember the rule when it’s relevant and can get refreshers as-needed by checking the reference sheet.
At a practical level here are varying degrees of how close-to-hand a mechanic can be: it could be on a shorter “quick play” document, a one or two page list of mechanics like you might see in a PBTA game, or even written on the character sheet in front of every player. Many games have even taken the approach of putting character mechanics on individual cards: Daggerheart, Ironsworn, and 4th edition Dungeons & Dragons all take this approach. The cards mean players can keep only the relevant parts of their character visible and hide irrelevant cards, reducing the extraneous load even further.
The problem with reference sheets, however, is also one of cognitive load. There are diminishing returns to how useful a reference sheet is as you add more and more to it. Every item added to a reference sheet means it will take longer to search it for what you need and increases the visual clutter- adding to the extraneous load. Multiple pages of reference sheets means physical work flipping through them. So a reference sheet needs to be limited to just the systems that are used very frequently (so that players don’t have to keep it in their memory at all times), or the systems used infrequently but which are very important to the experience (to reduce lookups in the book).
For examples, look at just about any PBTA game, but let’s look at the reference sheet from Masks: A New Generation for a specific example:
It presents only the most important moves, laid out in simple language with clear headings and emphasis on important text. The basic moves will be used constantly, and while veteran players may come to know them by heart, new players will have to re-read them every time because each move is quite complex and unique.
The adult moves, by contrast, are going to be used very rarely- but are very important when they are! They have a significant impact on the narrative so forgetting to use them or how to use them would be deeply unfortunate. I personally take issue with putting the adult moves first on the reference sheet, since a brand new character will not have access to any of them, however having them on the reference sheet is very important for long-form play because players may have so little interaction with those moves they would not have a point of reference for them.
Solution 2: Separation of responsibilities
Another way to reduce cognitive load is to divide it up between players. The most common way this is done is splitting up responsibilities between players and the GM. Using a traditional fantasy RPG as an example, the players don’t need to know how enemy stat blocks work. The GM doesn’t need to remember how every spell the players use works. Each player doesn’t need to know how other players’ character’s mechanics work.
But there’s a fatal flaw:
If you read through the rules of many of these games, you will see nowhere that this separation is written in stone. It’s just a best practice that tables have adopted because it is necessary to run the game at a high level. the more inexperienced the players are, the more of that cognitive load shifts onto the GM to keep the game running, and that leaves the GM with less cognitive bandwidth for tasks like storytelling, role-playing, and spotlight management. It leads to GM burnout and takes away some of the most fun parts of being a game master.
GM-ful games
However, there are games that make this explicit. Belonging Outside Belonging is an awesome example, where responsibility for certain parts of the game are divided between players. Seven Part Pact takes this to the logical extreme, giving each player a full set of unique rules that they are in charge of. These games have been called “GM-ful,” as a contrast to “GM-less,” as they give every player some part of the traditional “game master” responsibilities.
For an example, check out Masks of the Masks, a much darker superhero game inspired by Watchmen. This brilliant game breaks down the responsibilities of the game master into “pillars” that each have responsibility for running a different part of the game:
I love superhero games, but I have always struggled to run them. I have tried to run Masks: a New Generation many times, but I inevitably have burned myself out trying to manage everything I want to do in the game. It’s a goal of mine to figure out a system that lets me run Masks: A New Generation at the level I want without pushing myself too hard. But Masks of the Masks takes a GMful approach. One player runs the day-to-day people of the city. One person runs the government and the law. One person runs the mystery. And one person runs the inevitably-approaching Doom. Each player is game master for the other players, but nobody has to take on the role alone.
Even in a GM’d game, responsibilities can be delegated to players from an overwhelmed GM. Too busy setting up stat blocks to draw interesting terrain? Ask the players to draw the map! Forgetting to track health totals? Give each player some enemies to track health for. In fact, giving players authorship of some parts of the game and the world can help develop buy-in and engagement (I’ll talk about this more in a later post!) and give players something to do in games with strict spotlight management when it’s not their turn (I will also talk about spotlight management in a later post!)
Solution 3: Simplify
This is the hardest but most important as a designer. If players hare having a hard time remembering a mechanic, maybe you have too many. Maybe the systems are too unique and should be combined. If you see players in playtests struggling to remember a mechanic or forgetting to use it, consider if you need it at all.
This is really the core of the problem. The only guaranteed way to reduce cognitive load is to reduce the amount of information. Rules that are too complex increase intrinsic load. Rules that are too unique increase germane load. Rules that are optional or unnecessary increase extraneous load.
Reducing intrinsic load
Make your rules less complex! After your early drafts of the game, make a box that you have to fit your rule into. Then make the box smaller and re-write the rule in that box (without changing the text formatting). Then do it again. This forces you to strip out the least necessary parts of the rule- the exceptions, the qualifiers, the redundancy. Compress it into its most compact form. I promise, the rule will still work.
Reducing germane load
This one requires reading.
One thing you need to make sure your game has is consistency. Create a language for your game and stick to it. Go read other games and pay close attention to the language people use when writing game rules. What games have the most memorable rules? How do they template things?
Magic: the Gathering is an amazing example of this- it uses a lot of phrases like “at the beginning of each upkeep” or “whenever a player draws a card” that are very well standardized (at least, in modern cards). This sort of language has been refined over decades to make it as easy as possible for players to fit a new card into a system they already understand. Compare to Yu-Gi-Oh, where each card uses much more natural language. There may be less work to learn the basic rules (lower intrinsic complexity), but each unique card is much more difficult to understand because they’re so unique (high germane complexity).
Draw Steel is another phenomenal example for this. The game is extremely complex, with a lot of terms to learn like in Magic: the Gathering, but once you learn the language, everything is so well standardized, it becomes very easy to read a new ability and understand what it means, and the language they use is designed to be similar to other games which it follows in the footsteps of.
But also: steal. Find other games in the genre of game you’re trying to make and see what they do. Chances are, other people have tried to solve the same problems you have, and come to different solutions. This isn’t to say you should steal ideas from other games (though you absolutely should), but rather that the more similar your game is to other games people have played before, the easier it will be to remember the parts that are different. If there’s part of the game that isn’t important to the theme but is required to make it function, you should see if you can get away with cutting it altogether, but if you can’t, make it similar to what people who have played other games will be familiar with.
If the puzzle-piece edges of your game match up what’s already in the players’ brain, it will fit in without a problem.
Reducing extraneous load
Extraneous load comes in two forms: visual clutter, and mechanical clutter. The first is a design problem that you can approach in a similar way to reducing intrinsic load: Just fit the game into a smaller space. But you can also help by formatting the rules cleanly.
Reducing mechanical clutter is another beast entirely. As a designer, it can be really hard to kill your darlings. We can develop blind spots for things that have been in the game from the beginning but don’t serve it anymore. Remember that none of those ideas are gone forever. Start an ideas document you where you catalog the mechanics that don’t make the cut. Those things may have been necessary scaffolding to get the game to where it is now, but are no longer holding anything up, and you can pack them up to deploy them elsewhere.
To reduce your mechanical clutter, perform an “ablation test.” Pick one mechanic and see what happens to the game if you remove it completely. Repeat this for every mechanic, even the ones you think are critical. If you have to, replace them with the most bare-bones patch you can think of that will let the rest of the game function. Sometimes you’ll be surprised how well the game still works without something you thought was critical.
The bottom line
Every system is going to have a very different shape, and every person has a different shape of brain for all the pieces to fit into. Where some systems might heavily mechanize combat, some might have mechanics for social interactions, for exploration, for puzzle-solving, for crafting narrative arcs. The parts that come naturally to one person will be very different from another. Where one player might struggle to remember tactical options in combat, another player might struggle to remember how to engage an NPC in witty banter.
This comes down to the match between the kinds of fun a player prefers vs what the game provides, and the relative strengths and weaknesses of different players (I will definitely write more about this in the future). At a psychological level, it has to do with the points of reference a player has. The more a person has encountered similar things in the past, the more work they’ve already done to make space for that type of thing in their brain, because it can be put together with things they already remember (“XYZ is like YZ, but with the addition of X”). This is at the heart of germane load.
As designers, we know our games by heart, so it can be hard to see what other folks will struggle with. We build the games we want to play, the games that fit well into our own uniquely-shaped memory. So don’t build just for yourself, but for the player who wants to engage with your system but just can’t remember the parts that you know by heart.
Now I just need to remember to apply all this advice myself.
For more on cognitive load, check out this awesome video by Chubby Funster on youtube.
What’s next?
While it might seem like a simpler “rules-lite” game might have less cognitive load, for some players, those games are considerably more difficult because of the difficulty of knowing what to do next. The lack of direction, the blank page, can leave players less experienced with improvising feeling paralyzed. I’ll talk about this in my next post where I’ll go over the difference between and importance of “white space” and “green space” in game design.
Leave a Reply