Trace:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision 		Previous revision
Next revision Both sides next revision
fsmbot [2010/04/04 01:36]
honza created 		fsmbot [2010/05/16 23:11]
127.0.0.1 external edit
Line 4: Line 4:
 ===== Motivation ===== ===== Motivation =====
  
-Creation of bot using only programming language is hard, even with help of Pogamut that isolates developer from low-level stuff. Mine look like incoherent babble of insane programmer and I am unable to maintain at least some remote sense of purpose. Sure, examples are simple, but complexity is increasing exponentially as you increase stuff you want your bot do and react to. +Creation of bot using only programming language is hard, even with help of Pogamut that isolates developer from low-level stuff. My bots look like incoherent babble of insane programmer and I am unable to maintain at least some remote sense of purpose. Sure, examples are simple, but complexity is increasing exponentially as you increase stuff you want your bot do and react to. 
  
-That is not a news, it is a reason why AI programmers use something else (not some spaghetti code) to program AI (like Posh, Soar or neuron networks). Which one is the best approach is unclear to me, posh has trouble with its atomic actions problem. Posh evaluates plan many time and which element will be fired next is unknown, therefore things like walking is difficult, image your path planner computes path you start walking on, but in next iteration, some completely unrelated element will be fired and of course, the new fired element doesn't expect bot to walk. What to do? Move an inch every time? +That is not a news, it is a reason why AI programmers use something else (not some spaghetti code) to program AI (like Posh, Soar, neuron networks or anything that solves the problem). Which one is the best approach is unclear to me, posh has trouble with its atomic actions problem. Posh evaluates plan many time and which element will be fired next is unknown, therefore things like walking is difficult, image your path planner computes path you start walking on, but in next iteration, some completely unrelated element will be fired and of course, the new fired element doesn't expect bot to walk. What to do? Move an inch every time? 
  
 ===== Finite state machine bot ===== ===== Finite state machine bot =====
-This extension is a helper for developers of bot logic, it is a small finite state machine that  +This extension is a helper for developers of bot logic, if you don't know what FSM is, read an article on [[http://en.wikipedia.org/wiki/Finite-state_machine|wikipedia]] or google, there is a lot of info out there.
-If you don't know what FSM is, read an article on [[http://en.wikipedia.org/wiki/Finite-state_machine|wikipedia]] or google, there is a lot of info out there.+
  
 The idea is that bot moves from state to state and in every state it has certain job it has to do (e.g. rearm itself, find enemy, heal itself). Once the job is done (bot is healed), it will move to another job(state). Under certain conditions however, it has to stop its job, because more pressing matter has appeared (it is being shot at). So we can see that behavior is basically graph with vertices (jobs/states) and edges (transitons). Now if only we had some simple library, where we only had to program states and transitions and it would be all we needed for nice bot ^_^.  The idea is that bot moves from state to state and in every state it has certain job it has to do (e.g. rearm itself, find enemy, heal itself). Once the job is done (bot is healed), it will move to another job(state). Under certain conditions however, it has to stop its job, because more pressing matter has appeared (it is being shot at). So we can see that behavior is basically graph with vertices (jobs/states) and edges (transitons). Now if only we had some simple library, where we only had to program states and transitions and it would be all we needed for nice bot ^_^. 
Line 21: Line 20:
  
 Click to enlarge Click to enlarge
 +
 +I try to smooth the flow between phases, so if your state is being initialized, and it doesn't require additional time (isReady() return true), the method run is immediately called. Basically unless you require some additional time during maintenance (isReady(), isInterrupted(), isCleaned() all return true), the flow won't be suspended. The flow will however will be suspended after run().
 +
 +This benefits developer, because he can be sure, that at least in first execution of method run(), the condition that enabled transition to the state is still valid.
  
 ==== Creation of transition ==== ==== Creation of transition ====
Line 65: Line 68:
  
 ===== Who uses FSM ===== ===== Who uses FSM =====
-It appears FSMs are quite popular among game developers, unreal itself is using it for its bot, so does half life 2, some movies that require big CGI crowds with unsophisticated behavior. +It appears FSMs are quite popular among game developers, unreal itself is using (of course not mine, just concept of FSM) it for its bot, so does half life 2, some movies that require big CGI crowds with unsophisticated behavior. 
  
 ===== Pros ===== ===== Pros =====
-* Reusability, think of states as boxes that can do one simple thing, but even the most complex product is result of many simple actions. +  * Reusability, think of states as boxes that can do one simple thing, but even the most complex product is result of many simple actions. 
-* Isolated testing, it is quite easy to test each state or transition separately +  * Isolated testing, it is quite easy to test each state or transition separately 
-* No more spaghetti code, where you wonder what cause bot to bang its head against the wall+  * No more spaghetti code, where you wonder what causes your bot to bang its head against the wall
  
 ===== Cons ===== ===== Cons =====
-* FSMs are great for small and simple bots (up to 10-15 states)__[at least that is what I have been told]__, but as number of states increases, so does number of transitions that have to be maintained. Upper bound is (num of states)^2. Use of hiearchy can mitigate this up to certain degree, e.g. CTF bot can have three roles FlagTaker, Hunter and Defender with defined transitions between them. Simple FSM. Of course every role has its FSM that has much more limited scope. I am planning to try this and I may share results.+  * FSMs are great for small and simple bots (up to 10-15 states)__[at least that is what I have been told]__, but as number of states increases, so does number of transitions that have to be maintained. Upper bound is (num of states)^2. Use of hiearchy can mitigate this up to certain degree, e.g. CTF bot can have three roles FlagTaker, Hunter and Defender with defined transitions between them. Simple FSM. Of course every role has its FSM that has much more limited scope. 
  
 ===== Where can I get it? ===== ===== Where can I get it? =====