koobas.hobune.stream
Best Practices for switching player control logic
Hi all,
I'm working on 3D platform game where player will be able to moving object, jumping, climbing and use vehicles, etc.
Currently I'm looking for good idea for switching player control logic depending on the player state.
e.g.
normal state - player can walk in any direction (forward or back and rotate around) by gamepad joystick,
climbing state - player can move up/down or move left/right along the wall.
Currently I have three ideas (not sure if any of them is the right one)
switch statement in all MonoBehaviour methods (e.g. Update, FixedUpdate, OnCollisionEnter...) - looks ugly,
simple interface for logic object and call current in all used MonoBehaviour methods - looks better but there is the risk I will have to create interface with all MonoBehaviour methods,
MonoBehaviour which will enable/disable MonoBehaviours whith state logic - player object could looks ugly in editor with a lot of attached scripts.
Which do you use or do you have better idea for it?
Thanks in advance
It looks like normal State Machine: player can be in one state at the time - either climbing or walking, but not both simultaneously.
Switch statements will quickly become a nightmare. Better avoid any logic with switches.
MonoBehaviours in fact looks ugly and introduces additional work with attaching and configuring them. Why would you need MonoBehaviours with 'enable'/'disable' flag if you could do the same with pure classes and switch between them?
The trick here is to encapsulate all logic inside the state and implement state transitions.
I'd create a pure class (no reason for it to become Monobehaviour) which contain state logic (Update, FixedUpdate, ...) or even separate classes for each method (if they will become large enough - to support SRP principle of SOLID. Wrapping them with interfaces (as you mentioned) seems like nice addition.
Well, those classes could be ScriptableObjects, for flexibility and easy configuration (you could combine separate pieces of logic via inspector in endless combinations), but that depends on your needs.
Then I'd create StateController - either pure class or ScriptableObject which will contain transitions between states, eg:
interface IStateController {
void SwitchState(int newStateId);
IState CurrentState();
or
IState GetState(int stateId);
}
So your MonoBehaviour will become simple data and links holder, which calls required state/logic when the event occured:
IStateController.CurrentState().UpdateLogic().Invoke(...);
or
IStateController.CurrentState().Update(...);
You will easily modify monobehaviour, Controller or any piece of logic because those classes are separate and simple, and that system is easily expandable.
