Posted at 21:41h
Tema: Interneto radiniai
2013 rugpjūčio 05
From a top level programming standpoint, state is evil, and saved games are all about preserving and restoring state, which is doubly evil. But let's break that down ...
So you play the game, and it takes up, say 1GB of regular RAM and 1GB of video RAM while running. A lot of that video ram is textures and stuff that you can reload when the game starts back up (though see below). But a lot of that RAM is taken up because the game is tracking game state: where your character is, where the NPCs and enemies are, what your character is carrying, what actions have ongoing consequences (i.e., you pushed a box, and the physics engine is telling the box how to fall), etc. If you just took that state and saved it to disk, your game saves would be huge -- like 1 -2 GB apiece, and it would take forever to write the save. So you need to divide that information into stuff that you need, but can be compressed, and stuff that you can rebuild the next time the game loads. That means that you a) have to figure out which information to save, and write software routines that extract that from RAM, b) have to figure out how to rebuild the rest of the information, and write the code to rebuild it, and c) have to fix all the interesting resume bugs that this creates (i.e., the box was falling when the player saved, but you forgot to write code that picked up where the fall left off, so now you have a box that get some random physics applied to it and floats or flies or sinks through the floor or whatever when the player reloads their game). And don't forget d) you need to make sure that your game engine is capable of smoothly reloading textures from any point in the level, without crazy pop-in and other stuff.