I came across @Sashira’s post about a checkpoint save system, detailed here. (I didn’t want to revive the thread since it doesn’t seem like @Sashira has been on here for a long time.)
I’ll copy-and-paste the instructions here:
Make a scene. I called mine save_states. Find every variable that could possibly change over the course of the game, and make two lists of them. One will be used for saving, one for loading.
Go to startup. *create a saved_variable for every variable (e.g. if a variable is strength, create saved_strength.) Keep all of these together so you can delete them when they’re no longer needed (when you’re stripping the temporary save states back out before COG adds the official system.)
Under a label save_these_stats, paste a set command in front of each variable. Then add the matching saved_variable to each line. It will look like: *set saved_strength strength
Under a label load_these_stats, do the same thing but in the reverse order. Like so: *set strength saved_strength
You can use gosub_scene to save, so add a *return at the end of save_these_stats. The full command to get there would be: gosub_scene save_states save_these_stats
Using a gosub rather than a goto for loading can mess up your options; any options that were greyed out after being chosen will still be unavailable, if you’re reloading within the same scene. So instead, set a variable called checkpoint. Name each checkpoint.
Use goto load_these_stats to load, then depending on the name of the checkpoint, use a goto to send the player to the right scene and label.
I follow everything up to step 6, but for the life of me I am not understanding the checkpoint thing. (I feel like I’m just being dense, but knowing that doesn’t help.) Can anyone help me make heads or tails of this? How does this checkpoint system work? Do you create variables called checkpoint1, checkpoint2 in the startup file, or are they labels in the game itself? How does this system even allow for saving more than once in a way that won’t get overwritten?
Edit: duh, never mind. This is for a temporary save state system, not a checkpoint save system! Then… how would a checkpoint save system like this work?..
Make a second variable for your stats, like strength would have a s_strength accompanying it, or something similar, at the checkpoint, save set your s stats to the same value as your normal stats. That’s your saved information.
When your want to activate the save, simply being the player back to the label it was saved, and set the normal stats to the same value add the s stats.
It’s… Not much different from sashira’s, really
Not sure if they answered your question, and i know a couple more types of saving methods, but… Mobile…
Don’t forget to save initial values of all the variables you haven’t used yet so you don’t have to worry about them maybe being set to a value from a branch the player didn’t take.
Actually, I believe most saving is the same, just creating duplicate variables to call back when you need them.
It all depends on where you can save, where you can load, automatic? At the end of the chapter? You can also have multiple save slots by making another set of duplicates.
Sorry, trying to wrap my head around it! So to clarify, say at the end of each chapter, I want to save.
Blah, blah, fade to black.
You have reached the end of Chapter 1. Would you like to save now?
*choice
#Yes.
*goto save1
*label save1
*set save_strength strength
*set save_courage courage
etc.
*goto nextchapter
So I get that part… but when you want to load, how does it work/how do you activate that?
For some reason this part confuses me! Sorry for being dense!
Do you put that at the beginning of the chapter where you want to load, or where you put the save point with the relevant save?
Ah, okay, I think I see:
Blah, blah, fade to black.
You have reached the end of Chapter 1. Would you like to save now?
*choice
#Yes.
*goto save1
*label save1
*set save_strength strength
*set save_courage courage
etc.
*goto chapter2
*label load1
*set strength save_strength
*set courage save_courage
*goto chapter1
And so when you want to load chapter 1, you do *goto chapter1 load1?
But how does it remember all the variables from save1 only, instead of say, save5 down the road?
It can be basically anywhere as long as it lets you access those variables since it’s wholly self-contained; just put it somewhere you can find it easily.
If you want to have multiple saves accessible at once rather than just loading the start of the chapter, you need one of these sets of variables per save you maintain at once and a conditional to go to the label you want.
Ah, okay, this was what wasn’t making sense to me! So you would need save_strength2, save_strength3 at each separate “save point” you would want to implement! Then when it says, “Would you like to load a chapter?”
If you have one save total you can just repeat the sets each chapter with different labels before and after and have one save variable per regular variable. If you want multiple saves but less than one per chapter you can have one set of variables per save by doing something complicated to ensure each save point is associated with a particular set and only one avaliable load option points to a given set at a time, but just having one set per chapter and limiting which chapters you can load from is usually easier to write, unless you keep adding variables. Extra sets waste memory, but unless you have a ridiculously excessive number of save points like five hundred or something no one will ever notice. Don’t worry about it unless you want to do a rolling save like if you’re doing a time travel story and want to let the player go back 2-3 choices at will.
Don´t want to interrupt, but in the load section, the goto should also refer to chapter 2, shouldn´t it? otherwise you would plkay chapter 1 again with the variables from the end of one, or am I thinking wrong?
So… you’re trying to make a choice to save at the end of every chapter, and the option to load saves at the same time? If so, I think, yeah, you’re doing it right.
Except now you’ll have as many duplicates of stats and chapters XD
That’s an issue but I would advise not worrying about it; if there were a serious memory constraint I could potentially advise on complex ways to cut it down but it’s more important to be easy to read in this instance.
Just be careful if you add a new variable; it’ll be easy to forget to add it to one of the save/load options.
Yes, that’s why I figured I should just implement it all at the end so I’m not constantly updating the save states to include new variables, haha! I just wanted to get the skeleton/logic down before I forgot. Thanks for all of your help! It is a little bit of a pain in the ass, lol.
Yes, that was what I was trying to do! However, I realized the exact same thing you just said, so now I’m just going to do three major checkpoints, Choice of Rebels-style. XD I understand the pain now…
I would recommend just having a save per chapter and writing them all at the end. I’m 100% certain there’s an objectively better way from a code perspective but I don’t think the negative impacts aside from the difficulty of adding new variables will matter. And the alternatives would be more complicated to write.
I think if someone has to ask how to use *gosub to do this then the benefits aren’t going to be worth the difficulty in figuring it out; it’d save maybe 200 KB tops(if you’re really unlucky and it’s arranged very badly at runtime1) and on a vaguely modern anything that’s so small you will never notice. The code quality benefit is you can change more than one save’s variables at once but it’s also harder to find the piece of code used by a given save, so if there aren’t going to be any new variables there’s not much upside. I might do it if coding myself but even that would just be to maintain the habit for other situations.
1.the decisions are going to be made automatically by various layers of programs; it is definitely not worth trying to change the decisions to be better for the same data. The decision-making process works the way it does for sound reasons and it’s basically going to be impossible to get it to always work better on every computer.
Sorry for being dense!
Thanks for all of your help! It is a little bit of a pain in the ass, lol.