X hits on this document

PDF document

Enhanced NPC Behaviour using Goal Oriented Action Planning - page 55 / 110





55 / 110

    • 3.11

      FSM Design

      • 3.11.1

        The Finite State Machine architecture

It was decided to go with Buckland’s design for FSMs (Buckland, 2005) due to the available source code, documentation and relatively straight-forward implementation. Buckland encodes FSM states as C++ templates and encapsulates the actual state machine and state implementation in two single header files. The programmer then just has to implement the designed FSM states including the state transition logic, set an initial state for the state machine and then update it every frame. Each state has three primary functions; Enter, Execute and Exit. When a state is first initialised, the Enter function is called. Every time the state machine is updated, the current state’s Execute function is called. When the current state of the FSM is changed, the current state’s Exit function is called before the change is finally made. State transition logic is placed in both the Enter and Execute functions. States can transition if a state completes in the virtual world or if something occurs in the world that invalidates the state. The rest of the FSM design dealt with determining all the possible states and coming up with what the state transitions are between them.

The states designed as part of this project are outlined in Appendix B.

3.11.2 The FSM Controller

The FSM controller was designed to extend the base AI module. It has much of the same functionality as the GOAP controller, in that it updates the various subsystem managers but instead of updating the goal manager it just updates a reference to the state machine which runs the current states’ Execute function.


Document info
Document views400
Page views404
Page last viewedSat Jan 21 23:49:20 UTC 2017