Garshasp Development Blog

One feature which has been implemented in the Hierarchical State Machine we are using is the ability to support parallel states. Parallel states are usually drawn on a standard state chart diagram such as UML state charts inside one state, separated by dashed lines. A fork would be necessary to divide the incoming transition into two parallel tasks. Leaving any of these states would cause a transition from the parallel state.

An example for using parallel states in the AI of the main character would be a jump state where it would be possible to move forward during jump if the player presses the navigation keys. In this case, the jump itself is composed of a few sub states and a parallel state. Moving or not moving are the sub states for one of the parallel states. Pressing any navigation key would cause the player to move, change to moving state, not pressing causes a transition to stationary state. These change of states happen in parallel to the rest of the states related to jumping action.

This way it would be possible to add more dimensions to the behaviors of the PCs or NPCs.

Since we currently have a symbol definition system in order to store and evaluate variable values in the scripting system, it would be possible to simulate the join feature after a parallel state also. A join would mean that the process would stop continuing until both of the parallel sub states have made the exit transition. The two praralle states set a symbol upon exit, this join state would check for the two symbols, if they are both set, it would make the exit transition. Haven’t used this feature yet.

For the main decision making process of the AI in the game, we use the good old state machines. Very recently we tried to make these state machines data driven so that it could be tweaked by the designers easily and provide us with much more flexibility.

The grand design was borrowed from an interesting article in AI Game Programming Wisdom4 about hierarchical dynamic state charts. It has been implemented now in the engine and integrated with the in house scripting system from the top layer and the core Game Object component system from the bottom layer. All NPCs benefit from the data driven state machines now which use a basic XML file for their configurations. This xml definition is the standard SCXML used for defining state charts, like the UML state charts. A graphical tool has been implemented in Iranvij (the world editor) as part of the Behavior Tools we had planned to build. The state chart nodes can be created and connected using this graphical tool and once the architecture for the state chart is set, events can be set on the transitions and scripts added to the state entry/exit functions.

The functionality seems to work fine currently, once concern is performance as usual since this decoupled flexible design is not necessarily in line with improving performance (is there any design goal for software in line with improving performance at all?). For this we would have to profile a busy scene and really find out.

This new design transfers a lot of game logic outside the main engine code and into the scripting system. The scripting system we use currently requires simple commands to be developed in the engine and called from the script, we have to see how far we can go with this design, we will eventually either extend our scripting features or switch to a standard scripting language such as Lua or Angelscript and integrated that with the engine code.

The only dude in the game which is not data driven as far as the AI currently is the infamous Garshasp himself. Once we’re sure everything is going good with the new design, Garshasp will delegate its behavior definitions to a few data files outside the executable binary.