Jump to content
  • Advertisement
Sign in to follow this  
nesdavid

Save data and code structure

This topic is 572 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!