AI Package
by Phil Carlisle · 01/02/2006 (4:45 pm) · 17 comments
If I were superstitious I would think fate was trying to tell me something about this year. Not only did I get assualted by a drunk on Christmas Eve, but I was hit by a blackout for a good couple of hours on New Years Eve this year too.
But I'm not taking any notice, as this year is starting really well.
So I'm working on the AI Pack as a top priority this next few weeks. There is so much to document and make sure the API really sits at the right level.
One of the problems with the pack that Justin identified a while ago was that our early pack stuff had really just concentrated on adding AI functionality at the AIPlayer level. So for instance everything worked by passing pointers to AIPlayers around.
This was fine if you were only using AIPlayer type scenes. But obviously it doesnt help for things like vehicles, for GameBase style objects etc. The trouble is that as you go up the dependancy tree, you get extra functionality. This is a problem, because the "Actions", those particles of things the AI can do, well they are dependant on which object the action is running on. For instance, having something derived from our AIGameBase play an animation isnt possible, because animation support is added in the ShapeBase class.
The last thing I want to do is bloat out Shapebase any more with AI functionality. To me it is pretty obvious the place where AI functionality needs to be is within either GameBase or within an optional class derived from it. So far we have derived an AIGameBase from GameBase and have then given you the chance to derive ShapeBase from that instead of gamebase, or if youre feeling a tad more adventurous allowing you to derive from AIGameBase and copy the ShapeBase functionality into an AIShapeBase.
But it all feels somewhat dirty to me. Having an object at the low level is a requirement, however it adds functionality that then isnt required for every object after it. I'd much rather have this as a component model so that objects do not simply inherit AI functionality. But I guess thats an argument for another day :)
So what will the AI pack contain initially?
Pathfinding (Navmesh/Navgraph based A*, with additional path smoothing thanks to beffy)
Steering behaviors - Including all the "standard" behaviours, flocking, herd kind of stuff
Finite State Machine based control (mixture of C++ and script)
Task system - This allows the AI to control its CPU usage per frame
Sensor System - based on the task system, so you can sense the environment to trigger systems or attach sensors to objects to make them activate at a given point. Using the task system to control the CPU hit for what might be expensive operations
Action based control system - Actions are the particles of action a given AI can do. Like move to something, pick something up, run from something, follow something etc.
Event system - Messaging between AI systems
The idea of the task system might seem new to folks, so I'll explain it a bit.
The problem with AI is that if you run it every frame and do something expensive to calculate, you run the risk of slowing the game down a lot. Most commercial games allow for this by splitting anything expensive to calculate over multiple frames. We do this in the pathing system for example. However another idea is to use whats called a "Micro Task" which means we allow things to be stuck in a big queue of things to compute and only compute what we have time to do in that frame, doing the rest as time permits.
The Tasking system allows you to fine-tune the AI performance for different parts of the system (usually based on sensors) by allowing you to control how often a task is run. Giving it a frequency that allows you more control so that you can start off by having a very general "something is within range of interest" running every 5 seconds, then switching that up to "constant tracking" every .1 second, then back to 5 seconds when the thing goes out of range etc.
Anyway, we are trying to complete a number of demo's to show off the whole functionality of the pack. Right now this will show off how to setup reasonably simple scenarios for your games in as simple and easy to use a manner as possible.
I can see that we are going to have to expand the pack in a later update to include a more squad-based solution (believe me there is a lot to take into account there, but having the basics will help that come together a whole lot faster). That will likely be our main focus after the first pack is done.
Anyway, on with it, wont get done by itself :)
But I'm not taking any notice, as this year is starting really well.
So I'm working on the AI Pack as a top priority this next few weeks. There is so much to document and make sure the API really sits at the right level.
One of the problems with the pack that Justin identified a while ago was that our early pack stuff had really just concentrated on adding AI functionality at the AIPlayer level. So for instance everything worked by passing pointers to AIPlayers around.
This was fine if you were only using AIPlayer type scenes. But obviously it doesnt help for things like vehicles, for GameBase style objects etc. The trouble is that as you go up the dependancy tree, you get extra functionality. This is a problem, because the "Actions", those particles of things the AI can do, well they are dependant on which object the action is running on. For instance, having something derived from our AIGameBase play an animation isnt possible, because animation support is added in the ShapeBase class.
The last thing I want to do is bloat out Shapebase any more with AI functionality. To me it is pretty obvious the place where AI functionality needs to be is within either GameBase or within an optional class derived from it. So far we have derived an AIGameBase from GameBase and have then given you the chance to derive ShapeBase from that instead of gamebase, or if youre feeling a tad more adventurous allowing you to derive from AIGameBase and copy the ShapeBase functionality into an AIShapeBase.
But it all feels somewhat dirty to me. Having an object at the low level is a requirement, however it adds functionality that then isnt required for every object after it. I'd much rather have this as a component model so that objects do not simply inherit AI functionality. But I guess thats an argument for another day :)
So what will the AI pack contain initially?
Pathfinding (Navmesh/Navgraph based A*, with additional path smoothing thanks to beffy)
Steering behaviors - Including all the "standard" behaviours, flocking, herd kind of stuff
Finite State Machine based control (mixture of C++ and script)
Task system - This allows the AI to control its CPU usage per frame
Sensor System - based on the task system, so you can sense the environment to trigger systems or attach sensors to objects to make them activate at a given point. Using the task system to control the CPU hit for what might be expensive operations
Action based control system - Actions are the particles of action a given AI can do. Like move to something, pick something up, run from something, follow something etc.
Event system - Messaging between AI systems
The idea of the task system might seem new to folks, so I'll explain it a bit.
The problem with AI is that if you run it every frame and do something expensive to calculate, you run the risk of slowing the game down a lot. Most commercial games allow for this by splitting anything expensive to calculate over multiple frames. We do this in the pathing system for example. However another idea is to use whats called a "Micro Task" which means we allow things to be stuck in a big queue of things to compute and only compute what we have time to do in that frame, doing the rest as time permits.
The Tasking system allows you to fine-tune the AI performance for different parts of the system (usually based on sensors) by allowing you to control how often a task is run. Giving it a frequency that allows you more control so that you can start off by having a very general "something is within range of interest" running every 5 seconds, then switching that up to "constant tracking" every .1 second, then back to 5 seconds when the thing goes out of range etc.
Anyway, we are trying to complete a number of demo's to show off the whole functionality of the pack. Right now this will show off how to setup reasonably simple scenarios for your games in as simple and easy to use a manner as possible.
I can see that we are going to have to expand the pack in a later update to include a more squad-based solution (believe me there is a lot to take into account there, but having the basics will help that come together a whole lot faster). That will likely be our main focus after the first pack is done.
Anyway, on with it, wont get done by itself :)
About the author
#2
01/02/2006 (5:29 pm)
This is really impressive. I can't wait to see how it works.
#3
01/02/2006 (5:48 pm)
I am looking very forward to this. It will greatly ease my game development. Thanks for doing this. :-)
#4
01/02/2006 (6:04 pm)
In the past, I've created a separate abstract AI "Brain" class that can be multiple-inhertited by classes such as AIPlayer or Vehicle. Sub-classes can friend the brain class. That way you can have a nice portable brain solution that interfaces with all other classes without bloating them up.
#5
01/02/2006 (6:32 pm)
Thanks Andy, yeah, myself and Tom B were just talking about that idea. I think I'll go for that option. It seems nicer than using a derivation based approach.
#6
Just some thoughts.
01/02/2006 (6:41 pm)
I don't know anything about the details of the work, but from a cursory glance it looks like you could use the Adapter patterns to create an abstract AIObject interface (adapted from GameBase or ShapeBase or whatever) and have AIObject use a Strategy pattern to select the AIBrain implementation.Just some thoughts.
#7
Nick
01/02/2006 (8:36 pm)
Thanks for the update Phil. I've been following this for 1-1/2 years and really looking forward to using this in our game.Nick
#8
01/03/2006 (1:32 am)
Phil, this AI pack.. is it torque based? or torquescript based? I use T2D, so if the solution you are implementing is generic enough to work across Torque products (or even wider) that would be super sweet!
#9
I'll have a go at integrating it into the latest T2D when we're done with 1.4 and TSE.
01/03/2006 (10:56 am)
Hmm, good question Jason. The answer is, for the most part its C++ with some torquescript. So its possible it would work with T2D. I'll have a go at integrating it into the latest T2D when we're done with 1.4 and TSE.
#11
Can one create a nav mesh for a road surface by two splines?
Tnx
01/04/2006 (3:07 am)
Phil, how easy can the AI Pack be adapted for a car driving simulator?Can one create a nav mesh for a road surface by two splines?
Tnx
#12
The driving of the car would be like any other vehicle.
01/05/2006 (12:26 pm)
Hmmm, now theres a question. I dont see why you couldnt edit the navmesh to approximate a spline curve. We dont have any code in there to generate curves, but you could adapt the code from the pathmanager which does splines to add navmesh nodes.The driving of the car would be like any other vehicle.
#13
Will it be possible to create a navmesh on top of a DIF and/or join several navmeshes belonging to different DIFs (i.e. parts of a road)?
01/06/2006 (12:02 am)
That's an idea, PhilWill it be possible to create a navmesh on top of a DIF and/or join several navmeshes belonging to different DIFs (i.e. parts of a road)?
#14
p6.hostingprod.com/@bullpendesignstudios.com
01/06/2006 (3:00 am)
A few updated screenshots of the nav stuff can be found here:p6.hostingprod.com/@bullpendesignstudios.com
#16
It was work I was doing initially in isolation before we co-ordinated efforts...I just left it up for idea gathering initially...
01/06/2006 (5:09 am)
Please note the demo posted on my site is NOT related to the AI pack we're currently preparing : )It was work I was doing initially in isolation before we co-ordinated efforts...I just left it up for idea gathering initially...
#17
Well, I hope you'll publish the pack in a couple of month :)
And good luck!
01/06/2006 (2:31 pm)
Oh... that complicates things :)Well, I hope you'll publish the pack in a couple of month :)
And good luck!
Torque 3D Owner Jameson Bennett
Question: is your FSM heirarchical (such as an arbitrary goal based system) or is it a simple flat FSM scheme? Also, how much is handled by script vs c++, meaning where is the separation, what can be derived?
Thanks and Good Luck!