Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Question about State engine and variable storage optimization

Hi everyone!

A quick question about the state engine:

Is it possible to NOT track certain variables in the state engine, but still have them be accessible via the "$variable" formatter?

There are some things i like about the state engine, for instance I can have a variable $score that gets "automagically" updated in the story caption. Neat. However there are some variables that I really think it's a bad idea for me to keep multiple copies of their states because the aggregate over many turns would end up being really large.

Right now I am thinking about storing these variables in the window javascript namespace and then accessing them through functions.

Any better suggestions?



  • SugarCube 2 has a special variable named setup which it makes available to an Author so that they can store data / methods that are not part of the State, History or Save modules.

    The following Javascript creates a variable to store the Author's favourite colour, it goes in your Story Javascript area.
    setup.authorColour = "blue";
    ... and you can use a <<print>> macro like the following to output the value or an <<if>> macro to check it's value.
    Author's Favourite Colour: <<print setup.authorColour>>
    <<if setup.authorColour is "blue">>What a silly colour to like!<</if>>

    warning: Because the setup variable is not tracked by the State, History or Save modules the content stored within it is not changed when the Reader loads a save, and if you use it to store data that changes during the life-cycle of the story then you will need to standard $variable to track the changes or its state will not be in sync with the Reader's saves.
  • edited June 2016
    Hey GreyElf, thanks for having a go at my questions again (you sure are everywhere!)

    I have a couple of specific questions about your answers.

    First, is there a practical difference between storing my variables in this namespace or just storing them in the window namespace? Functionally this seems the same to me from your example.

    Secondly, you bring up a great point about saving/loading data that I only started to think about.

    I was thinking that since JavaScript does assignment by value, what I could do (somehow?!) was perhaps over-write some of the save/load functionality of Sugarcube to essentially assign my javascript data store to a state engine variable for the purpose of saving, and then on load reassign it back to the Javascript window namespace and clear the variable store.

    This may sound like a lot of hoops to jump through (it feels that way to me) but we're talking about potentially a lot of data that could change every turn, so if the state engine is tracking all these changes and the turns could count into the hundreds... well, I think this could get burdensome eventually on performance.

    I'm really open to other suggestions, so if anyone has any...
  • The window object is used by the web-browser so adding your custom properties / methods directly to it could result in present/future naming clashes, which is why it is generally a good idea to create your own unique namespace to store your properties/methods and to add your namespace to the window object.

    So the real question should be "is there a 'practical difference' between creating your own custom namespace instead of using the one already created for you", and I believe the answer is: Mehh

    SC has the Config.saves.onLoad and the Config.saves.onSave Configuration Object settings which you could use to modify the save/load states to include your custom data, maybe as a JSON string within an extra $variable.

    If you are going to have a your own state engine then I strongly suggest disabling SugarCube's Undo/Redo functionality (Config.history.controls and/or Config.history.maxStates) or else you are going to have to enhance your engine to handle the same functionality.
  • I suppose I was wondering if the engine treats the "setup" namespace in some special way, inferring from your comments the answer is "Nope, it doesn't". I'm (obviously?) already aware of potential namespace clashes and using my own for my game.

    Thanks for pointing out the onLoad/onSave event handlers. I was actually looking for something like this but looking in the wrong place (save and state API).

    I'm probably going to do exactly as you suggested - convert my data store into a json string, save it, then load it and unserialize it back into the datastore.

    I'm not really trying to make my own state engine, it's more like - I would like the ability to have some variables be saved/loaded, but not tracked by the engine because it's just unnecessary overhead.
Sign In or Register to comment.