Member-only story
Making a RTS game #31: Refactoring our save/load system with binary serialisation 2/2 (Unity/C#)
Let’s keep working on our RTS and refactor our serialisation process to better protect our data!
⬅️ Tutorial #30: Refactoring our save/load system with binary serialisation 1/2| TOC | Tutorial #32: Creating a debug console ➡️
📕 Get the ebook and bonus material on Gumroad!
🚀 Find the code of this tutorial series on my Github!
Last time, we talked about using binary serialisation for our load/save process. We saw the advantages of binary data over JSON in terms of security, and we saw how to apply this type of serialisation to basic data. We also discussed how reflection is a powerful tool that we can use to automate data extraction and make our methods more agnostic of the objects being handled.
Today, it’s time to actually apply all of this to our RTS and… there are yet a bit more surprises in store! ;)
2 important notes:
- throughout this tutorial, we will be touching and modifying our game parameters assets. Depending on when you run your game, this data might be invalid for a while, until we fix it later on in the tutorial. So if you have some settings you’d like to keep, make sure to back them up before hand, or wait for the end of the tutorial before running your game!
- to test the load/save process in the editor, you might need to deactivate the preprocessor check we added a while ago to prevent serialisation from the Unity editor:
Using binary serialisation for our game parameters
Now that we’re finished with our tests, we can clean up our GameManager Awake() method and remove all the code that is related to our TestScriptableObject object (plus the public slot). So we'll go back to our plain old Awake():
