As our game starts to grow bigger and bigger we started to notice that we needed to have some form of save / load system, as well as a way to jump to a level that the player desires. So to do this I was tasked at creating a Checkpoint system. When planning out this system I wanted it to be a simple for our design team to use as possible, to do this I decided that if possible just allowing them to drop the Checkpoints into the scene and assigning a position for the two players to spawn at would be the easiest to implement.
To do this, I would need to make the system as simple as possible but be flexible enough that the designers could do what they needed. First the prefab itself, all it is is a trigger and two empty game objects to represent points in space, these two empty game objects will be the spawn point of both players (allowing the designers to have a visual reference of where they will be) and the trigger is what will set the player’s spawn point to the current one.
The checkpoints work quite simply, when a checkpoint is triggered the checkpoint will record it’s name into playerprefs, then when the game loads (on start for the scene) it will find and move both player’s to the correct spaces on the spawn point based on the name saved in playerprefs. This allows the game to be loaded simply without any major new architectural changes to the game.
There are however some issues with this method, firstly name matters a lot. Since the name is the only thing that is recorded externally, the naming convention of this needs to be distinguished enough to not have issues. Secondly, it doesn’t take into account any previously triggered events or inventory. However due to the layout of the game this isn’t a needed aspect, checkpoints are going to be at the beginning of puzzles where previous keys aren’t needed, and events gets wiped, making recording these aspects worthless. However, if we decided that we want a puzzle that takes advantage of either of these things the architecture for the checkpoint system allows for the easy expansion of the system, enabling further use of the previous code.
This also doubles as a level select system for the game, as all we need to do is assign the name of the gameobject to player prefs in the menu when a level is selected, and it takes care of the rest automatically.
I’m generally pretty proud of this system, it’s simple to use, dynamic, and set up easily enough that expansion is possible if need be! Hopefully it comes in use and no bugs come out of it, but if they do I feel fully confident in my abilities to fix them!