Sponsored By

AI Middleware: Getting Into Character, Part 3: RenderWare AI

AI middleware is a new category of commercial tools for controlling the behavior of NPCs in games. This article, the third in a five-part survey, examines RenderWare AI from Criterion.

Eric Dybsand

July 23, 2003

14 Min Read

RenderWare AI 1.0

3body_arrow_sm_right.gifCriterion Software Inc.
Suite 100
Austin, TX 78701 USA
Phone: 512.478.5605

3body_arrow_sm_right.gifPrice: Varies with project.

In this is the third installment of our ongoing survey of AI middleware tools targeted at game developers, we examine RenderWare AI 1.0, a suite of C++ base classes. RenderWare AI (RWAI) was developed by Kynogon, a French company specializing in game AI (it developed the Kynogon Artificial Intelligence Modules, or KAIM), and is packaged as a part of RenderWare Platform, Criterion's suite of game development products. Discussion of the entire suite of RenderWare products, which also includes graphics, audio and physics tools, is beyond the scope of this article, which only focuses on RWAI. That being said, it would give RWAI short-shrift if we ignored the support the various other RenderWare Platform components provide RWAI (graphics representation of world data and the physics collision detection and visibility services, to name a few). Therefore, where appropriate, the services of the non-RWAI components of the RenderWare Platform will be pointed out when they can be used by the RWAI.

What does this AI Middleware product do for the game developer?

The RWAI Software Development Kit (SDK) primarily focuses on helping the game developer design and implement character behavior in a computer game. In doing so, the RWAI SDK provides services for modeling the world, the objects that occupy the world and then the characters that exercise behavior within the world. RWAI views the objects in the world as entities, in two basic forms: thinking entities and passive entities.

Thinking entities are typically NPCs, or what some games refer to as "agents". Thinking entities have a brain object that enables decision-making capabilities, which in turn can select behaviors to be carried out. Passive entities are typically objects that exist in the virtual world and interact with thinking entities, but are not under the control of the RWAI. More about entities will be presented in a moment, but first let's look at an overview of the services that RWAI provides.

The RWAI SDK provides these services in a multi-layered environment:


Figure 1. Game engine provides character and world status data, RWAI propagates input through appropriate layers and issues requests for more data or control of characters.

The Decisions layer supports the brain objects just mentioned. When a thinking entity is created, a brain object for that entity is also created and initialized. The brain object performs the decision-making process. Based on how the brain is initialized, and the current status of the entity, the brain object will select an agent (or behavior) to be carried out by the entity.

The Agents layer supports behavior packages that can be carried out by entities. So the term "agent", as used in RWAI, actually refers to a set of actions that reflect a high-level behavior. Some RWAI agents are: Go To, Follower, Follow Path, Wanderer, Runaway, Hider, Contact Combat and Distant Combat. Additional agents can be defined by the game developer and added to the brain objects.

The Services layer consists of a number of manager objects that provide specific services to RWAI and by proxy to the entities. There is a NextMove Manager which is used to find paths for characters in the world, a Graph Manager which manages path data that reflects the virtual world in which paths can be found, a PathWay Manager that stores pre-calculated paths for use by entities, a PathObjects Manager that supports access to all the non-entity objects that can participate in a path finding effort (doors, elevators, ladders), an Entity Manager which provides visibility and proximity services for entities, a SoundSources Manager which represents the audio and olfactory perception facilities for entities, and finally a NeuralNet Manager which manages all the data for neural nets used by RWAI.

The Architecture layer handles the initialization, updating and termination of the RWAI layers under the control of the game engine. The performance configuration of RWAI can be maintained using this layer, tuned to correspond to the needs of the game and platform in use. This layer is also responsible for exchanging information between the game engine and the other RWAI layers.

What are the main features of this AI Middleware product?

RWAI offers a number of AI-related services and features that are worthy of a little more detailed examination. First, the 3D pathfinding service of RWAI is supported by the cooperative functionality of several objects found in the Services Layer. The CNextMoveManager object provides the basic service of finding a path along a graph using the A* Algorithm (the A* is one of the most widely used search algorithms for computer game pathfinding functions). With the availability of the CNextMoveManager object source code, you can modify this process, as needed, to suit specific game needs. The graph used for pathfinding is supported by the CGraphManager object that manages all the PathData objects specific to a given level (or section) of the virtual world of the game. A PathData editor and Automatic Path Generation process are available for creating and maintaining the PathData objects.

Entity management can be performed in RWAI using the Entity API. Both thinking and passive entities must be created and placed in the world known to RWAI in order to affect how decisions are made and the services that can be provided. Basically, entities are created, added to the world, updated, queried for basic information (size, location, speed) and destroyed via the RWAI Entity API. The type of brain a thinking entity uses can be determined using entity management, and once the type of brain has been determined, the available default agents that the entity can use are also determined. Of course, passive entities do not use brains, they just exist and interact with thinking entities.

The RWAI provides dynamic avoidance by entities by using predefined agents (once again, "behaviors" as Criterion defines the term) such as Hider and Runaway. An entity brain can select the Hider Agent and that entity will attempt to move to a hiding place that is out of sight of the entities that are defined as being its enemies. If the Runaway Agent is selected for execution, then the entity will flee from entities that are defined as being its enemies.

The entity manager supports the 3D perception services for entity brains and agents. These services include determining the visibility of an entity, determining the distance between entities and identifying the nearest enemy entity. An optional service is a Sound Manager that provides sound event perception for entities.

In RWAI, agents represent pre-packaged behaviors that can be associated with a brain object and thus provide entities with the ability to perform these behaviors without additional user control. At the time of this writing, these agents consist of:

  • CGoToAgent - directs an NPC to a specific destination.

  • CFollowerAgent - enables an NPC to follow a specific entity, from a defined distance and at a defined bearing.

  • CFleeAgent - directs an NPC to move away from a set of locations and to stop when hidden from all of them.

  • CPathWayAgent - directs an NPC to follow a series of way points, that form a pre-determined path.

  • CWanderAgent - enables an NPC to wander to random destinations.

  • CHideAgent - directs an NPC to hide out of sight, of specific entities.

  • CShooterAgent - enables an NPC to move into a firing position and shoot at a targeted enemy with the current weapon, based on line-of-sight and weapon ranges.

  • CAttackNNAgent - enables an NPC to fight a targeted enemy in melee combat, using pre-defined strategies.

  • CTestAgent - provides a testing and debugging agent tool to the game developer for use prior to any agent modification or development.

The observant reader will notice that the RWAI agents are declared as C++ objects, and as such, are provided with public access functions to allow you to set parameters that control the behavior executed within each agent. Also, as C++ objects, if you are interested in extending your own behaviors you can derive them from the base agent objects, inheriting their basic functionality to which your own may be added.

The RWAI relies on XML file-based configurations for setting up default parameters and associating various components to the overall system. Here is an example of the XML used for configuring the main level of the game:


Figure 2. Level XML used to configure a given level of a game.

The example in Figure 2 shows the level is given a Name ("termitiere"), the value of OneMeter is provided in game units, the MaxEntity value indicates the maximum number of entities supported on this level, Tpf specifies the CPU time per frame that the core KAIM uses, and the name of the RawDataFile for the level. Additional sections of the XML file provide for declarations of Global Services, as shown in Figure 3.


Figure 3. Declaring global services in XML.

Time Slicing information in the TimeMgt section is shown in Figure 4.


Figure 4. Specifying time slice performance of path finding in XML.

These types of XML definitions continue for various sections: entities, brains, agents and services.

As mentioned above, most of the RWAI services are fully open modifiable source code, which means that extensibility and modification of RWAI by game developers is highly possible.

How does the game developer implement this AI Middleware product in a game?

As mentioned at the beginning of the article, RWAI is part of a larger suite of game development tools by Criterion, called the RenderWare Platform. If the graphics and physics components of the RenderWare Platform are also in use, then RWAI will access services provided by those components to give it knowledge about the world, line-of-sight and collision detection, and other services. In the absence of those components, RWAI will rely on your game engine for those services.

Thus, the implementation approach discussed in this article assumes the developer's game engine provides services to the RWAI. Access to RWAI through the API comes via three forms: access to the engine, to the world and to entities.

Accessing the RWAI Engine API lets you open and initialize the RWAI to set performance parameters, establish certain callbacks (to provide services such as collision and visibility detection), and set callback functions for path data services. By using the RWAI World API, the game developer can load, update and free AI World data to be used by the RWAI services for the game. If the RenderWare Platform Graphics component is in use, then the AI World gets its data from the world supported by the Graphics. Another function of the RWAI World API is to manage families (groups) of entities and to support the existence of the entities themselves. While entities are added to the AI World by using the RWAI AI World API, the entities are actually created by using the RWAI AI Entity API. When an entity is created, it is associated with an existing entity family (a group of similar entities) and then added to the AI World. Once the entity is no longer needed, the RWAI AI Entity API supports the removal of the entity from the AI World and the entity's destruction.

A set of callback functions must be associated with the entity, to tell RWAI how the entity is updated from game engine data, how RWAI control actions can be translated into a command that the game engine can understand how to execute, and how user defined decisions are made. RWAI Entities can rely on RWAI Agents for default and standard behavior. As noted earlier, there are a number of agents available for selection in order to implement this pre-defined behavior. If custom behaviors by entities are required, the set of behaviors available to entities can be extended. Extending a behavior is accomplished by deriving the developer's own classes from the KAIM base classes that form the core of the RWAI behaviors. This however, can constrain the developer by having to conform to the KAIM protocols and decision-making processes, rather than plugging his own decision-making processes directly into the KAIM.

Summary of RenderWare AI Middleware

RWAI is a powerful AI middleware SDK, and when used in conjunction with the other RenderWare Platform components, it is a robust solution. Even when you use RWAI by itself and have your game engine provide the services of the RenderWare Platform, the SDK is capable of implementing sophisticated character behavior. Such performance comes at a price however, in terms of the learning curve to be able to integrate RWAI into the game engine, and the constraints imposed by the KAIM based on how it must operate.

Read more about:


About the Author(s)

Eric Dybsand


Eric Dybsand ([email protected]) has consulted on an extensive list of computer games, including designing and developing the AI for Full Spectrum Command, a tactical command simulator used by the US Army. And he has designed strategic AI for MOO3, AI for Racing, Baseball and Wrestling games, he developed the AI opponents for the RTS game ENEMY NATIONS, and for the FPS games REBEL MOON REVOLUTION and the WAR IN HEAVEN, and a number of turn-based wargames. Eric has been involved with computer game AI since 1987, doing game design, programming and testing, and is a contributing author on AI to the Game Programming Gems and AI Wisdom series.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like