Making a RTS game #30: Refactoring our save/load system with binary serialisation 1/2 (Unity/C#)

Let’s keep working on our RTS and refactor our serialisation process to better protect our data!

⬅️ Tutorial #29: Improving our players system| TOC | Tutorial #31: Refactoring our save/load system with binary serialisation 2/2 ➡️

📕 Get the ebook and bonus material on Gumroad!
🚀 Find the code of this tutorial series on my Github!

In a previous tutorial, we talked about saving and loading data from files on the disk. We prepared basic serialisers and deserialisers using the JSON format that rely on the JSONUtility built-in Unity package.

Today and in the next episode, we are going to refactor this system to use binary files rather than JSON to benefit from the advantages of binary serialisation!

Important note: doing binary serialisation has lots of advantages but it is also heavier for developers. To me, it was a good opportunity to talk about this technique and data-agnostic reflection-based code in C#. But, of course, to protect our data, we could also stick with JSON data and encrypt/decrypt it in various ways… ;)

Why use binary serialisation?

“Ok, what’s wrong with our current JSON serialisation technique?”

A while ago, we saw how to use JSON serialisation to save our game parameters assets in edit mode or during runtime. We created a JSONSerializableScriptableObject class for our game parameters class to inherit from.

However, the strength of JSON data is also its weakness: it is very easy to read and modify! So even though we’ve somewhat “hidden” our files using the Application.persistentDataPath built-in variable, a player who finds these files can still access them to change the parameters by hand.

For some of those, it’s ok: for example, the music volume or the key bindings. Basically, the variables that are exposed in our in-game settings panel could technically be updated in the JSON file, too, even if it’s not as handy for the users.