Upcoming ChoiceScript Feature: Checkpoints

[dfabulich]

EDIT: Checkpoints are out now!

New in ChoiceScript: HTML Exports, Checkpoints, and Achievements

ChoiceScript now includes an easy way to export your game to HTML, which, in turn allows us to make checkpoints and achievements available to all users of ChoiceScript. Export to HTML with just two clicks When you follow our ChoiceScript introduction, you’ll run the “ChoiceScript server,” which will make your game available in your browser, locally, just on your machine. When you view a ChoiceScript game in your browser via that server, you’ll find a new “Export to HTML” link at the bottom of …

I’m working on a new feature for ChoiceScript, and I’d like some feedback from y’all before I roll it out. The feature is called “checkpoints.”

To save a checkpoint, you’d use:

*save_checkpoint

Then, later, you’d give players the option to restore to a previous checkpoint, like this:

*choice
    #Continue to the next chapter.
        *finish
    #Restore to the previous checkpoint.
        *restore_checkpoint

When you *restore_checkpoint, the player will “travel back through time” to the moment that *save_checkpoint was called. This includes re-enabling any *disable_reuse options that the player may have used after saving the checkpoint.

(Previously, if you wanted to implement checkpoints yourself, you’d have to use a *gosub_scene to individually copy all of your stats to separate “backup” variables, and then use another subroutine to individually copy all of your stats from the backup to the main variables. This was tedious and error prone.)

Try it out

To try it, download the checkpoints version of ChoiceScript.

https://github.com/dfabulich/choicescript/archive/refs/heads/checkpoints.zip

It’s not yet available in the ChoiceScript IDE or the official version of ChoiceScript, because I’d like to get feedback on it first.

Advanced checkpoint features

Checkpoints can be simple, but they can get much fancier.

• Check whether *save_checkpoint has happened yet
• Run some code after restoring from a checkpoint
• Exclude some stats/temps from being restored
• Use multiple checkpoint “slots”
• Restore to the last checkpoint at any time from the stats screen

Check whether *save_checkpoint has happened yet

If you *restore_checkpoint before you *save_checkpoint, your game will fail with an error:

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?)

You can use a magic variable called choice_saved_checkpoint. It starts out false, but when you *save_checkpoint, it turns true.

Run some code after restoring from a checkpoint

*save_checkpoint will set a temp variable called choice_just_restored_checkpoint and set it to false.

*restore_checkpoint will set choice_just_restored_checkpoint to true during the restoration process.

*save_checkpoint
*if choice_just_restored_checkpoint
    You just restored!

Exclude some stats/temps from being restored

Some games track the number of times that you restore from a previous checkpoint, in order to deduct “points” for using the checkpoint, or to limit the number of times you can restore.

*restore_checkpoint will look for a variable named checkpoint_exclusions, like this:

*create checkpoint_exclusions "experience_points courage wisdom"

The excluded variables would not revert back to their old values when you *restore_checkpoint.

*create checkpoint_uses 0
*create checkpoint_exclusions "checkpoint_uses"

*save_checkpoint
*if choice_just_restored_checkpoint
    You just restored!
    *set checkpoint_uses +1

You have restored from the checkpoint ${checkpoint_uses} times.

...

*choice
    #Continue to the next chapter.
        *finish
    #Restore to the previous checkpoint.
        *restore_checkpoint

Multiple checkpoint “slots”

When you use *save_checkpoint or *restore_checkpoint, you can specify the name of a checkpoint “slot.” This allows you to set multiple checkpoints, allowing players to go back just a little or a lot.

*save_checkpoint major
...
*save_checkpoint minor
...

*choice
    #Go back a little
        *restore_checkpoint minor
    #Go way, way back
        *restore_checkpoint major

(Each checkpoint slot gets its own variable. In this example, choice_saved_checkpoint_major would be set to true when you *save_checkpoint major.)

Restore to the last checkpoint at any time from the stats screen

You can write code to restore from the stats screen like this:

[choicescript_stats.txt]
*stat_chart
    ...

*choice
    #Done.
        *finish
    *if (choice_saved_checkpoint) #Restore from the last checkpoint.
        *restore_checkpoint

Note that you’ll need *if (choice_saved_checkpoint) to make sure the player doesn’t try to restore before the first checkpoint has been set.

What do you think?

Does this do what you need? Is there anything I forgot?

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?

(I suppose that if it were to restart from scratch, you wouldn’t need *if (choice_saved_checkpoint) in choicescript_stats.txt. Maybe that’d be easier to use?)

[Eiwynn]

@dfabulich

Some games track the number of times that you restore from a previous checkpoint, in order to deduct “points” for using the checkpoint, or to limit the number of times you can restore.

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.

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

If such an author did this, I, personally, would not consider their game to have actually offered this feature to me.

@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?

Both.

I believe the choosing to restore a checkpoint should trigger a warning in quicktest so the author realizes this is occurring (like how it warns if lines are uncovered now) and I believe such coding should be a game restart if enacted prior to reaching an official checkpoint location.

[HarrisPS]

This looks wonderful and I think it’ll be extremely in demand! I will take a closer look when I’m not on my phone. I think it’s an entirely good move to implement so life is easier for authors who want checkpoints in their games.

@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.

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

If such an author did this, I, personally, would not consider their game to have actually offered this feature to me.

I sort-of agree, depending on the kind of game it is (I do think there could be some very interesting uses possible - time-travel games perhaps!) but I think authors should be free to choose to do it if they want to - I don’t think it’s a problem for ChoiceScript to include it as an option.

[ViIsBae]

@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.

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

If such an author did this, I, personally, would not consider their game to have actually offered this feature to me.

So, for me, the first thing that popped into my head is say, a game where you have a certain amount of lives. Or maybe a game centered around rebirth, where every time you get reborn, you get slightly different text as your character begins to lose more and more memories of who they are until you’re reborn as an entirely new person altogether with no recollection of who you are.

I thought of less “punish players for using a checkpoint” and more thinking of it as an actual feature or mechanic opportunity of the game.

[Eiwynn]

@HannahPS

I sort-of agree, depending on the kind of game it is (I do think there could be some very interesting uses possible - time-travel games perhaps!)

Using checkpoints as part of in-game systems (time travel, puzzles, etc) is not what I am referring to. Incorporating checkpoints for system developments is a huge boon and would not be seen as offering a “checkpoint save” system.

There is no way the deployment of the time-travel system would be confused as an actual checkpoint save system, unless intentionally done by the author.

[Dvalor53]

@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.

That would be on the whim of the author. As a strict checkpoint system where the only point is to try something again, I agree that punishing readers is not ideal. However this is just a tool, so in the end it depends on implementation and context.

I see a lot of utility use in this for me testing multiple gaming runs without reloading the whole thing. I see use of this as a time travel device for characters. I could see this as a “You died go back to check point?” option and in that context, yeah maybe I can lower something.

I look forward to this feature being added.

[abbytrevor]

To be clear, “punishing” people for using checkpoints is not something that we’re requiring for authors or specifically recommending, it’s just a feature that’s available (and excluding variables from being reset has other game design uses, as people have noted). Based on how I’ve seen people use checkpoints so far, I don’t imagine that it would be standard.

[Doriana-Gray]

I’ll return with more detailed thoughts on this once I’m less busy—

But this is a great compromise on a more dashingdon style save system and I’m really happy to see it!!!

Great work!

[HarrisPS]

@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?

Am I reading right in thinking the failure and error message would be player-facing if the restore was being attempted from the stats page? If so, I think it should just restart without comment, as it would look like a bug and would worry or turn off players who didn’t know what was going on.

I like @Eiwynn’s suggestion about a QuickTest warning, also.

[Eiwynn]

@HannahPS

Am I reading right and thinking the failure would be player-facing if the restore was being attempted from the stats page?

I took it to be choosing the menu option either from the stat-page or prior to reaching an established checkpoint.

For example: I decide I want to restart the first chapter before reaching the chapter’s checkpoint, so it would then restart the game for me.

[Omeg]

Neat, I was about to start writing backup variables to create a makeshift checkpoint for my game. Having a checkpoint command will make my life a bit easier.

I’m probably less hyped for this feature than most people since I have a “roll with the failure” philosophy when it comes to playing and designing games alike, but I can’t imagine this particular feature being anything but an improvement.

[CC_Hill]

@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?

That’s an exciting feature and I can’t wait to see it implemented . I think it’s best to start the game from scratch.

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.

[HarrisPS]

@Eiwynn

I took it to be choosing the menu option either from the stat-page or prior to reaching an established checkpoint.

For example: I decide I want to restart the first chapter before reaching the chapter’s checkpoint, so it would then restart the game for me.

That makes sense. In that case I would rather the game restarted “silently” to avoid confusion - if an error message came up in the same way it does for *bug commands etc it would alarm players!

[LiliArch]

Hmm. I think I would, in that use case, prefer the game telling, in the same vein as it does in the “game updated” case, something like “no checkpoints to restore, restarting instead”.

[MahatmaDagon]

This is amazing. I wonder if, with this, early death scenes could be a thing in official CoGs.

[Omeg]

Choice of the Star Captain did one eleven years back. Early death scenes aren’t really a problem, since restarting is so consequence-free.

Midgame death scenes, on the other hand… yeah I can see checkpoints being useful for that. Even though I think I saw one of these once or twice as well.

[RockmanX]

Now that we have proper checkpoints implemented in code, if the player has yet to reach a checkpoint, the most feasible thing to do would be to send them back to the start of the game. If they have reached a checkpoint and moved beyond that and somehow, accidentally clicked something they shouldn’t have, then they get sent back to the last touched checkpoint.

Of course, this is not mandatory for everyone, but for people like me whose games will need checkpoints of some sort, it can definitely came in handy. In fact, I am not one who will punish for checkpoint use. Limiting checkpoint usage does not prevent people from cheating- people WILL cheat anyway, to experience that alternate route as mentioned. Also as mentioned, I did away with the lives system. Thanks a lot! Right now it’s a lot to take in, and a more thorough discussion will be made once more features are implemented.

[Dvalor53]

@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?

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

[EvilChani]

@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.

If such an author did this, I, personally, would not consider their game to have actually offered this feature to me.

Agreed. If this happened in a game, I’d avoid that author’s games like the plague (which they may consider a good thing, lol). But yeah, it would piss me off to be punished for loading a save. That’s ridiculous. I may as well stick to code diving.

[cup_half_empty]

That’s amazing news! Thanks for listening to the community.

I think throwing an error is not unreasonable when no checkpoints exist. Keeping the guard variable is better, so author can control when to offer the option, otherwise players might unintentionally reset the game.