Torque AI Pack
by Stefan Beffy Moises · in Torque Game Engine · 06/15/2004 (3:07 am) · 113 replies
Hey guys, since we are working hard on the TorqueAI project we were thinking it would be a good time now to start collecting some expectations and requests people would have with such a thing...
So if you scan through our plans, you should get a pretty good idea what the basic "AI Pack" will contain, here are some highlights:
Pathfinding / Navigation:
- autogenerated, highly customizable navigation grid for interior and exterior settings, seamlessly connected
- highly-optimized, A* based pathfinding routine
- filters: the autogenerated navigation nodes / "waypoints" (and the "links" between those) can be filtered, e.g. by slope between nodes (terrain slope, but also interior-slope (global as well as on a per instance basis) or by distance to static obstacles or interiors etc.
- possibility to filter waterblock nodes
- NavMeshBlockers: you can block a certain area to not have any nodes generated
- InteriorBlockers: interiors can also be tagged to not have any nodes, but to be used as "blockers" instead
- Terrain texture filter object: you can restrict the node generation to certain terrain surfaces (or prevent the navgraph to create nodes on certain surfaces)
- Additional waypoints can be added manually
- NavMeshModifiers: you will be able to flag certain nodes as "not usable", "blocked", "one-way-only" etc.
- Path interpolation / smoothing / straightening: the generated paths can be visually optimized
Here is a typical AINavGraph block:
So if you scan through our plans, you should get a pretty good idea what the basic "AI Pack" will contain, here are some highlights:
Pathfinding / Navigation:
- autogenerated, highly customizable navigation grid for interior and exterior settings, seamlessly connected
- highly-optimized, A* based pathfinding routine
- filters: the autogenerated navigation nodes / "waypoints" (and the "links" between those) can be filtered, e.g. by slope between nodes (terrain slope, but also interior-slope (global as well as on a per instance basis) or by distance to static obstacles or interiors etc.
- possibility to filter waterblock nodes
- NavMeshBlockers: you can block a certain area to not have any nodes generated
- InteriorBlockers: interiors can also be tagged to not have any nodes, but to be used as "blockers" instead
- Terrain texture filter object: you can restrict the node generation to certain terrain surfaces (or prevent the navgraph to create nodes on certain surfaces)
- Additional waypoints can be added manually
- NavMeshModifiers: you will be able to flag certain nodes as "not usable", "blocked", "one-way-only" etc.
- Path interpolation / smoothing / straightening: the generated paths can be visually optimized
Here is a typical AINavGraph block:
new ScriptObject(MissionNavGraph) {
terrainAngleFilter = "60"; // max. terrain angle in degrees (0-90)
terrainFrequency = "5"; // dist. between terrain nodes
interiorAngleFilter = "50"; // max. interior angle in degrees (0-90), can be overwritten for each interior
interiorFrequency = "1"; // dist. between interior nodes
botHeight = "2.0"; // max. bot height for this map
interiorInteriorRayscanHeight = "0.6"; // rayscan height between 2 interior nodes
terrainInteriorRayscanHeight = "0.4"; // terrain - interior node rayscan height
terrainTerrainRayscanHeight = "1.0"; // terrain - terrain node rayscan height
surfaceExclusionMode = "1"; // 1 = exclude marked surface textures (don't create nodes),
// 0 = create only on the marked surfaces / textures
// surfaces are marked with the (up to 16 per mission) "SurfaceMarker" entity in the mission editor
filterWater = "1"; // filter waterblocks, i.e. water that is below the terrain, not the whole rect
objectDistanceFactor = "1"; // distance factor to remove nodes around obstacles, e.g. interiors
};
About the author
#2
06/15/2004 (3:38 am)
So far, it looks good. Would be nice if you publish a demo with 2-3 smart bots to hunt ;)
#3
06/15/2004 (3:47 am)
Yeah, there will also be a little demo of course before the release :)
#4
But for my melee combat i use a ranged combat function so a bot can switch weapon deppending how far from the enemy he is.
And i have guard functions like bots standing guards and not chasing the enemy all over the map only a short distance.
Would be nice to have some sound senses to.
Your Aipack looks real good ,basicly what i want is all above stuff but that ai getting stuck its a major part.
06/15/2004 (4:01 am)
I dont know if this it to any help Stefan.But for my melee combat i use a ranged combat function so a bot can switch weapon deppending how far from the enemy he is.
And i have guard functions like bots standing guards and not chasing the enemy all over the map only a short distance.
Would be nice to have some sound senses to.
Your Aipack looks real good ,basicly what i want is all above stuff but that ai getting stuck its a major part.
#5
Rasmus
06/15/2004 (4:09 am)
This sounds great... when do you think this will be out so we can buy it?Rasmus
#6
06/15/2004 (4:18 am)
Ya it's one of the best pack for torque so please give us an estimated release day.
#7
Getting stuck is definitely a big issue though :)
06/15/2004 (4:40 am)
Billy: You would do that by adding different sensors to the player object, which would signal when they are fired. Getting stuck is definitely a big issue though :)
#8
My input: I've been very impressed by this effort: http://opensteer.sourceforge.net/
To quote from the site: "OpenSteer is a C++ library to help construct steering behaviors for autonomous characters in games and animation."
They have a very cool demo, well worth the download.
06/15/2004 (4:51 am)
Your AIPack will definately be on my "must buy" list just from the features you've described!My input: I've been very impressed by this effort: http://opensteer.sourceforge.net/
To quote from the site: "OpenSteer is a C++ library to help construct steering behaviors for autonomous characters in games and animation."
They have a very cool demo, well worth the download.
#9
06/15/2004 (4:51 am)
The final release date isn't really set yet (our initial plans were to relese it sometime in late summer/early fall, we'll have to see if we can hold that...) We will meet as usual this Thursday and talk about it ... and once we have nailed down exactly what should be in the initial pack and what everybody's status is we will be able to tell you the estimated date in more detail ... :)
#10
06/15/2004 (5:10 am)
As long as the scripting is either easy to understand or well documented, and the demo is fun (which i'm sure it will be) you can count me in for >=$50 don't know when or where but I will buy it. :D
#11
Merging a project with the current head is more or less a pain, but absolutely neccessary, since only HEAD gives you the best GG has to provide ;)
(Of course this is my opinion, but Jeff uses to answer newbie question about "which code base to download" with the advise to go for HEAD).
Extra merging work caused by the code pack would be really bad.
I hope you keep an eye on this.
-- Markus
06/15/2004 (5:19 am)
The pack should seamlessly integrate with the Torque codebase.Merging a project with the current head is more or less a pain, but absolutely neccessary, since only HEAD gives you the best GG has to provide ;)
(Of course this is my opinion, but Jeff uses to answer newbie question about "which code base to download" with the advise to go for HEAD).
Extra merging work caused by the code pack would be really bad.
I hope you keep an eye on this.
-- Markus
#12
But these should be relatively few and VERY well documented.
We have been aware of the issues of code compatability and integration (especially seeing how some people always seem to have problems).
We are also making sure the codebase integrates well with other projects by actually doing it ourselves (i.e. integrating it with the codebase of LORE etc).
06/15/2004 (5:24 am)
Markus: most of the code is in new objects or files. There will inevitably be a few different things to change (new functions in shapebase for instance).But these should be relatively few and VERY well documented.
We have been aware of the issues of code compatability and integration (especially seeing how some people always seem to have problems).
We are also making sure the codebase integrates well with other projects by actually doing it ourselves (i.e. integrating it with the codebase of LORE etc).
#13
@Markus: good point, we definaltely are keeping an eye on that... we try to touch as few as possible existing files (we have to make *some* changes though of course), but most of this stuff is additional and just has to be added to the workspace... and we are keeping a textfile listing every change we are doing and adding comments everywhere we change something in the engine or the scripts ... and we will offer regularly updated patches as well I think (for HEAD since we are all working with HEAD usually, too).
But there will be patches for v.1.2. too so that everybody can use it of course.
06/15/2004 (5:28 am)
@Shay: hopefully the script side will be easy to understand *and* well documented ;)@Markus: good point, we definaltely are keeping an eye on that... we try to touch as few as possible existing files (we have to make *some* changes though of course), but most of this stuff is additional and just has to be added to the workspace... and we are keeping a textfile listing every change we are doing and adding comments everywhere we change something in the engine or the scripts ... and we will offer regularly updated patches as well I think (for HEAD since we are all working with HEAD usually, too).
But there will be patches for v.1.2. too so that everybody can use it of course.
#14
Would it be useful to be able to assign weights to specific points. And along with those weights, give an identifier that says what the weight applies to? Follow me here for a second... One of the things that bugs me most out of AI is that it never really knows where the best places to "hide" are. Such that right in the middle of a fire fight, instead of standing in a hallway or running and jumping like a bunny, the bot can locate the closest "blocking object" to "hide" behind.
Imagine a waypoint having this ID called "waypointIdent" which has a value called "hideout". Within a hallway there's a barrel, a tall crate, and a fallen girder. On each side of each object there's a weighted value assigned between 1 and 10 which indicates that the points around the object are good "blockers" when under fire.
Of course, some logic would need to be implemented so the bot didn't pick the point that was on the same side as the guy firing upon him.
Anyways... just wanted to get that off my chest.
- Brett
06/15/2004 (6:19 am)
Just an idea that popped into my head. You may or may not have this, or have thought of this...Would it be useful to be able to assign weights to specific points. And along with those weights, give an identifier that says what the weight applies to? Follow me here for a second... One of the things that bugs me most out of AI is that it never really knows where the best places to "hide" are. Such that right in the middle of a fire fight, instead of standing in a hallway or running and jumping like a bunny, the bot can locate the closest "blocking object" to "hide" behind.
Imagine a waypoint having this ID called "waypointIdent" which has a value called "hideout". Within a hallway there's a barrel, a tall crate, and a fallen girder. On each side of each object there's a weighted value assigned between 1 and 10 which indicates that the points around the object are good "blockers" when under fire.
Of course, some logic would need to be implemented so the bot didn't pick the point that was on the same side as the guy firing upon him.
Anyways... just wanted to get that off my chest.
- Brett
#15
Christophe
06/15/2004 (6:57 am)
Good idea Brett. The system can also be used to find the best places to snipe or move under coverage.Christophe
#16
06/15/2004 (7:10 am)
Yes, I think we can pretty much implement that from the stuff we have now. But yes, attraction/interest area's and such will be covered.
#17
06/15/2004 (7:13 am)
One good idea would be a pathfinding for vehicles because there is a real lack of solutions for this.
#18
Example: a move_to goal is set, and no path is possible. That is a "permanent frustration" by the terms I (semi-randomly) defined.
Now, if there is an enemy (single, squad, fire-field, whichever) that is temporarily blocking the path, it would be good to be able to recognize that, and have the base "move_to" goal pause at an appropriate time so the situation can be handled appropriately. Many times I've seen an ai drive a player/npc through enemy fields of fire, or even worse, enemy formations, simply because the move_to goal was the only one set, and the fact that the ai wasn't able to sense the enemy contact condition during the move_to goal handling.
It doesn't have to be complex, just the ability to pause a primary goal because a frustration condition was found, and be able to resume (or cancel) the primary goal when the temporary condition is resolved.
06/15/2004 (7:36 am)
From the description you gave, this could be inherent, but one thing that can be important is being able to recognize "temporary frustration" as opposed to "permanent frustration", and provide a "pause" so a temporary frustration can be resolved.Example: a move_to goal is set, and no path is possible. That is a "permanent frustration" by the terms I (semi-randomly) defined.
Now, if there is an enemy (single, squad, fire-field, whichever) that is temporarily blocking the path, it would be good to be able to recognize that, and have the base "move_to" goal pause at an appropriate time so the situation can be handled appropriately. Many times I've seen an ai drive a player/npc through enemy fields of fire, or even worse, enemy formations, simply because the move_to goal was the only one set, and the fact that the ai wasn't able to sense the enemy contact condition during the move_to goal handling.
It doesn't have to be complex, just the ability to pause a primary goal because a frustration condition was found, and be able to resume (or cancel) the primary goal when the temporary condition is resolved.
#19
06/15/2004 (7:55 am)
Out of interest, would the AI beable to reconise say for example a jeep (with a weapon mounted on it) and either use it as cover or use it to attack the player?
#20
To be honest, FSM's arent necassarily the best thing for combatants in a large conflict. At least not at the sort of FPS level. I'll be working on other more optimal solutions to this as we add more functionality (more actions, more goal behaviour, more of everything I guess).
This is part of my effort to actually get to the stage where we can apply a number of AI techniques to the problem. Maybe FSM's for some stuff, goal based methods for others, rule systems for others etc.
Of course one issue is that we MUST make this extremely versatile and scriptable as part of it. So any complexity is hidden as much as possible, or is as open as possible (for an example, we have a number of C++ based pre-defined sensor objects, but you can create a "scriptcallbacksensor" which is a sensor that can be entirely script based.
06/15/2004 (8:12 am)
Stephen: yes, there is an extension to the FSM structure to allow it to act as a push/pop state-stack (instead of directly changing states, you push them), which effectively makes it a PDA (push down automata). For instance, you could be in the "travel to contact" state, which could then transition (via a push) to the "fight" state, when done would simply pop the fight state and return to the travel state.To be honest, FSM's arent necassarily the best thing for combatants in a large conflict. At least not at the sort of FPS level. I'll be working on other more optimal solutions to this as we add more functionality (more actions, more goal behaviour, more of everything I guess).
This is part of my effort to actually get to the stage where we can apply a number of AI techniques to the problem. Maybe FSM's for some stuff, goal based methods for others, rule systems for others etc.
Of course one issue is that we MUST make this extremely versatile and scriptable as part of it. So any complexity is hidden as much as possible, or is as open as possible (for an example, we have a number of C++ based pre-defined sensor objects, but you can create a "scriptcallbacksensor" which is a sensor that can be entirely script based.
Associate Stefan Beffy Moises
similar to several articles in AIWisdom 1 and 2, all of the player AI functionality (apart from pathing), is handled using a task-based architecture.
Tasks are generic units of update, with the updates being time-managed such that they are updated when time is available (i.e. a maximum cap on the AI processing time is available that should mitigate any CPU overhead).
AI objects can also have a number of specific AI techniques applied:
Actions - these are things the AI can do. Actions are typically things like, moveto, patrol, pickup object, throw object, animate etc. Actions are performed from an action stack for the player, so that pre-scripted sequences of actions can be created (i.e. goto here, pickup thing, play animation, goto here, press button).
Goals - These are still in development, but are basically a rule-base architecture for defining some nature of rules to be used.
Sensors - these are tasks which allow an object to sense the world they are in. Including things like line of sight, hearing, object proximity, obstacle proximity etc. Sensors also form the basis of steering functionality.
StateMachines - These are simple FSM (finite state machines), which allow simple state based functionality. For instance, you might have a FSM attached to a trigger, so that it has an "open" and "closed" state. That would allow you to perform some specific action when it went from closed (the default) to open, i.e. play a siren or something.
Gui Support
- configuration screens to customize the navgraph, pathing, etc. settings
- FSM Editor: an easy to use Finite State Machine editor similar to the one used in MaxPayne 2 where you can assign FSM based behaviours to almost every object in your mission
Examples, documentation, support
Of course, if we sell this stuff as a code pack, we would add extensive documentation, example missions and scripts, and provide customers with bugfixes, updates and support.
So what do you think? Is that what you would expect from an "AI Pack"? Does anybody have any suggestions or requests what should be added/changed etc.?
Thanks for your feedback!