The save game feature seems simple but it’s mind-blowing how it can return the exact state of a game with all elements/events organised in the correct order. Can anyone explain how it works?
In: 668
Games have flags (kind of a checklist) of all the possible action you need to do in the game (in the sense of “complete this quest”, “find this object”, “unlock this part of the map”, etc.) And also a bunch of variables to indicate your location in the game, what equipment or item you have in each slot (+inventory).
The save will just be a backup of all those flags and variables and which state they were in at a point in game.
This is a bit of a simple answer and will vary a little depending on the type of game.
Bonus: this is how cheats work too. People will analyse game memory and find where these flags/variables are and offer you to edit the value. Like find the variable “health potion in inventory” so that you can add 99 of them if you like.
Just make a global state struct where you keep all the state data, store that, you can serialize it in the simplest case.
So it really depends on the game. However I can give you insight as a programmer.
Almost everything in a modern program is what is known as a class or object.
A class is a bit of code that acts as a container to make programming way more structured. An example of a class might define a vehicle in your game.
The class holds the properties of the vehicle:
Type, color, xyz position velocity and orientation.
It will also contain other properties, like the 3D model, textures, sounds e.t.c – but these are effectively defined by the type and color properties. Classes contain what is known as constructors (which have to be programmed in) – these take a minimal number of properties of the class, and they allow the class to construct itself into a fully featured representation. For example, you save the car’s type and color – when loading the game, the vehicle class’s constructor uses this information to go and fetch the correct 3D model and textures.
The class also holds all the methods – these are the things that the vehicle can do:
Drive forward, stop, turn e.t.c
The thing is these methods don’t need to be saved because they don’t change.
Classes can contain collections of classes (like the vehicle class might contain a class for each passenger).
To save this, you undertake a process called serialization. This recursively traverses your classes and saves the minimum information necessary to restore every class and every class they contain it back to their current state via all the constructor methods.
Nowadays, a lot of this can be handled for you via the game’s engine (Unity/unreal/source e.t.c)
Edit: It’s also worth pointing out that a lot of games don’t actually save the full state of the game, they just save an adequate set of information such that most people wouldn’t notice. For example, the game might save your player character fully, but only saves enemy position and health. When you reload the game, you might find the enemies do slightly different things since their velocity/orientation/AI state wasn’t saved. Since these things are highly dependent on player actions, and no human would generally do exactly the same thing upon reload – gameplay wise it may not be noticeable unless you’re looking for it.
Edit 2: If you design all your classes well to a set of rules, then the ability to save basically becomes an emergent property of your code, rather than something that you actually need to think about structuring and developing at the end.
[deleted]
It’s kinda like if a teacher tells all their students in a classroom to put away their stuff and head off to lunch. As long as each student knows how to put away their things and how to bring it out again for the next class, the teacher’s job is easy. Each student might have different things on their desk but they each know where to store all of it. (This would represent different objects and systems serializing their states to the save file).
To be certain that every part of the game saves/loads correctly, you can create tests that check all different components. So if you run a test and see that Jimmy doesn’t have a pencil anymore when the next class starts (you load a save file), you can investigate what went wrong.
It really depends on the software as each will likely have its own specific way of recording data albeit all will have similarity.
Genuine 5yo level though, imagine you have 100 elves and you are moving to a new bedroom, you tell the elves to write down whats in your old room and where it is down to the last lego so that when you start in the new room, the elves can check thier notes and put everything back where its meant to go. In essenece, thats game saving.
In addition to other answers: it should be noted that different games do this differently.
Many games have ‘checkpoints’ in relatively quiet places with no enemies around (or have a requirement that no enemies be near when you save), hence there’s little to save other than the player character’s state and inventory.
In other games – the Halo series is a notable one – the checkpoint can happen at given spots regardless of what’s occurring, and it saves everything (player state, NPC state, projectiles etc.) This can often mean the game saves just after you fire your last bullet, or just a second before a fatal shot strikes you. You revive, die, revive, die…..
(However, it’s clever enough to add a feature that if you die within a few seconds 5 times in a row, it’ll revert back to a previous checkpoint where you’re not almost instantly killed).
I’m not a game designer but I am a software engineer. There’s a pattern called Event Sourcing that basically tracks all of the events that may happen to a system (that are storage worthy).
To put this into simpler terms, imagine you have a piece of paper (a ledger), a basket, and an apple, and that you record every time the apple is added or removed from the basket. Rather than crossing out or erasing the last line and rewriting it, you would simply add a new line to describe what happened. At the end, you would have a series of additions and removals of the apple to and from the basket, but in the end you still have one apple either in, or out of the basket.
Extrapolate that to much larger game systems and you have, obviously, much more than an apple and a basket, but the theory is the same. Everything that took place was recorded and can be replayed to produce the exact same state as before.
This doesn’t apply to all games/software, as some just save a previous state at a given moment and reload it. This would be more akin to a backup than event sourcing.
The “mind-boggling” thing for me is how often games get it terribly wrong, almost as if no thought was put into the design.
Disregarding that, it’s more often than not that getting rid of the problem is better than trying to solve it. The complexity of the game state is mostly an illusion.
Ever seen respawning loot? You might think the game is “doing” the respawning, but actually it simply returns to the state it already knows – the game world when you start. It only keeps track of what you might have looted recently, and then simply “forgets” all of you interaction. So any container you have looked at recently will have a fixed inventory that needs to be saved. But all the others are just labeled like “junk”, “basic”, “boss” and will generate their actual content on the fly, when you access them. So there’s nothing to “save” about them.
Possibly simpler example of the same idea is lootable enemy bodies. The base state is that there are none, no bodies anywhere. The game might pretend that there are some, like bodies is a zombie game, but they are just as fixed as the actual “boxes”, it’s just a different paint over a container.
Whenever there’s a fight the game will remember a couple of new boxes, but there’s a limit on that and it will “despawn”, or forget, any information beyond what the base state of the world is.
Same for enemies. Instead of keeping track of every single enemy in the world, the game will “spawn” entities when you enter a certain area, just like it did when you looked at a loot box. So a game save might keep a couple of them, but when you come back to an area hours later you will find the enemies have “regenerated”, or more accurately, reverted to their base state.
When it comes to quests it’s often important to actually design the quest around the need to keep track of the progress. Fetch quests are not only simple to think of, they are also really easy to keep track of. That’s part of the reasone why you see so many of them. Same goes for other completely linear quests, although here’s where it boggles my mind that people get it wrong and either skip sequences or manage to soft or ever hard lock the game.
TL;DR: The game state is not that complex.
The state of the game is constantly held in RAM all the time you’re playing it.
Saving the state of the game is simply a matter of recording ALL of that state out to disk and then – at a later date – being able to read it back in. The trick is doing that even when you’ve updated the game, fixed bugs etc. between the version that the game was saved in, and the one you’re trying to load it back into.
But at all times, you need to know where every point of every object is, what every texture is, where it is, what attributes every object has, what objects the player is carrying, where the player is located, where they are looking, where all the enemies are located and looking and what “mode” they are in (e.g. searching for you, attacking you, etc.).
No matter what type of game it is, all that state has to be held in memory all of the time. A save game is nothing more than a nice standardised way of reading ALL of that information, discarding anything unique to the computer (so you can save the game while running at 320×240 but load it on another machine at 1080p, or whatever), and putting that data onto disk. Then having a routine that can look at such a file, load it all back into memory at the right places, and then “restart” the simulation that is your game.
Sometimes that can be as simple as:
`player_level=4`
`player_location=(1023,12977)`
`player_health=90`
`…`
in a file. Sometimes that’s writing out the entire physics and graphics objects directly to disk. Sometimes that’s a combination of the two, then compressing the result so that save games aren’t too huge, etc.
But, actually, saving and loading is one of the easiest bits of writing a game – you just MUST remember to save all the relevant information, and load it back into the right place. Otherwise you can introduce bugs where, say, the item that the player is holding is lost when you restore a game from a save file, or it forgets that you dropped this item on the ground or completed a certain mission or spoke to a certain NPC and that’s not happened when you later load the same save file.
In extremis, certain languages have “serialisation APIs” where you can literally just pass it programming objects and it gives you a “save file” for that object back out that you can later load back in and it’ll give you back your programming object the same as it was before. There, a savegame can be as simple as passing a “Object” called “game” to the serialisation API and then putting that data in a file.
Latest Answers