sega 500 intro to bot ai jeff “ezeikeil” giles [email protected] jgiles

Sega 500

Intro to Bot AI

Jeff “Ezeikeil” [email protected]://gamestudies.cdis.org/~jgiles

mailto:[email protected]

http://gamestudies.cdis.org/~jgiles

What Today Is

The plan is to look into what makes the AI in UT2003 tick and figure out some of it’s dependencies.

Also to see how we can influence it’s decision process.

What Today Isn’t

This is not a lesson on how to build a whole AI system given that doing so is a course on to itself.

Starting simple

Bare in mind that the exisitng AI code and it’s dependencies are HUGE and have with little documentation.

The result is that they bring much pain and suffering in figuring out the code…

Hence today’s code changes will have small effects on the pawn as figuring out this much took over a day and a half!

The result

Hopefully a reasonable starting point from which we can implement further changes.

So, lets get started.

What’s needed?

What are the 4 known components (classes) needed to get the AI system up and running?

( We’ve talked about some of these before )

Anyone?... Anyone?...Bueller? ...Bueller?

The Pieces

A Controller A Pawn A Gametype An AI Class

And…

The AI system in UT2003 is heavily dependant on states, so a good firm grasp of states, state programming and it’s inheritance rules is very much essential.

A controller

Controller. ( We’ve already talked about these.) They are the base class of players or AI. Controllers are non-physical actors that can be

attached to a pawn to control its actions AIControllers implement the artificial intelligence for

the pawns they control. Controllers receive notifications for many of the

events occurring for the Pawn they are controlling. This gives the controller the opportunity to implement the behavior in response to this event, intercepting the event and superceding the Pawn's default behavior.

A Pawn

Something to control. (And these) Pawns are the physical representations of

players and creatures in a level. Pawns have a mesh, collision, and physics.

Pawns can take damage, make sounds, and hold weapons and other inventory.

In short, they are responsible for all physical interaction between the player or AI and the world.

A game type

To specify which controller the bots are to use.

This can also be done via a mutator, but this is not a real good idea as the AI rules may not be synonymous with the game type.

The AI Class

What team, squad or deathmatch AI methods to use.

This determines just how a specific bot will related to its team mates.

PlayerReplicationInfo

Which basically says what’s doing what & how to replicate the game over a network.

Bare Bones

This is the core requirements that I’ve found to make changes & have an impact on the AI system.

There are other items which influence the Bots are such as AIScripts and ScriptedAction’s

So roughly

If we map out the basic class dependencies, we sort of see how things relate.

Keep in mind, this is a very simplified version.

Giving UT a Lobotomy

Getting down to the code, we’re quite probable going to cause the AI to behave erratically…such is the nature of playing with one’s neural pathways.

In effect, we’re going to cut out a portion of the decision process & insert our own.


For simplicity, I’m creating a very simple gametype which is now derived off team Game

class AITest extends xTeamGame;

Doing so, allows us to only have to create one class at this time…Which is my new AI controller class which I deriver from xBot.

class EzeAI extends xBot;


For now, I’m not going to do anything different. We just need the definition at this point.

And then in my AITest gametype, I create the following function…


function PreBeginPlay()

{

class'xGame.xPawn'.default.ControllerClass=class'Eze.EzeAI';

super.PreBeginPlay();

}

Which simply tells our xPawn which AI controller to use by over riding the defaults.


If you build & run now, you won’t see any changes. But it is using our new controller.

To prove it, I kept the old killed function from this game type and inserted a log entry.

log(" ----> Player: "$Killer.pawn.PlayerReplicationInfo.PlayerName$" is a “$Killer$" controller and a "$killer.pawn);


Which simply spits out the player name, controller and pawn type.

The log reads:

ScriptLog: ----> Player: Hyena is a eze1.EzeAI controller

and a eze1.xPawn

Where eze1 is my test map…


So, as you can see our Ai controller is in use, but it behaves exactly like the xBot controller.

But before we go about changing the AI properties, let me show ya something.


I’m going to whip up a large, yet very simple map so that I can be outside of the pawns line of sight.

One start point…no pathing node, objects, nothing…


And watch the bots behaviour when I run around the back to where I can’t be seen

X Start point


Notice that the AI gets rather dense and just tends to stand around.

(a bit less so if version 2225 and the bonus pack are installer)


This is because the path nodes, pickups and other placeable objects are integral to how the bots path finding is calculated

Notice the difference once I add a bunch of path nodes…


Once I build the network after clicking the build paths button I’m rewarded with this:

Which is in effect a network of pathways where the bot CAN go…watch the bots move now…

Giving UT a Lobotomy Notice how much more aggressively they

move about the map. Actively searching for opponents.


Right, so this being said, other than watching them…Is there a way to tell just what the bot is doing or thinking.

Yes there is, but I’m not talking about logging piles of information out to file or even using the debugger.


If you poke through the code, you’ll find a fairly frequent occurrence of a function called DisplayDebug.

Which does just that…spews debug info to the HUD.


Oh, dear sweet lord! In all your divine wisdom and glory…Where, prey tell, do I sign up for that!!!

Actually it’s pretty easy, no contracts in blood either.


If you look in the controller, you’ll find

function DisplayDebug(Canvas Canvas, out float YL, out float YPos)

Which does just that…sweet! It’s done for us! We just need to know how to access it.


Which means…A simple HUD class.

Here’s the whole thing


Most of this code is self explanitory, The part we’re really interested in is:

We access the nearby controllers and draw the debug info to the screen.

targetP.Controller.DisplayDebug(c,space,msg1);


Yeah…it’s pretty simple...

Here’s all the juicy goodness we get back…


Dude! Lots of info, Here’s a breakdown.

My Info

Bots controller

Bots state


Where it’s goingDestination path node

Current orders Squad leader


As you can see, this yields us lots of information, I’ll let you poke about it at you leisure.

But why am I doing it this way? Can’t I just use the ‘showdebug’ command to display this information?

Why?

We’ll, yeah I can.

However, doing so shows all sorts of information I’m not really interested in right now.

And it’s fairly specific to my pawn and controller.

Because…

Using this method, shows me exactly what I need to see.

Right…Now to make the AI do stuff.


Simply, we’re going to insert some functionality into our EzeAI class.

Just to see if we can get it to work, I’m going to create a new roaming state…which is the easiest to get into.


And once in there, cause them to bunny hope about the level, searching for an opponent.


state myRoaming extends Roaming{Begin:

SwitchToBestWeapon();WaitForLanding();

<SNIP!>

Pawn.doJump(True);

DoneRoaming:WaitForLanding();WhatToDoNext(12);if ( bSoaking )

SoakStop("STUCK IN ROAMING!");}


So, here’s what’s going on. We’re using and abusing the state inheritance rules so that we don’t have to write the whole state structure again…that would be bad.

state myRoaming extends Roaming


Remember our state inheritance rules: If a state doesn't override a state of the same

name in the parent class, then you can optionally use the "extends" keyword to make the state expand on an existing state in the current class

What this means to us is that we keep all the functions, but override the labels… Hooray for inheritance.


But how do we get into our state?... The bot class has 2 functions for causing

a state change to roaming function Restart() & function

SetAttractionState() It’s inside these where I found gotostate(‘Roaming’), I changed it to gotostate(‘myRoaming’).


At this point, don’t really care what these functions do, we’re lobotomizing UT remember?


When they enter myRoaming state, they get all giddy and start hopping about the map.


For additional states & functions to over ride to cause changes in the bot.uc class & have a look.

Most (but not all) of the bots are behaviours are done here.

Additional changes are done at the squad level, which we’ll look at tomorrow.

sega 500 intro to bot ai jeff “ezeikeil” giles [email protected] jgiles

Documents

ai rules

ai classwhat team

exisitng ai code

deathmatch ai methods

pawns default behavior

team mates

game typeto

codehence todays code