 If your game is made to be played throughout many play sessions or throughout long play sessions, maintaining players' progress is fundamental, and for that, we have the Checkpoint 2Ds, which is one of the recipes that is all about maintaining players' progress. The Checkpoint 2D is one of the recipes in the Platform Essentials Cookbook, alongside with 11 other design patterns, which I call them just recipes. So if you don't know the Platform Essentials Cookbook project yet, I put it in the description so you can grab your copy. The project just got a wall-jumping character to the recipe, which is all about, well, wall-jumping, right? And it's honestly, guys, not humbly, one of the best implementations of wall-jumping that you see around in the good city, good town. But going back to the Checkpoint 2D recipe, basically, I think that you all know what is the checkpoint is one area which can be explicitly or implicitly visually expressed in your game. So there may be an area in the level that once you touch it, the character will interact with this area, and it will save the player's progress in this specific level. You can find this kind of mechanism throughout many classic and modern platformer games. So, for instance, I don't know if you played it, I don't know if you liked it, I personally love this game. Might number 9, which reference games are, of course, Rockman and Mega Man X series. When you are about to face a big platformer puzzle, a challenge, or if you are about to face a boss, so right when you are about to enter the boss pit, there is an invisible area that once you cross it, it will save itself as your next spawn point. So, if you die, as long as you have enough lives, you can die and go back to this point in the level instead of starting the level all over. But there are also instances of this mechanism that are visible to the player to interact, and they can decide if they want to actually save this point as the spawn point. So, for instance, on Super Mario Road, a classic platformer game, there are those candy bars that once you interact with them, they will save the next checkpoint of Mario. So, if Mario dies, he will come back to this specific point in the level. But they can also become a mechanic in the game. So, for instance, on Ori and the Blind Forest, we have to Soul Charge, I don't remember the actual name of this mechanic, where you can charge the energy of Ori, and you will create a save point that you can also use to increase your skills and update your skill tree. But they will also become a checkpoint. So, if you die, you can go back to this specific point in the level. So, players can trade energy, I think there is energy on Ori, the resource that they use to create those save points. So, checkpoints are great to save players progress, especially if you give them the ability to choose if they want to or not to save this point as the next spawn point. So, let's see how we can actually make and use the checkpoint recipe today. So, here I have our project, which I already made a checkpoint level, so we can just straight up see how this recipe works. But before we dive into the recipe and all of that, I want to show you the new and improved asset importing workflow. So, they made a very good live quality of life improvement here. If you go to asset library, import and choose the platform essentials assets, now we can actually change the install folder. And I will choose the recipes folder here, select, we can tell it to ignore the assets route. And I will basically, I just want the, yeah, I just want the checkpoint here, this one. But you can see that I can choose it because I already have it important in my particular project. But if you don't, you can select this folder and hit the install button and it will install all of the recipes in your project. So, back to the project, let's see how this recipe actually works. So, I will play the scene and you can see that I start on the beginning of the level. And if I die, so I think that I can die here, one, two, three, I will go back to the starting of the level, right? But if I go to, if I cross this part here, I will actually hit a invisible checkpoint. So, I'll cross it and I will die on these bombs. And you can see that now I spawn right before the bombs. And even if I go back here to this, to this enemy, I will die and I will go back to this small point as well. But we can actually change that. So, for instance, if I go to the beginning of the level, I am technically interacting with a checkpoint to the and die, I will actually go back to the spawn point right before the bombs. See? But we can change that by taking off the incremental option here. So, I will save the scene. I will interact with the level beginning checkpoint and I will die to this crate big here. One, two, three. See? Now we start from the beginning of the level. And this is all because when we took on the incremental option, they will, the checkpoint will only override the previous checkpoint if the next checkpoint index is greater than the current one. And we all, and we manage that through the scene tree itself. So, I will do this, I will close that. And you can see that there are three checkpoints here. So, zero, one, two. If I cross, if I interact with the third one, I won't be able, if the interactive, the incremental option is to go on, I won't be able to save the next, I won't be able to override the checkpoints before it. But if I have it to go off, I can basically interact with checkpoints and I will always go back to the latest, to the one that I interact with the most recent. Okay? On the other hand, if I have the incremental to go on, I will be able to save the checkpoint closest to the level's goal, ideally, but basically just managing the indexing here. So, let's see what this recipe is all about, actually. So, I'll open the script here. And you can see that it has, it exports a checkpoint data, which is a resource. Let's see what this resource does. So, checkpoint data, it basically just saves the index of the current checkpoint. And this is important because if you go to the checkpoint again, you can see that when we save the checkpoint data, we take a user file path. I made this because if you want to have different checkpoints for each level, you can actually change the path right here. So, in this case, I have the user checkpoint level, which is this current level, slash checkpoint data. So, it will be saved under the checkpoint level folder. Let's see that project open user data. We have here the checkpoint level. And here we have the checkpoint data resource. And when it loads, it will see if it's persistent or not. And if it is persistent, it will load it from this particular data path. Otherwise, it will just override it with the default one, which can be indexing, we can point to the checkpoint of index zero. But the most important part here is that we have this move to checkpoint method, which will basically teleport the object to the child with the point indexing here. So, I get the index of the child, it will load this from the checkpoint data. So, it can be the default checkpoint data or the current levels checkpoint data. And when we load it, it will get the file access and check for this data path. If it doesn't have currently if there is no resource on this particular data path, if this data path doesn't exist, so if the file exists, it will basically create it and save the checkpoint. So, for saving the checkpoint, you go to the resource saver and we save it the checkpoint data using the user file path that we have right here. And we basically just connect the children because you can see that the checkpoint is basically an abstract node 2D that has some interactive area to these as these children. These areas today, these interactive areas today is what will actually communicate with the checkpoint 2D to override the current index of the checkpoints. And basically that is what the checkpoint 2D recipe is all about. And basically to use it, we just have to go to the topmost node of the scene, in my case, the level. And we just have to tell it to the checkpoint to move to teleport the object, in this case, the player to the current checkpoint using the checkpoint move to checkpoint method. And also when my player die, I actually tell it to reload the current scene. Right? So, this is how we can make a checkpoint. And basically this is how you can actually save resources on your player's user folder as well. So, there are a lot of knowledge packed in this recipe. So, what can lead us to use the checkpoint 2D recipe as a design decision for our game? Well, failure can be very frustrating for many players, especially if they don't feel like failing is actually progressing them through your game. So, if they feel like that every time they fail, they have to come right from the starting of the level and play everything that they already learned how to overcome, they will feel that failing is actually punishing them, instead of basically just saying, hey, you need to learn how to overcome this specific challenge, because the other ones that you face and you overcome are already saved. Your progress, the progress that you did on them is saved. You don't have to face them already. We are presuming that you already learned how to overcome this kind of challenge. So, we can lighten the player's cognitive load, because we can basically cut our level into many sessions and allow players to basically focus on each section at a time to overcome each section challenge, instead of overcome the whole level all again, even though they already know how to overcome the level's challenge. But on the other hand, checkpoints can serve as a exit gate for players. Let's say they are stretched out by your game, they feel that they are not making progress, learning how to overcome new challenges, and they just need to take some distance from your game for some brief time. You can basically save their progress and they can come back to your game, refresh anew, ready to invest more time in your game. This is all about being forgiving with your player and allow them to invest the time that they need to finish your game and to actually interact and engage in your game. They don't have to be concerned about losing progress, about losing data, about not overcoming new challenges, about cognitive loads. They can basically just think that we are taking care of them, we are being good designers with them and they can take their space from our game and come back when they feel so. Well, now from an engineering point of view, why would you use this specific approach to implement a checkpoint? Well, with this approach, we rely as much as we can on growth building features, such as the resource system, the resource class, the resource saver and the resource loaders singletos, which can parse data in and out very quickly into a human-readable way. And if you don't want this on your final release, which is completely understandable because players will be able to change the checkpoint if they open this file, you can use some cryptography to encrypt your file, your saved files and allow only the system, the game to open and save this on the player's machine. Hey there, Enrique from the future here. I forgot to also mention that on top of this part where we are relying on the building growth resource managing classes, so the resource saver and the resource loader, we are also relying on growth singleto restructure to manage the indexing of the checkpoint. So based on the child indexing, so the first checkpoint will be index zero, the second checkpoint will be index one and so on and so forth. We can manage how far away or how close the player is to the goal of the level. So we are also relying on that to manage the checkpoint system. So this is also another engineering advantage of this approach. And with this, since we are using resources, we'll always have a reference to this checkpoint resource. If we need to reload the path, if we need to reload the level, sorry, we won't lose this specific resource from memory. So we can keep on reloading the scene knowing that the player's progress won't be lost between these reloads, which if you don't have this kind of mechanism, you can rest assured that players will lost data when you change levels or when you reload a level. But using this approach, we can maintain the player's progress throughout this reloading and scene changing processes. So as I say, the checkpoint today is one of the 12 main recipes from the Platform Essentials cookbook, which just got an extra recipe update, which is all about wall jumping, making it so that we now have 13 recipes in total. So 2012 from the main cookbook and one now from the extra recipes. So if I was you, if I were you, if I was you, if I were you, if I was you, I will grab my copy before the price bump. So go to pickdev.each.io slash platformer.essentials and grab your copy before the price bump, guys. But for now, that's it. Thank you so much for watching. Keep developing and until the next time. See you there.