- Home /
Too subjective and argumentative
Implementing a game state system
I am implementing a turn based strategy game and was thinking about what the convention in Unity is to handle state transitions and logic. If I were to code it myself I would implement it using a stack whereas each object in the state implemented an interface "GameState" and each of these states has its own update logic and state info. The top most state is the "active" state and can transition be either adding a new state on the top of the stack or to pop itself off the top (returning "active" to the state below it).
Initially I thought of implementing a single monoBehaviour for each state and have a "master" monoBehaviour hold the stack. I would add the monobehaviours to the gameObject when I add them to the stack and remove them when popping. I would make sure setActive(false) is set for all monobehaviours not on top of the stack. However this doesn't seem to work as you cannot pass an instance of a component to addComponent() and the gameStates require construction parameters.
My next thoughts were to not implement monobehaviour on the states and rely on the "master" monobehaviour to call update manually on the top state. This seems to go against the Unity Model though as I would be re implementing parts of the standard monobehaviour interface (update, awake, destroy e.t.c.).
What would be the optimal way to acheive such a state system?
" If I were to code it myself I would..."
The optimal way is the one which you can code and maintain for your platform and performance requirements. Open-ended discussions like this are better suited for the Forums as your reponses here are likely to be subjective.
Follow this Question
Related Questions
Switch animation state while keeping animation timing 0 Answers
Checking Transitions in Animator 0 Answers
Can an empty state in Animator cause performance issues? 1 Answer
moving gameobject from state machine behaviour/different code result from inside OnStateExit() 1 Answer
Calling a function outside the Finite State Machine 0 Answers