Advice on how to disable playe scrolling back to a passage

Authoring Twine
1

Hi all

I have a particular passage (where the user rolls the dice) that I don’t want the player to be able to scroll back to once they have visited that passage.
Does anyone know how to code it to disable a user revisiting a particular Twine passage?

Thanks in advance

2

You have a few options. In order of desirability:

1. Limit the history, so undoing is not possible (most)

If you don’t mind disallowing the player from undoing history at all, then the easiest and best solution would be to limit the history to a single moment via the Config.history.maxStates setting.

For example: (goes in your Story JavaScript)

Config.history.maxStates = 1;

2. Move the number generation

You could simply move the number generation a passage or two further back from where it appears to happen. A bit of slight of hand.

For example: (in Twee notation)

:: A
Text, more text…

<<link [[To B!->B]]
	/* Roll 3d6 a passage earlier than it seems. */
	<<set $roll to random(1, 6) + random(1, 6) + random(1, 6)>>
<</link>>


:: B
Blah, blah, blah…

[[Roll the dice!->C]] /* No rolling actually happens here. */


:: C
You rolled a $roll!

3. Use the built-in seedable PRNG (least)

SugarCube includes a seedable PRNG that, when enabled, will produce pseudorandom results based on a seed that doesn’t change for the entirety of a playthrough. Meaning that for any playthrough, a particular pull will always yield the same result—i.e., undoing the history to retry a roll always yields the same number(s), defeating roll scumming.

You enable the seedable PRNG via the State.prng.init() method.

WARNING: The seedable PRNG only affects the random() function, randomFloat() function,
and State.random() method.

For example: (goes in your Story JavaScript)

State.prng.init();
3 Likes
3

Thanks for that! For various reasons, I chose option 3 which seems to do exactly what you describe.
One question, I take it this will not affect future rolls - i.e. it won’t yield the same roll results later in the game?

4

If affects all pseudorandom number generation and the same value could be generated down the line, because it’s (pseudo)random, but it wouldn’t be the same result.

To be clear. If you meant will it will always generate the same number for the same pull count in future playthroughs, then the answer is no, as long as the seed differs—which it will if you use it as shown in my above example.

It only yields the same result for the same pull count in two situations:

  1. You specified a seed, rather than letting it automatically seed itself. Don’t do that.
  2. It’s the same pull count in the same playthrough—e.g., the player keeps undoing and replaying a moment in an attempt to get a different outcome.

The latter situation is why you’re using it, so players can’t roll-scum.

Basically, it does what you want and nothing more.

5

cheers!