Brainstorming for a UnityAtoms v5 / Rewrite / Successor

[soraphis]

DISCLAIMER 1: the following is full of personal opinion
DISCLAIMER 2: this is just a bit of brainstorming, on things that work nice in UnityAtoms, and things that don't

Good things in UnityAtoms v4.x

• There are a lot of good things in atoms, but I'm too lazy to list them all :D

Bad things in UnityAtoms v4.x

• Inheritance Architecture. This was chosen because it's easier for the serialization system of unity.
• AtomActions are to cumbersome to work with. The Idea is great, the execution is meh.
• Addressables and SceneLoading messing with the lifecycle of ScriptableObjects (often different in a build than in editor)
• A lot of ScripableObjects → cluttering the project folder and makes it hard to scope variables (what is global state, and which one is only used in scene 1 as a temporary value?)
• AtomList / AtomCollection, they are named too-similar to AtomValueList but they are
• Instancers, runtime creation of ScriptableObjects have a too high performance impact, that is easily overlooked in the beginning of an project.
• Events. In general they are nice, but they mix two different concepts: Events can be an "EventBus", there is no state, there are just messages send on that line, but they can also be the ChangedEvent on a variable, and then they suddenly have an "initial-state" (at least conceptually).

Things I'd like to do different in the future

• ScriptableObjects should be runtime-immutable. Runtime-Values should be stored in a "VariableManager" (Self-Instantiating-Singleton, don't destroy on load). This way...
  • ... a) ending playmode automatically loses the runtime values, no extra reset necessary, works easily with disabled domain reload
  • ... b) references to Variables are kept and SceneLoading (in a build) does not free the resources and resets their state
• AtomActions could make use of [SerializedReference] (which has it's own drawbacks, sadly)
  • this removes the need to create an asset instance (though it creates a class-instance at runtime/deserialization, but that should be okay (compared to the overhead a SO has and considering the lifetime is as long as the containing object))
  • this allows different actions to have different fields that can be configured on the component itself.
• AtomActions need a way to pass arguments to them dynamically.
• Scoping/Grouping. Make it easy to manage which variable are globally scoped, scene scoped, gameobject/prefab scoped.

[jackboz]

Additional wishes on atom actions.

If I want to call an atom action in OnSomethingHook I have to do the following:

• add a OnSomethingHook component.
• add a Void Event Reference Listener.
• create a VoidEvent and assign it to the listener and the Hook
• create a custom AtomAction that does your job
• create an instance of that AtomAction and assign it on the listener to the ActionResponses

But it seems that one can avoid steps on creating an additional event and an corresponding listener. We can modify an OnSomethingHook that it can call an action directly.