Checkpoint/Saving system


#1

Hello! Today, I’m not going to ask for help for any kind of errors. I’m thinking about how to develop a checkpoint system that allows the MC to get redirected back to the previous checkpoint if they die(With the stats they had previously). I’m thinking of games that had this kind of a system, but can’t really think of many, so I’ll just use the example of Sabres Of Infinity(Along with Guns of Infinity), I think Mecha Ace had a checkpoint system too, though, I might be mistaken. I’m looking for an easy to develop checkpoint system, because I know how hard it is go through a 100k+ word game if you die.
So, any help is appreciated!
Thank you in advance.
:smiley:


#2

Think about all the variables you have up until the checkpoint.
Save them.
Then you can reload if needed.

Example:
Let’s say you have 5 variables:

  • Strength
  • Intelligence
  • Agility
  • Charisma
  • Luck

So, why not save the strength variable in another one called strengthsave
Like this:

*set strengthsave strength

Then you repeat for your other variables.
If you want to load it, you just do it in reverse:

*set strength strengthsave

Hope this helps.


#3

Thanks for the suggestion, it’s a bit confusing, but I think I got the mechanics.
:smiley:
Edit: Interested in what others comment so I can see other methods as well.
Edit 2x: Come to think of it, that seems to be the easiest solution.


#4

If you’re thinking of checkpoints, you can autosave using CJW’s awesome plugin. You can code in checkpoints and the player can just load it up when they die.

If you are thinking of a save system to port the stats between WiP updates, I recently did up a PlayerCode system, you can check out my code on dashingdon!


#5

I’m afraid I don’t want the kind of a system you’re suggesting, the player code, I’m looking for an actual checkpoint system, thanks for the suggestion though.
Never heard of the plugin, could you link it? I also avoid using plugins, so, I hope it’s an easy-to-use one.
:smiley:


#6

Well, the simplest (most basic) solution is just as what @Carlos.R said:

  1. Create a “hub” scene where your player will go if their die. This scene will contain #Load_latest_checkpoint and #Restart options (or whatever you like)
  2. Make a copy of all of your *create variables
  3. Rename those copies as, for example, *create [var]save
  4. Each time player reach a checkpoint, save those [variables] into [var]save
  5. If the player dies and are sent to the “hub,” the #Load_checkpoint will load [variables] with [var]save

As for @nauhziy’s system, go to his WIP thread.
I personally shy away from it though. My brain can’t handle the enigma :laughing:


#7

Well, not really looking for what @nauhziy said. Just a simple checkpoint system. I got the point, I think, the variables just reverse.
:smiley:


#8

I think CJW’s save plugin will be much better for your purpose. Its super easy to use too.

Type this to initialise the plugin:
*sm_init mygame | 3

Then this when you want to do an autosave/checkpoint.
*sm_save 0 | false |

Then when you check the CJW save plugin on dashingdon when you upload your WiP. Thing is, it doesn’t work offline so like you need to comment it out during your tests.

What @Szaal said works too!


#9

Psst. It actually does work offline.
But you’ll have to edit your index.html and paste additional files to make it work, though, which can be daunting for coding-newbie. :frowning::raised_back_of_hand:t4:

The file can be found at a link around this thread.


#10

DID YOU JUST ASSUME MY CODING LEVEL?!!
:smiley:
TRIGGERED!


#11

I’ll stick with the basic checkpoint system because I didn’t fully understand how to use the plugin.
:smiley:


#12

I created a checkpoint save for tokyo wizard, as described above (basically saving all variables…). It takes some effort if you have lots of variables, but def posible


#13

Likewise, I had created my own checkpoint save system for Monsters, though I am rotating that out in favor of CJW’s plugin. Benefits for each, as I see them: Checkpoint: Keeps players from save-scumming if that matters in the game, makes for potentially more ‘weight’ to choices. CJW plugin: Allows saving at any time, much easier than creating one’s own if there are many variables in a game.


#14

Also, Hosted Games can be published with checkpoint systems, but not with @CJW’s save plugin, correct? So that might be something to consider.

@N1GHTMAR3 If you’re hosting on Dashingdon, then @Dashingdon’s set up the website so that all you have to do is click the box that says ‘enable CJW’s save plugin’ on the ‘Edit Game Details’ page, like so:

Then put *sm_init mygame | 3 (or however many save slots you want) at the end of your *creates in startup.txt. I usually just *comment that line out when I’m playtesting or using Quicktest and Randomtest, or it causes an error. Then I unhide it when I upload my files.

This will allow players to save anywhere, not just at checkpoints. That might be helpful for regular testers anyway, since they often play through the same sections a number of times to get to new content.


#15

Fiogan makes a point.

I suppose there’s always the option of doing both. Weird as that sounds, I think it would gain the benefits of both, during the WIP stage. Allowing testers to find route-oriented bugs easier, and not needing to replay segments so many times. While also allowing the custom system to be tested.


#16

I think that in the line *sm_init mygame | 3 the ‘mygame’ parameter should be changed to a suitable (hopefully unique) name for your game so that it does not conflict with other in-browser saves for other games. Also (as @Fiogan mentioned) the ‘3’ can be changed to however many save slots you would like to be available for the reader/player, but in most cases 3 slots is sufficient.


#17

Correct, definitely don’t leave it as ‘mygame’! Try and make this as unique as possible.


#18

Does “kljdvbaewiuh” unique enough?


#19

What I would do is isolate the checkpoint through the part where the player is no longer at a risk of dying into one chapter.
ie. (chapter start) *label checkpoint
… … …
(chapter end) *finish

make a *temp variable for every variable that can be changed in the chapter (ie if only the player’s health and ammo and speed stats are changed, then you would create 3 temps, one for each)
Then you set the temps to the variables at the start and if the player dies, goto the beginning, replace the real variables with the temp ones, and start again.

This is how you would label it:
*temp ammotemp ammo
*temp healthtemp health
*temp speedtemp speed
*label checkpoint
*set ammo ammotemp
*set health healthtemp
*set speed speed temp
[put chapter here]
*finish
(when the chapter is finished the player should be safe and move on to either another checkpoint or whatever.)

Edit: If you are going to have several checkpoints and possible deaths, you could use normal variables instead of temp.


#20

Hmm, thanks for the suggestion!
Though, I think I won’t be using that, thank you, still.
:smiley: