Unity State Machine Architecture for Organizing Unit Behaviors

    The first stage in the development of my game was the development of the RTS engine. I plan to write a series of posts about the problems that have arisen and their solutions on this blog. In this post I will tell how I organized the behavior of units.

    Thinking about where to start this RTS engine in general, I came to the conclusion that it is worth starting with specifics and moving from it to abstraction. The first application that came to mind was the collection of resources, or rather, the extraction of wood.

    Usually this process in most strategies consists in the fact that the employee, upon receipt of the decree to cut the tree, goes to the tree, for some time waves a pickax near him with an ax, then goes to the warehouse and starts again.

    That is, the process looks something like this:


    So that this picture could really claim the name of the automaton, it lacks the conditions for transitions between states and the initial and final state.

    Everything is simple here: the machine is initialized with the state “I am going to chop”, and the end of the work occurs during the change. We can express the transitions between states using the following conditions: “reached the tree”, “chopped up a full pile of firewood”, “reached the warehouse”, “surrendered resources”. With a positive answer, the machine goes into the next state, with a negative answer it remains in the current state.


    In each state of the automaton, the corresponding action is called during iteration. A set of actions can also be performed during the transition between states.

    For example, when iterating in the “Hand over” state, the resources from the unit’s backpack will be transferred to the player’s resources store, and when switching from the “Going to chop” state to the “Ruble” state, the corresponding animation will start.

    I also note that walking itself is not an “atomic” operation, it is found in many behaviors and is itself a behavior, and therefore, in fact, the behavior of tree extraction uses the behavior of walking within itself. That is, a new automaton can be obtained using the composition of several other finite automata.


    By writing behaviors in this way, we get an architectural boundary between the details of the implementation of the behaviors and the high-level policy for managing these behaviors. Implementations of behaviors become essentially plugins for the rest of the game, that is, changes in them will not affect the correctness of the work of high-level logic.

    These behaviors work by calling the iteration method from the Update event of objects of type Unit (this event fires every frame). To communicate with the rest of the world, IStateMachineListener methods are called.

    This is an example of a state machine construction in my game. Upon receipt of a construction team, the unit goes to the specified point, and then enters the state of direct construction, transferring the building units to the building. When the building has accumulated enough building units, the construction machine ends and the unit receives a new behavior, the default behavior.

    That's all. If you like or dislike this format, then write about it in the comments!

    Also popular now: