| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| smutbook:classes:persistence:start [2023/08/06 20:44] – 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. |
| 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 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 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. |
| |