It seems to me if that were the case that your directory of saved binaries or serialized objects could get massive real quick. Is there some sort of strategy being employed on top of the State pattern that is optimizing each time stamped saved game so that it isn't saving the entire game "context" all the time?
\$\begingroup\$
\$\endgroup\$
3
-
1\$\begingroup\$ What does the State pattern have to do with this? (Or, what do you think it would have to do with it?) There doesn't necessarily have to be a pattern involved at all. \$\endgroup\$– KylotanApr 9, 2011 at 11:09
-
\$\begingroup\$ Most saved game data from what I've researched is from an object in state (using the State pattern). The object maintains its state so that when it is saved it can be serialized without a lot of hassle. It was just an observation. \$\endgroup\$– user6214Apr 9, 2011 at 15:38
-
\$\begingroup\$ All games and objects have state, but that's very rarely using the State pattern as such. More often you just have write and read functions to save and restore whatever state the object has. \$\endgroup\$– KylotanApr 9, 2011 at 17:07
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
Remember that all you need to save is the dynamic data generated at runtime. For example, if you have a monster about to attack the player, you need to save its position, its monster type, and its aggressive state, but you don't need to save its textures, model, behavioural scripts, and so on, because they are part of the static state that can be inferred from the monster type.
As long as your system keeps a clear distinction between the dynamic properties of the game state and the static properties of the world, there is usually not all that much data to store.
\$\begingroup\$
\$\endgroup\$
I think you may be over estimating the size of that data and/or underestimating the size of what is saved. Taking a quick look, I see saves in my folder ranging from about 400kb to 3mb, with one outlier of 8.5mb
What can you fit in 400k? Well, to store the position and orientation of an object in 3d space you would probably use 24 bytes (32 bit floating point numbers for x, y, z, yaw, pitch, roll). That fits into 400k over 17,000 times. Obviously there is more to each object than that, but not much. Keep in mind that you are only storing dynamic objects for the level you are currently on, since you never move backwards to revisit old levels. If you think about it, there are probably no more than a couple hundred objects on each level, most of which are very simple, like physics objects or health/ammo pickups, which probably don't need anything more than the previously mentioned position/orientation and their type.
As example that I'm more intimately familiar with, a ~15mb file can hold all the data you need to recreate an hour of game play in Heroes of Newerth. The exact size/time varies depending on the particulars of the match, but what you have there is the initial state of the entire game, plus the changes between each frame and its previous frame. That is a complete game state (minus unchanged data) every 50 milliseconds!
\$\begingroup\$
\$\endgroup\$
One other aspect of game saving is that you really don't need to save anything that hasn't changed. Say you've got a room full of objects if the player enters the room but doesn't manipulate anything you don't need to bother saving the positions of those objects. So you when you're saving the game you could compare the object's default and current attributes and only save the delta. Obviously the comparisons would add complexity and overhead to the process but that's a typical CS trade off, storage or CPU.
