Flawed/Missing Feature : The Stats Screen


#1

Hello,

Quick intro, I’ve been coding using choicescript for about a month now, and I hope that I’ve gotten a decent grip on it by now. But in either case, I noticed that variables cannot be updated from the stats screen.

Why would this be neccessary you ask? Well, because of user friendliness, I’ve added a little something something on the stat screen that lets you see right away when/where there’s a new entry. I did this using two separate choices both leading to the same place, but one of the choices reads “New Entry”. Now the problem I found, was that despite the fact that I linked that particular choice so that it would set a variable to false when being chosen, thus when you’ve selected the sub section leading to the new entry, it wouldn’t read new entry anymore. It works temporarily, BUT once you leave the stat screen, the variable reverts.

It looks like this;

*choice
–*if (gallery = false) #Character Gallery
----*goto Gallery
–*if (gallery = true) #Character Gallery < New Entry
----*set gallery false
----*goto Gallery

The variable in question here, is (gallery), which if true, will revert to true when I leave the stats screen even if I’ve selected the link to gallery, supposedly setting the variable to false.
So yeah, IF this is something that is doable/feasible, I would very much like to see this implemented in a future upgrade/version.

In addition, I’ve had some problems with non-consistent bugs regarding the stats screen. Sometimes when I leave the stat screen, the game reverts back to the first scene after startup, but keeps the stats. This is of course not only annoying but potentially game breaking, I have yet to figure out why it happens, as I’ve replicated the exact conditions a few times, to different results. Has anyone else experienced these problems?


#2

When you edit your scene code and save it, flipping to and from the stats screen will reset you to the beginning of the scene you were on. At least that’s when I have experienced what you’ve described. It won’t break your game, and is only an issue during the editing process.


#3

Hmm, spontaneously I would say that I normally update the browser as soon as I’ve edited a scene. But I suppose I can’t rule out human error at this point. If that’s truly all it is, it would certainly be a load off my mind. Thank you. =)


#4

I do agree, I think it would be fantastic if you could change stats within the stats screen, but I do understand why (from a technical standpoint) it might be a difficult or bad idea.

I think @MultipleChoice is right about the stats screen to, I recall something being said about that at one time or another.


#5

Do we know that it would be difficult and/or a bad idea?
I’m a bit curious as to why, as it stands it seems that it is static in every regard except displaying variables, is that out of neccessity then?

It’s awfully frustrating when your creativity gets stifled by the limitations of technology, and you can’t even work around it. I even tried a *gosub command to try and set the boolean variables outside of the stat screen, but to no avail.

I also ran across another strange occurrence yesterday. It would seem as if setting up a rand command on the start screen is a bad idea, as when it switched over the next scene, and I selected stats screen, it kept running through startup in the background seemingly, randomizing new results every time I selected stats screen and exited back.

*scene_list
–startup
–childhood < Problems with the stat screen

I had it set up to randomize names etc, and the names kept changing. I had to create a proxy page with some text (it didn’t work without text) in order to prevent the startup from running over and over.

*scene_list
–startup
–proxychildhood < Problems with the stat screen
–childhood < Problem sorta solved

Not even deleting the rand var afterwards helped.

I’m not yet sure if this is a bug specific to startup or if you simply need to separate the rand with at least two pages for it to stop running. I have several labels in between but that wasn’t enough. So for now, I have just lampshaded it and made it seem like an intentional feature. :stuck_out_tongue:


#6

I’m not sure how best to describe it, you’d really need to dig into the CS source code yourself to understand it properly, but I’ll give it a go:

Choicescript isn’t really designed in a way in which you can just say “go back to page 5”, pages are decided progamatically as the code is run by page_break’s and the like.

In fact the only way we can track a player’s position in a choicescript game is via scenes (text files) and their line numbers, and of course any precision falls to the latter.
Now if you think of how a lot of the commands in choicescript work, jumping to the wrong line can actually break a game, you can’t say jump to a line that contains a ‘#’ option for a *choice, because without that preceding *choice command, we’d be landed with an error.

This is of course is where the *label command comes in, you can use labels a little like you would bookmarks, but it’s impractical to put labels EVERYWHERE, particularity every-time you stick a *page_break in your code.


So how does all this affect the stats screen? Well another limitation of Choicescript is that it doesn’t really have support for two simultaneous scenes, so in order for the stat screen to be loaded, we need to swap out our game scene. But wait…
If we go back to our previous discussion, this is a problem, what if we’re at a point in our story where there are no labels, how do we remember where the player was in the previous scene? It seems a bit much to take them back to the last label, ideally they’d return to the same page (but remember: we don’t really have any concept of “pages” in CS code).

So how CS does it is it actually sticks the entire game’s - we’ll call it “state” - into a variable/bank and loads a brand new scene, to which we’ll pass a copy of all our variables. When we return from the stat screen all we have to do then is restore our banked/saved state and there we have it, we’re back to exactly where we were before we went to our stats screen, but alas, the bad side-effect of this is that all our variables are reset too.

tl;dr - When you click “Show Stats” for all intents and purposes consider your game saved and a new faux/fake game is started purely for displaying your stats, once you click return to game, your original game is loaded.

Note though that I didn’t write Choicescript (although I’ve worked with and looked through the codebase a fair bit), so don’t take this as gospel, but that’s how I think the stat screen behaviour is best described.

Could it be done better? Yes it could, but it would most likely involve something along the lines of giving CS a proper concept of pages (though in my opinion this would be too fallible), or hacking around the restoration (for example storing variable changes and re-restoring the game variables on return from the stats screen, this does actually work but it is what you’d consider to be a rough, “hacky” job and not particularly stellar or reliable code). Another option would be to simply store the page’s first line number but then you’ve got the issue that on return you rerun all the code and would get *set buildup (*set +5 how ever many times you went to the stats screen and back?).

Well there are a million and one ways to make it work but all would some rewriting of the CS core, which obviously takes time and time is money, and COG obviously haven’t thought this particular issue is quite worth their time (at present), but maybe they will in time.

Your issue with *rand is related to all the above, essentially when you restore the game state from the stats screen it does rerun that page’s code so if you’ve got a random command it’ll be re-randomized, it’s not so much a bug as another unintentional but rather unavoidable side-effect. General practice is to simply roll and set a random value a couple of pages before you need it, it’s not ideal in terms of code legibility I know, but it saves players from the temptation to abuse the roll.


#7

I see… Oh well, thank you for that very expansive explanation. =) I guess there’s not much else for me to do than keep my fingers crossed then.


#8

I don’t know if anyone responsible for updating the CS engine read all this, but I’ll just mention a few more things that would be possible if these changes were to be implemented (call it a bit of incentive perhaps);

-Using potions/healing items from the stats_screen
-An equipment screen that could be updated directly
-Updating items from one state to another, e.g. combining flashlight + batteries, or turning wrapped present into wooly sweater

Including the helpful UI I already mentioned and probably a dozen other things I haven’t thought of yet. So yes, if at all feasible, this would open up a lot of new possibillities.

In fact, I could even offer an idea on how to implement it (from a layman’s point of view of course), since from what CJW said, I’ve come to understand that the stats page, is a stasis of the original game, and so a copy of the variables created ought to follow, since they can be displayed in the stats page. If the copies simply overwrite the originals when you return, wouldn’t that work?