with you being busy creating Traversal and all, I'd like to propose some ideas we (me and some colleagues and students) have collected over time, also having tried out several other Trigger-Action-Condition based systems and also having talked to several developers from established companies (like Deck13, Ubisoft, CryTek) as well as indie devs.
So here are the points, roughly sorted by the priority we feel they have:
- ScriptableObject based approach for all Actions/Triggers/Conditions instead of Monobehaviour.
Generally putting Monobehaviors on empty GameObjects just to have them in a scene doesn't feel right. GameObjects have a Transform and represent things that have a position in 3D space and are part of a visible scene. So having an empty GO as a point to spawn gun muzzle is ok, but putting a GameManager etc. into a scene just cannot be right. It would be a much cleaner design. This would also make scene-independent logic possible. The behavior module is already doing this.
- Blackboard-based approach for all variables. Every field of an Action/Condition can by-default be populated with a variable value from a blackboard. This is kind-of implied by the ScriptableObject-based approach, that cannot directly reference GameObjects in the hierarchy.
- Remove the naming confusion between "Actions" (an Actions-Object), Actions (the plural of one Action), and Action (one single Action):
-> "Conditions" should be more generally called FlowControl-Nodes or FlowControl-Objects, so all the nodes that somehow define the flow can be in this category, not only If-Then-Else but also switch and branch nodes of all kind.
-> An Actions-Object should be called "ActionSequence". Because it is a container class and that name is very intuitive.
-> One graph containing Triggers, ActionSequences and FlowControls could be called a "Flow"
- Provide a node-based tool to arrange the nodes of a Flow-Graph visually. This works well, as a Flow usually does't contain too many Actions. An ActionSequence can be a single node that is expandable, like the inspector view now, but in a graph-node.
- Have some powerful FlowControls by default, like a weighted random selection of one (or more!) ActionSequence (with options of, e.g., never selecting twice) with weights being modifiable at runtime, and also potentially multiple ActionSequences being picked for execution. Such stuff can be extremely important for story-driven games and dialog-logic.
- Have an Action that waits for an event (like a trigger in the middle of a sequence). This makes powerful synchronization between Flows possible.
So these are the distilled points that came up over time and from lots of hours of collaborative thinking and using such systems.
I hope this can help make Game Creator even greater and introduce and establish this fantastic approach to an even broader community.
with best regards
Customer support service by UserEcho