How are you handling Serialization with Unity3D?

[RogueDeus]

Me again. Finely have reason to bother you!

I have one of those pesky Unity questions I warned you about... Hope you don't mind.


Q: Since there is very little built in support for saving data in the Unity library, I was wondering how you implemented serialization in your games?

[x4000]

Completely custom.  Our serialization is based on custom input and output encoding buffers that write ascii data, which is then compressed when need be.

[RogueDeus]

Completely custom.  Our serialization is based on custom input and output encoding buffers that write ascii data, which is then compressed when need be.

How often do you write it to disk?

[x4000]

It really varies, and depends on what game you're talking about.  If you mean AI War, it's as often as every minute, depending on how autosave is set up.  With Tidalis, it's whenever data changes that we persist.  With AVWW, it's in thousands of smaller files that get written (and read, for that matter) only as their data changes, but with a max amount of data allowed to be saved at any given time.

[RogueDeus]

It really varies, and depends on what game you're talking about.  If you mean AI War, it's as often as every minute, depending on how autosave is set up.  With Tidalis, it's whenever data changes that we persist.  With AVWW, it's in thousands of smaller files that get written (and read, for that matter) only as their data changes, but with a max amount of data allowed to be saved at any given time.

Thanks for the swift replies.

So in AVWW when you enter an area with persisted data, you check to see if serialization has already occurred for that data, and if so you retrieve it?

I am wondering about serialization mostly because it is the most mysterious part of coding for me.  (at the moment)

[x4000]

Thanks for the swift replies.

Sure thing.

So in AVWW when you enter an area with persisted data, you check to see if serialization has already occurred for that data, and if so you retrieve it?

Pretty much.  And if it's not there, then we generate it at that time, and then flag it to be saved when the program feels like it has time to.

I am wondering about serialization mostly because it is the most mysterious part of coding for me.

There's nothing that magic about it; it's like writing notes to yourself on paper, and then remembering where the notes are.  You only look at the notes when you need the info they have, and you only write to the notes when something actually changes and you don't want to keep the info in your head anymore (for fear of forgetting, or because you want to think about something else now).

[RogueDeus]

So in AVWW when you enter an area with persisted data, you check to see if serialization has already occurred for that data, and if so you retrieve it?

Pretty much.  And if it's not there, then we generate it at that time, and then flag it to be saved when the program feels like it has time to.

Do you cache it in an array and manipulate it there till its written?


Most of the mystery for me is in when where and how to (de)serialize stuff. The whole idea of starting a game, as a movement of data, I get. But restoring the movement from a serialized state often turns my brain inside out for some odd reason.

[x4000]

We don't use an array, no.  Usually.  The answer actually varies a bit.

If we have things that no longer need to be in memory but which need to be written to disk "at some point soon before they are dropped from memory," then we'll stick that in a generic list (in C# parlance).  Then the game can write from that list at its leisure, and remove the items as it goes.  That's very easy to throttle.

For other things, when determining what to write, it's usually just a bool on the object.  Then something else checks the bools on all the objects every so often, and writes the ones to disk that are flagged.  This also is easy to throttle if you have to, although slightly harder.

[RogueDeus]

We don't use an array, no.  Usually.  The answer actually varies a bit.

If we have things that no longer need to be in memory but which need to be written to disk "at some point soon before they are dropped from memory," then we'll stick that in a generic list (in C# parlance).  Then the game can write from that list at its leisure, and remove the items as it goes.  That's very easy to throttle.

For other things, when determining what to write, it's usually just a bool on the object.  Then something else checks the bools on all the objects every so often, and writes the ones to disk that are flagged.  This also is easy to throttle if you have to, although slightly harder.

By generic I guess you mean by 'type'? If so that is one of the other mysterious parts of coding for me. I have not quite digested generic type coding yet... Or reflection for that matter. (Though I want too!!)

Thanks for the info. As always you are great at feedback!

[x4000]

Generics have a specific meaning in C#, which is different from type.  It's basically just a way of having a single "generic class" that inserts other types in place of the generic notation to make it as efficient as if you coded out the generic class once for each specific instance of the class.  So you don't get boxing and unboxing, etc.  And you don't need a ListOfInts class, or a ListOfGameObjects class.  You just have List<int> and List<GameObject> and that's that.  Much better than in the old days before generics.

[RogueDeus]

Generics have a specific meaning in C#, which is different from type.  It's basically just a way of having a single "generic class" that inserts other types in place of the generic notation to make it as efficient as if you coded out the generic class once for each specific instance of the class.  So you don't get boxing and unboxing, etc.  And you don't need a ListOfInts class, or a ListOfGameObjects class.  You just have List<int> and List<GameObject> and that's that.  Much better than in the old days before generics.

I suppose I am showing my ignorance. FYI , I only just recently got the idea of the need for Delegates... :p


Anyway, the way you are handling serialization is much how I would like too, but it seems I have a lot more learning to do.

My current game design will only require the main PC and a few global variables to be serialized so it wont be to difficult. I am going to use a custom serializer just to help myself learn though.

[x4000]

Cool stuff.  It's a long road, but if you enjoy the process that makes it much easier.  And I think delegates are overrated, by the way.  We use them, but minimally.

[RogueDeus]

Cool stuff.  It's a long road, but if you enjoy the process that makes it much easier.  And I think delegates are overrated, by the way.  We use them, but minimally.

I have not found anything more fun to learn.

Till next time.

[RogueDeus]

I just tackled Enums, Delegates, and Generic Class/Method/Delegates this week and I find myself unsure why I thought them so difficult before hand. They are actually quite intuitive once you understand them.

Earlier in this thread I was a bit confused by how you where talking about Generics an assumed you where using some custom Generic Classing to handle custom lists, but I suppose you merely meant that you like using the Generic Collections introduced in C# 2.0? I had actually been using them in my practicing and never thought about it that way...

Delegates are an interesting way to add method calls to collections, or even clean up some extremely long method calls with simple place holders, but otherwise I can see why you find them overrated. And Enums strike me as a convenient way to simplify the creation of constants. Only, from what I have read, C# creates a lot of temporary code when using Enums and slows things down when iterating through them. So calling them in long loops may end up seriously effecting performance.

You know, the more I look at these short cuts (like Enums and Delegates) the more I realize why code is getting bigger and slower... Its faster (easier) to write, but takes longer to process. I suppose that is the trade off really. Otherwise we would still be writing in machine code! :p

I also played a lot with Unity GUI. It is remarkably simple to use, and will make prototyping mechanics a lot less time consuming.

[x4000]

You know, the more I look at these short cuts (like Enums and Delegates) the more I realize why code is getting bigger and slower... Its faster (easier) to write, but takes longer to process. I suppose that is the trade off really. Otherwise we would still be writing in machine code! :p

Enums add no extra processing whatsoever if you use them right.  They are just like CONSTs.