Design Threads, Compiled

This post is a compilation of some threads that I wrote on twitter about game design a few years ago.  I'd probably write them a little bit differently if I was writing them today, or not for twitter, but instead of rewriting them I'm just copying and pasting.  This is currently a draft as I type this, maybe by the time it's a post I'll actually edit them.  On the other hand, if you're reading this, that means I didn't.

Basic Mechanic Design Steps

So here's a ramble about my process when designing a new mechanic.

The first step is to ask some questions: Why do I want this mechanic? What is the use case where players will interact with it? What is the intended gameplay experience? Do I need this mechanic, or are these use cases and gameplay experiences already adequately covered by existing mechanics?

Assuming I decide that the mechanic is needed, then I continue. At this point I have the expected use case and desired gameplay experience. These are the two most important things about the mechanic and the things that I keep in mind throughout the entire rest of the process. Let's take an example I designed; rules for running away from combat in Against the Fall of Night. Sometimes a combat just goes bad and you want to run away.

My expected use case is: Players are in a combat that they don't want to be in, so they decide to run. My desired gameplay experience is: Running has a cost, you can't just run at the drop of a hat, but you're reasonably likely to make it if you flee and the cost doesn't feel punishing even if you fail.

Is this a needed mechanic? Standard D&D-like combat movement systems make fleeing basically impossible. You can disengage, but they'll just follow you, and unless you move faster than them (which you usually don't, especially not in armor) then you're not making any real progress. AFN has similar combat movement mechanics, so yes, this is a desired experience that is not served by existing mechanics; it's worth adding.

The mechanic that I designed, put in what is basically system-neutral psedudocode, is: Everyone fleeing gives up their turns for a round. At the end of the round, everyone fleeing makes a check and everyone chasing makes a check. If half of the fleers succed, and half of the chasers don't, they get away. If half the chasers succeed, and half the fleers don't, escape is impossible. Any other result, it becomes a running battle where you automatically check again at the end of each round.

I check it against my ideals. Use case: Yes, you can run away in combat using this rule (you better be able to, that's all it does). Yes, it costs you something (all your actions for one round); but it's not a one-and-done roll. It always only costs you your actions for one round, not your actions for the rest of the combat, even if you fail. And if you end up in a running battle, it adds tension and changes the nature of your choices; with you knowing that the fight might end at the end of each round, you'll make different choices than you might otherwise.

And it also adds possible tension in the form of heroic sacrifices, by specifying 'the enemies chasing' instead of 'all enemies'; if you can make it so that some enemies can't chase, maybe by blocking the corridor, then those enemies don't get to be part of the check.

This is obviously an alpha rule, since I wrote it the same day as this original thread, and it's subject to plenty of change and revision. Almost nothing ever stays in its original form (iterate, iterate, iterate!) But, at least on a twitter-appropriate level of verbiage, that's my basic mechanical design process. Focus on the use case and the gameplay experience, make the math and design match it, and then iterate it until your eyes bleed.

Dice Mechanics

Last time I mentioned making the math and design match the use case and gameplay experience, but didn't actually say anything about how to do that. This time I'm going to talk about dice and how I pick which dice to use for a mechanic.

It doesn't cover every possible trick you can do with dice, but most of the time, you can separate dice mechanics into two kinds; one die or multiple dice. One die is a mechanic like D&D's d20 rolls; you roll a single die, you add whatever, you compare it to target, you're done. Multiple dice can be done by adding the pool vs a target, or by checking each individual die against a target. The big difference between the two is probability.

On one die, all results are equally likely. On multiple dice, the results are on a bell curve. One die has a lot more swinginess as a result. If you're rolling a d20, a 1, a 10, and a 20 are all equally likely. If you're rolling 3d6, a result in the 9-12 range is almost 50 times as likely as getting a 3 or 18! (100 times as likely as 3 or as 18, each). So if you have, say, a +1 modifier and you need a 10; this is a 60% chance on a d20, but a 74% chance on 3d6. As your modifier grows, the difference gets bigger. With +5, it's a 80% chance on a d20 but a 98% chance on 3d6! You're ten times as likely to fail on the d20.

What does this mean for game design? It means that a single-die system emphasizes randomness and elements outside your character's control, because failure is always a meaningful chance due to the machinations of the die. If your goal is to create a mechanic where the player is never sure what's going to happen, and where failure is always an option, a single-die is a good choice.

If your goal is to create a system where predictable tasks can be performed predictably, then a single-die is probably going to be too swingy for you (which has led to some of the complaints about D&D's skill system, historically). To emphasize skill and experience over chance, a multi-die system will give you results that are capable of staying random at low modifiers but scale towards determinism at higher modifiers.

Does it matter what kind of multi-die system you use? Yes, but not for this discussion. Successes and sum vs target both follow a bell curve and both fundamentally share the same elements in this regard, but they have different secondary tricks that you can do with them. It's also worth noting that the more dice you're throwing down, the more tightly bound to the bell curve the result will be.

Adding more dice to the pool isn't just a modifier on success; it changes the shape of the curve, which limits the effect of outlying results all on its own. It's a form of bounded accuracy enforced by probability, with the small chance of going way outside the expected results. If you roll 10d6, 68% of the time, it'll be between about 30 and 40. 95% of the time, it'll be between about 25 and 45. 99.7% of the time, it'll be between about 20 and 50. But 0.3% of the time, it'll be lower than 20 or higher than 50.

The mathematics of the dice bound the possible results pretty tightly, but allow for exceptional results in very rare cases. (For reference, the odds of having advantage and rolling a pair of 1's anyway is 0.25%; about the same as the odds of going below 20/over 50 here.) If you roll a d20, on the other hand...68% of the time it'll be between 5 and 15. 100% of the time it'll be between 1 and 20. That's it, that's all the confidence you get.

So what's the summary? Dice and math matter when designing a mechanic, because the players are going to interface with them, and the mechanics of the probability will determine the experience that the players have with the mechanic. If the players expect the mechanic to be predictable, but instead it's swingy, then your mechanic doesn't match the expected use case. Conversely, if the players expect it to be swingy and random, but it's actually very predictable, same problem. Make the mechanic as players experience it match what you want the gameplay experience to be; and picking dice is one way to control that.

Implied Incentives in Design

Today's discussion is about player choices and incentives as they relate to the mechanics that you design. Incentives and the results of choice are an important part of the experience that players will have as they interface with a mechanic.

Imagine you're designing a skill system. You have a variety of possible ways to do this. As always, we start with the goals; use case and intended experience. We'll assume that your game doesn't have a skill system yet and that you do need this mechanic. The use case is that a player wants to do a thing that isn't directly combat-related. The intended experience is that the more resources the player invests into doing this thing, the better they are at it.

There's already a lot going on here, and it ties into the tone and genre expectations of your game. But that's not the topic here so I'll just assert something. I assert, for this example, that characters should be able to range from untrained to highly skilled, and that their chance of success at a given task should increase each time they invest character resources into this skill.

Already we're making incentive choices. The incentive we're giving is that players can improve at their skill by spending resources. But the question becomes, then, how much do they improve? Is it better for them to specialize or spread it out? Will any choice offered to them ever feel like it was a trap?

(Don't do that, btw. Trap options aren't real choices.)

You can adjust these knobs with mechanics changes, and there's a lot of ways to get any given result, and this is (originally posted on) twitter. So instead I'm going to talk about why you might aim for one goal or another, and what that does to the player incentives.

Let's say that you decide that you start with 50% success, and you have four ranks, and each rank gives you +10% success. You can focus them in one skill or spread them across others. This is a fairly balanced option that makes both specializing and focus decent options. What if your success rates by rank 0-4 are, instead, 10%/50%/80%/90%/100%?

You can see a strong incentive here to have at least one rank in anything that you want to get done, and a second rank if you want to get it done reliably. Because of the huge jump between ranks 0 and 1, it's unlikely that anyone would put all four ranks in one skill, so they're rewarded with 100% success rate if they do. There's incentives for both.

But what if it was 10%/50%/80%/90%/91%? I don't think you'd see a lot of rank 4's in there. That extra 1% is not a strong incentive and would not feel rewarding, especially not when they could be putting that to make something else from rank 0 to 1 and getting a 40% boost. By considering the incentives that your mechanics offer to players, you can analyze the experience that they'll receive when making these decisions, which in turn will affect their satisfaction with the mechanical interface of your game.

I've only been talking about character building here, but the same principle can be applied to actions in-game. Some games have a stunting mechanic, where if you take a recklessly awesome action, you get a bonus to your resolution. This is an incentive. Recklessly awesome actions are often unlikely to succeed and very dangerous to the player; so they're fairly uncommon. If you want to make them more common for genre or gameplay experience reasons, you can provide players with an incentive to take these actions, and that's what stunting does. (Of course, this can also generate undesired results, like players competing to take the most over-the-top action, but that's a separate topic.)

Another example of an incentive in gameplay is the oldschool XP for GP rule. You gain one XP per GP value of treasure that you safely return to town with. XP for GP reduces the value of combat, because combat is dangerous and grabbing unguarded loot isn't. It leans players towards wanting to play carefully, because they need to return safely, and to find ways to get loot without combat. If that's something you want for genre or gameplay reasons, that's something that XP for GP can do.

Incentives can be a very strong design tool for gently leaning players towards the expected experience. Don't go too heavy with them, though, because an incentive that's too heavy isn't an incentive anymore; it's a balance problem. But whether or not you use them intentionally, they'll always exist in your design. Thinking about your mechanics in terms of incentives is a useful way to help predict what kind of gameplay experience a player will have, and to figure out whether or not that matches your intent.

Mechanical Variance

Today, I'm talking about the value of variability in mechanics, and why you might want a mechanic to be highly variable; or, perhaps more accurately, why you want to avoid an entire character being low-variance.

High-variance and low-variance characters have existed in a variety of ways in different RPGs. I'm going to draw my examples in this thread mostly from D&D 5E, because lots of people are familiar with it and it can handle it if I say anything that could be considered negative. One of the most traditional examples of variance differences is the fighter versus the wizard.

A fighter, in the majority of combat situations, will find themselves taking the Attack action. Because of the way 5E balances attack bonuses vs AC, using HP as a primary defensive stat, you can have a pretty good amount of confidence in what the attack will do. It will very likely do damage within the expected bounds.

A wizard, in most combat sitautions, will cast a spell. What will the spell do? That depends on the spell, the targets, any required saving throws, the terrain, and so on. It's almost impossible to predict the actual result on the battlefield just by knowing that a spell will be cast; whereas the fighter's attack is very predictable.

So we can see that the wizard has much higher variance in combat than the fighter. There are other ways to increase variance too. A fighter using Sharpshooter or Great Weapon Mastery will have a higher variance than one who isn't; with the attack penalty and damage boost, they can get huge swingy differences outside of their average result. So we know that there's ways to get lots of variance in combat. What does this tell us about the value of it, though?

If we look at the most common complaints about the fighter, it tells us that variance is fun. Variance feels like power. The most common complaints about the fighter are that it's boring or underpowered. The fighter isn't underpowered. It's a very strong class. But it doesn't always get those same kind of high-variance spikes that we can see from other classes, which can make it feel less powerful.

Imagine a class that had one attack, always hit, and always dealt 5 damage (at first level). This would be a very strong class! But would it feel strong, next to a character who might occasionally spike something much more effective than it?

Introducing high and low points into a class experience, rather than keeping them as a smooth average, allows for players to feel good about the awesome thing they just did. Assuming the amount of low points are kept in check (missing all the time isn't fun, but the attack roll itself wouldn't be fun if you could never miss), and the high points need to be kept appropriately rare as well - it's not as awesome if it's just something that you can do all the time, variance introduces a feeling of power and fun that can be lacking when things are too predictable.

This is all, of course, in addition to the fact that variance introduces tension and excitement to dice rolls (if there's no risk of a meaningful failure, why are you rolling?), but that's generally better-understood intuitively and I rambled on long enough for today. Agency is also a different topic; variance can be controlled or uncontrolled, and that's about agency, not the variance itself.

System is Setting

This time, an opinion that not everyone might agree with. But I think it makes better games. System is setting.

What does 'system is setting' mean? All mechanics contribute to the experience of gameplay. A setting is implied by the system, and if the implied setting does not match the narrative setting, you end up with a disjointed experience. You can't play LoTR in 5E any more than you could play WoW in 1E. (Side note: You can play LoTR in 5E with Adventures in Middle-Earth, if you have a copy. But AiME makes significant systemic changes to make this possible. Which goes to my point; system is setting, and in order to make the setting work with LoTR, it was necessary to adapt the system.)

While I'm talking about this, this is something that @\cavegirl knows very well and talked about while designing Dungeon Bitches. It's on DTRPG now and you can go check it out. She designed mechanics of the game not just to create the desired gameplay experience, but to reinforce the themes and tell a story about the world at the same time.

So back to system is setting. All systems create an implied setting with what they put in the book, even if they don't have a specific setting. Some of this is place names and monsters and so on, some of it is mechanics. This was commonly seen in 3E, where people would use the demographics and magic shop tables from the DMG to create the setting of their world.

Another common example is when people try to play Star Wars in whatever system they like, often 5E currently, and it doesn't work at first. You can't just add mechanics and make the system Star Wars; you need to remove mechanics too. For Jedi to make sense and tell the same stories that they tell in SW, you can't just have space monks with laser swords. You need traditional spellcasting to not exist, you need armor and weapons to work differently, and you need the Dark Side to be a thing.

This is in part why generic systems almost always lead to kitchen-sink fantasy worlds. Again, something that we saw a lot of in 3E. As book after book was released and more and more options crowded their way into the world, whatever setting you started with became less distinct over time as it just continued to be the same kitchen sink as every other setting that had all these same elements in it.

5E was originally designed as a modular generic core where you'd add only what you needed for a given campaign, and you can still see an echo of this in the DMG in the section where it just has ~100 pages of optional rules. That would be a very flexible system, where you could just have your core resolution mechanics as reliable and then add in what you needed bit by bit.

But even then, something as generic as a core resolution mechanic of roll d20 + mods vs DC still implies things about the setting. It doesn't work for professionals doing professional tasks; a character with +5 vs a DC 10 (Routine) task has a 25% chance of failure! But a roofer, even a 1st level one, does not have a 25% failure rate per roof or per shingle. The d20 is designed to create that failure chance to generate interesting gameplay in the aspects that D&D focuses on, high-tension moments, and is not well-suited for reliable tasks in low-tension moments.

So we can see that even a mechanic as simple and generic as the d20 + mods vs TN still contributes to the implied setting and expectations of what the characters will be doing. Any mechanic that is generic enough to work for every possible setting is too generic to be interesting. Similarly, we can see the same kind of thing in a healing system; imagine a system where all characters are healed to full after every encounter, all resources recovered, everything is perfect. It would be impossible in this system to tell the story of a group of rag-tag adventurers getting beaten down over time but refusing to give in, because they're always at full resources!

The system influences and guides the kind of stories that the gameplay can tell. This is part of why I feel it is so important, when creating a system and making mechanical design choices, that you consider these questions. What kind of setting is implied by this mechanic? What kind of stories does this mechanic enable? What kind of stories does this mechanic make more difficult or impossible?

System is setting, and it's important and valuable to ensure that your system supports and enables the kind of stories that are core to your setting.

In Defense of Subsystems

 Many RPGs these days use a universal resolution system that covers all parts of the game.  This was popularized with D&D 3rd edition and the "d20 System", the idea that no matter what you're doing in-game, you roll a d20, add modifiers, compare to a target number, and you succeed if you beat the number.  I'm going to explain why this is bad (or, at least, shouldn't be used for every situation in every game).

This is distinguished from older games where you would have different rules to resolve the situation depending on what you were doing.  Using AD&D 2E as an example (because it had a ton of these), you might make a Strength check by rolling 1d20 to roll under your Strength score.  But if you were trying to perform a major feat of strength, you would instead of a percentage chance to Bend Bars/Lift Gates (the exact percent is determined by your Strength score).  Or if you were trying to kick open a door, you'd roll your Open Doors score instead, with a different distinct target number if the door was magically sealed.  Obviously, there's a lot going on here, and maybe we don't need three or four different subsystems just for doing strong things.  But that doesn't mean that we shouldn't have subsystems at all.

The point of subsystems is to allow your gameplay to feel different when your character is doing different things or going through different experiences.  It creates tactile feedback for the player that mirrors the kind of feedback the character would have.  The value added is that feedback, the experience actually being different and not being the same gameplay with a new coat of paint.

Does it add friction?  Yes, of course it does.  Every mechanic adds friction in resolution.  Sometimes that's the point of a mechanic - go read jay dragon's post about how rules are a cage.  I don't necessarily agree that that's the point of every rule, but absolutely it is the point of some rules.  Sometimes the point of a rule is to restrict the player, to add friction, to make it so that your whim as a player is not the only thing that affects the character and the shared imagined world.

The resolution of every rule creates an experience and, when done right, will reflect the experience of the character.  This feedback helps ground the player in the game and should make it both more interesting and more real.  If your experience as a player is identical whether you're in combat or fixing a wagon wheel, then the game is not accurately providing that feedback to you about the experience your character is having.  If resolving the rules to fix a wagon wheel is a meditative experience, while combat is tense and frenetic, then we've got something much more interesting here than a smoothed-out universal resolution system that relies on the player to provide anything of value.

So to go back to our feats of strength, maybe you just use a normal roll for normal things.  If you want to do something that would break a record, you'll need to do something more difficult.  The friction involved in resolving the more difficult task - the pushback that the rules give you, when you try to resolve the action - that mirrors the pushback that the world gives the character when the character tries to take the action.  In this way the rules serve to reinforce the roleplaying loop, by giving the player an experience that's analogous to the experience the character feels.

And certainly we don't want it to be exactly the same thing the character feels in a lot of situations (no one needs to get stabbed just because your character did), but if you feel something mildly unpleasant because your character is in an extremely unpleasant situation, that's working as intended.  If resolving the rules to determine whether or not your party member dies after their severe injuries causes you to feel stress and tension, that's a good thing.  

And if a negotiation with the king feels exactly like a relaxing day fishing which feels exactly like combat?  Something is being lost, there, and subsystems are how we get it back.

Rules Fragment: Nightfall Tactics

 Today I had a thought and had to write it down, so here we are.  This is the design fragment of a tactical wargame using the basic core of the Nightfall Engine (from Against the Fall of Night).  Rules terms that are referenced, but not defined here, are the same as in Against the Fall of Night.

Nightfall Tactics

A wargame/SRPG/tactical game built off an extension of the Nightfall Engine.

Tactics Skill:  Your default Tactics Skill is equal to half your Combat Skill.  Tactics Skill is used as the basic resolution roll for this layer (for example, if you're determining the effect of your infantry attacking, you roll Tactics Skill instead of an attack roll).

Strategic Skill:  Your default Strategic Skill is equal to half your Mind.  Strategic Skill is used to determine starting setup, layout, limits of units you can command, and so on.  It would be tested to determine if you can successfully ambush someone, get to the high ground before combat starts, etc.

Units can be actively commanded, or just on your team.  The number of units you can actively command is determined by your Strategic Skill, but you can have as many units on your team as you can hire (see the note on Wealth and Economy later).  You can only use your Tactics Skill to benefit units that you’re actively commanding.  (Thus a character with very high Tactics Skill, but low Strategic Skill is a fantastic sergeant or lieutenant who commands a single unit; a character with high Strategic Skill but low Tactics Skill is still useful as a commander of a large number of units to prevent them from default-stats.)

Feats can increase or affect both Tactics Skill and Strategic Skill.  (For example, a feat Magical Tactics:  You can use your Magic Skill instead of Combat Skill to calculate your default Tactics Skill.)

Strategic Spells:  Big battlefield versions of magic.  They take 10 minutes to cast (which is 1 round at this combat scale) and require the support of a company of mages (60 people who each have Magic Skill +1 or higher).  (Optionally, a total Magic Skill of 60+ is required, so you could have ten 6th-level thaumaturges cast one, if you somehow have those available.)  Caster characters can learn strategic versions of spells that they know with a feat.

Strategic Techniques:  Combat techniques scaled up to battlefield scale.  Martial characters can learn strategic versions of combat techniques that they know with a feat, and then units they command can use those techniques.

Units would be designed like monsters, with levels, stats, and basic attack and defense techniques.  The commander stats can replace certain stats here (like the unit would have a Combat Skill of its own, but a commander can use their Tactics Skill in place of it).

Units have Cohesion and Health in place of Vitality/Wound.  Cohesion reflects their ability to keep it together, Health is how many of them are still alive.  Like AFN, melee attacks that are not defended against deal damage directly to Health, while those that are defended against attack Cohesion first.  Ranged attacks always deal damage to Cohesion first, unless their attack test is a modified 21+ and the attack was not defended against.  Undead, constructs, and other mindless/controlled troops have Cohesion -, because they never break Cohesion and need to be actually destroyed.  Cohesion is also the Morale rules; when a unit hits 0 Cohesion, they need to make a check of some kind to stay on the field or else they disperse.  Whatever the check is by default, it can be replaced with a Tactics Test if the unit is being actively commanded.

Initiative phases are Ranged, Cavalry, Infantry, Magic.  (Flying cavalry, as a special ability, get to act in the Ranged phase.)

Strategic spells can’t be cast if the unit has been attacked that round, though the mage unit can still use their normal techniques.  Only a character with Magic Skill +1 or higher can actively command a magic unit; they just use their default stats if you don’t have at least Magic Skill +1.

Economy:  For balancing units against each other, there is some form of economy.  Units cost Wealth.  You can only keep a number of units supplied with total Wealth cost equal to your Wealth.  Default Wealth cost is Level, double for cavalry, but specific units may be more or less expensive.  (Note that multiple people can combine their Wealth to supply an army.)  (Note:  This makes it difficult for normal players to bankroll an army, and right now I don’t care, integration can get figured out later.)

Units don’t use Attack Points, Defense Points, or Magic Points, because a round is 10 minutes long and they have a ton of all of those points.  Instead, every technique or spell they have is very situational with distinct strengths and weaknesses.  If the unit has something that’s always useful?  That’s their special ability, being generically useful.  Each technique can only be used a specific number of times per round, usually once unless specified otherwise.

Units normally can’t do things that would make them Vulnerable while in melee.  Unlike individual characters who get to choose that kind of thing, units just aren’t given the choice.  A successful Tactics Test can get them done, or units with – Cohesion can do so automatically.

Damage is generally the same thing as on personal scale.  Rough default is 1d6 + Combat Skill, reduced by Armor which is usually approximately equal to Level.  Aura for undead, constructs, and anti-magic units.  Cohesion/Health is roughly half what Vitality/Wound would be on personal scale; units die faster than heroes (but it’s rounded to even numbers to make things easier to track).  Like personal scale, units can be ogre-sized or giant-sized as well, which makes them terrifying.

Units have facing.  We’re making a square-based wargame because I’m a heretic.  A unit has three front squares, two flank squares, and three rear squares.  Attacks from a flank have slight advantage, attacks from the rear have high advantage.

Weapon triangles:  We’re adding weapon triangles based on weapon qualities.  Cunning, Brutal, Reach.  Brutal > Reach > Cunning > Brutal.  If you’re on the good side of the triangle, you have slight advantage.  If you’re on the bad side of the triangle, you have slight disadvantage.

Basic unit statblock:
Wealth Cost, Level
Combat Skill, Magic Skill
Armor, Aura
Cohesion, Health
Attack Techniques/Defense Techniques/Spells

Two example units.

Militia (Infantry)
Wealth Cost 1, Level 0
Combat Skill +0, Magic Skill +0
Armor 0, Aura 0
Cohesion 2, Health 2
Attack Techniques
Swarm – The militia make a melee attack.  1d20+0, 1d4 damage.  On a miss, the militia take 2 damage.

Spearfighters (Infantry, Reach)
Wealth Cost 1, Level 1
Combat Skill +1, Magic Skill +0
Armor 1, Aura 0
Cohesion 4, Health 4
Attack Techniques
Long Strike – The spearfighters attack a target one square away from one of their front squares.  1d20+1 to hit, 1d6+1 damage.  This technique cannot attack adjacent targets.
Defense Techniques
Brace – The spearfighters set their spears to defend.  If the attacker misses, they lose 1 Cohesion.

A Rule Is An Answer

As is eternal, there is discussion about RPG design theories, what is a rule, what is the purpose of a rule, etc.  I offer a definition that may be of some use, by looking at what might be the most fundamental way to define it (or, at least, the most fundamental way I can think of).

I don't think it's useful to try to say that all rules have the same purpose.  Obviously different rules, in different games, are designed for different things and for different reasons.  To actually get something universal, I think we need to go deeper, to a definition so obvious that it's almost useless on its own (but we can still use it in context to analyze things, and get use out of it when combining it that way).

So.  A game is made of rules.  Some of these rules are obviously game-rule types; a pawn can only move one space forward, while a rook can move any number of spaces in a straight line.  Other rules are less apparently part of the game, but are part of the game nonetheless; a Dungeon Master builds encounters following guidelines.  A player builds their player character and chooses their actions.  These are rules of a game as much as a rule about movement.

Combined, all the rules form the system or the game.  We're not debating whether or not the text on its own counts as a "game", we don't need that level of pedantry here right now.  Now that the game exists, the next question becomes; how does one play it?

Regardless of what the game is or what its rules are, you play the game by asking it questions, by interrogating it; what can I do, what can you do, what does this do, what's over there.  In TTRPGs, the process is the same whether you're trying to resolve a mechanical loop or if you're trying to explore the imagined world the game takes place in.  The way that those questions are resolved is by consulting the rules of the game.  A rule is an answer.

The most fundamental question to ask is "What happens next?"  and every game will be able to answer this.  Whether the answer is move to the next phase, roll some dice, ask someone at the table, end the game, or do something else, the game will provide an answer when you ask it what happens next.  As players (including GMs), your actions set up the context for the next question that the game is asked, and the rules provide the answer.

For example, a player says "I attack the guard".  This implies a question; what happens when you attack the guard?  The rules will answer that for you.  In another game, the player moves their pawn into a square containing an opposing piece; what happens next?  The rules answer.  Most TTRPGs have examples demonstrating that this is their core gameplay loop; the player declares an action, the GM consults the rules, and the GM says what happens next.  The rules are how the GM determines what happens next; they provide the answer to the player's implied (or explicit) question.

This is equally true for questions about the fictional world the game takes place in, such as "what's over that hill" or "what's in the chest".  The game will provide rules to determine that.  Depending on the game and what it cares about, these may be distinct rules, or they may be guidelines.  The way most RPGs are written, there's no real distinction between GM rules and GM guidelines, for the purpose of this discussion they're both rules.  The rule might be "the GM decides", "the GM rolls on a table", "the group determines by consensus", or anything else.  The point is that the rule is the answer.

Depending on what the rules care about, the answer might vary.  Some possible answers might be "You can't do that" (no, your bishop can't cast Meteor Swarm), "I don't care.  Three." (for things that the game doesn't really care about, it just gives you a quick answer and you move on), or "That's a great question!  Here's ten pages of charts to figure out the answer." (for things that the game wants to spend time understanding and resolving).  In some ways, this might cause the rules to abstract a complicated task.  Sometimes it might add complexity to something that seems like a simple task.  Sometimes the rules will restrict you with their answer, and sometimes they will empower you.  Most TTRPGs that lack a specific answer do have a general rule covering that situation, "Ask the GM/group", while most board games default to an answer of "You can't do that" if it's not covered by a rule.  (No, the Air Bud clause does not work in Monopoly.)  (The two types of games are more alike than most people think.  This general rule is the biggest difference between them.  The reason you can do anything in TTRPGs, and not in Monopoly, is because TTRPGs have a general rule that says if there's no rule that covers the situation, there's a person at the table empowered by the game rules to add a rule.  If Monopoly had Rule 0 for the banker, you could reinvent financial derivatives and sub-prime loans just like real banks!)

The only thing that every rule will always do is to answer you, when you ask the game a question.  To make this interpretation useful, we need to think about questions.  What we can do to use this is to think about what questions people will be asking our games, and what answer will we give?  How long will the answer take to understand and implement?  Do we really care about this question; is it really that important to have a good answer to it, or do we want to just pick something and move on?

(Generally, the less the game cares about a question, the more abstract and quick-to-resolve the answer will be.  If your game doesn't really care about traveling the wilderness, fine, make a single check for your journey.  If your game thinks this is an important and valuable question, provide a whole system for the experience.)

Appendix:  Semi-Related Rambling

Rulings over rules is a popular phrase these days (not quite as popular as it used to be, which is good).  It fits into this paradigm without any issues; it just means that it is not providing answers for many things, and answering those questions follows the default rule of ask the GM.  This is also totally consistent with the feedback that GMs of this game often give, which is that they feel like the game isn't helping them answer the questions that come up in play.  A rules-light game can avoid this problem by focusing the questions being asked.  If you only expect players to ask one or two questions in gameplay, then you only need one or two answers.  If you bill your game as an anything game that can do anything, you're going to need either some very broad answers or a whole lot of answers.  

This is where the importance of a game setting expectations comes in; these expectations can be set with prose, art, layout, and many more parts of a game.  If your game as a whole can get players to understand which questions to ask, and provide answers (in the form of rules) to those expected questions, it will generally be a smooth and understandable experience.  Conversely, if your game prompts players to ask questions that it doesn't provide answers for (again, in the form of rules), it will tend to be a frustrating experience that feels like it requires a lot of patching.