Of course it is. You have to be able to jump these 3 barrels all in a row. You can't try 500 times on the first one and save when you succeed, then try 500 times on the 2nd one etc. You have to do them in a run. That's obviously a game rule.
Not really, the rule in what you describe is what will happen when you perform the jump action: how far you will jump (height, distance), what will happen when you hit the ground (e.g. will any sound that can be heard from other entities be made? Will that affect your character's state? Will you get any damage if the fall speed is over some threshold? etc), what will happen if you hit the barrel instead of jumping over it, etc.
Rules specify how the simulation works - ie. the rules of the gameplay itself.
The "you have to jump over these 3 barrels" is a setup (and depending on the game, can be the requirement for some sequence), not a rule. You can use rules to create such setups (and requirements) but these are not rules by themselves.
When Mario falls in a pit and dies, you don't get to just climb out of the pit and keep going. You have to start the level over. And when you die 3 times, the whole game is over.
Right, however the roadblock here is the pit - you can either jump (or fly) over the pit or you cannot. Being able to save the game does not affect your ability to do that.
These are game rules, regardless of whether or not they make sense when LARPing as Mario. In exactly the same way, a save system constitutes a subset of a game's rules.
I've already mentioned above what i mean with rules here, but to make it clear, in your Mario example the only rules are the "if you fall in a pit, Mario dies", "if Mario dies you have to start the level over" and "if you die 3 times the game is over". That last part is the only relevant rule because it wouldn't make much sense if the game allowed you to save and load, however while it makes the game harder to complete, that additional difficulty does not come from the game's own rules (including the "if you die 3 times the game is over" rule because if you had save and load that rule would be nullified and only the other rules would remain).
Also i'm not sure where the LARPing part comes from, i never mentioned anything even remotely relevant. Everything i've mentioned so far is about the game's simulation and rules, not about anything that happens in your head.
Why do you keep repeating that saving and loading is not part of the game's rules? You're making a completely arbitrary distinction in order to categorically dismiss any preferences for checkpointing schema other than your own. The game is the totality of the mechanics (interactivity), systems (rules), and structure of goals. You can't separate the content of the "simulation" from the manner in which the player interfaces with it, including the control scheme and especially the consequences for failure (those are just rules, my dude).
I do not think there is arbitrary distinction, i describe above in my reply to Zombra what i mean with "rules" - which include what i think you mean with mechanics. Saving and loading is about the simulation (as i wrote in a previous post, i see the entire game as a simulation, not just to the individual game systems)'s state and as such it exists at a higher level than the simulation itself.
One way you can think of it is as if the game was running inside an emulator and saving and loading were the emulator's savestates. A (good) game should not be affected by the existence of savestates.
And since you point out the control scheme, i think your next example is interesting... :-P
It's absurdly easy to find counterexamples to your user interface example. In a turn-based game, the manner by which you send instructions to the game doesn't add anything to depth or challenge, I agree. But in a real-time game, this is thrown completely out the window! System Shock: Enhanced Edition is substantially easier than the original game due to mouselook, and the gap widens if you assign hotkeys for tasks such as reloading which originally required several mouse clicks.
...because i agree with what you write (SSEE is easier) but not the implication of it: the original SS1 is indeed harder, but that difficulty does not come from the game's own rules, but from the interface that it gives you to interact with those rules, which is a bad way to introduce difficulty (obviously this was not the fault of Looking Glass, they just didn't knew better at the time and i'm 100% sure that they'd do differently if they designed the game while knowing about the better control schemes that were introduced in games later).
Keep in mind that i do not disagree that saving and loading affect the game's difficulty - and in this case i also do not disagree that a game can be easier or harder based on its control scheme. My point is that because these are not part of the game's actual rules, any difficulty they introduce is not due to good design but either due to being unable/not known how to do better (e.g. the technical limitations for savegames in Mario mentioned above or not knowing how to do a better interface in System Shock 1 here) or due to simply being lazy (most modern games that pad their length by disallowing saving).
Because there is no reload delay other than the time it took to mouse over and make the appropriate clicks, the hotkey renders magazine capacities on weapons entirely superfluous. There is no sense in which this can be said to be "outside the game's rules".
It actually is, the game's rules is about what will happen when you perform the reload action (do you have spare ammo? which weapon will obtain the ammo? how much ammo will be moved to the weapon? etc), what you describe is the interface to that action (reload key or fumbling with the mouse in the on-screen GUI). My entire point is that the game's difficulty should come from the former (actions, rules), not the latter (interface, saving the simulation state).
The player has been granted a new way to interact with the game that drastically changes the playing field. The original rule was "ammo count can be reset by the unload button and replenished by the load button", but now the rule is "ammo count is replenished by the reload hotkey", and the difference matters.
And just to make it clear again, these are not rules, these map the interface to actions which are what rules work with, but they are not rules themselves. You can introduce difficulty by making the interface harder to use, but - IMO at least - this is not the sort of difficulty a good game should have.
In fact, most of the depth of System Shock's combat came from manually managing the interface in real time to load the appropriate ammo type, throw grenades, use patches, and toggle cybernetic implants.
I do not think any depth can come from the interface in a game but instead it should come from the game's own rules - ie. how your actions (regardless of how you interface with those actions as a player) affect the systems that make up the game's simulation. The interface should be the proxy between you as a player and the simulation (e.g. you have a health meter because you cannot feel your avatar's actual health state and you have a use key because you cannot reach into the game's world though your monitor to touch/push/rotate/etc the objects you want to interact with) but the depth is something that is part of the simulation.
You can't just say "the rules of the simulation are whatever I decide makes sense in the game's fiction".
Um, no, i never mentioned anything like that.
If Thief had a magical stopwatch forged by the Keepers that Garrett could use to set rewind points and it worked exactly the same as saving and loading does now (activated from a pause menu, same number of slots, etc.), why on earth would this change anything? It's just setting fluff on top of the same game and the same rules.
Assuming i understand your example, then sure it wouldn't change anything, but also it'd only be nothing more than fluff - essentially not any different than the gizmos, gears and sounds that Thief makes in its menu screen.
To argue otherwise is to insist that NetHack is fundamentally the same game if you copy files back and forth to abuse suspend saves, even though the game's entire design is built around permadeath and procedural generation.
I've already mentioned it above, but i do not imply that a game cannot be designed with saving and loading in mind, however doing that makes for a worse design when it comes to difficulty as saving and loading is not part of the game's simulation. I not believe that NetHack (or any other similar game) is a better game because it disallows saves, it is a cheap form of difficulty that should instead come from the game's rules (which is something that NetHack already has in droves anyway).
Finally, and I've argued this one already, forcing you to repeat challenges is a legitimate form of difficulty.
And to be clear, i never claimed that repeating challenges isn't a form of difficulty, however what i claim is that it is a cheap form of difficulty that should not exist in a game with a good design and instead the game should rely on its actual rules and systems for that difficulty.
Being forced to repeat content means being tested on your consistency in tackling each of those challenges as well as your strategic choices in maneuvering through their network.
I'm not sure how one follows the other, being forced to repeat content only means that you are forced to repeat content - what you do in that repeat is up to you. You may do the same choices, you may do something else (assuming the game allows for that, which is very often not the case).
The question of where/when/how to provide checkpoints is one where anyone is free to have a subjective preference, but the expectation that every game always allow for Save and Load Anywhere ultimately means that dumb instakill death trap bullshit
Both where/when/how to provide checkpoints and what constitutes dumb instakill death trap bullshit are subjective, however...
ends up in games because it's considered a mild nuisance if you're saving every 15 seconds, but becomes agonizingly frustrating if you're trying to restrict yourself so as to maintain tension and consequence for failure.
...only being able to save and load anywhere at least saves you from the badly designed parts of a game (yes, games should not be badly designed, but this never happens in practice and when in doubt i'd rather err on the side of the player having more options to handle their situation).
A better compromise is for games to be built with designer checkpointing in mind (e.g. Doom and Quake are more or less perfectly paced without mid-level saves)
This is largely reliant on the individual and i'm certain that many people do not find Doom and Quake perfectly paced - which is also why these games allow you to save and load anywhere.
but allow the player to opt in to manual saving as a separate mode if the intended game rules are found to be too frustrating. As Gloomwood is doing.
Gloomwood, at least from the descriptions given so far, seems to associate difficulty with the ability to save and load anywhere, which is what sparked the entire discussion since -as i wrote several times so far- difficulty should come from the game's own rules and systems instead of the ability to save and load. While what you describe can be an option for those who want it, similar to something like the permadeath or ironman other games have, it should be something independent of the game's difficulty.
