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 are 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
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 and debug and modify it by himself.
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 on the disk.
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()).
So that the Checkpoints that were reached before now also fire off their UnityEvent when the level was loaded.
Thank you for your interest, let me know what you thought or if you have any questions
Thanks for the idea! I was having a hard time thinking about how to save object states throughout a scene where it will only save objects that were interacted on. I used a traditional saving system where I serialized the whole class and saving some variables.
This reminded me that I can just save some checkpoints and compare the combination of reached ID's and then make a scene load in a certain way.