The three game rules framework

 If you have ever seen game design discussion on the internet, especially if you saw say rpg fans and arcade fans fighting each other, you probably seen a lot of disagrement of the subject of say, challenge and punition. Should the game punish the player ? Be frustrating ? Or do any option go to maximize the "fun" ?

I think that what can sometimes make theses discussion so confusing is that people sometimes aren’t really talking about the same thing in the first place. I would like to suggest 3 "meta frameworks" rather than the usual two "toy or game" that each compare with a non video game form of play and that allow to see 3 differents way people judge the very goals of rules in a game in the first place. They will go from loosest to more restrictive

1) The TTRPG framework.

You ever saw in a ttrpg the rulebook telling you "Yeah also feel free to change any rules that you want" ? That’s the framework I’m talking about. Rules exist here mostly not as an end in themselves, but as a way to facilitate some kind of experience, and should be modable as will. How this apply to video game is in the form of big options menus with no shaming the player for picking what he want, but also in more subtle ways, like dynamic difficulty or xp. XP here isn’t compared to the ttrpg model because "ttrpg have xp too", but rather because they can be seen as a way to emulate the dm in order to create a pace; the better you are, the more underleveled you might be, which will force you to take a break, while a bad player will never stay stuck too long even if he learn nothing on how to play the game. While you can have game with puzzle solving with this framework, it make it take a backseat to make sure the player can enjoy other elements.

2) The board game framework

I am cool with people playing Dominion by whatever variants they want, provided that all players have agreed to them, including using an automatic score tracker.

I disagree vehemently with what you're saying here though.

In all games, within game contexts, you may only do things expressly allowed by the rules. This is what it means to have rules; it is the covenant you have agreed to by agreeing to play. You can play tic-tac-toe in a van while yodeling, but putting a Z in a box is out of the question.

It is not up to any rulebook to say that you can't use a memory aid; rather it is up to the rulebook to specifically allow it, or else you can't use one. It doesn't matter how much the game for you is not about this memorization, how much the memory thing seems tangential to whatever fun the game provides; you do not get to use anything other than your brain to handle that memorization, unless of course you are explicitly playing a variant. You also do not get to - and this is important - scrawl notes to yourself on your belly using your own blood. Games between players are played between players, and "players" do not by default include notebooks or pencils, even makeshift ones that are constructed from the players. Expecting all rulebooks to repeat this is nonsense, and anyway would offend people who don't like to talk about blood.

(Donald X, creator of Dominion, on the forums of Dominion Strategy)

Within the board game framework, while the game and rule are segregated and nothing stop the players to use the componant as he wish, the game designers have strong opinions on how the game should be played. This isn’t a framework exclusive to multi-player games, as there are plenty of single player board games. While experimentation and variation are possible in order to potentially easily create iterations, people still have expectation on the rules designer, and will note negatively any broken design.

This philosophy in video game is probably best represented by games who let the player modify settings but also have default with sometime an impossibility of saving some datas outside of them. The settings are just for fucking around. Other exemples of component/ruleset decouplage in video game is asking the player to modify external files, modding api, or when the whole code is available in open source

Here’s exemples of what I mean. While motogp 3 as a whole is not representative of this philosophy, the read me explain how to tweak further parameters than the ones in the "options" of the game, telling you how to do the work around (and that you’re on your own if that doesn’t work). Brogue is an open source roguelike, so anyone can see the source code and fork his own version. That hasn’t stopped the community from carefully considering what to add into the game.

3) The mechanical game framework.

In the mechanical games settings, there is less of a separation between component and rules, and modifying them is hard. This isn’t an idea specific to video game; most physical puzzles also follow under that framework, as well as non video arcade game that the owner is probably not gonna let you modify. In fact, since this framework is more easily enforced if the player doesn’t own the game, it may as well be called the arcade game framework.

(several exemple of "physical games" : a flipper, a hanayama puzzle called Cast Radix, A flyer for a periscope arcade machine).

In the case of video games, this translate to games you can’t easily modify without the risk of irreversly breaking something, whether it’s the machine or your future right to enter an arcade. So there is arcade games of course, but also console games, heavily drm games, and games with abscond modding documentation.

I think it might be clear from how I present thing, but I have a preference for the board game model. The TTRPG model isn’t interesting if you want to discuss game design because it turns rules into vague suggestions that must not get in the way of the true experience. The mechanical game design I am not a fan of because it’s enforced by concept that probably wasn’t a positive for the computer industry as a whole. Is having an always online connection your favorite thing unique to video games ? I happen to not really care about "exploiting the medium at his full potential" because it always feel like a box people throw thing they like to give it a veneer of objectivity, but if you’re gonna come to this angle then I’m gonna say that the ease of copying data means that the ability to both automate itself AND easily allow for iteration could be say to be the thing that make video game unique compared to flipper and other games that enfore their own rules.
If we’re talking coldly I think that the mechanical game design is also a tough sell for games above a certain scope. Not just on how game need multiple customer to be rentabilized, but also that the damage of a poor game design, from an ""economical"" perspective, is to delegate workload on the player. How much can you justify using the mechanical design to avoid this problem when the game already have a lot of economical value from other perspective ? I think that this is the part of the equation that make going out of the TTRPG model hard enough as it is.

We however have years of recording that show that the board game perspective can work. It worked on board games, where the enthousiast care about their rules and consider having to house rule a minus. It worked on video game themselves, with roguelikes often being born from iteration and trying to have a solid design, in the same way that chess was born from multiple people trying their own shot at iterating on something. Being able to change component, not as a "convenience" but as a way to test game design idea can imo be a good way to mesure the solidity of some concepts, rather than the very abstract armchair design you tend to see on video game discussions. It’s probably gonna be hard to work with on console games, but if you’re developing a game on pc, I’d say give a shot to let the player tune wacky thing with maybe an executable outside the main game, rather than having a bloated ruleset that detail every variation as "valid" somehow.