RedditBest: Save game system from a top-level programming standpoint - ReAnimated.lt
Asmeninės nuomonės, įspūdžių ir apžvalgų tinklaraštis
9827
post-template-default,single,single-post,postid-9827,single-format-standard,ajax_fade,page_not_loaded,boxed,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-8.0,wpb-js-composer js-comp-ver-4.12.1,vc_responsive

05 Rgp RedditBest: Save game system from a top-level programming standpoint

Sample-Programming-Code

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.

You also have to deal with the situation where the game crashes, or the power goes out, or the player gets impatient and force-quits the game, right when the game is writing the save data to disk. This usually means that you have to write code that makes a backup of the save before the save is written. And then you have to write code that does integrity checking to make sure that the save that you just wrote actually works, and fallback code that drops the backup in place if your last save didn’t work.

… and then you have to optimize all of this so that save and resume happen as quickly as possible, and take up as little space on disk as possible. And the players would like you to integrate with steam cloud saves, thankyouverymuch. Plus QA and fixing all the fun little bugs that only show up when you save at exactly the right time and then reload your save at midnight on a Wednesday or something.

Which isn’t to say that any of this is especially hard, at least in comparison to programming the rest of the game. But it does take time and care. If you’re a small team on a tight time budget, you probably want to make saves as simple as possible. And saving your inventory, character sheet and the record of some decisions you made during the last level is a lot, lot simpler than saving the state of everything while the player is at an arbitrary state somewhere in the middle of the level.

In short, next time you play a game with quicksaves and they work and you don’t lose all your progress right before the final boss … take a minute to think kind thoughts about the programmers and QA people that made all that possible. :-)

Original thread

Komentarų nėra

Komentuoti