1. Sega 500 Intro to Bot AI Jeff “Ezeikeil” Giles jgiles@artschool.com http://gamestudies.cdis.org/~jgiles

2. 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.

3. 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.

4. 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!

5. The result Hopefully a reasonable starting point from which we can implement further changes. So, lets get started.

6. 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?

7. The Pieces A Controller A Pawn A Gametype An AI Class

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

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

14. 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

15. 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.

16. 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.

17. Giving UT a Lobotomy 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;

18. Giving UT a Lobotomy 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…

19. Giving UT a Lobotomy 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.

20. Giving UT a Lobotomy 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);

21. Giving UT a Lobotomy 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…

22. Giving UT a Lobotomy 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.

23. Giving UT a Lobotomy 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…

24. Giving UT a Lobotomy And watch the bots behaviour when I run around the back to where I can’t be seen X  Start point

25. Giving UT a Lobotomy 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)

26. Giving UT a Lobotomy 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…

27. Giving UT a Lobotomy 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…

28. Giving UT a Lobotomy Notice how much more aggressively they move about the map. Actively searching for opponents.

29. Giving UT a Lobotomy 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.

30. Giving UT a Lobotomy 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.

31. Giving UT a Lobotomy 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.

32. Giving UT a Lobotomy 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.

33. Giving UT a Lobotomy Which means…A simple HUD class. Here’s the whole thing

34. Giving UT a Lobotomy function DrawHUD(canvas C) { local pawn targetP; local float space, msg1;//positional space=8; super.DrawHud(c); foreach RadiusActorS(class'pawn', targetP, 512, PawnOwner.Location) { if(targetP.controller != none) { c.Font=c.TinyFont; targetP.Controller.DisplayDebug(c,space,msg1); }

35. Giving UT a Lobotomy 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);

36. Giving UT a Lobotomy Yeah…it’s pretty simple... Here’s all the juicy goodness we get back…

37. Giving UT a Lobotomy

38. Dude! Lots of info, Here’s a breakdown. My Info Bots controller Bots state

39. Giving UT a Lobotomy Where it’s going Destination path node Current orders Squad leader

40. Giving UT a Lobotomy 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?

41. 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.

42. Because… Using this method, shows me exactly what I need to see. Right…Now to make the AI do stuff.

43. Giving UT a Lobotomy 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.

44. Giving UT a Lobotomy And once in there, cause them to bunny hope about the level, searching for an opponent.

45. Giving UT a Lobotomy state myRoaming extends Roaming { Begin: SwitchToBestWeapon(); WaitForLanding(); Pawn.doJump(True); DoneRoaming: WaitForLanding(); WhatToDoNext(12); if ( bSoaking ) SoakStop("STUCK IN ROAMING!"); }

46. Giving UT a Lobotomy 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

47. Giving UT a Lobotomy 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.

48. Giving UT a Lobotomy 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’).

49. Giving UT a Lobotomy At this point, don’t really care what these functions do, we’re lobotomizing UT remember?

50. Giving UT a Lobotomy When they enter myRoaming state, they get all giddy and start hopping about the map.

51. Giving UT a Lobotomy 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.