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
In order for a game to even run, it has to be able to answer – and update the answers to – a variety of questions. These questions are things like:
* Where is the player? (I, the console or computer, need to know this so I know where to draw them.)
* What’s the player’s name? (I need to know this to fill in text boxes properly.)
* Which door did the player last come through? (If they die, that’s where I’m going to respawn them.)
* Which bosses has the player already killed? (I need to know this so I can determine where certain NPCs are, which quests are available, whether certain doors are or are not unlocked, etc.)
* What items does the player have, and if they’re consumables (bullets, medpaks, PokeBalls, etc.), how many? (Can’t let you buy arrows if you don’t have a bow. Can’t let you shoot them if you’ve run out.)
…and so forth.
The answers to these questions are stored in the computer’s “short-term memory” (more technically known as RAM, random-access memory) as “variables” (since they can vary as the game is played), and the game references these variables whenever it needs to answer (or change the answer to) these questions.
Since this is the case, and since these variables are *necessary* to play the game in the first place, it’s fairly straightforward to design a subprogram that collects all these variables from RAM and stores them somewhere else – like, say, the computer’s *long*-term memory (i.e. the hard drive). If you couldn’t do this, any time you reset the computer’s RAM – by turning it off, playing a different game, or loading a different save file – you’d have to restart the game from scratch (as indeed you do have to on some really old games like Super Mario Brothers). To load the game, you simply have a subprogram that grabs the variables back from wherever in long-term memory they were stored and puts them back in RAM in place of whatever’s normally there when you start the game afresh
.Even for really large and complex games, however, variables only make up a fraction of the code, and the code in a modern game, however complex, only makes up a small fraction of the game itself – *most* of a game’s file size is things like maps, graphics, animations, and audio files. As an example, the actual *code* for unmodded, original Skyrim (the .esm file) is about 240 MB; the whole game is about 5800 MB, and the save files vary in size but are generally around a paltry 6.5 MB each. As a further example, Skyrim mods that *only* change code, even those that change it extensively and create new subsystems for the game, etc., are generally less than a megabyte; mods that change or add graphics can quickly get into the dozens or hundreds of megabytes.
**Tl;dr:** When you save the game, you’re essentially taking a list of answers to questions the game has to ask while you’re actively playing it. Since the list of answers already exists and since it’s a vanishingly small fraction of the actual game itself, it’s easy to write it to a file.
Latest Answers