by date
Artificial Intelligence FSM
Artificial Intelligence FSM
| Name: | Brett Canter | |
|---|---|---|
| Date Posted: | Jan 22, 2008 | |
| Rating: | Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Brett Canter |
Blog post
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.
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.
Submit your own resources!| Phil Carlisle (Jan 22, 2008 at 22:42 GMT) |
I'd recommend checking out Behavior Trees (www.aigamedev.com) as a nicer alternative to FSM's. Or even HFSM's.
| Casey Weidner (Jan 23, 2008 at 03:41 GMT) |
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
| Phil Carlisle (Jan 23, 2008 at 09:41 GMT) |
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).
| Brett Canter (Jan 23, 2008 at 14:59 GMT) |
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++!
Edited on Jan 23, 2008 15:01 GMT
| Kory James (Jan 23, 2008 at 16:39 GMT) |
| Ben Acord (Jan 23, 2008 at 17:12 GMT) |
Edited on Jan 23, 2008 17:13 GMT
| Eric Preisz (Jan 24, 2008 at 16:38 GMT) |
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.
| Brett Canter (Jan 31, 2008 at 13:53 GMT) |
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!
You must be a member and be logged in to either append comments or rate this resource.


Not Rated


