by date
AI Coding Ongoing..
AI Coding Ongoing..
| Name: | Phil Carlisle |  |
|---|---|---|
| Date Posted: | Jan 19, 2006 | |
| Rating: |  5.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Phil Carlisle |
Blog post
Well, this has certainly been an experience.
Trying to get this AI pack finished has thrown up a load of issues. But apart from lack of time sometimes, its been going really well.
After talking with Justin a week or so back, I got to thinking about what it is we really want to deliver as the final product of this AI effort.
Now its pretty clear that AI is mostly very game specific. Thats one of the things that really puts most people off from creating an AI pack. The support issues are huge because its very hard to just create things that are suitable for so many game possibilities (imagine trying to make an AI codebase that works for EVERY game type).
However given that its a huge problem, we can really help ourselves by not trying to bite it all off in one go. So in all likelyhood, we are going to need a few different AI packs aimed at very game genre specific usages (and Ive talked about that before, SQUAD AI, RACING AI etc).
But at the other end, there is the "generic" AI thats used widely enough that it can be there in all of the packs at the foundation level.
This genericity got me thinking again. Perhaps we are thinking far too low level?
In fact, there are generally going to be two classes of user for the AI packs. The low level, these are guys who could quite easily create thier own AI stuff (this aint brain surgery after all, anyone can code a FSM or an A* or any one of the things we're going to provide), but wants to save themselves some time.
But then there is the other class of user. Which sometimes I think I forget about. This is actually probably the archetypal torque user. Someone who dabbles in code, level design and art etc.
So I started thinking about what exactly it is those guys need from an AI toolchest, given that the hardcore developers can usually get themselves sorted out pretty quickly, what is it that the level designer types want to use?
After some talking with Logan F and a few others, its clear that my thinking was FAR too low level. I was thinking scripts and stuff.. Nooooo!
So what else is there? well, Ive been busy doing some reading around different engine SDK's and Ive pretty much decided that whats needed is something very similar to Halflife's map entities like trigger and trigger_multiple and game_team_master and such!! After reading up on the various entities it becomes clear just how far a user with no programming knowledge can get with a relatively simple (in torque terms) trigger->entity system! with a few and/or type switches and on/off switches, you can do quite a lot!
So right now, we are on the brink of getting everything in place. The AIBrain is now fully replaceable and sits inside an AIGameBase class, so you can literally drag and drop "brain" objects into different creatures and have them behave differently. Each Brain is essentially an FSM which feeds control actions into its owner object. The actions themselves are mostly written in C++ and can be either low level partial instructions (move to here) or can be complete high-level actions (mellee attack creature until death) and anything in between. The brain itself is a task, so it can be called at a user-defined frequency independant of the low level function of the actions (which are processed when the owner object is processed). A cheap way of setting AI difficulty would simply make the frequency less responsive for the AI!!
So thats the creatures.. Object + Brain = AI Object
Now then, how do we get those into the world doing stuff thats interesting?
Now we get to the fun bits!! AITriggers, AISpawners, AITransitions, AILandmarks etc.
Basically, I'm slowly making my way through the logic-block type objects that as a halflife level designer you place in the map to trigger environmental and AI responses. Using our new event system, we can happily have objects trigger each other, trigger multiple others, count activations etc.
So what kind of things are we talking about?
Well, for instance, all of the events in halfliffe multiplayer with AI objects involves map entities controlling behaviors of AI and environment along the way. All of those huge scripted sequences for instance! There are actually so many entities that I might have to release an updated pack as there are too many to code in one go, or we'd be waiting months to finish up.
So imagine a couple of typical scenarios:
Player steps up to a door at the end of a corridor. Just in front of the door is a TriggerVolume that is set to trigger an object named "SpawnEnemies". The "SpawnEnemies" object is a trigger which when it gets set, actually triggers multiple others. All of its outputs are set to trigger AISpawner objects. These spawn a bunch of monsters ready to attack on the far side of the door. One of the outputs is set to trigger an "Audio_Environment" entity, which plays its sound when the trigger activates. The player hears a growling sound and decides not to open the door. Instead he backs off and looks for an alternative safer route. He sees a teleporter object just along the corridor. He steps into it and is teleported to another room. This teleporter is activated by another TriggerVolume, but this not only triggers the teleport, it also activates another AISpawner, which is set to spawn a Boss monster into the room. Immediately the boss monster starts attacking the player.
Ok, its a tad cheesy as a scenario. But remember ALL of this is done by the level designer. No code at all is involved. Given a variety of entities for the designer to place, you can actually produce some REALLY interesting behaviors. For instance, one of the fields on all of these entities is a "Master" value. If this master value is set. It allows the designer to relate a "Master" object to each entity. With a worldSpawn, a Game_Master for each team type and with the entity's master property set. You can actually restrict various objects to only work for a given team.
Now I know that the programmers out there will be screaming that this is all possible in Torquescript and theyre absolutely right, it is. Its also far easier in torquescript (given an event generating/handling system). But thats not the point! the point is that now non-programmers will easily be able to make levels with interesting behaviors. We will provide enough "black box" AI monsters and such that the players will be able to generate interesting gameplay without a lick of code!
Hell if its worked for Halflife, Call of Duty, Max Payne etc. Its got to be ok hasnt it? :)
So, now for the completely underwhelming AI object screenshot!
Here is an AITrigger object being placed. AITriggers arent like torque's own triggers. These things do not normally occupy space and dont usually interact with anything physically. The AI entities like this are actually just sceneobjects (renderable things) with some logic which is run using an ITickable timer update (only on the server). Better to think of them as switches or logic objects.
Notice that there are a LOT of AI objects to go into the world editor creator tree. I'm toying with adding an AI toolbox to the world editor as the creator tree is far too cludgy to use quickly.
Until next time, when I should have some more object shots and a few videos done! Gary and Dee have both been hard at work fixing up the rest of the codebase, so we're just into "pull it all together" mode right now.
Trying to get this AI pack finished has thrown up a load of issues. But apart from lack of time sometimes, its been going really well.
After talking with Justin a week or so back, I got to thinking about what it is we really want to deliver as the final product of this AI effort.
Now its pretty clear that AI is mostly very game specific. Thats one of the things that really puts most people off from creating an AI pack. The support issues are huge because its very hard to just create things that are suitable for so many game possibilities (imagine trying to make an AI codebase that works for EVERY game type).
However given that its a huge problem, we can really help ourselves by not trying to bite it all off in one go. So in all likelyhood, we are going to need a few different AI packs aimed at very game genre specific usages (and Ive talked about that before, SQUAD AI, RACING AI etc).
But at the other end, there is the "generic" AI thats used widely enough that it can be there in all of the packs at the foundation level.
This genericity got me thinking again. Perhaps we are thinking far too low level?
In fact, there are generally going to be two classes of user for the AI packs. The low level, these are guys who could quite easily create thier own AI stuff (this aint brain surgery after all, anyone can code a FSM or an A* or any one of the things we're going to provide), but wants to save themselves some time.
But then there is the other class of user. Which sometimes I think I forget about. This is actually probably the archetypal torque user. Someone who dabbles in code, level design and art etc.
So I started thinking about what exactly it is those guys need from an AI toolchest, given that the hardcore developers can usually get themselves sorted out pretty quickly, what is it that the level designer types want to use?
After some talking with Logan F and a few others, its clear that my thinking was FAR too low level. I was thinking scripts and stuff.. Nooooo!
So what else is there? well, Ive been busy doing some reading around different engine SDK's and Ive pretty much decided that whats needed is something very similar to Halflife's map entities like trigger and trigger_multiple and game_team_master and such!! After reading up on the various entities it becomes clear just how far a user with no programming knowledge can get with a relatively simple (in torque terms) trigger->entity system! with a few and/or type switches and on/off switches, you can do quite a lot!
So right now, we are on the brink of getting everything in place. The AIBrain is now fully replaceable and sits inside an AIGameBase class, so you can literally drag and drop "brain" objects into different creatures and have them behave differently. Each Brain is essentially an FSM which feeds control actions into its owner object. The actions themselves are mostly written in C++ and can be either low level partial instructions (move to here) or can be complete high-level actions (mellee attack creature until death) and anything in between. The brain itself is a task, so it can be called at a user-defined frequency independant of the low level function of the actions (which are processed when the owner object is processed). A cheap way of setting AI difficulty would simply make the frequency less responsive for the AI!!
So thats the creatures.. Object + Brain = AI Object
Now then, how do we get those into the world doing stuff thats interesting?
Now we get to the fun bits!! AITriggers, AISpawners, AITransitions, AILandmarks etc.
Basically, I'm slowly making my way through the logic-block type objects that as a halflife level designer you place in the map to trigger environmental and AI responses. Using our new event system, we can happily have objects trigger each other, trigger multiple others, count activations etc.
So what kind of things are we talking about?
Well, for instance, all of the events in halfliffe multiplayer with AI objects involves map entities controlling behaviors of AI and environment along the way. All of those huge scripted sequences for instance! There are actually so many entities that I might have to release an updated pack as there are too many to code in one go, or we'd be waiting months to finish up.
So imagine a couple of typical scenarios:
Player steps up to a door at the end of a corridor. Just in front of the door is a TriggerVolume that is set to trigger an object named "SpawnEnemies". The "SpawnEnemies" object is a trigger which when it gets set, actually triggers multiple others. All of its outputs are set to trigger AISpawner objects. These spawn a bunch of monsters ready to attack on the far side of the door. One of the outputs is set to trigger an "Audio_Environment" entity, which plays its sound when the trigger activates. The player hears a growling sound and decides not to open the door. Instead he backs off and looks for an alternative safer route. He sees a teleporter object just along the corridor. He steps into it and is teleported to another room. This teleporter is activated by another TriggerVolume, but this not only triggers the teleport, it also activates another AISpawner, which is set to spawn a Boss monster into the room. Immediately the boss monster starts attacking the player.
Ok, its a tad cheesy as a scenario. But remember ALL of this is done by the level designer. No code at all is involved. Given a variety of entities for the designer to place, you can actually produce some REALLY interesting behaviors. For instance, one of the fields on all of these entities is a "Master" value. If this master value is set. It allows the designer to relate a "Master" object to each entity. With a worldSpawn, a Game_Master for each team type and with the entity's master property set. You can actually restrict various objects to only work for a given team.
Now I know that the programmers out there will be screaming that this is all possible in Torquescript and theyre absolutely right, it is. Its also far easier in torquescript (given an event generating/handling system). But thats not the point! the point is that now non-programmers will easily be able to make levels with interesting behaviors. We will provide enough "black box" AI monsters and such that the players will be able to generate interesting gameplay without a lick of code!
Hell if its worked for Halflife, Call of Duty, Max Payne etc. Its got to be ok hasnt it? :)
So, now for the completely underwhelming AI object screenshot!
Here is an AITrigger object being placed. AITriggers arent like torque's own triggers. These things do not normally occupy space and dont usually interact with anything physically. The AI entities like this are actually just sceneobjects (renderable things) with some logic which is run using an ITickable timer update (only on the server). Better to think of them as switches or logic objects.
Notice that there are a LOT of AI objects to go into the world editor creator tree. I'm toying with adding an AI toolbox to the world editor as the creator tree is far too cludgy to use quickly.
Until next time, when I should have some more object shots and a few videos done! Gary and Dee have both been hard at work fixing up the rest of the codebase, so we're just into "pull it all together" mode right now.
Recent Blog Posts
| List: | 11/28/08 - GDC AI sessions 09/18/08 - Tell me I'm not going crazy!! 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 |
|---|
Submit your own resources!| Nick Zafiris (Jan 19, 2006 at 00:40 GMT) Resource Rating: 5 |
Nick
| Treb Connell (formerlyMasterTreb (Jan 19, 2006 at 01:23 GMT) |
| Vashner (Jan 19, 2006 at 01:46 GMT) |
| Dave D (Jan 19, 2006 at 01:57 GMT) |
Quick question though, have you thought about, or will this be a drop in solution for T2d as well?
| David Montgomery-Blake (Jan 19, 2006 at 02:44 GMT) |
| Treb Connell (formerlyMasterTreb (Jan 19, 2006 at 02:57 GMT) |
timeline?
| Rex (Jan 19, 2006 at 03:09 GMT) |
I also like the idea of a dedicated .gui to keep things organized and step thru the logic setup; another great[imho] feature of the WC interface HL map building process. Not wanting Torque to be 'like' Valve's HL engine...I do wish the missionBuilding and scripting of scenes were more that way...;). And that, I hope, is not a 'bad' thing. I really appreciate the thought towards the 'art' end of the process, bless you!
David
| abc (Jan 19, 2006 at 03:42 GMT) |
| fireVein (Jan 19, 2006 at 03:59 GMT) |
However, I do hope there will be some kind of implementation for vehicles to atleast use pathfinding and tie into some of the other features. I do recall you mentioning something about vehicle AI in one of your other blogs/.plans. Just something that can be built off of would be really great, but not necessarily something full blown for, say, a racing game. Multiple packs geared more towards game specific genres would definitley be the better way to go.
Anyways, this AIPack is going to be awsome, and I'm really looking forward to it.
-Jase
Edited on Jan 19, 2006 10:17 GMT
| Michael Cozzolino (Jan 19, 2006 at 04:25 GMT) |
| Ron Yacketta (Jan 19, 2006 at 13:20 GMT) |
I like the idea! as you said
Quote:
Hell if its worked for Halflife, Call of Duty, Max Payne etc. Its got to be ok hasnt it? :)
Only thing that caught my eye was 'TriggerVolume', could be confusing. At first glance a user might think this is strickly sound related.
-Ron
| Allen Turner (Jan 19, 2006 at 17:58 GMT) |
I'm really looking forward to your pack as this is how I feel this sort of thing should be done. If someone could figure out how to turn the multitudes of scripts into tags and make a tag editor they would be my best friend. I've worked on a bunch of games (Myth, Myth II, Mech Assault, Stubbs the Zombie) and all have used a format similar (in one way or another, in varying extremes) to this for putting together the ai for the game. The main reason was because the people (like myself) who were actually doing the game logic and play needed to be able to do it quickly with the ability it iterate fast and move the scenario between multiple folks with minimal chances for code based bugs to pop up.
A good team is maintained by a good set of tools that obfuscates any coding that isn't necessary. Any new code that a team member wants for AI should be summitted as a request for the programmer to fulfill. If it can't be done (or faked) in the existing system then the coder may add it (or not depending on time and budget).
Working on Stubbs which used the Halo engine, 85% of ai was set up in a visual environment (called Sapien). The rest were simple scripts done in a variant of LISP that allowed the designers to manipulate things with combinations simple boolean statements, if loops, and calls to objects created and named in the editor. In Mech Assault we didn't even have scripts, everything was done via a logic bricks sort of thing.
I guess what I'm saying is that what you're doing isn't just something for hobbyists it is the sort of the thing preferred in the field because it makes good business sense from the stand point of bug fixing and iterations (imagine having a large bug plate (like 70 to 150 a day) from testers and you're 3 weeks from having to certify with your publisher. At this point you just don't want to have your 5 (or more) designers digging through code and writing new code to fix problems. You want them to be able to see at a glance what the problem is.
Designers and artists need good tools to help them do their jobs. This sounds like its shaping up to being a great tool. If you're looking for beta testers give me a holler.
@ Ron I wouldn't wory about the word "Volume". Every engine I've worked with has had trigger volumes and I've never known it to trip anyone up. I think the word is necessary to keep people in the right mindset and diferentiate between any sort of line or 2d area triggers. People will get the idea. Granted there will be absolute newbies who might scratch their head but that will be the least of their hurdles. I think of it as field lingo that they'll have to learn eventually.
-Allen Turner
| Tim Muenstermann (Jan 19, 2006 at 19:13 GMT) |
-Tim
| Phil Carlisle (Jan 19, 2006 at 19:46 GMT) |
I've used halflife mapping tools myself before and I really dug how much you could do with such simple entities.
Now just got to finish writing them all :)
Ron: TriggerVolume will also be there, along with TriggerAudio and TriggerEffect
Thanks for the comments guys. Tim, I'll go and have a quick look at the OP FP AI stuff if its online.
Phil.
| Tom Spilman (Jan 19, 2006 at 20:08 GMT) |
| Christian S (Jan 19, 2006 at 20:52 GMT) |
Thumbs up for sure, this is so like the level desing (scripting/trigger) stuff I've done in the UT(Rune) engine. When this comes around, Im for sure going to support it by throwing greens in your direction ;o)
I am really looking forward -so keep up the spirit!
| James Thompson (Jan 23, 2006 at 21:22 GMT) |
| Dee (Jan 26, 2006 at 01:10 GMT) |
Some info in the nav stuff, things you can do...:
Can generate indoor only, or outdoor only graphs for navigation use.
Can directly/manually insert/delete/re-position nodes if needed via editor.
Block editting available for nodes/properties
Adjustable graph density - can be different for indoor and terrain
Height, slope, etc. generation parameters can be done via editor, similar to texture 'filter' panel
Additional 'modifiers available' for various other uses.
Some pics can be found here:
www.bullpendesignstudios.com/Main.jpg
www.bullpendesignstudios.com/nav_edit.jpg
www.bullpendesignstudios.com/nav_indoor.jpg
www.bullpendesignstudios.com/nav_outdoor.jpg
www.bullpendesignstudios.com/dif_only.jpg
www.bullpendesignstudios.com/outdoor_only.jpg
Dee
Edited on Jan 28, 2006 03:43 GMT
| fireVein (Jan 27, 2006 at 13:39 GMT) |
-Jase
Edited on Jan 27, 2006 13:39 GMT
| Dee (Jan 28, 2006 at 03:48 GMT) |
Yup gone now that's it more collaborative :)
Quite a lot of credit goes to Justin for the nav graph work you see in these recent pics.
Works well when similar ideas with different implementations come together.
Edited on Jan 28, 2006 03:51 GMT
You must be a member and be logged in to either append comments or rate this resource.
