koobas.hobune.stream
Serialization Theory Question
I'm still somewhat new with Unity and I'm working on implementing a save game feature for my project. I have read a good bit of the documentation about how serializing works and can save/load things without any issues.
What I'm wondering about is more of the theory of how to set up a save system for a project that needs to save a lot of information. IE, should game objects export their data out to saver/loader objects to handle only the bits of information they need to save and restore, or should I build those methods into the game objects themselves (through interfaces or whatever).. should I cram everything that needs saving all together and save it all at once, or should small bits be saved as they are needed.. etc.
If someone has already written a guide or some theory on this I would appreciate if anyone had the link. I don't have trouble with the code to do the saving/loading itself. I'm getting hung up on trying to see all the potential pitfalls before I step in them.
Thanks in advance for any insight.
There is no general valid approach that fits all situations. It highly depends on the kind of data. For some data it's possible to actually perform "delta compression" if it is based on some kind of static base data. So you only store data that has been modified. If that makes sense and how it might be implemented also depends on the actual needs and what data we talk about. Of course from a pure techical point of view data is just data. But certain techniques or compression methods only work properly for a certain kind of data. Just to provide a random example: JPEG can't be used to compress text but works pretty well for images that don't have sharp edges.
Just as an example some "id tech 3" savegames essentially store a complete copy of the whole level, including the level geometry. Though assets of course are just referenced. However the savegame file is essentially the same as a built-in level with some additional state information. Just storing information of things that have changed of course would result in a smaller savegame file, however it can be much more complicated to first determine those changes when saving and to actually restore those changes at load. Another thing is what happens when you ship updates to your game? This could easily break the savegames which were based on the old levels. Again it highly depends on what kind of game we actually talk about and what kind of data. Many FPS games want to have an interactive environment. So many things in the level could change. However if the game is round based you don't have to worry about any level data. You only have some state / progress data.
So in short your question is way too broad. There is no best way to do something in general. There is no silver bullet / golden hammer. If you fear to fall into certain common pitfalls I would recommend to read through the anti-pattern list which is now longer (and probably more important) than the list of common software design patterns.
I can see what you're saying here. It does seem that each individual project is going to have its own requirements. I will look into that anti-pattern list you mentioned. It does let me know that the save system itself is going to be a core part of the design process from the ground up, and not something that should be added after the fact when you already have all the data you want ready to be saved.
Thanks.
