Hypothetical: Removing quicksave/-load functionality

[MFG38]

Thread inspired by a random thought that popped into my head the other day. Not asking this for any practical purposes, but rather out of general curiosity.

I happened to recall Nocturne in Yellow, an indie game running on what was essentially a commercial distribution-friendly version of GZDoom at the time. In that game, you couldn't save your game through the pause menu - if you wanted to save your game, you had to do so by finding a save point in whatever map you were playing and "activating" it. However, you could still quicksave and quickload, which I have no shame in admitting that I abused in some of the later maps.

That made me contemplate the feasibility of removing the quicksave/-load functionality from GZDoom. How could it be done if one were to want to get rid of it? Could it be done simply with engine features (most likely either ZScript or DEFBINDS), or would such a task imply modifying the source code?

[Nash]

Short answer: it will forever be [No], no matter how much sense it makes from a game design perspective. Your only chance is to fork the engine. Removing or limiting save and load is very easy to do actually.

This is all I am willing to say before emotions and opinions start flying all over the place again for the hundredth time. If you absolutely want knowledge, do a forum search.

[Apeirogon]

Problem not that it good or bad, or somebody dont like it. Problem is that gzdoom is a source port of 29 years old game, not a game engine. So disabling native, for doom, things in its port is out of point of port.
For such opportunities it must be forked to something like "gzdoom : generic game engine edition. now with 30% more access violations", to differ "pure" engine from actual game.

[Matt]

Isn't there something in ZScript that checks for if the game has just been loaded from a save? If so you could use that as a way to penalize any savescumming (or even defeat the purpose of it if you can randomly regenerate enough stuff)

[leileilol]

This is all I am willing to say before emotions and opinions start flying all over the place again for the hundredth time. If you absolutely want knowledge, do a forum search.

Should this lead to a sudden lack of quicksave/load, is there a maintained fork that de-commits some of the controversial design decisions while keeping up to date?

[Nash]

lei: I'm not sure why you're even asking that? GZDoom's save features are here to stay. It's only custom projects/full standalones that are encouraged to fork if they need custom save systems (or lack of one).

[Graf Zahl]

Isn't there something in ZScript that checks for if the game has just been loaded from a save? If so you could use that as a way to penalize any savescumming (or even defeat the purpose of it if you can randomly regenerate enough stuff)

Trust me, if I ever see a single mod trying to use the event handler for such things, I'll add an override to hide the save state from the mod as a user option.
This is mainly meant for data to be recreated that cannot be put in the savegame for some reason, but even doing that will require some deliberate fuckery with certain object types.

[neoworm]

I am really.against removing option to quicksave in general. Let the player spoil their game if they want to. Also even if designer decides his game would not feature save anywhere function, it doesn't mean it's actually a good idea. Example being the horrible invisible platform jumping puzzle in Nocturne in Yellow. It was annoying unpredictable, it didn't kill you if you fell into the endless void anyway and it just wasted my time by forcing me to run from the start of the now empty level back to the place where the puzzle was. I was seriously considering just cheating it at one point. Letting me quicksave would save me ten minutes of my life and bit of my nerves.

[NeuralStunner]

I'm fully with Graf and Neoworm on this one.

Another related anecdote: I was playing ROTT 2013 and I got to a place in the second chapter where there's a mandatory jump-pads-over-instant-death-pits segment. Never mind that the air control is just frustrating enough to make that a bad idea, but the whole thing is locked under a single checkpoint. Fail, start over, repeat... If I were able to quicksave I could've made it through that fresh hell and gotten back to enjoying the FPS parts of the game. Instead, I've uninstalled it.

In essence, I don't see the value in punishing everyone for some hypothetical "cheaters". You're only trying to dictate everyone else's enjoyment of your work, and the end result of that is going to be a lot of people going off to play something else. Put that effort into making your mod more worth playing, instead.

[Kinsie]

ROTT 2013 added quicksaves post-release.

[PlayerLin]

I pre-ordered and play RotT 2013 since the first version and then uninstalled it at 1.4 after a lot of frustrations, never finished the game.

ROTT 2013 added quicksaves post-release.

Only one problem: It was buggy as hell, at least on the first version(1.2 or 1.3, just forgot) when quicksave got added, sometimes load a quicksave made all objects you got/destroyed or even dead enemies respawned just like you restarted the level but on your quicksave position, or sometimes it just messed out the game states to unplayable and may have to restart the level or load last checkpoint...at least checkpoints still working fine.

I know it's not the problem of Unreal Engine 3 but seriously...why use an engine that you (devs) do not know how to do proper save states?!
(I do remembered the devs had to ask Epic's tech support for that)
I think they may fixed a lot of quicksave bugs on following patches, 1.4, 1.5 and latest 1.55(sadly their promised 1.666 patch never happens), but I already given up at 1.4 since I just hate the score penalty (lose 50% of your original level score when using quicksave in the level) and......those hard jump-pack platforming and silly checkpoint locations...I just can't take them anymore, even had no interest to finish the game(I also never finish DooM 2016 by similar reasons too...shame on me)...but I would rather to play the original RotT 1995, at least I can save whatever I like without worry about any penalty even traps in original still so nasty too.

Sorry for my silly, frustrated rant.

[Kinsie]

I believe the general implication was that Unreal Engine 3 didn't have a proper savegame system. If you look at a lot of UE3 action games, they typically saved at checkpoints where the game could just reset to a known good state. Anything beyond that probably had to be cooked up by the programmers themselves.

[wildweasel]

I believe the general implication was that Unreal Engine 3 didn't have a proper savegame system. If you look at a lot of UE3 action games, they typically saved at checkpoints where the game could just reset to a known good state. Anything beyond that probably had to be cooked up by the programmers themselves.

I'd presume that the reason behind this is, since UE3 onward are meant to be all-encompassing engines intended to be used on far more than shooters and action games, that any given built-in savegame and serialization functions would need to be effectively rewritten anyway, depending on the developer's needs. If you're trying to save the state of a real-time strategy game, it's a lot more important to maintain the state of unit AI and issued orders and a lot less important to preserve the locations of physics objects. If you're saving in an RPG, it's more important to preserve the state of RNG and several hundred hours' worth of previous dialogue choices and alignment actions. If it's a pinball game*, one might preserve the exact state of the physics engine and frame-perfect inputs for sake of replay data. And so on. Everybody's needs are different and it wouldn't be possible to write one all-encompassing Save The Game Right Now function that accounted for every possible use case.

*Yes, really.

[Graf Zahl]

Savegame systems are a non-trivial thing. So it's not surprising that many developers cheap out and don't do it right.

Let's never forget that even Doom itself only had a half-assed saving feature that forgot important state when reloading.

[PlayerLin]

I did heard about UE3 just had no proper save state/savegame system, I just not sure about that when I wrote my previous post, now it's confirmed.

Due to that I already sick of those UE3 games. Checkpoint saving system, no proper save state supports? No, thanks.