CruxScriptables are modified ScriptableObjects that utilize their own referencing system, and have built in capabilities for saving and loading, even in runtime builds. They can also be set to auto-instantiate when Play mode is engaged in the editor. That way, any changes made to the CruxScriptable during Play mode are temporary.
Why did I make CruxScriptables?
Because ScriptableObjects are a really cool idea that has even more potential to unlock, with the ability to save and load at run time. Once I'd gone that far, the ability to instantiate during play mode just sort of fell in my lap.
I was thinking about using a CruxScriptable to represent a characters memory. I had the idea that it could be cool to have some characters retain their memories over multiple playthroughs of a game, while others would be reset to a default state, each time.
At some point, the idea dawned on me that I could sort of reverse that concept: In the editor, I could have CruxScriptables reset themselves after play mode had ended. Turned out to be really useful.
Why are CruxScriptables cool?
Because I packed them full of really useful stuff, that's why! CruxScriptables all use a custom referencing system. This is because, traditional ScriptableObjects often lose references to one another, particularly when you enter and exit play mode, but in various other non-obvious ways. In particular, I often found in testing that ScriptableObjects would lose references after building a game build. Both in the build, and in the editor!
The CruxScriptableManager keeps a simple double-blind reference to all loaded CruxScriptables and it keeps all of their references straight with one another. The ScriptableObject Instantiate methods have all been overridden to register the newly created CruxScriptable with the Manager.
You can also import and export packs of CruxScriptables through the manager. These are known, obviously enough, as CruxScriptablePackages.
Lastly, it includes the CruxScriptableComponent which extends from MonoBehaviour and provides scenes with an object based reference point for CruxScriptables. When a CruxScriptableComponent is first loaded, any CruxScriptables it references are automatically registered with the CruxScriptableManager.
You can tell each CruxScriptableComponent which of its CruxScriptables to unload when it is destroyed. This way, you can have sets of CruxScriptables that are loaded in and out with scenes. But, since CruxScriptables are loaded when the CruxScriptableComponents Awake function is called, and optionally unloaded when the CruxScriptableComponent is destroyed, loading Disabled objects also allows you to control when the CruxScriptables are registered and removed.
And all of that makes them... pretty cool, I'd say.
What ideas have I had with CruxScriptables?
Well, as a big start, check out my Narrative Spaces project. All of the narrative objects in that project are extended from CruxScriptable. But what else?
Plug-and-play behaviors. As with traditional ScriptableObjects, CruxScriptables are uniquely suited to slotting in complex behaviors that will change and/or be swapped out during game play. But, since they can be saved and loaded, as well, they are far more malleable.
Custom / game created content. With the ability to save, load, and create packages, CruxScriptables make for an easy solution for handling custom, downloaded, or player created content.
Procedural content. With their custom referencing system, CruxScriptables are very modular. They could easily be used as building blocks of different procedural systems: The first could generate a maze, for example, before sending it to the second. We could then swap in various modules for the second step. One for traps, one for enemy placement, one for loot, etc. As procedures are created, they can be saved in packages for future reuse.