1 / 31

Finite State Machines

Finite State Machines. Stanislav Tsanev. Outline. Introduction, definition Extensions/Deviations Implementation. FSMs in Game Programming.

gaius
Télécharger la présentation

Finite State Machines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Finite State Machines Stanislav Tsanev

  2. Outline • Introduction, definition • Extensions/Deviations • Implementation

  3. FSMs in Game Programming • “[FSMs] are without a doubt the most commonly used technology in game AI programming today. They are conceptually simple, efficient, easily extensible, and yet powerful enough to handle a wide variety of situations.” (Fu&Houlette) • “[Finite] state machines are widely used because they poses some amazing qualities. They are easy to program, easy to comprehend, easy to debug, and completely general to any problem.” (Rabin)

  4. Game AI Uses • Used to control the behavior of different game elements (monsters, etc.) • Small number of states representing the state of the element • State changes usually based on a small set of external events • Actions associated with either states or transitions • Used at design time and in code

  5. Finite State Machines • Mathematical formalism from theoretical computer science (CSE 318, 409) • Finite set of states Q • Finite input alphabet Σ • Transition function • Various possibilities for output • In practice, more relaxed FSMs are used

  6. Example b a, b a q0 b q1 a q2

  7. FSMs in Practice • Actions take place either in states or at transitions or both • Inputs are other aspects of game world • Often complicated computations necessary to determine transitions • Can have variables in addition to the state • Many extensions and variations

  8. Example Monster in sight Gather Treasure Flee No monster Monster dead Cornered Fight From Fu&Houlette

  9. Extending States • Add actions to be executed when an FSM first transitions to a state or when it leaves a state • Can be emulated with more states

  10. Hierarchical FSM Monster in sight • Each state consists of sub-states • Better modularity Gather Treasure Flee No monster Monster dead Cornered Fight Find treasure Go to treasure Take treasure

  11. Stack FSM • Extension of the “pushdown automata” from CSE 318 • Stack provides additional memory • Can be used to remember state history (push) • Can return to previous state (pop) • Or enter a new state entirely and forget about the old one (replace).

  12. Example Hide Patrol See enemy See enemy Attack

  13. Message-Passing FSM • Event-driven • Integration with other FSMs or game engine • Messages are enums • Used to notify of external change of the world

  14. Example Robot Hit Default State Robot Scanned Wall Hit Bullet Scanned …

  15. Polymorphic FSM • Even minor changes in one FSM can introduce the need of changes in other FSMs • Use polymorphic FSMs instead • Achieves different behaviors • Parameterize key behavior aspects • Code reuse, flexibility

  16. Example Monster in sight & AggressionLevel<0.5 Gather Treasure Flee No monster Monster dead Cornered Fight Monster in sight & AggressionLevel>0.5

  17. Fuzzy State Machines • Based on Fuzzy Logic, where truth values are real numbers between 0 and 1 • Multiple states at the same time with varying degrees of presence • Not widely used in game AI

  18. Probabilistic FSMs • Transition function is stochastic • (meaning which state to go to next is determined “randomly”) • Adds element of chance, achieves more varied behavior

  19. Example Monster in sight (0.3) Gather Treasure Flee No monster Monster dead Cornered Fight Monster in sight (0.7)

  20. Implementation • Development Environment/Tools • Integration within the game • Interface to the rest of the game

  21. Representing FSMs with Standard Programming Languages • Plain/native code (C++/Java) • No need for specialized tools • Various degrees of abstraction/ encapsulation: • FSM • State • Transition • Action • Condition • Etc. • Can become hard to maintain/debug • Where do actions go? • When does the state transition take place?

  22. Example void RunLogic(FSM * fsm) { int input = 0; switch(fsm->getStateID()) { case 0: //GatherTreasure GatherTreasure(); if (SeeEnemy()) input = SEE_ENEMY; break; case 1: //Flee Flee(); if(Cornered()) input = CORNERED; if(!SeeEnemy()) input = NO_ENEMY; break; case 2: //Fight Fight(); if(MonsterDead()) input = MONSTER_DEAD; break; } fsm->stateTransition(input); }

  23. Using an FSM Language • For instance, using preprocessor macros (C++) • More readable • More structured • Easier to write and debug • Introduces a minimum of new key words • Need to make decisions about those

  24. Example BeginStateMachine State(0) OnUpdate GatherTreasure(); if(SeeEnemy()) SetState(1); State(1) OnUpdate Flee(); if(Cornered()) SetState(2); if(!SeeEnemy) SetState(1); State(2) OnUpdate Fight(); if(MonsterDead()) SetState(0); EndStateMachine

  25. Data-Driven FSM • Create a specialized scripting language (will covered in next class) or GUI tool • Easier for non-developers to understand • Helps in design • Relies on translation rules and other data to interface the game • Can compile either to C++/machine code or be interpreted • Big overhead in creating tools

  26. Example Data Monster in sight Gather Treasure Flee Generated Code (output) void RunLogic(FSM * fsm) { int input = 0; switch(fsm->getStateID()) { case 0: //GatherTreasure GatherTreasure(); if (SeeEnemy()) input = SEE_ENEMY; break; case 1: //Flee Flee(); if(Cornered()) input = CORNERED; if(!SeeEnemy()) input = NO_ENEMY; break; case 2: //Fight Fight(); if(MonsterDead()) input = MONSTER_DEAD; break; } fsm->stateTransition(input); } No monster Monster dead Cornered GUI Tool (user input) Fight

  27. Polling Implementation • FSM logic executes on fixed interval • Either certain number of frames/ticks or on timer • Very easy to implement • Potentially a lot of useless computation

  28. Event-Driven Implementation • Implement broadcast-subscribe paradigm • Each FSM subscribes to events of interest • Recalculation only when event is received • Need to make decisions about granularity, what events to make available • Far more efficient than polling • Infrastructure cost

  29. Multithreaded implementation • Each FSM runs in a separate thread parallel to the game engine • Concurrent communication • Continuous updates • Synchronization, etc., considerations • This is the one used in Robocode

  30. Interfacing options • Need to interface the rest of the game to receive inputs and to perform actions • Hard-code each action as a separate function • Maintain an array of function pointers • Invoke functions by name

  31. Summary • FSMs are a powerful technique for encapsulating behavior logic • Many extensions exist • Can be coded directly or with the help of specialized languages or GUI tools • Can be polled, event driven, or run in parallel • Can interface the engine by directly calling its functions, by function pointers, or by dynamically invoking methods

More Related