It is very possible that a player might succeed at a difficult encounter or platforming segment once, by the skin of his teeth, but be hard pressed to do it again. Anybody who has attempted to master a skill should know that true mastery consists not in being able to do something well once, but in being able to do it well every time. The game is calling on you not to succeed once and be done with it, but to be able to succeed consistently.
Right, obviously introducing an obstacle type - be it a platforming section or an enemy encoutner - isn't something to be done one and thrown away, but this should be done in terms of the level design: if the game wants to test your skill several times, then the levels (or whatever) should have those tests instead of implicitly relying on the lack of a savesystem that will force the player repeat previously beaten sections. Games that rely on that are doing
exactly what i call artificial increase of their length: it isn't their levels' length that is long, it is the game being padded by repeating the same short level sections over and over.
Of course this has a ton of positives from the developer's perspective, even if we ignore the technical side, so i understand why developers do it and as i wrote previously i'm often willing to ignore its downsides as a player.
When I was young I played Mega Man X for the first time on an emulator. I discovered save states and used them extensively in a boss fight. Here's what I would do: everytime I managed to get in a hit without taking damage, I would quicksave. If I got hit, I would quickload. Needless to say, it trivialized the whole affair. I was not required to be skillful, to truly understand the mechanics of the fight. If I could get in one clean hit, then that's what "counted" thanks to save states, even if that clean hit only came after a dozen failed attempts.
This example is basically what i wrote several times: Mega Man X relied on its lack of a proper save system for its difficulty, so of course introducing savestates would obliterate it.
In the indie gaming scene, the argument against savescumming is a true blessing for the developers, because they can justify to avoid implementing a save everywhere feature, that (if it is not already sufficient the default save game system included in the engine they are using) is a pain in the ass to implement from scratch. As a consequence you don't have a proper save & quit feature neither (because technically you need to implement the possibility to save everywhere in order to save when you quit, if you don't want a limited "quit the game" too...). Hence the reason why so many modern indie games have a broken save system.
I was actually surprised to learn recently that Unity, the by far most used engine among indie (and many non-indie) developers, does not provide a save system and developers have to implement it from scratch - which is something they often do late in development. I mean sure, implementing a save system isn't exactly rocket science, but i always considered it a core feature of a
game engine and was certain Unity would have one.
Anyway, one group reply:
The crazy thing is that once I had some friends test the game with the ability to save anywhere, I found they were saving before trivial things like traps just to make sure that they disabled the trap each time even though taking the hit doesn’t kill you it just causes some damage and maybe a status effect. I still looked past this though thinking maybe it was just my friends doing it and released the game with save anywhere. Now I’ve seen multiple people play it on Twitch and YouTube and each person did the same thing, saving before traps and reloading when they failed a disable check.
Now, I do think people should be able to play however they like but as a developer it makes me wonder why should I even make a system like traps and disable device when everyone is just going to bypass it with save scumming?
A good roguelike player must be able to examine any situation and decide where to position, which enemies to prioritize, which abilities or spells to use, whether a consumable is necessary, whether an equipment swap is necessary, or if he should simply flee. With quickload, if the player makes a costly mistake in one of these areas, he may simply try again. He need not learn how to properly analyze anything at all because he can just try each method in turn, immediately, consequence-free. He could even try the same risky tactic repeatedly until it succeeds through RNG.
You also completely fail to acknowledge the game design limitations that arise from the presence of quickload. See the rusty's post from earlier:
Traps and unidentified items are prominent features of tabletop and roguelikes. They can have immediate negative consequences and require the party to work around them. In a game with quickload, however, they serve no purpose whatsoever. As the developer says above, permadeath (or limited saving) enables game mechanics with actual consequences which quickload invalidates.
All of the above are issues with RNG and the solution is something i've already wrote about in my previous posts in this thread: have the RNG state be part of the game state that is saved so it doesn't matter if the player loads after a bad roll: the next time they reload they'll get the exact same roll. You could even use different RNGs (each with their own saved state) for each type of roll to avoid muddying the RNG state by unrelated actions (e.g. to avoid something like "use skill A => skill A check fail => reload => do a search or whatever else that relies on a random number => use skill A => skill A check succeeded" because both both "skill A check" and "do a search or whatever" would use the same RNG).
.
