Game Development Community

Artificial Intelligence FSM

by Brett Canter · 01/22/2008 (9:14 pm) · 8 comments

Artificial Intelligence ... it's an interesting and challenging field of study, and its application to gaming is a complex task. I've spent the last two to three weeks coding my first attempt at an A.I. solution for a student project, and thus far, it has been a memorable experience and a moderate success. Initially, I needed a solid understanding of what should be expected of A.I. within the area of gaming. Once I had an idea of what needed to be in place, I decided that any solution must be robust and extendable. Third, it had to be easy to understand. Conceptually speaking, my design is nothing more interesting than a basic Finite State Machine.

Where to start?!
I began with the Starter.FPS demo, and from this demo I took what already existed while adding a few scriptobjects to bring the framework into focus. Starter.FPS begins the AI process by calling AIManager::think. This function creates/spawns the AI bots as AIPlayer objects, and the bots begin performing whatever actions were scripted. AIPlayer is where I decided to begin changing the scripts. The first big change was to create specific types of AI bots that derive from AIPlayer. I added functionality to AIPlayer that would create a new scriptobject for the specific type of AI bot that would be required. For example, our demo level needed a few different types of bad guys: basic guards, killers for hire, and a boss. Recalling that one of the overall goals of the framework was robustness, I decided to allow Level Designers to specify the type of AI being spawned as well as various sense and personality attributes to be assigned directly within the mission. These dynamic fields are pulled from the mission by AIManager actually, and AIPlayer then creates the appropriate scriptobject for the AI bot type, including allocating the sense and personality values to the new bot.

Great, now Level Designers don't have to bug me to hard code new values and bot types (as our Level Designers are not scripters)!

Next, I needed to create an instance of the FSM for each bot. Yet another scriptobject was used. Finally, each state needed to be created and coded to create the actual behavior for each bot. I started off with two basic states for proof of concept, and I made each state a scriptobject. The states (attack and guard) incorporated three functions: Enter(), Execute(), and Exit(). As the FSM transitioned between states, it would call the following:

Outgoing state's Exit() function
Incoming state's Enter() function
Incoming state's Execute() function

This allows for a nice separation of activities by each state, as well as allowing the scripts to make more sense in my head. This might look familiar to some, as the states' functions are based on an example found within Game AI Programming by Example (an excellent resource!). Now that the framework was ready, I began the difficult task of coding the state functions.

Giving Life to AI
Although it was a major challenge, I took great delight in creating all sorts of crazy actions and states. For example, I began adding evasion states and cover seeking states. After many days of coding and recoding, I began to wonder if an in-house WYSIWYG tool might be better suited to do this repetitive work. After mulling the idea over for a few days, and theorizing how the program would work, I further wondered if the community would be interested in just such a tool.

The Future?
So here's your chance, gang. Would you be interested in paying a small fee for a WYSIWYG tool that would allow you to code state functionality, transitions and auto-generate the necessary scripts for your game? Initially, the tool would require that you use the framework detailed above, and also incorporate the proper variables into your missions for each AI bot. At least, that's how I envision it right now ;) I'd also explore a testing process, so that each AI bot could have its "brain" tested live while the states are being coded, instead of firing up the game each and every time you make a change.

About the author

Recent Blogs


#1
01/22/2008 (10:42 pm)
I think you'll soon find that you need to do a lot of this kind of code in C++ to keep it performant.

I'd recommend checking out Behavior Trees (www.aigamedev.com) as a nicer alternative to FSM's. Or even HFSM's.
#2
01/23/2008 (3:41 am)
Hey brett, looks like you guys are making progress. I thought Herb was covering AI?

But as the wise Phil Carlisle said a lot this stuff should really be in C++,

Also don't forget about utilizing path finding algorithms such as A* or anything bigger and better out there now.

Phil:

Behaviour Trees eh? i havent heard about those yet i'll have to take a looky at them when i get a chance
#3
01/23/2008 (9:41 am)
Casey: yeah, BT's are a pretty big thing in games right now. Check out Damian Isla's paper from GDC about thier use in Halo's AI.

BT's are a great way of addressing the problems with FSM based AI's (and believe me once you try and work out a complex FSM you'll know what those are).
#4
01/23/2008 (2:59 pm)
Thanks fellas!

Phil - you are absolutely right about complicated FSMs! The one I'm working with right now is already getting out of hand. I checked out aigamedev.com last night, and watched all the videos on BTs. Very interesting stuff! Thank you very much for pointing me in that direction

Casey - Herb is going to join me on AI dev once he's done with a few other things ;) We figured that the AI solution would take quite some time, so I might as well get cracking on it. Thanks for the recommendation on pathfinding, too. I was reading a few articles on A*, and hoping to dive into it while I working out the FSM states. Thanks man!

Regarding moving this all into C++, I completely agree that at some point it will have to be done. I'm taking this very slowly and deliberately, in Torquescript for the moment, since this is my first attempt. However, I will eventually follow your advice about moving to C++!
#5
01/23/2008 (4:39 pm)
This sounds like a great product, anything that help make the game easier and faster, you have my purchase.
#6
01/23/2008 (5:12 pm)
Shoot yeah! If there was a solid tool for TGE(A) AI I'd buy it.
#7
01/24/2008 (4:38 pm)
Also, I've integrated a .dll based neural net imlementation into Torque before. It was actually pretty easy. The .dll comes with an editor that you can use to train the neural net. They can be tricky, but I used the nets to drive a decision tree (not sure if my use of decision tree matches the concept of the GDC talk.)

The api and tool are coming to market right now and there are no set plans that I know of for costs. My guess is that you may be able to get in now as they try to come to market as a beta, but the end product will probably prohibit casual devp. Again, not my product, I was just using it for a DOD small business innovation research project.

Depending on your case, I may be able to link you with the owners of this tech.
#8
01/31/2008 (1:53 pm)
I've moved away from Behavior Trees for this implementation, mainly because that's like "sprinting before crawling" for me. We're back to the HFSM model. The design and framework are being implemented in C++ and it will be exposed to script, so that it can be modded.

Future updates may include ANNs and/or Behavior Trees, but not in the first release. I will continue to update this blog as progress is made.

Thanks for all the comments!