Previous Blog Next Blog
Prev/Next Blog
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:GarageGames Blog feedor 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 :)

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 ResourceSubmit your own resources!

Jameson Bennett   (Jan 02, 2006 at 17:24 GMT)
Glad this is all finally coming together. Ive been following the progress since you guys started postiing about it originally.

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)
This is really impressive. I can't wait to see how it works.

Tim Sullivan   (Jan 02, 2006 at 17:48 GMT)
I am looking very forward to this. It will greatly ease my game development. Thanks for doing this. :-)

Andy Schatz   (Jan 02, 2006 at 18:04 GMT)
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.

Phil Carlisle   (Jan 02, 2006 at 18:32 GMT)
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.

Bryan Edds   (Jan 02, 2006 at 18:41 GMT)   Resource Rating: 5
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.

Nick Zafiris   (Jan 02, 2006 at 20:36 GMT)   Resource Rating: 5
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

Jason Swearingen   (Jan 03, 2006 at 01:32 GMT)
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!

Phil Carlisle   (Jan 03, 2006 at 10:56 GMT)
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.

Bucko   (Jan 03, 2006 at 20:52 GMT)
Yay, less script, more C++, this looks even better.
Can one preorder?

Alexander "taualex" Gaevoy   (Jan 04, 2006 at 03:07 GMT)
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

Phil Carlisle   (Jan 05, 2006 at 12:26 GMT)
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.

Alexander "taualex" Gaevoy   (Jan 06, 2006 at 00:02 GMT)
That's an idea, Phil

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)
A few updated screenshots of the nav stuff can be found here:
p6.hostingprod.com/@bullpendesignstudios.com

Alexander "taualex" Gaevoy   (Jan 06, 2006 at 03:58 GMT)
Thanks a lot for the link, Dee.
I'm going to try that demo.

Dee   (Jan 06, 2006 at 05:09 GMT)
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...

Alexander "taualex" Gaevoy   (Jan 06, 2006 at 14:31 GMT)
Oh... that complicates things :)
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.