The word of God(ley)

Avoiding revision as usual, I’ve been working on Grid Wars settings page and finally have my settings library working. It’s probably a pretty standard thing for most people to have done, but I figured I’d write a bit about binary serialization (recommended for use by Joe Stead) because it’s fun.

Binary serialization is essentially taking an object and dumping it into a file, without having to rebuild the object yourself when you come to reload it. So not only is the data saved line by line into the file, all the metadata Visual Studio knows about the object is also stored in there. Right now, my settings.txt file looks like this:

So essentially, to anyone reading it, it looks like gobbledigook. It’s best use is for when you’re not going to be looking at the file from outside the program, and you’re definitely not going to be editing it.

Originally, I looked at something called MessagePack which is a library meant to be faster than serialization and cross platform – however this is badly documented and there is very little support, so I gave up trying.

How mine now works is:

- Each “setting” has 2 objects – a data object, which gets serialized, and a drawing object, which does not. I found that with messagepack and I presume binary serialization there comes an issue when you try and serialize xna things such as rectangles, vectors, textures and spritefonts, so I split them into two. The objects are linked together by their name – such as Player name – which becomes the title and gets drawn next to the box.

- When the Settings class is instantiated, it attempts to load the setting data from the settings.txt file. If it doesn’t find the file, it creates a new one when the settings are saved, and takes our default setting from whatever you’ve told it.

- When the user goes to leave the settings page, the data all gets serialized to the file.

In practice, it’s reasonably simple to set up serialization.

First off, it’s important to label your objects as serializable, like so:

Whilst the objects within my data class don’t need to implement the ISerializable interface, I did still need to put [Serializable] before the class or the compiler complained at me.

To implement the ISerializable interface, I needed this method:

which controls what you want the program to serialize. I also created two constructors, one for serialization and one for default creation:

Finally, my save method:

which takes the current object and pushes it into the file, and my load method:

which is static as before the object is created we want it to be able to create itself by calling SettingsData.Load().

I’m not entirely sure whether it matters whether your data is public or private, but all that is contained within my two data classes are a title, current selected index and list of items within the OptionData class (for Music, Sound effects and volume boxes), and a title and entry within the NameData class (for Player name), all of which are public bad as it seems to me.

The libraries I used to do this were System.Runtime.Serialization.Formatters.Binary and System.Runtime.Serialization – I only needed to reference these from SettingsData and not from the classes within it.

Anyway I hope this provides a good overview of the syntax and stuffs required – I like this method as not only is it faster (I think), it means all my data is stored to one file and takes minimal lines of code to create.