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?
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.id] = 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:
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?
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.id] = 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?
Comments
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.
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.