AI Coding Ongoing..

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.