Grr...More restrictions found on the stats screen

(Looks like I accidentally posted as @dfabu, now posting as @dfabulich correctly.)

Actually, it turns out “some point” is right now. :slight_smile:

I’ve been putting some more thought into this topic and wanted to write down some of my musings.

A lot of the weirdness of choicescript_stats has to do with the “refreshability” goal of ChoiceScript.

Note that in published games on choiceofgames.com, if you refresh your browser while playing the game on the web, it remembers where you left off (assuming you have cookies enabled). Something similar happens if you quit the downloadable apps (iOS, Android, and Steam apps) and reopen them.

Suppose you have code like this:


*set leadership %+20
Now your Leadership is ${leadership}.
*page_break

When I first implemented ChoiceScript, when you set a stat, we’d update your stats right at that moment. This created a bug where if you refresh the page on code like this, your Leadership would keep going up and up and up.

So, instead, the policy is to accumulate all temp/stat changes and only actually save them when the player clicks “Next.” Suppose you start with Leadership 50, so %+ 20 gives you Leadership 60. When you see the “Next” button, your saved Leadership score is still 50; it would only increase to 60 at the moment you click “Next.”

If, instead of clicking “Next,” you refresh the page (or quit/reopen the app, or whatever) we’d restore the game based on your old Leadership score of 50 (since the stat bump wasn’t yet saved). We’d then re-apply the stat bump, giving you a Leadership of 60 again; only once you click Next would the changes stick.

That worked pretty well, but it created a major bug on the stat screen, which I then had to work around: if you check your stats right after your score goes up, you’d see the old Leadership score (50), not the new one (60). It was especially embarrassing when the text just told you what your new score is, but then you’d check the stats screen and it would already be out of date.

To work around this bug, I created two saved games, one “regular” save that would be used for refreshing and restoring the main game, and one “temp” save that would be updated immediately after stats changed. In the regular save, Leadership would be set to 50; in the “temp” save, Leadership would be set to 60. Then, the stats screen would use the temp save. When returning from the stats screen, we’d refresh the game based on the regular save.

But that created a new problem, which, at the time, I thought was pretty minor: you can’t *set any permanent stats on the stat screen, because anything you *set would be set in the temp save, which would be lost when you navigated away from the stat screen.

I still don’t have a good way to handle this. What should happen in this case?


main.txt:

*set leadership %+20
Your Leadership is ${leadership}.
*if Leadership > 70
  Your leadership is high enough.
  *finish
*else
  Your leadership is too low. You lose reputation.
  *set reputation %- 20
  *finish

choicescript_stats.txt:
*label start
*stat_chart
*choice
  #Boost leadershp
    *set leadership %+30
    *goto start
  #Boost strength
    *set strength %+30
    *goto start

Today, main.txt won’t truly save the stat bump until you click “Next Chapter,” and the stats screen will show Leadership=60. If you bump Leadership on the stats screen, it will appear to work, but the changes will be lost when you dismiss the stat screen.

Suppose I tried to let you modify stats permanently on the stats screen. If the stat_chart shows Leadership 60, then presumably Leadership %+ 30 should give you a Leadership of 72. But what should main.txt say when you return from the stat screen? Should it still say “Your Leadership is 60; too low”, even though it’s now 72? Should it undo the reputation change? How would it know to say 72 and not 77 (72 %+ 20)? What should we show/do if you then refresh the main page/game?

In a very real way, letting you set stats on the stat screen means you’re playing the same game in two panels at once (especially on iPad, where both panels are visible simultaneously), where neither panel is strictly “primary." What should happen to the left panel when the right panel changes something, and vice versa?

1 Like