Howdy, everyone, I’m K, the head honcho over at Loreshaper Games. In addition to making my own games, I also do freelancing within the industry and have a background in education. I was also a game reviewer for DriveThruRPG for a while, so I’ve seen more games than I can shake a stick at. 

Today I’d like to talk about some lessons that we can take from field education into the realm of game design. Particularly, I want to talk about teaching by design, and particularly focus on how we can use this information as a game designer.

I’m going to split this into three parts: Understanding Knowledge, Barriers to Knowledge, and Techniques to Foster Knowledge. Each will have its own objectives and its own take-away applications.

Part 1: Understanding Knowledge

Objectives

• Be able to explain what the various depths of knowledge as applied to games are.
• Be able to identify elements of a game (e.g. mechanics, setting) that require different levels of knowledge.

Future Objectives

• Be able to identify and explain what players need in order to learn game systems.
• Be able to remove barriers from the knowledge-formation process.
• Be able to present information in a way that fosters knowledge.
• Be able to encourage the retention of knowledge through application of design principles.

Introduction

The goal when teaching is to make someone familiar with something. That’s a pretty simple statement, but the actual process can get pretty messy. As a game designer, one of your goals is to make something that people can learn from, committing parts of your game to their memory and being knowledgeable about it. When I look at games from a player’s perspective, especially tabletop roleplaying games, there’s really four stages of knowledge that things tend to break down to: 

1. Know Intimately
2. Know Vaguely
3. Know Where to Find
4. Know Nothing

So, for instance, when I look at a game I might say that I know the basic skill mechanics intimately, the combat flow vaguely, I know where to find the gear entries, and know nothing about a setting-specific subsystem like magic or hacking.

This isn’t to say that these are all the stages of knowledge; they’re just the four that are most applicable to games and players. As a designer, you might have two more levels of knowledge: Know to Critique (analysis), and Know to Create (synthesis), but those are not relevant to everyday players unless they want to modify your game in some way. As a designer, you want to know these things yourself, and if you want to make your game open to third-parties you should think about how to foster that knowledge, but it’s not something we’re going to concern ourselves with here.

Generally, it’s best to move everything up to the top of the ladder; players should intimately know as much of your game as possible in order to have play go well. If players don’t know things, the game slows down. That’s something of a pipe dream, though. Players won’t know everything. You need, as a designer, to categorize important and less-important mechanics and systems.

Traditional game master-driven games have the advantage of offloading a certain amount of this onto one player, the GM. They’ll be high-interest, high-investment players who put a lot of time and effort into managing things. 

You’re also aiming to have at least one player in a game know everything that comes up in an average play session intimately, including obscure player-specific things that only they have enough reasons to become intimately familiar with. This would be something like the hacker in a game like Shadowrun or Cyberpunk; the GM might know the rules vaguely or intimately, but the player of that character should know the rules intimately.

Let’s quickly break down the four stages, then we’ll talk about what resources you might have to help players move up the chain of knowledge and solutions for when players might not have the level of knowledge that they want.

Knowing Intimately

What a player knows intimately they can either quote or paraphrase in such a way that it is 100% accurate to the flow of play. For instance, I can tell you that an attribute of 10 in D&D is going to lead to a modifier of 0 on associated actions. That’s intimate knowledge; I’ve played enough of D&D and its derivatives that I no longer need to worry about details like that.

Intimate knowledge is familiar without any association other than the terms in which the concept is discussed. If someone asked a player what the six attributes in D&D were and got an accurate reply immediately without them referencing the character sheets or books, that would indicate intimate knowledge. If they have to glance at the character sheet, that’s vague knowledge or knowing where to reference the information, depending on what they had to look up (e.g. if they were trying to order them properly, or if they knew all but one).

For a player to have intimate knowledge of something in your game, they also need to understand it. If I can tell you that 10 leads to a modifier of 0, but not when it matters (e.g. I’m thinking of something other than an attribute, or I don’t know where that modifier applies), then I’ve got vague knowledge at best.

Knowing Vaguely

Knowing vaguely happens when a player knows that a concept in the game mechanics exists, can roughly explain what it does, but can’t necessarily apply it accurately. For instance, if a player who is playing a Rogue in D&D knows that they do bonus damage on attacks when they have an advantage, and they know the dice type and amount, but they don’t remember the rule about enemies who are flanked or incapacitated, they have vague knowledge of the sneak attack feature.

Of course, it’s worth noting that they may recall that information in the right circumstances because of associations it draws from them, but they wouldn’t necessarily think of that information off the top of their head.

Vague knowledge is generally acceptable for most things; you can’t have it for things like central mechanics where players need to figure out what dice to roll, but it works well in other places. 

I’ve experienced this as a barrier to playing Fantasy Flight Games’ Genesys system; when players don’t understand what the icons on the dice mean, play slows to a crawl, and it led to a sort of interest death spiral in one group I played in where people weren’t paying attention when other peoples’ dice came up and then they never were able to understand their own dice results. An exacerbating factor here was the use of graphics to represent certain outcomes instead of something like a number that can have a known general value (e.g. high is good, low is bad). Just because there are “good dice” and “bad dice” doesn’t mean that the result is immediately obvious to the players.

It’s worth noting that this required something of a perfect storm: players with limited access to the books and dice (one copy/set for the group), general unfamiliarity, and low investment. If 50% of the group are only vaguely knowledgeable about your dice mechanic, you’ve made a game that becomes frustrating quickly for everyone involved.

This is something that seems trivial, but if you have people who have marginal interest or other high-priority concerns (like complex player characters) you want to make sure that important things are highlighted for intimate knowledge, and presented in such a way that this is easy.

Knowing Where to Reference

Knowing where to reference things is an important skill for all the parts of the game that aren’t incredibly important but come up often enough to be worth having on hand.

This means that players actually have to know where it is. The 21st century has given us a whole bunch of fancy tools for this, but they still pull people out of the game.

A while back there was a meme going around of Shadowrun players having a sort of teach-out of game mechanics; basically they would do a brief slideshow on a particular game element. This isn’t a terrible idea, but it says something about the game: too much of it lives in the “know where to reference” space. As someone who cut their teeth as a GM of Shadowrun, I wish I’d had a few of those for my group myself, but I’ve generally moved to simpler systems.

The danger with reference is that it should only be relied on for things that are rare and unusual.

This level of knowledge is what you see when players have to consult their sorcerer’s whole spellbook to figure out which spell does the damage when you cast it in the middle of everyone, or look at their character sheet for specific examples of their characters’ abilities.

Knowing where to reference something doesn’t kill the flow of play outright, but it certainly leads to people losing interest or having attention lapses, since everyone goes away from the game at hand and back to the rules to figure out what to do.

Knowing Nothing

If your players are winding up in the Sergeant Schultz school of philosophy, it’s probably a consequence of them actually knowing nothing, and not being Prussian comic relief characters.

There can be heated disputes about when players should know nothing; Paranoia is an example of a game that actually tells the GM that players should know nothing (depending on the edition) because it adds to the chaos of the experience.

Generally, however, knowing nothing is a major problem, because it’s a step further than even not knowing where to reference something. If I know nothing about how, say, combat order works in a game, I have to consult the whole rules again. This can be solved with proper organization, but still takes longer than at least having the player know where something is.

It’s worth noting that this level of knowledge can apply for subsets of information that a player knows where to reference, and it can be dangerous within that. If I know where to look up spellcasting, but not where to find a particular spell (for instance, because I don’t know its name), I know nothing about something that might become important.

This is going to happen occasionally with any large game where there may be players who have so focused their experience that certain elements become irrelevant to them. In that case, their ignorance is not desirable, but it is acceptable so long as it is not an issue during play.

This is also the point where all newbies start out with almost everything; they may have exposure from pop culture or take to certain concepts naturally, but they are not going to have a lot of knowledge.

Takeaways

General Wisdom

The general rule of thumb for educators is that people learn by constant repetition. Assuming that everything is perfect, you still need to teach something three or four times before someone commits it to memory, and in practice you might have a misunderstanding or a lapse in attention that wastes two or three of those opportunities.

I’d say that a good benchmark is that a player will move up a level of knowledge after five to seven exposures to a particular mechanic; this includes reading it, seeing an example of it, and using it in play. This is not a guarantee: seeing someone use a mechanic doesn’t necessarily cause a player to remember it. I certainly don’t care about how every other players’ abilities work when I play D&D, 

This is where a core mechanic that is easily generalized comes into play. Everyone knows how to do a skill check in D&D, but how many players will know how eldritch blast works? A druid’s shapeshifting? Magic item creation per the DM’s Guide?

Every element that you can apply from a generalized concept can count toward moving a player up a step; first to knowing where to reference it, then later to knowing vaguely. Intimate knowledge requires direct exposure, but if you can generalize things (like “An attack functions like a skill check”) then your players will have some pre-existing knowledge to apply to that one case.

A Note on Reference

One of the philosophies that I’ve seen come up is whether or not reference is acceptable. The truth of the matter is that you’ll always have some information that is fluid and changing: the characters in a game. Everyone will typically need some way of representing their character, and this provides high-speed reference opportunities.

However, there is a limit to how much this can apply. As someone who has a love-hate relationship with D&D, I’ve done the whole “index cards full of spells from my spell list” thing, and I can tell you that a game like D&D often puts too much emphasis on materials that have to be referenced.

Every time a player needs to go from the stuff that is immediately in front of them to something they have not immediately at hand; be it a second sheet of material or (heavens forbid) a book, you’re going to wind up with the flow of play seriously interrupted.

My golden rule as a designer? One page (not front and back; just the front!) for everything on a character sheet, including summaries for a character’s unique abilities. More complex games will occasionally be too complicated for this, but you should think about how you can move anything from a second or third page to a main page.

Also think about what information doesn’t need to be referenced, but might need to be recorded: this should go on the back. Biographical information goes well here, plus things like currency that you’ll only need to use in a slow moment.

Having game mechanics that exist only once or twice in a book and don’t have a home on a character sheet can be a problem.

This is also what a GM screen or similar tool is for; it quickly summarizes the rules for people. Conside

Application

Identify the components in your game that require different levels of knowledge.

Create clear priorities for each. Consider how often an element comes up in play and how important it is to narrative flow. Can an element be put on hold or taken outside the flow of a session? This is how one might handle, say, downtime actions or one-player specific actions like making a magic item or deeply involved hacking in a cyberpunk game. If this is the case, you need to think about what this implies for your players and the level of investment they will need to make.

Simplify or generalize from other mechanics the things that require intimate knowledge. You want to make it so that within two or three sessions (if even) players have a highly functional knowledge of how the game handles every common task. In a generic fantasy game, this might be: applying skills, determining combat order, resolving attacks, using magic/special abilities, and resource management (healing, regaining spell slots, etc.).

Think long-term. What do your players need to play their first session of your game? Give them enough to do this immediately! Then present hooks and guides toward the more advanced elements. 

Include introductory materials that walk players through important mechanics: a sample adventure is not just a luxury, it’s a chance for you to present information in such a way that it leads players through the process of playing your game.

Consider the presentation of fiction, examples, and mechanics themselves. Use graphics or diagrams where possible to foster additional explanations.

Consider the following, from my upcoming game HYPERSPACE BLEEDOUT:

You’ll note that I present the rules three ways here: first with the overview, then with a simplified and visually distinct summary, then again with an example. I set these off visually, which is a presentation technique intended to make it easier to spot the examples and summaries at a glance for players who still need to reference them.

Next Week

Next week we’ll discuss the barriers to knowledge that many players face: the lack of investment, interest, or aptitude. We’ll also go into some practical applications for figuring out how to create or foster each, though a more in-depth toolkit will be reserved for the third part of this series.