AI Middleware: Getting Into Character, Part 2: DirectIA
July 22, 2003
This is the second installment in series surveying the landscape of game AI middleware. As the name suggests, tools categorized as AI middleware provide artificial intelligence services to game engines, and it's a segment that is emerging as a serious alternative to custom AI software systems developed for specific projects.
the most part, AI middleware finds itself located outside the game
engine and the process of producing the desired behavior of agents
or non-player characters (NPC) or decision-making objects found
in a game.
In this installment, we'll look at DirectIA, developed by Mathematiques Appliquees S.A. of Paris, France. This product can be characterized as an a behavior-oriented SDK.
Mathematiques Appliquees S.A. (MASA)
15 Mercer St, #6
New York, NY 10013, USA
Price: All packages are sold on a per platform, per title, per year, royalty-free basis. Contact for details.
DirectIA (Direct Intelligent Adaptation) is a generic game AI SDK. The SDK allows a developer to construct agent behavior for her game, which in turn relies on several DirectIA built-in engines for processing. There is a motivation engine to model the emotions and needs of the agents, a behavior engine to model the agent's decision processes, a communication engine that supports agent intercommunication, a perception engine to process input from the game world, an action engine to enable the agent to interact with the game world, and a knowledge engine to organize the agent's understanding of the game world.
What does this AI middleware product do for the game developer?
provides an agent-based behavior modeling system. With significant
considerations of how and why a character makes a decision, DirectIA
provides interesting options. Fundamentally, DirectIA processes
state variables that are influenced by emotions, which come from
stimuli. The emotions trigger motivations that are also influenced
by stimuli. Motivations can trigger behaviors. Behaviors can trigger
other behaviors, or trigger actions that best satisfy the needs
of the agent.
The actions are what the game developer sees executed as behavior within the game. This process can result in some rather complex decision-making that leads to behavior by the character.
Figure 1. Typically, character and game state status flow from the Game Engine to the AI Middleware, and then character control requests flow from the AI Middleware to the Game Engine, and are acted out by the characters.
What are the main features of this AI Middleware product?
DirectIA offers real-time decision and action behavior modeling tools, in the form of a high-level tool suite and a low-level tool suite. Within the high-level tools is support for complex agents and reactive agents (which will be discussed in detail in the next section), while the low-level tools offer pathbuilding, hierarchical pathfinding and steering tools (which are in beta at this time). The pathbuilding tools were not available at the time this article was written.
Figure 2. DirectIA's flow of information goes from stimulus to action.
Additionally, there are facilities for communication between agents (and the player) and inputs for perceptions of virtual world of the game. Agents can coordinate their activities through this communication.
The behavior engine is the main component DirectIA, and can be viewed as a set of motivations that compete within the agent to determine the actions of that agent. The behavior engine is accessed through the various script files described later in this article.
For testing purposes, a GUI testing environment is provided with DirectIA that allows a developer to display and follow the decision process of each agent while the game is playing. Also, various state variables and agent data elements can be displayed.
Figure 3. DirectIA's IXI Tuning GUI showing behaviors and how some of them are implemented in scripts.
How does the game developer implement this AI Middleware product in a game?
DirectIA is implemented in a game via script and parameter files that are initialized and loaded into the DirectIA engines at run time. The developer also needs to create C++ classes (derived from DirectIA base classes) for declaring entities, agents, actions and behaviors. Callback functions are used to perform services for the scripts. Finally, a number of DLLs are included with DirectIA as well. As you can tell, these processes mean that DirectIA is geared more towards the programmer than the level designer.
Scripts and Parameters
The engines can be tuned by editing a number of different script files. These scripts use a language similar to C++ with a DirectIA-specific syntax. Each script must be loaded and parsed to be used, but this is a fairly straightforward process - the game engine simply calls DIA_ReadScript_Engine(). Here are some of the scripts:
This script contains signatures (similar to a function prototype) of the agent script. The functions are coded in C/C++ and can be called from within scripts. Global variables are also defined by this script file. Script-based functions are also declared and implemented within this file, which can access and process data only within the scope of the DirectIA script variable and object definitions. In other words, these functions are not able to access data outside DirectIA - data governing the game world - except through the use of user-written C/C++ callback functions.
This script defines the effect (in terms of a value) that perceived objects may have on the agent. The script contains a calculation that computes the value of a particular stimuli and then calls DIA_SetStimulusValue() to make it available for use. Listing 1 shows a sample stimulus script.
declare the stimulus with a unique name to identify it
// a c callback function is called
that will return the list of all
// The loop instruction in the DirectIA
is the reserved word for the ID of the agent.
Code Fragment Copyright © MASA (Mathematiques Appliquees SA) 2002
Listing 1. Sample stimulus script
This script defines buffers that act between stimuli and state variables. The definitions in the emotion script help simulate surprise and habit. These state variables are input to the motivation engine mentioned earlier. Listing 2 shows a sample emotion script.
The emotion is declared with a unique name to identify it.
// The surprise factor is used to
simulate a boost when the emotion increase.
// define the max increase and decrease
rate of the value per time unit.
// Used to simulate the adaptation
of an agent to a stimulus
// The name of the input stimulus
used with this emotion
// The state variable that is modified
by the output of this emotion.
Code Fragment Copyright © MASA (Mathematiques Appliquees SA) 2002
Listing 2. Sample emotion script
This script sets the values for physiological or psychological states of the agent. These state values are used by other scripts to help make agent decisions. Think of these values as control attributes used by the agents.
This script sets variables for a particular motivation by using state variables that were set by stimuli and emotions. The variables are then used by the motivation engine. This script also defines the behavior code (found in behavior scripts) that is executed to respond to this particular motivation.
This script sets parameters for the behavior engine, mentioned earlier. An agent's actuators (which limit the actions an agent can simultaneously perform) are listed in the behavior script. The behaviors and actions that can be performed by an agent are also defined and implemented in this script file.
Initializing and using DirectIA
Initializing and using DirectIA is performed with your game code. Initialization is best performed before the main loop of the game begins to run. Parse the "types" file by calling DIA_ReadScript_Types() with the name of the file. Optionally, you may parse the "workspace" file by calling DIA_ReadScript_Workspace() with the name of the file. However, if the game does not need any global script variables or C/C++ callback functions, then this step can be skipped.
The objects controlled by DirectIA should be game object classes derived from the DIA_Engine class. Game objects that do not use the DirectIA engine, but are still manipulated by DirectIA would be derived from the DIA_Thing class. An agent would be derived from the DIA_Engine and an object that the agent uses (like a magic wand) would be derived from the DIA_Thing class. In either case, the developer must include a const char *GetName() function implementation in those derived classes.
You create and register models or a defined type of agent using the DIA_Model class. This way you don't have to parsing the script files for each agent-the script files are read once for each type of model, and the models are copied to the agents as necessary. Once the models have been read (a copy step similar to that just mentioned), the engines initialize.
Updating agents involves an iteration of the DirectIA engine, and is performed within your game loop. DIA_Workspace::GetTime() is called to calculate the elapsed time since the last iteration. Then DIA_Engine::ComputeActions() is called to update the engine and have the agents select the best actions for satisfying motivations and reacting to the environment. This evaluation function is not called as often as DIA_Engine::ExecuteAllActions(), which executes the selected actions that were not completed.
Of course, any C/C++ functions that are called from the scripts need to be written and must conform to a specific prototype as defined by DirectIA. Additionally, these functions must be registered before use.
DirectIA is a very agent-centric tool. Its sophisticated behavior engine relies on its own built-in functionality tuned via script files to meet an agent's decision-making needs. The DirectIA decision-making process is very "state" oriented, at least from an external point-of-view. Since using this tool involves extensive coding (creating and updating scripts, developing C/C++ callback functions, deriving game world objects and agents from DirectIA base classes, embedding DirectIA API calls within the game code, and so on), it's not as accessible to level designers as the tool surveyed yesterday, AI.implant. Instead, I believe the proper use of DirectIA would require a programmer/designer team working together to access the powerful behavior engine of DirectIA.