It's not so much the engine "not having proper save states" but more "the engine doesn't have a pre-built save state system". The engine provides you basic low level utilities to write and read files to and from the disk, but that's about it. Because the engine is a generic game engine, game developers are expected to code their own save/load system to fit their specific kind of game... and as Graf explained, Doom-style "save any time, any where" systems are not easy to make at all.
As players, we tend to take these things for granted because the games we play already conveniently have these save state systems in place, but the truth is, behind the scenes, this stuff can get quite complicated to code.
There's a reason pre-built save/load systems are sold on the Unreal and Unity marketplace for money. Especially the Doom-style ones aren't usually cheap (I've seen some priced at $60 and even $99 sometimes)
Hypothetical: Removing quicksave/-load functionality
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Hypothetical: Removing quicksave/-load functionality
Those prices are actually very reasonable for commercial developers - the cost of implementing it themselves can be 20x higher.
Re: Hypothetical: Removing quicksave/-load functionality
And whats the problem save numbers on disk?
1. Pick number
2. Save it on disk
3. ???
4. Profit
Or problem in what and how pick and how save?
1. Pick number
2. Save it on disk
3. ???
4. Profit
Or problem in what and how pick and how save?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Hypothetical: Removing quicksave/-load functionality
A game state is not just numbers - it's a complex relationship between 100's or 1000's of map entities.
Re: Hypothetical: Removing quicksave/-load functionality
That was a joke.
I just really dont understand problem of saving actors position/state/health/etc on disk.
I just really dont understand problem of saving actors position/state/health/etc on disk.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Hypothetical: Removing quicksave/-load functionality
Like I said, it's not just saving a few numbers that makes it hard, but saving the complex relationships.
Re: Hypothetical: Removing quicksave/-load functionality
I know. I am willing pay even hundreds, if I'm making a large-scale project, and that'd even still be considered cheap. It would be monumentally more expensive to pay a contract programmer or artist, by comparison. $99 or even $199 is a small price to play for an easy-to-use save system.Graf Zahl wrote:Those prices are actually very reasonable for commercial developers - the cost of implementing it themselves can be 20x higher.
When I used the word "expensive", I really meant relative to the typical "starving indie artist" crowd, not to mention the fact that these engines being free-to-download has exploded the user base in questionable ways...
Re: Hypothetical: Removing quicksave/-load functionality
Saving is not even the biggest problem. If I remember correctly from development of Dex, most problematic was actually loading the game, because you had to do it in the right order and inicialize all the pointers right otherwise it failed horribly.
Most games that have savepoints or checkpoints do usualy have them because you can't do propper saving anywhere due to various limitations. Not because it is a design decision.
Most games that have savepoints or checkpoints do usualy have them because you can't do propper saving anywhere due to various limitations. Not because it is a design decision.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Hypothetical: Removing quicksave/-load functionality
Building a system that is fully saveable requires careful design from top to bottom, every single object that can be in the game needs to be fully serializable - miss one tiny bit and you're toast.
In GZDoom, putting a single CVar reference into a custom actor will mean the game cannot be saved anymore because the CVar reference cannot be restored.
In GZDoom, putting a single CVar reference into a custom actor will mean the game cannot be saved anymore because the CVar reference cannot be restored.