Howdy, Stranger!

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

How many objects can Sugarcube handle before slowing down/becoming unstable?

edited August 2016 in Workshop
How many objects can Javascript/Sugarcube before slowing down/becoming unstable?

Right now we're working on a game with randomized NPCs that are encountered.

Our upper bound for saved NPC objects is 50-70. Each of these currently have 47 simple properties such as "class" : "class_merc", and 3 arrays of variable size (max 15 simple strings, such as "wounded_arm", "blind_leye").

We want to implement a "history" object for each of these NPCs, a way to know what they where compared to what they are right now. Each "history" object is unique to each NPC, and will contain 30-40 simple properties; essentially the defaults for this NPC.

Each of these NPC objects have a pletora of functions to manipulate the NPC and "verbalise" their status.

To manage these NPCs, we give them an ID and put them in an object like this; db[] = npc;

Using this ID, they will have equipment and other accessories (3-4 systems) which I would estimate at 5-15 simple objects per NPC.

So it would look like:
An NPC is created. It is added to DB with it's ID.
DB has NPCs with IDs
System1 uses these ID
System2 uses these ID
System3 uses these ID
OverarchingSystem uses an ID for an NPC, on demand, for a lookup one or multiple systems so the user can interact with it.

OverarchingSystem says, show  #27's head slot equipement. EquipSystem returns that.
OverarchingSystem says, replace #28's head slot equipment with X, EquipSystem does that.

We're compiling all the files into 1 HTML with Tweego 0.99.0 with SugarCube 2.7.2. We only plan on supporting recent browsers, which support ES6.

Being not too familiar with javascript and sugarcube, I am wondering whats the point where our story will start slowing down?

Is there anything I should avoid doing?

Are there local storage persistence solutions that work with SugarCube?


  • sssk wrote: »
    How many objects can Javascript/Sugarcube before slowing down/becoming unstable?
    You're asking a question for which there's no convenient answer and which no one save you can answer besides. The best answer you're going to get is to populate your systems with simulated data and then to run through some sample passages—representative of what you're planning to have in the complete game.

    sssk wrote: »
    Is there anything I should avoid doing?
    The largest, and most consistent, mistake I see authors/developers make is blowing the size of the story history to ridiculous proportions. This is usually a combination of two factors:

    1. Keeping too many moments/states within the history.
    SugarCube's default assumption is that authors are creating interactive fiction, so the default setting of Config.history.maxStates is 100—which should be fine for the vast majority of projects. For projects which are significantly game-oriented and/or those who will have a huge variable store regardless, lower settings are better. Additionally, if the ability for the player to traverse the history is unwanted or unnecessary, the best setting is 1.

    2. Storing data which doesn't need to be a part of the history within story variables (e.g. $foo).
    Do not store data which is not part of the playthrough history within story variables, since they're part of said history. For example, data which doesn't change probably does not need to be stored within story variables—it may be convenient to do so, but the trade off is bloating each history moment.

    sssk wrote: »
    Are there local storage persistence solutions that work with SugarCube?
    What are you asking, specifically?

    SugarCube has a save system which, where supported, offers both in-browser and to-disk saves—backed, in-browser, by Web Storage and, to-disk, by FileSaver.js. That's a well known feature, however, so I doubt you're asking about that.

    If you're talking about an in-browser database, then, based on your ES6 requirement, your options are essentially limited to Web Storage and IndexedDB. As an additional complication, IndexedDB may be off the table unless you can integrate the use of an asynchronous API into a largely synchronous workflow. I assume you aren't keen on hand-rolling a solution, so something like localForage would be your best bet—again, with the huge asynchronous/synchronous caveat.
Sign In or Register to comment.