by date
AI Package
AI Package
| Name: | Phil Carlisle | ![]() |
|---|---|---|
| Date Posted: | Jan 02, 2006 | |
| Rating: | 3.7 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Phil Carlisle |
Blog post
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 :)
Recent Blog Posts
| List: | 12/05/07 - The importance of good tools for productivity 11/17/07 - Using the way back machine. 09/21/07 - Juggling cats. 09/04/07 - End of Summer. 08/27/07 - Come work with me!! 08/14/07 - The changing nature of entertainment 07/25/07 - Someone stole my notes!! 07/16/07 - Art pipeline and other things. |
|---|
Submit your own resources!| Jameson Bennett (Jan 02, 2006 at 17:24 GMT) |
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!
| Rubes (Jan 02, 2006 at 17:29 GMT) |
| Tim Sullivan (Jan 02, 2006 at 17:48 GMT) |
| Andy Schatz (Jan 02, 2006 at 18:04 GMT) |
| Phil Carlisle (Jan 02, 2006 at 18:32 GMT) |
| Bryan Edds (Jan 02, 2006 at 18:41 GMT) Resource Rating: 5 |
Just some thoughts.
| Nick Zafiris (Jan 02, 2006 at 20:36 GMT) Resource Rating: 5 |
Nick
| Jason Swearingen (Jan 03, 2006 at 01:32 GMT) |
| Phil Carlisle (Jan 03, 2006 at 10:56 GMT) |
I'll have a go at integrating it into the latest T2D when we're done with 1.4 and TSE.
| Bucko (Jan 03, 2006 at 20:52 GMT) |
Can one preorder?
| Alexander "taualex" Gaevoy (Jan 04, 2006 at 03:07 GMT) |
Can one create a nav mesh for a road surface by two splines?
Tnx
| Phil Carlisle (Jan 05, 2006 at 12:26 GMT) |
The driving of the car would be like any other vehicle.
| Alexander "taualex" Gaevoy (Jan 06, 2006 at 00:02 GMT) |
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)?
| Dee (Jan 06, 2006 at 03:00 GMT) |
p6.hostingprod.com/@bullpendesignstudios.com
| Alexander "taualex" Gaevoy (Jan 06, 2006 at 03:58 GMT) |
I'm going to try that demo.
| Dee (Jan 06, 2006 at 05:09 GMT) |
It was work I was doing initially in isolation before we co-ordinated efforts...I just left it up for idea gathering initially...
| Alexander "taualex" Gaevoy (Jan 06, 2006 at 14:31 GMT) |
Well, I hope you'll publish the pack in a couple of month :)
And good luck!
You must be a member and be logged in to either append comments or rate this resource.



3.7 out of 5


