An Implementation of AI in TGE
by Eric Roberts · 02/10/2007 (10:08 pm) · 1 comments
Yes - I have my own AI working in the Torque Game Engine.
It seems that a lot of people have been talking about implementing AI in Torque recently. And I've been meaning to write up a .plan about how I was going about it for a while now, and hopefully someone will learn something they like from this ;). It's nothing terribly technical in terms of AI theory (if any) - and I'm liking the setup I have for myself.
WARNING: Techy stuff follows.
Here's my setup and my late night attempt at a class diagram:
1. A Generic AIShape game object
First thing's first. I wanted a specific AIShape game object to have special AI helper attributes. Nothing too fancy. Mainly all the stuff you'd expect from a dynamic shape but with simple helper functions such as looking at a target, moving to a destination and most importantly, lots of callbacks. Such as a "think" callback for every tick is incredibly useful. There are other callbacks such as "OnTargetReached" or "canMoveToDestination". I wanted all my AI to be defined entirely in script. It's important to note that
the callbacks are calling into the object's datablock. In fact, each AIShape has its AI defined by the datablock it's using. So lots of shapes can share the same AI characteristics and attributes just from using the same datablock.
2. Yet another Finite State Machine
It seems as though this is the term everyone's been clinging to when it comes to AI. For my purposes an FSM for my AI suits just fine, and it's incredibly easy to manage and define decision based behaviour. Each AIShape datablock has it's own defined FSM. Each AIShape object has a "state" script object initialized when the object is added to the scene. This "state" object is defined as a dynamic field in script. The reason why I chose this was to allow complete freedom on how AI could be defined. It doesn't have to be an FSM - and putting the "state" object in the engine seemed unnecessary. The FSM itself is more of an ad-hoc state machine. And I'll explain how it works in the following few sections.
3. States are responsible for changing states.
This is part I was really happy with in the design. A really fitting "State" design pattern applied/extended into Torquescript ;). All callbacks called on an AIShape's datablock are delegated to the dynamic "shape" object. Each callback when called on the "state" object gets a copy of the datablock and the object it's referring to. So all AI behaviour depends on the current state - and a change in state happens inside a state callback. This system also abuses the namespace system available in Torque.
4. Delegating AI state behaviour up the namespace chain
There can be a total of 3 namespaces attached to a script object. The name of the object, it's class, and it's superclass. This allows for very flexible control over AI behaviour. Say, I pick the name of the script object state to be specific to the AIShape and the state it's in (e.g. SomeEnemyIdleState). I can then pick a classname that can be used for global state-based decisions for that particular type of object (e.g. SomeEnemyState) - so any callbacks that aren't defined on the specific namespace level are called up the chain to this generic namespace for the type of object. Finally, superclass allows for another level of laziness. I can pick a superclass name global to a specific type of AI characters (e.g. EnemyState). This last namespace is defined for a catch-all for any callbacks that aren't defined on the more specific namespaces. In this setup AI decisions can be shared between states and different AIShape datablocks. That last little point is what I'm liking the most. I would post more examples - but I can't publicly divulge too much (or rather, any) about the engine itself.
Of course this might've all been done before - I'm not entirely certain. This is just for anyone else who might be interested in an approach to implementing AI. And, despite all of that design stuff above - the AIShape itself is what took the longest time to implement properly (as in - in a working condition).
Happy Torque'ing!
- Eric
It seems that a lot of people have been talking about implementing AI in Torque recently. And I've been meaning to write up a .plan about how I was going about it for a while now, and hopefully someone will learn something they like from this ;). It's nothing terribly technical in terms of AI theory (if any) - and I'm liking the setup I have for myself.
WARNING: Techy stuff follows.
Here's my setup and my late night attempt at a class diagram:
1. A Generic AIShape game object
First thing's first. I wanted a specific AIShape game object to have special AI helper attributes. Nothing too fancy. Mainly all the stuff you'd expect from a dynamic shape but with simple helper functions such as looking at a target, moving to a destination and most importantly, lots of callbacks. Such as a "think" callback for every tick is incredibly useful. There are other callbacks such as "OnTargetReached" or "canMoveToDestination". I wanted all my AI to be defined entirely in script. It's important to note that
the callbacks are calling into the object's datablock. In fact, each AIShape has its AI defined by the datablock it's using. So lots of shapes can share the same AI characteristics and attributes just from using the same datablock.
2. Yet another Finite State Machine
It seems as though this is the term everyone's been clinging to when it comes to AI. For my purposes an FSM for my AI suits just fine, and it's incredibly easy to manage and define decision based behaviour. Each AIShape datablock has it's own defined FSM. Each AIShape object has a "state" script object initialized when the object is added to the scene. This "state" object is defined as a dynamic field in script. The reason why I chose this was to allow complete freedom on how AI could be defined. It doesn't have to be an FSM - and putting the "state" object in the engine seemed unnecessary. The FSM itself is more of an ad-hoc state machine. And I'll explain how it works in the following few sections.
3. States are responsible for changing states.
This is part I was really happy with in the design. A really fitting "State" design pattern applied/extended into Torquescript ;). All callbacks called on an AIShape's datablock are delegated to the dynamic "shape" object. Each callback when called on the "state" object gets a copy of the datablock and the object it's referring to. So all AI behaviour depends on the current state - and a change in state happens inside a state callback. This system also abuses the namespace system available in Torque.
4. Delegating AI state behaviour up the namespace chain
There can be a total of 3 namespaces attached to a script object. The name of the object, it's class, and it's superclass. This allows for very flexible control over AI behaviour. Say, I pick the name of the script object state to be specific to the AIShape and the state it's in (e.g. SomeEnemyIdleState). I can then pick a classname that can be used for global state-based decisions for that particular type of object (e.g. SomeEnemyState) - so any callbacks that aren't defined on the specific namespace level are called up the chain to this generic namespace for the type of object. Finally, superclass allows for another level of laziness. I can pick a superclass name global to a specific type of AI characters (e.g. EnemyState). This last namespace is defined for a catch-all for any callbacks that aren't defined on the more specific namespaces. In this setup AI decisions can be shared between states and different AIShape datablocks. That last little point is what I'm liking the most. I would post more examples - but I can't publicly divulge too much (or rather, any) about the engine itself.
Of course this might've all been done before - I'm not entirely certain. This is just for anyone else who might be interested in an approach to implementing AI. And, despite all of that design stuff above - the AIShape itself is what took the longest time to implement properly (as in - in a working condition).
Happy Torque'ing!
- Eric
About the author
Torque Owner Frank Carney
DemolishunConsulting Rocks!