I know how they work and all, but, what is the true importance for when the game is on the market on various platforms?
Specifically, for my current WIP, it’s 2 scenes. The first scene does some intro stuff and the second scene is the game itself. There won’t be any more scenes in this particular game.
So, would 200 *create variables be that much worse than 100 *temp variables and 100 *create variables when it goes to market? Would our users have any problems with memory/loading/whatever, or should I be prudent with my variables?
You’re not going to notice a difference, certainly not with those numbers. The only extra cost you’re going to be paying is memory (RAM), but you’d have to have tons more variables for that to become a problem.
In that case, create’d variables “hang around” longer.
Otherwise, if this is for your simulator, just watch out for busy loops that act on lots of variables (type of variable difference should be negligible).
What about 400 *create variables and 250 *temp variables? Or is that still trivial?
The game runs in a single scene, so I could essentially dump them all in either direction, but
now I wonder, is there any benefit to having them in *create over *temp?
I assume both save between playing sessions? And since it’s playing in just one scene, no loading lag problems?
The beauty of writing text based games is that, unlike their 3D counterparts, they use remarkably little memory. That’s going to hold regardless of whether you use *temp or *create.
There’s no underlying difference to how they’re stored/implemented, the only difference is that on scene change the temp slate is wiped. *create is handy because you can access the values across scenes. If you only have two scenes, then that’s less important.
I can think of only two potential advantages to using *create over *temp:
Whatever CoG do to implement a “save system” to carry over to sequels might be expecting *create variables
It’s just tidier (IMO) to define all your global state in the startup.txt, away from your actual text/code
Your biggest concern with performance when it comes to ChoiceScript games is heavy computation. So if you’re constantly looping over 1000 variables to decide which values to display etc, then you might notice degradation. I was writing a paginated inventory system and spotted that things started to get noticeably slow at around 1000 entries, if memory recalls. But that was comparing a filter string against all 1000 entries (amongst other things), so it was heavy stuff for a CS game.
EDIT: Similarly, loading and re-loading files (gosub_scene, goto_scene) can be quite expensive, especially when combined with heavy computation.
I’ll quote something from the CSLIB contribution guide on that front:
ChoiceScript isn’t built for performance, and cslib isn’t going to make that any better. The library relies heavily on usage of *gosub_scene, which is costly but it’s also the only reliable way to handle complex variable scoping. If you’re using the odd function or two as a utility here and there, then you shouldn’t have any problems. If, however, you’re planning on a super awesome complex simulator that loops through thousands of strings which it passes to cslib:replace or cslib:find… At that point, you might want to consider other options (including a different scripting language!).
