Most web browsers only allow for 10 megs (though some are as low as 5) of on-disk storage per origin. This not only has to contain the current game state, but also all previous game states in the game history. This is a particular problem with very large and/or complicated Twine games.
In an attempt to minimize this issue, SmutBook uses a defaults and delta Persistence system. “Persistent Objects”, be they characters within the game and their statistics and inventory, articles of clothing and their state, etc etc, are all defined at initialization time, outside of SugarCube's game history stack. Later, when an object's state is changed, only the differences from the object's initially defined default state are stored within SugarCube's game history stack. This greatly reduces the game's localstorage footprint (versus storing every object's full state within every game history moment), while still allowing the flexibility for almost all objects to be modified and tracked in the story history.
All persistent objects must ultimately derive from the PersistentObject class.
Each PersistentObject has a readonly “id” field (hereafter referred to as the “Persistence ID”), a simple alphanumeric-underscore string (whitespace, punctuation, and special symbols are not allowed).
A PersistentObject may be the “child” of another PersistentObject. This is tracked in the id field via a dot notation. For example, each Person object contains a GeneralInventory object that tracks what the Person is carrying. If the game contains a Person with the id of “joe”, then the id of Joe's GeneralInventory object might be “joe.inventory”. Likewise, the actual contents of that GeneralInventory might be stored as “joe.inventory.contents”, an array called “contents” within the joe.inventory object.
You won't generally need to worry too much about this id hierarchy, though. SmutBook takes care of most of it for you. The vast majority of the time, you'll only need to know the ids of toplevel objects that you have explicitly created: “joe”, “cocktail_dress”, etc.
The implementation of PersistentObject isn't very straightforward to read. Here's a high level overview of how it works.
There are three layers of data associated with a PersistentObject.
The lowest layer is called the “object layer”, and comprises properties that are defined in the actual subclass itself, in the constructor, in the usual way. These data are generally default values that will be the same on any object of a given type, although they can be overridden by higher layers of data.
Unless you are actually extending SmutBook itself, you will probably never really need to deal with the object layer in your story.
The middle layer is called the “defaults layer”. These data are defined by the story author in a JS file, using the static function PersistentObject.define(). This is used to define every specific concrete object in the game, by registering its Persistence ID, PersistentObject subclass, and default properties. These data will override any properties that are set on the object itself in the class constructor.
Finally, the top layer is called the “SugarCube layer”. This layer is stored within SugarCube's state history, and overrides data in the layers below it. If you change a property on an object to something different than the value you defined in the defaults layer, the new value will be stored in the SugarCube layer and will override the data in the defaults and object layers. If you delete the property or set it back to the value you defined in the defaults layer, it will be removed from Sugarcube's state history, and the value from the defaults layer will be used once again.
In this way, only the changes from the default data are stored in Sugarcube's limited-size story history, yet all properties on any PersistentObject can be mutable.
These three layers are implemented transparently by returning a Proxy object from the PersistentObject constructor. The Proxy's handler intercepts all property accesses to the PersistentObject and correctly routes them through the layered data levels.
This handler also replaces all references to PersistentObjects stored within Sugarcube's state history with a placeholder object that tracks the real PersistentObject's 'id' field, and then reinstantiates the real PersistentObject when it is fetched back from the Sugarcube datastore. This allows for circular graphs of PersistentObjects to be stored within Sugarcube's state history without causing a covfefe. You still can't have circular graphs of non-PersistentObjects, but as long as there is a PersistentObject somewhere in the graph that keeps the circle from linking back to itself, things should kinda work, maybe. It's not the most efficient way to do things, but I think it's the best way short of patching SugarCube itself.
Please look at the Tutorial for more details. This implementation works decently well, but there are some gotchas to look out for that are sort of hacked around, particularly in the constructors of subclasses.