Grr...More restrictions found on the stats screen

Game Development ChoiceScript Help
21

@dfabulich I feel like I’m too much of a novice to get all of it. But essentially, where we’re at right now, is that a variable can be changed on the stats-screen but the change doesn’t carry over or last, like you said.

I’m not sure I understand how that would create an infinite loop though, if you close the stats screen, reopen the game, and the stats update, or vice versa, pause the game and open the stats screen and the stats update. Won’t that just happen once, when you open and when you close it? I honestly don’t know. I get what you’re saying that currently it’s set to update only when you click next or the equivalent. Is there no way around that then? Updating it when you reload the main game returning from the stats screen or arrive at the stats screen?

I haven’t played any of these games on an ipad, didn’t know they differed that much. That sounds like it’s a whole different system then? I suppose you can’t “close” the stats screen at all then in the ipad version, thus negating any fix I could think of.

Like @fantom said; "I know something similar can be achieved with *gosub_scene and such, but the player would only be able to access it when they have the option put in, whereas with this the player could access it at any time just like the stat screen. "

This is essentially what I’ve been saying, if you have something like an inventory system on the stats screen, then you won’t have to insert code everywhere, gosubbing to it. That’s what I’ve been hoping for. Though I dunno if adding another button would work either, because then we’d just be having the same problems? Unless you could create a permanent gosub button.

And thank you to @Havenstone for linking, I wrote a few examples there as well, of a few things that could be achieved if the stats screen could update and stay updated.

If the only way to update it is through next and it can’t be changed, then I’m stumped. Creating your own gosub button up among the stats and the achievement ones though, how does that sound?

22

Let’s focus on the iPad version for a moment, not least because I began thinking about this topic as I considered bringing the iPad approach to the web.

It looks like this: http://www.choiceofgames.com/press-files/screenshots/heroes-rise-3-herofall/ios/6-1.png

Here’s how it works today.

  1. Load/restore the current scene file from the “main” autosave slot.
  2. Play the current scene file until it reaches a “Next” button (*page_break, *choice, *finish)
  3. Save the updated stats into a “temp” autosave slot.
  4. Refresh and re-run choicescript_stats.txt in the stats screen, using the “temp” autosave slot.
  5. The user clicks “Next” in the main game. Now we save the updated stats into the “main” autosave slot.
  6. Return to Step 1, running through Step 4. If we then refresh the game at this point, we can run and re-run Steps 1 through 4 as many times as we like, without double-counting stat bumps, etc.

(The web version is exactly the same, except we don’t run Step 4 until the player clicks “Show Stats.”)

The solution I called “Answer 1: Immediate refresh” would insert a step between Step 4 and Step 5:

4.5) If the user clicks “Next” in the stats screen, save the “main” autosave slot and go to Step 1.

That could easily cause an infinite loop.

The solution I called “Answer 2: Delayed effect” would be easier to implement, and would at least fix the Tin Star bug.

In that solution, we’d modify Step 5 to copy the “temp” save on top of the “main” save, so changes that happened in the stats screen would eventually have an effect, just not right away.

Regarding an inventory panel, that goes to my point about ambient options. If you write a *choice, what exactly is supposed to happen when someone clicks a button that isn’t an #option in that choice?

Inform has a mechanism called a “rulebook,” where you can write, “Whenever X happens, Y happens as a result.” The whole game is written in that style. You’d kinda need to add rulebooks to ChoiceScript. But ChoiceScript is a completely different philosophy from rulebooks, and I’m afraid that mixing and matching them would result in a jumbled mess.

For example, suppose I do somehow sort out the infinite loop problem. Would you write a puzzle like this?


main.txt:
*if key_used
  The door unlocks!
  *set key_used false
  *finish
*if chicken_used
  The chicken does nothing.
  *set chicken_used false

*label door
You see a door.
*choice
  #Knock on the door.
    No one answers.
    *goto door
  #Open the door.
    The door is locked.
    *goto door

inventory.txt:
*label start
*choice
  *if (key) #Use the key.
    *set key_used true
    *goto start
  *if (chicken) #Use the rubber chicken.
    *set chicken_used true
    *goto start

That looks like an enormous hassle. What if there were dozens of items?

Instead, a proper “inventory” system would be needed. Maybe something like this:


main.txt:
*label door
You see a door.
*choice
  #Knock on the door.
    No one answers.
    *goto door
  #Open the door.
    The door is locked.
    *goto door
  *inventory key
    The door unlocks!
    *finish

But now we’re talking about building an inventory system, not just setting stats on the stat screen, and it’s barely a step toward a general system for handling “ambient options” of all kinds. (e.g. a “give me a hint” button). And what happens if the user tries to click on the chicken at this point, where the author forgot to mention the chicken in the list of options?

A rulebook system would be much better.

Whenever the player tries to use the key, if the door is nearby, unlock it, else say, "There's nothing here to unlock.

But that’s a completely different language!

23

@dfabulich What are you saying exactly? It can’t be done? You’re stumped? I was kinda hoping a brain-thrust would form here and toss ideas around, as I’m woefully unfit myself. :-/ Having more options as coders is something that ought to interest everyone making a COG. But I suppose in terms of suggestions/ideas, noone knows more about the engine than you do, most of us are only driving the car, we have no idea what makes it go forward…

This ipad stuff feels like an anvil around my neck, I don’t much care about it myself as it’s not my platform of choice but obviously it would be unfair to offer limited experiences or even to break games just because the user is on another platform. So yeah, I dunno… I dunno. I have seen games with custom made buttons where they have modified the JS file instead, I’m curious as to how that affected the ipad users.

But yeah, I hadn’t really considered what would happen if you choose an item in the supposed inventory screen like that, where it would move forward from then. Potions/Health packs and the equivalent would work fine because they’d just modify a stat, but items that drive the story forward is a whole nother matter, depending on how you code it. I dunno if those things NEED to be accessed from the inventory screen though, in the case of the key, that would be much smoother to just *if (key) #Open, rather than having to go switch screens for it obviously.

I can still see a lot of uses for such a screen though, you could potentially switch between dimensions, like in Soul Reaver, doesn’t even need to be a pure inventory screen, it could depend on what you need/want. And even if you can’t use all items directly on the screen, you could still play around with variables, combining items, inspect items, use anything that would affect pure stats, since it’s a *gosub there wouldn’t be the same delay either. It’s sorta like key-items vs restorative items. In RPGs, you usually don’t need to tamper with the key-items, just having them will trigger the event they’re meant for. And even if it would be a hassle, it would still be an optional thing after all. I’d hate to give up on this idea as I can see so many possibillities emerge from it.

24

OK, here’s what I’ve got.

  1. *redirect_scene: A New Variant of *goto_scene

Previously, when using *goto_scene in the stats screen, it was just buggy; the game was partially in stats mode and partially not in stats mode. A few weeks ago, I “fixed” it so *goto_scene and *gosub_scene would reliably leave you in stats mode, requiring the user to actually click a button to leave stats mode.

The *redirect_scene command only works in stats mode; it exits stats mode and executes a *goto_scene command back in the main game. In tablet mode, the stats screen can’t be “exited” (it’s always visible as a panel on the side of the screen) so we just *goto_scene back in the main game and then refresh the stats screen.

Like *goto_scene, you can add a label name, e.g. *redirect_scene party invitation to redirect to party.txt at *label invitation.

I haven’t written up a lot of documentation about it yet, because I’m not 100% convinced that I like the name *redirect_scene. I’d like to call it *exit_stats_and_goto_scene_in_main_game if that weren’t such a mouthful…!

  1. Saving In Stats Kinda Works Now

In the latest version of ChoiceScript up on github, *set commands on the stat screen will take permanent effect, but only after you return to the main game and click Next.

So, for example, if you have code like this:

startup.txt
-----------
*create count 0
*set count +1
page 1: ${count}
*page_break
page 2: ${count}

choicescript_stats.txt
----------------------
*set count +1
*stat_chart
  text Count

Now suppose you start the game and visit the stats screen eight times without doing anything else.

Surprisingly, even though you visited the stats screen eight times, the counter will show “page 1: 1” in the main game and “Count: 1” on the stats screen. But as soon as you click Next, it will correctly show “page 2: 9,” one for each visit to the stat screen plus the initial +1 for starting the game.

In other words, we refresh the stat screen when the main screen changes, but we don’t refresh the main screen when the stats screen changes. (That would be an infinite loop.)

As a result, players can now set preferences on the stats screen, e.g. it mostly fixes the bug in Tin Star where you can’t force it to remember that you want the stats screen to stay in “story mode.”

(That is, the Tin Star bug is completely fixed in tablet mode, where there’s no way to exit stats mode. In non-tablet mode, if you select story mode, exit stats and immediately re-enter stats, your preference will be forgotten. But if you exit stats, click Next and then re-enter stats, the preference will stick.)

If you want to make a change on the stat screen that has an immediate effect on the main game, use *redirect_scene instead of just *set.

What do you think? Close enough?

7 Likes
25

Wow! Hmm, will it trigger before anything else then? Like before the code after the choice. Because if so, it is practically instantaneous and the only lag would be if you had a display in the main game right?

Like if you used a health potion in stats before you choose get punched or something, if it triggers/updates directly once you click next then that’s awesome. grovels in reverence :smiley: The only thing I can see, is if, let’s say the choice is dependant on the update to be selected, like if you have a choice that says, costs a 100 gold, then you go into the stats screen and select break piggy bank and get 100 gold but still can’t select that option. That would be the only thing, but I’m happy to get this much still. Great job, thank you so much!

I’m curious about the redirect scene. It basicly functions like a normal *goto scene, but from the stats screen? What happens with the original position you were in, in the main game then, is it forgotten/overwritten? So let’s say you’re at apartment.txt, go into the stats screen and select open invitation, it transitions you to ball.txt, and forgets the apartment then?

I guess one could save what chapter and what label one is at, and use the *goto_scene to jump back to that place after one has gone via the route of *redirect_scene? Like so;

chapter_one.txt
*set chapters "chapter_one"
*set labels "home_sweet_home"
*label home_sweet_home

choicescript_stats.txt
*choice
  #Drink Potion
    *redirect_scene potions

potions.txt
*set health 100
*goto_scene ${chapters} ${labels}

Something like that?

26

Yup. If you want to have an instantaneous effect on the main game, you’d have to do *redirect_scene and try to jump back to the right spot.

Yes, because it is actually ambiguous. e.g. in this code:

hello
*page_break
*set health -20
Now what?
*fake_choice
  #Punch
  #Kick

If you drink a health potion right before punching, it’s not clear whether you’d want to “go back” to the *page_break line (and re-run the *set command) or go back to just the *choice (skipping “Now what?”). So the author has to decide exactly where to go back.

*goto_scene doesn’t accept ${} variables. I think you’d have to do it with *if/*elseif. But I think something like that would work.

2 Likes
27

Mhm, okay. Awesome, then at least there’s now a way to work around it. Thanks again! Super excited now! XD

28

@dfabulich Just thought it might be worth suggesting; if the save stat bug is completely fixed on tablets due to how the stat screen is displayed, surely making the web client operate in the same (or similar way) would be preferable to get rid of the problem altogether?

I’m not familiar with JS at all but if users might feel bothered by constantly having stats displayed at the side of the browser window, would it be possible to contain them in a collapsible panel?

Either way, thanks a lot for this commit! :slight_smile:

29

I’m a little late coming to this conversation, but I feel I should say, in regards to creating infinite loops due to changing variables in the stat page, really, it’s up to the programmer/writer to avoid doing this, like with anything. Theoretically, one can create an infinite loop with labels and goto after all.

30

Couldn’t there be a separate div for the stat chart? This div would be invisible most of the time but made visible and placed over the regular game div when the stat button is pressed. This would make it like the tablet version, just that it wouldn’t be visible all the time.

31

I’ll say the same thing here as I did on the discord server:

I don’t get it, isn’t there a way for the devs to keep track of if you’ve visited the same page before? Can’t you just implement some background variable that keeps track of if you’ve refreshed the page, and if the variable thinks you have, ignore other variable changes on the page if you update? That way you wouldn’t really need to have multiple types of variables.

32

What’s wrong with

*set nextscene "scene1"

*goto ${nextscene}

EDIT: Oh wow didn’t realise how significantly this thread had been necro’d.

1 Like
33

That syntax didn’t exist at the time. Yep, I’m going to close this. I don’t think there’s much to add.

2 Likes