<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF
	xmlns="http://purl.org/rss/1.0/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel rdf:about="http://feeds.garagegames.com/rss/blogs/developer/101667/">
		<title>Blog for Brett Canter at GarageGames.com</title>
		<description>Blog feeds for Gamers and Developers in the GarageGames community.</description>
		<link>http://www.garagegames.com/</link>
		<image rdf:resource="http://www.garagegames.com/images/GarageGames_logo_small_w.gif" />
		<dc:date>2008-11-22T11:17:54+00:00</dc:date>
		<items>
			<rdf:Seq>
				<rdf:li rdf:resource="http://www.garagegames.com/blogs/101667/14187"/>
			</rdf:Seq>
		</items>
	</channel>
	<item rdf:about="http://www.garagegames.com/blogs/101667/14187">
		<dc:format>text/html</dc:format>
		<dc:date>2008-01-22T21:14:50+00:00</dc:date>
		<dc:creator>Brett Canter</dc:creator>
		<title>Artificial Intelligence FSM</title>
		<link>http://www.garagegames.com/blogs/101667/14187</link>
		<description>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.&lt;br&gt;&lt;br&gt;&lt;b&gt;Where to start?!&lt;/b&gt;&lt;br&gt;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.  &lt;br&gt;&lt;br&gt;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)!&lt;br&gt;&lt;br&gt;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:&lt;br&gt;&lt;br&gt;Outgoing state's Exit() function&lt;br&gt;Incoming state's Enter() function&lt;br&gt;Incoming state's Execute() function&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;&lt;b&gt;Giving Life to AI&lt;/b&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;&lt;b&gt;The Future?&lt;/b&gt;&lt;br&gt;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 &amp;quot;brain&amp;quot; tested live while the states are being coded, instead of firing up the game each and every time you make a change.</description>
	</item>
</rdf:RDF>
