Vortex AI

From C4 Engine Wiki

Vortex AI (VAI/Mutant)

Contents 1 Introduction 1.1 Key Features 2 VAI Overview 2.1 Components 2.1.1 VAI Editor 2.1.1.1 Workspace 2.1.1.2 Builds 2.1.2 Agent Initialization 2.1.3 Agent Architecture 2.1.3.1 Agent Components 2.1.3.2 VAI Layers 2.1.3.3 Agent Architecture Overview 3 Modules 4 VAI Brain 4.1 Acting 4.1.1 Goals and Behaviors within tree 4.1.2 Plan Organized as a Behavior Tree 4.1.2.1 Parallel execution 4.1.2.2 Plan in VAIEditor 4.1.3 Actions 4.1.4 Expressions 4.1.5 Composite plan elements 4.2 TO BE CONTINUED 4.3 TODO for 2011

Introduction

Vortex AI is a combination of tools and API designed for creation of sophisticated in-game artificial intelligence (NPCs).

Key Features

• Seamless integration with C4 Engine.
• Modular architecture
• Pathfinding (currently only waypoints)
• Action planner.
• C4-style scripting for conditions
• Steering behaviors
• Parallel behavior execution

VAI Overview

Components

• VAI Editor - plan editing
• Agent System - Agent API
• Agent debugger (wip) - provides debug functionality, including remote debugging;

VAI Editor

VAI Editor is a visual editor for Vortex AI. Editor allows to set up agent types, create architypes and plans. All data is saved in xml format, making it possible to read & edit by other applications if required. Everything editor does happens in a workspace. Workspace contains all agent settings and plans themselves. Workspace contains all possible agent Builds, agent Configurations and Plans.

Workspace

Workspace is a folder VAI Editor has been set to. For C4 users Workspace location might be /Data/GameAI/ . Newly created workspace will have no Agents, just default list of plan elements and modules copied from the library. User may define Modules and Actions in Workspace so that all created Builds have them available.

Builds

Builds are used during authoring only. Build can be viewed as a collection of plans and configurations which are guaranteed to work together (no worries about missing variables for some agent types, missing actions, etc). It can be used to set AI archetypes as in example below.

Picture shows example of Build setup in VAIEditor. Builds are Humanoids and Missiles. Humanoids were created to be used for some NPCs and it defines 2 distinct configurations : Soldier and Hostage. Both configurations are having same set of Actions and Modules available to them but can differ significantly in initial parameters set to Modules. Missiles is very simple Build, having only 3 actions (Idle, Chase and Explode) and some basic Modules. There are 2 kinds of configurations - missile and mine. 1 plan available for both configurations - Attack;

Later in the authoring process it is easy to add configuration for Sniper by replicating Soldier but some tweaks in initial parameters of VWeaponSystem module to enforce camping.

Agent Initialization

Agent structures can be assembled directly by a game code but VAI has more convenient way - by passing configuration files to VAI. 2 types of files are required for VAI to build a bot: *.config and *.plan, both consist of xml structures defining Agent and can be produced in VAIEditor.

• *.config - contains Agent settings in form of list of modules and module parameters (e.g. memory duration, aim accuracy);
• *.plan - defines agent behavior;

Both files must be from the same Build to guarantee compatibility (choice is up to the user, because some plans can work across builds).

Agent Architecture

Agent Components

• Sensory Module - processes sensory input from supports, maintains agent blackboard and manages implementation details of AI. Module can be viewed as a specific subsystem (weapon system, movement system, etc);
• VAI Brain - Module used only for reasoning, contains Blackboard and Plan;
• Module Support - interaction layer between the game and VAI. Main purpose of Module Support is to hide game-related details from the Modules using it.
• Agent Controller - bridge between VAI Modules and Module Supports (Can be separate from C4 Controller).
• Action Object - entity interacting with the game to fulfill the plan - game counterpart of the Action used in Plans. Action Object implements logic which actually makes character execute VAI plan according to game rules - run, jump, shoot, etc.

VAI Layers

3 layers are present. Module Supports interact with the game directly, Sensory Modules maintain memory state for VAI Brain to function. Action Objects are only exception that may violate this hierarchy and interact with all other components on all levels.

Agent Architecture Overview

Brain's Plan is only entity which is able to invoke changes to Action Objects.

Modules

VoH AI has several prebuilt modules. Module can provide specific functionality and can be added to Agents as needed.

Modules have 2 main functions within VoH AI.

• Providing special functionality for Actions
• Feeding information into Agent's blackboard in form of variables for further evaluation.

List of default modules:

Module	Description
Brain	Cognitive module, selects agent actions.
Pathfinding	Provides means of finding and following path from point A to point B (currently waypoints).
Steering	Collection of simple steering behaviors (Seek, Wander, Separation)
Memory	Keeps track of all seen actors
Targeting	Provides means of choosing and tracking targets.

For example Steering module provides force vector based on active Steering behaviors.

VAI Brain

Acting

Before behavior can take place, Sensory Modules are writing all sensory inputs into a blackboard variables, in a form, Brain can understand. Variables can be strings, integers and decimal. Plan processes filled data and it yields active Action. Action itself is simply is an entity within Plan, real action is executed with the help of associated Action Object.

• 0 - game module calls Agent::ProcessAI() to update bot behavior
• 1 - Agent calls an update on available Sensory Modules;
• 1.1 - Sensory module may ask its Module support for game-related information (e.g. player position, velocity);
• 1.2 - Sensory Support asks game for requested details (e.g. from CharacterController, Player);
• 1.3 - Sensory module writes gathered data into Blackboard;
• 2 - Agent executes simulation step on Brain;
• 2.1 - Brain processes Plan for all Plan Groups;
• 2.2 - Plan selects Action, and calls UserActionObject::Update() to advance Action Object;
• 2.3 - Active Plan element modifies Blackboard if necessary;
• 3 - active Action Object calls available Module Supports to gather additional info or execute action on the Game Side (e.g. updating location info using game data);
• 3.1 - active Action Object calls available Modules to be able to execute action on the VAI side (e.g. traversing path);
• 3.2 - Action Object changes world state (e.g. sending C4Message over network, updating HUD, simulating pressing a key);
• 3.3 - Action Object changes state of the plan (e.g. declares itself finished or failed. It can be used when logic is too complex to put it in plan expressions);

Goals and Behaviors within tree

VoH AI can be used to model Goal based and Behavior based agents. Goal-based agent can be achieved by using Planner element while other prebuilt elements can be used to construct Behavior based agents. Both approaches can be successfully used in the same Plan.

Plan Organized as a Behavior Tree

Blue - Composite plan elements. Governs action switching.
Green - Actions
Yellow - Expressions, such as start conditions and success conditions.

Parallel execution

Plan elements can be organized in groups to allow parallel execution of the plan. Plan element can be in one group at the same time and only one element from any group can be executed at the same time. All plan elements share same variables. For example NPC should be allowed to walk around and shoot or reload it's weapon (while walking). Solution using grouping would be to put all actions related to movement in one group and other actions (like aiming, shooting, reloading) into another.

Failure or success in one group doesn't interfere with other groups directly but users can create relations among Actions using variables stored in Brain or forcing to finish or fail Actions themselves.

Plan in VAIEditor

Actions

Agent interacts with world using Actions. Actions can implement things like "pursuit", "attack" or "shoot target".
While action is running, success and failure conditions are being checked. Each action can have built in success and failure conditions or can rely on added Expressions by user.

Expressions

Expressions can be used to control execution of Plan elements they are attached to. Expressions can use similar syntax that C4 uses for its expressions within C4 scripts and use variables that are written to the blackboard. List of Expressions

Icon	Name	Function
	Start Condition	Starting rule for any Plan element it is attached to.
	Success Condition	Contains rule for success of the Action
	Failure Condition	Failure rule of the Action
	Utility Element	Special Expression used to calculate utility for Plan element. Utility is used by Selector to choose the best child.
	Strategy Element	Variable to be maximized (for Planner element)
	Goal	List of variables with values plan should work towards (for Planner element)
	Resource Element	Type of precondition which can change state of the blackboard.
	Result Element	Decorator for writing variables inside blackboard upon completion or beginning of the Action
	FSM Transition	Defines a state transition for a child of FSM node

Composite plan elements

Composite plan elements provide switching mechanism within the subtree of actions. Most simple example is the default plan element - Generic.

Editor icon	Name	Description
	Generic (aka Loose Sequence)	Sequence element selects whichever plan element can be run from the list of subnodes and runs it. If subnode finishes execution with success Sequence selects next allowed plan element. If it encounters plan element which can't be run, it moves to next one. Sequence is at the root of every Plan.
	Sequence	Strong sequence is same as a Generic but enforces order. If some child can not be executed then it fails without skipping.
	Selector	Evaluates all children with Utility Expression elements. The one with highest utility value gets executed at any given time. Utility is checked each simulation step.
	Stack	Executes sub-nodes in priority. Highest priority active child node is made active. Child failure forces to search next child but child success propagates upward.
	Planner	Special node which allows to build a sub-tree based on Resource and Results of it's children.
	FSM	Finite state machine node, best used to switch between 1st level nodes.

TO BE CONTINUED

TODO for 2011

• Nested queries within expressions;
• Evaluation result cache;
• Action parameters within plan;
• Plan visual debugging;
• Parallel execution enhancements;
• Fuzzy logic;
• Asynchronous VAI integration API;
• VAIEditor enhancements;