The Torque AI Pack v1.0 Overview

The code provided in the Torque AI Pack v1.0 is intended to form the basis of a user friendly but powerful AI codebase for use with all styles of Torque-engine powered games. However no single codebase can cater to all games in all circumstances. What we are intending to do here is allow you the user to be able to get up to speed producing your own AI characters and interactions as quickly as possible, while providing as much of the default behaviour as we can realistically produce.

At its core, the Torque AI Pack v1.0 provides you with an automatically generated, but hand-editable implementation of a pathfinding technology known as a navmesh. This navmesh provides the main method of moving AI Objects around a given mission map.

This navmesh technology is supported by a number of mesh modifiers along with a path generation algorithm (based off the very well known and common A* algorithm) which allows you to create a path from any node in the mesh to any other node in the mesh (note: as long as a path is possible A* is guaranteed to find that path).

At its most basic level, you can use the navmesh/navpath technology to simply provide a method of guiding your AI objects from one point in the world to another without using any of the other technologies contained within the pack.

However pathfinding is not the whole of the problem. Once you can move your AI objects around, then you must consider how they can interact with one another and with players.

The remaining parts of the Torque AI Pack v1.0 are there to make it easier for you to define AI Objects (creatures, ojbects, monsters etc) that have meaningful behaviors.

There are several important parts to making an AI object with interesting behaviour:

• The AI must be able to sense its surroundings and/or events that occur during the game
• The AI must be able to react to those senses and events in a meaningul way
• The AI must have some method of controlling what it does to allow that reaction to work

All of this of course must happen very often for the AI to be responsive in the game. Unfortunately much of this sensing and reacting can involve quite complex code and thus has the potential to slow the game down. So in addition to the above requirements, we must provide some method of fine-tuning the impact of the AI on the CPU to allow us to ensure the game maintains its performance when lots of AI is interacting. We call this system the "Task" system.

To allow the AI to sense its surroundings, we have created a class of "AISensor" objects. These are objects which exist in space and allow the AI to be reactive to thier environment whilst maintaining control of the CPU usage.

Let me explain this a little with a typical scenario: Imagine you have a level with 100 monsters on it and 30 or so AI adventurers. Each one of these AI based characters must have some method of telling who/what is near to it. Normally this would involve doing the eequivalent of a container radius seach (a search which returns which objects are within a given range of another object) every AI object update. That would mean 130 expensive searches EVERY UPDATE. Considering most of these searches would return nothing, clearly there is a lot of speed to be gained here.

With the AISensor class being based on our "Task" system, we can not only tell the sensor how often to run, but we can also dynamically update the sensor. So for instance, we can intiially set our sensor to a large range, but allow it to run only relatively infrequently. This means the expense of calculating the radius search is less. If we need the search to be performed more often, we simply decrease the frequency between sensor updates.

But this isnt the best part, the best part is that for any given update, only the sensors and other tasks which CAN be executed without affecting the rest of the games performance are run! the updates of sensors and other tasks are queued automatically and run whenever there is time to process them!

Of course, there are some tasks and senses that MUST be run every update. That is allowed also.

So we have sensed our surroundings, what happens with that sensory information?

This is where the reacting comes into play. For processing the reactions for our sensory inputs, we have used a technology that has been used in games for many years. The basic Finite State Machine is a method suitable for many different types of AI objects and forms the basis for the reactive technologies included in the current pack. A finite state machine (known as an FSM) is a very simple data structure that simply constrains itself to a single "state" and processes some code based on that state's value.

Now the FSM by itself isnt really that useful. It can determine what state we are in, i.e. idle, attacking, fleeing etc. However it doesnt by itself apply any behavior. This is left to a mechanism called an "Action".

Actions are essentially the things you can command the AI to do. You could command an AI object to perform a list of actions by hand and it would happily execute that list (which is what you might do for a scripted sequence for example). However most of the time in a game, you want the actions to be controlled by the state of a FSM, so that the FSM feeds actions to the AI Object as it changes states and attempts to react to its situation.

So what kinds of actions are available?

There are many and we have provided a mechnism to allow you to create actions entirely in script if you prefer script to the default C++ actions code.

Actions are available including:

• Look at Something
• Flee (Run away from something)
• Follow something
• Fire (Ranged attack) something (when in range/in line of sight)
• Mellee attack something (hit it if within range)
• Patrol (given a path)
• Hunt (for an object based on its last seen position)
• Stop (stop moving etc)
• Move (to location)
• Pickup (object)
• Send Message (send an event to other AI's)
• Guard (an object/location)
• Script (call scripts for control)
• Play animation
• Play sound