| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| smutbook:classes:persistence:start [2023/08/06 20:29] – lee | smutbook:classes:persistence:start [2023/08/07 15:57] (current) – lee |
|---|
| 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. | 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, <i>outside</i> 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. | 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. | 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). | 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. | 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. | 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. |
| ===== How It Works ===== | ===== How It Works ===== |
| |
| The implementation of [[PersistentObject]] isn't very straightforward to read. Here's a high level overview of how it works. | 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]]. | 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. | 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. | 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. | 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. | 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. | 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. | 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 [[PersistentObject]]s 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 [[PersistentObject]]s to be stored within Sugarcube's state history without causing a covfefe. You still can't have circular graphs of non-[[PersistentObject]]s, but as long as there is a [[PersistentObject]] somewhere in the graph that keeps the circle from linking back to itself, things should work. It's not the most efficient way to do things, but I think it's the best way short of patching SugarCube itself. | 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. | 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. |
| |