Upcoming ChoiceScript Feature: Checkpoints

[Jacic]

I must admit, I’m looking forward to a feature like this. My only concern is I know with some of my own games, save points will lock players out of branches/choices due to delayed stats (for example choices you made in a earlier chapter lock off a path or open a new one up) or due to accumulated stats. Is there any way to potentially flag there is a issue with using the save point or would you have to write it up under spoilers in the stats menu or a the start of the game?

I do worry that this will enforce that failing something = bad outcome and restart. I try to write storylines that can actually sometimes have the potential for better outcomes or at least storylines that are satisfying even if you “make the wrong choice” but on the other hand maybe it will encourage replayability as at the moment it seems like a large proportion of the audience doesn’t replay many of the games at present. The really long games in particular need a checkpoint somewhere for QOL sometimes I think particularly if they’re relatively linear, the shorter ones not always.

@Eiwynn

I understand “making choices matter” but this is punishing people for wanting to experience alternate routes and other choices without needing to restart an entire game and speed-running through an entire chunk of the game to do this.

Yeah not sure I’m a fan except under perhaps some specific storyline purposes. I’m actually going the other way with a reset point on the game I’m currently working on to give the player the option to make it easier to get the outcome they’ve decided they want to make it less annoying to replay over and over given there’s an amount of RNG in that section and different paths lead from if you pass/fail. I don’t think that’s always necessary either for most games but I can’t think of many circumstances where restoring a checkpoint should be limited as it’ll just lead to frustration (especially if there are locking issues like I mentioned above- run out of restarts, replay all the way through again and still get locked out of choices).

@dfabulich

(Is this the right thing to do? I think the only alternative would be to restart the game completely. Would that be better?)

I don’t think it should restart without a warning. IMO either error with an explanation it cannot be used yet as you haven’t reached the first checkpoint, or throw up a message that there are no save points and proceeding will restart the game. Proceed? Y/N

Just out of interest, will there be and option for multiple check points or the option to save or not save at a checkpoint? Or does it auto save as you pass through checkpoints in the game. Edit- I miss read that, looks like you can make the checkpoints? I’ll have to play around with it when I’m home.

[HarrisPS]

@Jacic

I don’t think it should restart without a warning. IMO either error with an explanation it cannot be used yet as you haven’t reached the first checkpoint, or throw up a message that there are no save points and proceeding will restart the game. Proceed? Y/N

I said earlier that I like the game restarting “silently” but I like this and what @cup_half_empty says above better - I could imagine a player getting confused about going all the way back to the beginning if they misunderstood and thought they had gone through a checkpoint already, or something. I had interpreted “fail with an error” as displaying the same message you get when there’s a game-breaking bug, where you then have to restart the game anyway; but I think I may be wrong - either way I think what you describe is a good idea.

[Eiwynn]

The “error” could be both facing out and under the hood.

I think having both a Quicktest warning as I proposed upthread and @Jacic’s prompt would be ideal. It does not, nor should it, have to be either or here.

[MoonlightBomber]

Alright, that’s what I need in my upcoming game, since it has 20 chapters and is of an episodic nature.

[Sailingshells]

This is very cool I’d love to include something like this in the game I’m writing - thanks for developing it!

@dfabulich

startup line 48: Invalid *restore_checkpoint; we haven’t saved a checkpoint

(Is this the right thing to do? I think the only alternative would be to restart the game completely. Would that be better?)

I’m pro ‘catching errors before they go live’ personally, so I like the “Invalid” error, assuming something like quicktest would catch it. I can’t imagine trying to deal with how annoyed a player would be at me if their game reset on them

@dfabulich

When you use *save_checkpoint or *restore_checkpoint, you can specify the name of a checkpoint “slot.”

I’m particularly excited about this feature I like how simple you’ve made it to code.

One random other note: I enjoy the freedom this gives for both the user to specify they’d like to save a checkpoint, as well as for the coder to just auto-save without asking. Personally I think I’d be doing the latter, rather than giving the play the option, and then offering a page in my choicescript_stats for users to view the list of checkpoints and load one of them at will. But I think it’s nifty that for games with hard/easy modes the writer could offer a more “fail once and it’s over” experience for players.

[Nocturnal_Stillness]

@Eiwynn

Even if a game had checkpoints, if the author punished me, the reader, for using an offered feature, I’d be angry and resentful.

Would you consider tracking it and linking it to achievements a punishment?

For example not restoring a checkpoint and finishing the game unlocked the achievement “I’d never change a thing”

But restoring a lot and finishing the game unlocks the achievement “Groundhog Day”

---

I’m curious about using a restore checkpoint system to have a sort of déjà vue thing where the protagonist sort of remembers what happened previously.

For example let’s say they go through the left door and get shot so the player restores a checkpoint then when they reach that choice there is a bit of additional text saying something like “you consider both doors but you feel like you should pick the right door”

[Eiwynn]

@Nocturnal_Stillness

For example not restoring a checkpoint and finishing the game unlocked the achievement “I’d never change a thing”

No, i would consider awarding an achievement to be a legit reward, and a way to encourage cheevios to replay the game

@Nocturnal_Stillness

For example let’s say they go through the left door and get shot so the player restores a checkpoint then when they reach that choice there is a bit of additional text saying something like “you consider both doors but you feel like you should pick the right door”

Tin Star does something like this, with the Sheriff’s legend changing as you use checkpoints.

[Unregistered]

Okay, before I start digging through gobs of code, I’ve got a couple questions.

1 - Is there a limit to how many checkpoint slots can be created?

2 - These different slots will persist for good even if the game gets closed/reloaded/etc (until it gets overwritten in the next playthrough)?

3 - Can the Stats Screen be used to restore to multiple checkpoint slots? (Right now, it just says that the last checkpoint can be restored from there) I.e. something akin to…

• Restore to Chapter 1
• Restore to Chapter 2
• Restore to Chapter 3

Right now I’m using the old checkpoint code from here (which doesn’t require creating a new variable for every variable saved in the checkpoint like other systems) to do the above, but the big problem with that system is that the code starts slowing down a lot when you try to restore 100+ variables.

Regarding the player trying to restore before the first checkpoint (assuming that the author didn’t gray out that option themselves), I’d go with the warning message that’s been suggested about how the game will restart from the beginning, please confirm, yes/no.

[dfabulich]

@Jacic

or throw up a message that there are no save points and proceeding will restart the game. Proceed? Y/N

The problem with prompting the player whether to restart from the beginning is: what are we supposed to do if the player says “no, I don’t want to restart?” I don’t see what to do if the player just decides to cancel restoring the checkpoint.

For example, suppose you wrote this:

[startup.txt]
1: *scene_list
2:    startup
3:    chapter2
4: *create leadership 50
5: *create strength 50
6: 
7: Here's the first chapter.
8: *gosub thingy 
9: 
10: *choice
11:     #Continue to the next chapter.
12:         *finish
13:     #Restore to the previous checkpoint.
14:        *restore_checkpoint
15: *label thingy
16: Here's a little thingy!
17: *return

This game never mentions *save_checkpoint. Now imagine the player tries to *restore_checkpoint, and we pop up a little prompt, “Start over from the beginning? Are you sure?” and the player says “No.”

So, we’re left off where we were, at line 14. What now? The player just said that they don’t want to restart from scratch. But we can’t just continue on to line 15; that’s the thingy subroutine. That code is only supposed to be reached via the *gosub on line 8.

The whole point of the *choice at line 10 is that you’re either going to *finish or you’re going to rewind time, so there was no need to handle the case where you do neither. If *restore_checkpoint can be canceled, then we’d need the author to do something to tell us what should happen if you cancel.

Maybe we could require authors to type this:

*label chapterend
*choice
    #Continue to the next chapter.
        *finish
    #Restore to the previous checkpoint.
        *restore_checkpoint cancel=chapterend

That would say “if the user decides not to restore checkpoint, then *goto chapterend.”

But that makes *restore_checkpoint more annoying for everyone, just so we could more smoothly handle the case where the author forgot to type *save_checkpoint.

I currently think it’s clearer for everyone if *restore_checkpoint just fails like *bug if you forgot to *save_checkpoint. QT can catch it. RT can catch it. We won’t ship a game to CoG or HG unless QT and RT pass.

Alternately, as Dvalor53 suggests:

@Dvalor53

My logic is this: Starting the game is the first checkpoint.

That’s a totally reasonable approach, and it’s really easy to make it so, just for you: just put *save_checkpoint at the start of your game.

Then, if you want to ask an “are you sure?” question, you can do it yourself.

*create leadership 50
*save_checkpoint

...

*choice
    #Continue to the next chapter.
        *finish
    #Restart the game.
        Start over from the beginning? Are you sure?
        *choice
            #Restart the game.
                *restore_checkpoint
            #Continue to the next chapter.
                *finish

[Natman1025]

Oh my God it’s finally happening

[dfabulich]

@Unregistered

1 - Is there a limit to how many checkpoint slots can be created?

Not that I’ve set, but I believe there’s a practical limit in terms of running out of how much disk space the user is allowed to save in their browser. It’s… really big, though.

It would surprise me if any game needs more than a couple of dozen checkpoints per playthrough, and that’d be fine.

3 - Can the Stats Screen be used to restore to multiple checkpoint slots?

Yes, like this:

[chapter1.txt]
*save_checkpoint chapter1

[chapter2.txt]
*save_checkpoint chapter2

[chapter3.txt]
*save_checkpoint chapter3

[choicescript_stats.txt]
*stat_chart
   ...

*choice
    #Return to the game.
        *finish
    *if (choice_saved_checkpoint_chapter1) #Restore to Chapter 1.
        *restore_checkpoint chapter1
    *if (choice_saved_checkpoint_chapter2) #Restore to Chapter 2.
        *restore_checkpoint chapter2
    *if (choice_saved_checkpoint_chapter3) #Restore to Chapter 3.
        *restore_checkpoint chapter3

2 - These different slots will persist for good even if the game gets closed/reloaded/etc (until it gets overwritten in the next playthrough)?

It’s not totally clear what you mean by “reloaded.” If you just refresh your browser, or close the tab and come back to the game later, the game will resume right where you left off, with all of your stats and checkpoints still there.

But if you click “Restart” and restart the game, that will wipe all of your progress, including erasing the checkpoints.

If you want a saved game that can survive restarts, that really persists forever, you’ll presumably need to use our *save_game system, but that only works on choiceofgames.com, because you login with an email address and save the game on our servers.

[AletheiaKnights]

@Nocturnal_Stillness

For example not restoring a checkpoint and finishing the game unlocked the achievement “I’d never change a thing”

But restoring a lot and finishing the game unlocks the achievement “Groundhog Day”

I love this idea!

[Unregistered]

Thanks for answering! Yeah, for that last question I basically meant if the checkpoints would survive through a Restart back to the starting screen. In that case, I’ll probably just put up a warning on the Checkpoint page that they’ll be wiped out if the player Restarts from the very beginning.

[JimD]

@dfabulich

Do you think *restore_checkpoint should fail with an error when you haven’t reached a checkpoint yet? Or should it just restart the game from scratch?

First off, thank you for implementing this. It is the number one feature people request.

I agree with everyone who has said there should be an error that pops up in QT and RT. However, I would rather this not crash the game and send someone forward.

In the case below, if the restore option is selected, but there is no checkpoint saved, I would rather continue the player to the next chapter with a message that no checkpoint has been saved.

#Continue to the next chapter.
  *finish
#Restore to the previous checkpoint.
  *restore_checkpoint cancel=chapterend

Otherwise, some game could potentially get released (if QT and RT did not catch this error), and you will just have a lot of upset players submitting support tickets or writing angry reviews that their game crashed due to a bug.

[Big_fan1231]

Glad that this was implemented. Now we can finally stop begging COG for a save system as this is a really good compromise. How soon can we see a game using this by your estimate?

[expectedoperator]

This is awesome!!! My WIP has a checkpoint system, but I’ve had trouble with it because I always forget to add the variables to that scene. It really was so tedious and stopped the flow of writing, and I’m so happy I don’t have to spend time adjusting it anymore!

If I’m understanding this correctly, then I think being able to restore a checkpoint without a save should fail QT and RT and bring up a error, because the option shouldn’t even be available to the player. I would consider it game-breaking if I was given that option and it brought me back to the start without any warning. It’d be like a save file glitching in any other game.

I do sort of like the idea of the game still moving forward if there’s no save, but even then I’d want a warning – and if there’s a warning, why couldn’t the writer just adjust the options so I’m not wondering if I have a previous save I forgot about, or have me waste my time picking that option, etc.

[dfabulich]

*label chapterend
#Continue to the next chapter.
  *finish
#Restore to the previous checkpoint.
  *restore_checkpoint cancel=chapterend

haha, when I suggested that code sample, I thought that approach was obviously wrong!

I agree with everyone who has said there should be an error that pops up in QT and RT. However, I would rather this not crash the game and send someone forward.

I think this is also what @CC_Hill said:

@CC_Hill

With a failing error, readers would think there’s a bug and bombard support with email because they don’t know it’s what the code is supposed to do when there’s no initial checkpoint.

Here’s the problem. In general, we can’t add more restrictions to ChoiceScript in order to prevent crashing with an error, because breaking the rules will always just crash the game (and fail QT/RT).

In this example, let’s suppose we require cancel= on *restore_checkpoint in order to prevent *restore_checkpoint from ever crashing. But, what happens if the author forgets to type cancel=, or misspells it ancel=, or misspells it *label hapterend name and writes cancel=chapterend?

In that case, the game will just crash with an error message, of course!

The only way to prevent crashes is to ensure that QT/RT can catch them, and ensure that QT/RT both run before we ship to the public. It’s not just that the author might have used *restore_checkpoint before *save_checkpoint. They might have had a typo and typed *estore_checkpoint, or *hcoice, or any number of other errors.

Our best defense against crashes is testing; in fact, it’s the only possible defense.

QT gives us the confidence and security to make sure that *restore_checkpoint is a very simple command, adding complexity only for advanced use cases.

[HarrisPS]

@JimD

Otherwise, some game could potentially get released (if QT and RT did not catch this error), and you will just have a lot of upset players submitting support tickets or writing angry reviews that their game crashed due to a bug.

I think if I’m understanding right, this shouldn’t happen because QT and RT would pick it up and it wouldn’t get released? It could be an issue on dashingdon if and when it’s updated, but that’s the case for anyone who isn’t using QT and RT on their WIPs.

[dfabulich]

I have another question, a vague, open-ended question, for anybody who’s reading this far down the thread.

I’d intended *save_checkpoint and *restore_checkpoint to primarily help with end-of-chapter checkpoints, to simply restart the current chapter, if the player wants to.

But I also introduced checkpoint “slots,” and I’m wondering what people think they want to do with them.

In my OP, I gave an example of *save_checkpoint major and *save_checkpoint minor. In this post I gave an example of setting one checkpoint per chapter, so you could *restore_checkpoint chapter1, *restore_checkpoint chapter2, etc.

But there are a lot of ways that games can be saved. There’s some overlap and some differences between the CoG-only *save_game command and the smPlugin that many games use on Dashingdon.

The *save_game command:

• Stores saves on our servers at choiceofgames.com (that’s why Dashingdon games can’t use them)
• Only lets you save when/where the author includes a *save_game command
• Only lets you restore when/where the author includes a *restore_game command.
• Doesn’t let you save in the middle of a file (you have to specify a “destination file” in the *save_game command, e.g. *save_game chapter2)
• Lets players name their slots
• Allows authors to detect when you just restored, with the choice_user_restored variable

The smPlugin:

• Stores saves in your browser’s local storage. (Those saves can be lost, or can fill up all of the “quota” that your browser allows Dashingdon to have. The quota is especially small on Firefox, FYI!)
• Lets players save at any time, in the middle of a file, whenever
• Lets players restore at any time
• Doesn’t allow the game to detect when you’ve used it (as far as I know)

*save_checkpoint:

• Stores saves in your browser’s local storage
• Only lets you save when/where the author includes a *save_checkpoint command
• Only lets you restore when/where the author includes a *restore_checkpoint command (but you can put it on a stats screen).
• Supports excluding some variables from restoring
• Allows authors to detect when you just restored, using the choice_just_restored_checkpoint variable

Then there’s just “not losing your progress when you refresh the page.” That doesn’t have an official name, but I’ve always called that feature “autosave.” Autosave is a built-in feature of ChoiceScript, but Dashingdon has never turned it on for some reason. (It always stores your current state in your browser’s local storage.)

I might be able to make *save_game work with just local storage, especially if Dashingdon were to turn on autosave. Would very many authors bother to use *save_game, given that smPlugin is already there and already works?

If you could only have just one, would you prefer *save_game, *save_checkpoint, or smPlugin?

(Also, do checkpoints even matter that much if they don’t work on Dashingdon? I don’t think Dashingdon has incorporated any of the CS updates from last year, including *create_array from Sep 2022, say nothing of keyboard shortcuts and disabling touch-slide controls from June 2023.)

The absolute worst case scenario for me would be for people to try to recreate *save_game using *save_checkpoint slots.

It would look something like this monstrosity, click here to see it

*label save
Which slot do you want to save?
*input_number slot 1 3
What do you want to call your saved game?
*input_text save_name[slot]
*if slot = 1
    *save_checkpoint slot1
    *return
*if slot = 2
    *save_checkpoint slot2
    *return
*if slot = 3
    *save_checkpoint slot3
    *return

*label restore
*choice
    #Slot 1: ${save_name_1}
        *restore_checkpoint slot1
    #Slot 2: ${save_name_2}
        *restore_checkpoint slot2
    #Slot 3: ${save_name_3}
        *restore_checkpoint slot3
    #Cancel
        *return

The problem with this code isn’t that you can’t do it… you can. But it’s kinda like implementing a checkpoint system from scratch by copying and pasting all of your stats into backup stats. It’s a big waste of your time, and I’d like to stop doing that!

But, if that’s what everybody wants to do, then I should probably just work on making *save_game work on Dashingdon, right?

[dfabulich]

@Big_fan1231

How soon can we see a game using this by your estimate?

This is a actually surprisingly tricky question, because so many of the ways people use ChoiceScript are outside of our control.

I’ll probably continue the thread here until sometime next week, and then, assuming we’re all kinda on the same page, I’ll make any necessary changes and publish what I have into the master branch on Github, which will make that the “official” version of ChoiceScript.

At that point, if you submit a game to us that uses checkpoints, and it passes QT/RT, we can deliver it to players.

But checkpoints won’t start working on Dashingdon or ChoiceScript IDE until they each incorporate my changes. (CSIDE’s ChoiceScript usually updates faster than Dashingdon, but it can still take many months.)

So, even if I “finish” next week, it might not be practical for you to use for quite some time.