Im a CpE Major and its not that hard to create a save system. Various objects in-game relate to known structures, there are a known number of states for each object. For instance we have enemy soldier, he will have an object ID, position and orientation, current behavior (from a finite enumerated list most likely), health, items. That tells us everything we need to know about that soldier, you will make a function that hashes this so its in a nice serialized chunk that is easy to deal with. Hashing an object in a specific way is an easy way to serialize things you would save, huffman encoding is a loss-less way to reduce the size of the save that is easy to load from.BloodSquirrel said:You've clearly never actually tried to write a game-save system.
The current state of any game is represented by a very, very complicated nest of objects each with their own data and linking to each other in complicated ways. In order to save it all, you have to make every object such that all of its data can be accessed. Then you need to send all of that data up through the complicated object structure to a top-level object which can turn it to a serialized game state. Since your object structure isn't a simple branching tree, you need to be able to only save each object once, then recognize when you've already saved an object, and have a way to include that reference as part of another object's data. Then you have to be able to put all of it back together.
But that's only part of the fun: you don't want your save games to become unusable every time the code changes. Meaning that you need to find a way to do all this without tying it too closely to the details of the object structure.
And, no, computers are not "good at organizing information". They need to be told, in excruciating detail, how to organize any information you give them. We've got plenty of general-purpose cases which have already been solved by programmers, so you've never had to worry about it before, but none of those are going to work with the game engine that you just built.
Having an emulator save the state of the game it's playing is much easier- you can just straight up write the emulator's memory and register contents to a file. You don't have any external resources to worry about, and nobody expects to re-load a save emulated game state after patching the game.rembrandtqeinstein said:As a software developer myself (not games....yet) whenever I hear another developer say "Its too challenging to..." I translate it in my mind to "I'm too lazy to...."
Off the top of my head STALKER and Doom 3 were bit time FPS games that pulled off save anywhere just fine. Aliens vs Predator 2000 shipped with no save system and it was introduced later in an expansion.
Unity has the ability to just save the state of a scene in its entirety and I can't imagine more industrial strength engines don't have the same capabilities. Maybe back in the olden days of one-off engines saving might have been challenging but there is no more excuse now. Even emulators let you save the state of the system they are emulating to reload later. In summary yes it might be "hard" but that isn't an excuse.
Step 1: Create hash method that serializes the important bits
Step 2: Have hash of all non-area specific things; inventory, health, abilities, found items, etc
Step 3: Go through all non-static objects in the scene that you want saved recording them as you go
--Using object IDs its easy to loop through only a single time
Step 4: Write to file
That is a simplification of what is done, but its not to hard really. A save file is essentially an array of objects, objects themselves don't have much information being a structure full of variables where certain methods do work on said variables. Math and behavior doesn't need to be saved because that's not part of an object.