Sign in to follow this  

Save data and code structure

Recommended Posts

Hi,

I'm looking for ways to make the save & load process as painless as possible.

 

In previous games I was cherry picking which variables got saved and load back, because I didn't want to serialize the whole class due to inheritance and because some variables get pulled from config files e.g:

public class Player : MonoBehaviour {
  public Vector2 position;
  public float animTimer;
  public AnimState animState;

  public float attackForce;
  public float speed;
  ...
}

I do want to save the first three public variables, but I don't want to serialize the parent class nor the config stuff stuff. As you can imagine, writing the save and load routines was very error prone. But I could easily handle future updates, if the game is in version 2 and the save game is in version 1 I know exactly how to migrate.

 

Now I'm trying to use the native c# serialize features, but again there are some variables that I don't want to serialize, so I regroup the ones I want to serialize into another class

[Serialize]
public class PlayerProgress {
  public Vector2 position;
  public float animTimer;
  public AnimState animState;
}

public class Player {
  public PlayerProgress progress;
  public float attackForce;
  public float speed;

What remains to be seen is how can I handle future updates because the deserialize process works as a whole and if it fails, an exception is thrown. The best thing that came to my mind is keeping the old PlayerProgress and make a new one like PlayerProgress2, etc.

 

How do you handle this whole process?

Tx

Share this post


Link to post
Share on other sites

I can only tell you that you need to be ceraful, you also need to reload your data if you modify your code at runtime (much of the unity's annoyance comes from this). (You just don't load on load)

I can't tell you how, but I would immediately get drawn to a orm-db duo (there're a bunch of problems associated with references/self contained classes and binary/xml serialization), but that's overkill most of the times (just like in this particular case). Maybe even the inbuilt playerprefs are an acceptable lazy choice (it's just 3 pieces of data pls). But, both of these are considered bad practices (context). So you are left with binary/xml serialization, check the MSDN. 

Edited by RenzoCoppola

Share this post


Link to post
Share on other sites

Unitys native serialize is a pain. I took more than once a day to find a bug that was related to an uninstantiated serialization data.

 

What I ever prefer in a game is to self serialize things. For each component in your code that needs to, write an ISerializeable interface an let that code manage his data on its own by getting a byte[] array and send a byte[] array back when loading from file without knowing whatever is in it. You should also take care of backwards compatible savegames, I for example put a byte-flag in front of any propertie I serialize so could then switch-case them when reloading

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this