The Flow System
Similar to the 'Sequencer' system, the Flow system was implemented and iterated on during my time at Cortiical. It ended up much more fleshed out than the sequencer system, with more actions and a more stable pipeline.
The flow system consists of 3 types:
- FlowHost
- FlowAction
- FlowCondition
The flow system consists of 3 types:
- FlowHost
- FlowAction
- FlowCondition
Flow Host
The Flow Host contains the list of actions to take. It derives from Monobehaviour, and thus sits in the scene. The purpose of the Flow Host is to be completely modular. It can run the main logic thread of your game, or it can run a single moving platform.
A simple FSM allows scripts to query the status of the FlowHost, with support at both Host and Action level for mid-flow cancellation.
A simple FSM allows scripts to query the status of the FlowHost, with support at both Host and Action level for mid-flow cancellation.
Flow Actions
Flow Actions are the substance of the flow system. Each type of action defines a beginning and a completion. The progression of the flow will not continue until an action declares it is complete, leading to easy creation of "WaitFor" or "WaitUntil" actions. Actions also implement a similar FSM to their Host, controlled at a high level by the Host and a low level by the Action logic.
Creating actions is as easy as creating a new class that derives from FlowAction. Using OdinInspector, once you have done this, as soon as you press the '+' symbol in FlowHost, your action will appear in the list of possible actions to add.
As FlowActions are serialized classes, as soon as they are added the the FlowHost, they also expose their public variables. This allows you to customise the inputs for each action separately. As the actions sit inside the scene, you can easily reference scene items without using a reference system, unlike if the actions were based on ScriptableObjects.
Creating actions is as easy as creating a new class that derives from FlowAction. Using OdinInspector, once you have done this, as soon as you press the '+' symbol in FlowHost, your action will appear in the list of possible actions to add.
As FlowActions are serialized classes, as soon as they are added the the FlowHost, they also expose their public variables. This allows you to customise the inputs for each action separately. As the actions sit inside the scene, you can easily reference scene items without using a reference system, unlike if the actions were based on ScriptableObjects.
|
|
Flow Actions like TriggerFlowHost or FlowBranch allow you to attach FlowHosts to each other, creating larger trees of logic. FlowBranch in particular allows the integration of FlowConditions to decide how to split the flow. This can lead to Behaviour Tree functionality if applied correctly.
Flow Conditions
FlowConditions allow for packaged conditional logic to be fed into certain FlowActions. A FlowCondition returns an Evaluate function with either a boolean or integer value. By deriving from this class, you can create custom conditionals easily, allowing you to branch and evaluate your current game state.
The following is a simple implementation that allows you to choose a flow host to run based on the currently loaded environment. If it is Env_Scene_01, it will run the seating flow host, else if it is Env_Scene_02, it will run the game object flow host.
The following is a simple implementation that allows you to choose a flow host to run based on the currently loaded environment. If it is Env_Scene_01, it will run the seating flow host, else if it is Env_Scene_02, it will run the game object flow host.
Source
I am currently sorting out licensing of this system with a client, I will be uploading it to github once it is complete, and linking it here.