Building a save system for level objects in Unity Pt1 - Checkpoints

posted in Christin Kalina

Published January 31, 2019

Gameplay C# Unity

Building a save system for level objects in Unity Pt1 - Checkpoints

As the player moves along in a game and interacts with different objects in the world, the aim is to reflect his actions in the game by changing the state of objects permanently. For example, a door is opened or some first experience guidance does not need to be displayed anymore.

Objectives

Save and restore states of objects in the scene according to the progress of the player.
These objects may bE interconnected. (A door opens when pulling a level/ defeating an enemy)
Let level design decide and modify which objects need to have their state changed when.

Used programming concepts

Enum https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/enum
Monobehavior https://docs.unity3d.com/ScriptReference/MonoBehaviour.html
UnityEvent https://docs.unity3d.com/ScriptReference/Events.UnityEvent.html
JSON serialization https://unity3d.com/learn/tutorials/topics/scripting/loading-game-data-json

Checkpoints

Step 1 - Checkpoints

First, we need something that defines what a state change in the game is and when it happens. Let's call this a Checkpoint. When the player does an action to activate the checkpoint let's call that reached the checkpoint.

This checkpoint needs an ID to be identifiable for saving and restoring.
This checkpoint also needs something that can be fired off when the checkpoint was reached.

In my case, for the ID, I created an enum because its nicely readable in the inspector. On top of being readable by humans it also is robust against typos and other string mischief.

For firing off the state changes, I picked UnityEvents which have the advantage that your level designer can put anything in there by himself (fe changing the activation status of a GameObject, changing a material or calling a public method in a MonoBehavior) .

Step 2 - Reaching Checkpoints

So, we have a MonoBehavior called Checkpoint, that has an ID and a UnityEvent. Now, you can attach this to any gameObject in your scene. What will happen? Nothing, because we are not reaching the Checkpoint yet.

To reach the Checkpoint, we add a public method that calls the UnityEvent. Now we can call this function from anywhere in the code or from another UnityEvent.

Step 3 - CheckpointController

Great! But wait, when I restart the scene it does not remember that I reached the Checkpoint.

To save and restore the state of the Checkpoint I created a CheckpointController that knows

all the checkpoints in the scene and
who to talk to make the state persistent.

For the first part, I created a function that registers the Checkpoint in the CheckpointController. This can be called in Awake(), for example. Now this controller can store all the Checkpoint GameObjects in the current scene.

For the second part, I let the Checkpoint inform the CheckpointController when a it was reached. The controller that is hooked up to any kind of saving like a JSON file reader/writer can then write the ID of the Checkpoint that was reached to the disk. On top of saving, I also inform all the Checkpoints with the ID that was just reached to fire off their UnityEvent. This way, I do not need to fire off the UnityEvent on the individual Checkpoint anymore but let it backfire through the CheckpointController .

Great success!

Now, when Unity starts a new game, the CheckpointController needs to receive the persisted list of Checkpoint IDs that where reached before. When the scene has loaded successfully, it will notify all Checkpoints that have the IDs that were saved before. (Remember that the Checkpoints register themselves to the CheckpointController on their Awake()).