1 / 21

CO3301 - Games Development 2 Week 18 Extensions to Finite State Machines

CO3301 - Games Development 2 Week 18 Extensions to Finite State Machines. Gareth Bellaby. Topics. Additions to standard FSMs. Probabilistic FSM Extensions to FSMs: Stack-based FSM Hierarchical FSM Subsumption FSM. Additions to FSMs.

cachet
Download Presentation

CO3301 - Games Development 2 Week 18 Extensions to 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. CO3301 - Games Development 2Week 18Extensions to Finite State Machines • Gareth Bellaby

  2. Topics • Additions to standard FSMs. • Probabilistic FSM • Extensions to FSMs: • Stack-based FSM • Hierarchical FSM • Subsumption FSM

  3. Additions to FSMs A FSM is a machine which models states, transitions between states, and actions. FSMs are in common usage. FSMs are a comparatively easy way of modelling behaviour. They are also very effective. FSMs are flexible.

  4. Additions to FSMs • On entry operations. • On exit operations. • Allowing event notifications to trigger transitions. • Reference to additional information, including requests for information.

  5. Probabilistic FSM Describes any FSM which includes probabilities. Probabilities are placed on transitions out of states. Can have: • An output state which has a probability associated with it. • Multiple output states with probability scores used to select between them.

  6. Probabilistic FSM Probabilities could be fixed. Probabilities could change over time, e.g. activation and decay. Note that you extend probabilities in lots of ways, e.g. multiple stimuli, trigger functions, etc.

  7. Stack-based FSM Track past states using a stack. Stacks are pushed on and popped off the stack at transitions. This means that an agent can be interrupted and later return to a previous state. For example, an agent is in a patrol state. The agent becomes involves in combat. The patrol state is pushed onto the stack. After the combat has ended the patrol state is popped off the stack and the agent returns to this state.

  8. Stack-based FSM Stack-based FSM can produce a simpler FSM than a standard FSM. Note that it may not always be appropriate to return to a previous state.

  9. Hierarchical FSM • A state may link to another FSM or set of FSMs. • Transition from a state leads to a brand new FSM. Use the stack to store the initiating state. • If control is passed down the hierarchy then the new FSM starts at its own initial state. • Hierarchical FSMs allow you to identify and separate out behaviour or tasks. • Helps reduce size and complexity of a FSM.

  10. Hierarchical FSM

  11. Hierarchical FSMs For example, there could be a state called "Find Enemy". This could be a high level state which runs another FSM. States may be concrete. A state may have a direct effect upon the world. A state may be abstract. A state may not have a direct effect upon the world.

  12. Hierarchical FSMs Two alternatives: 1) Control is passed completely down to the sub-FSM. 2) More commonly the different levels of the FSM are evaluated concurrently.

  13. Hierarchical FSMs Note that if execution passes to another FSM lower down the hierarchy you would have to record the original state and any associated data because control may pass back at some point.

  14. Hierarchical FSMs • May lead to code re-use since a task could be used in several different situations. • It is good idea to design your game to allow the re-use of FSMs. • For example, combat and movement states can be reused. • The hierarchy of states can produce behaviour unique to an agent even if states are shared with other agents.

  15. Hierarchical FSMs • It is possible to swap FSMs in and out. • This can be done with any one of the FSM layers. • Hence an agent could exhibit different implementations of a task in different situations, e.g. different combat FSMs. • Or a higher layer could be changed so that different planning behaviour occurs.

  16. Hierarchical FSMs • A state could have sub states. • This can bypass the need to have a new FSM. • Don't do it too much else it can lead to the FSM becoming broken or at least difficult to keep track of.

  17. Subsumption FSM • The term subsumption was invented by Rodney Brooks. • Intelligent behaviour can be built from a collection of simple machines. • Decompose complex behaviour into simple modules, operations or tasks. • The modules are implemented as layers.

  18. Subsumption FSM • Layers of FSMs. • The layers of FSMs all operate at the same time. • Lower layers deal with short-term goals. • Higher layers deal with long-term goals. For example • A low layer implements obstacle avoidance. • A higher layer implements attraction to a target.

  19. Subsumption FSM Lower layers have priority. This should mean that the system is robust. Subsumption architectures have been used in games such Jedi Knight: Dark Forces and Halo: Combat Evolved (Rabin, Intro. to Games Dev.) Example: • Planning FSM. • Movement FSM.

  20. Subsumption FSM Layers can deal with radically different operations or tasks. For example, a low-level FSM could implement character animation. Keeps sight of long-term goals. Goals stay relevant.

  21. Further reading Rabin, S., (2003), "Common Game AI Techniques", AI Game Programming Wisdom 2, Charles River Media: Hingham, Mass, USA. Stack-Based FSMs: Tozour, P.l, (2003), "Stack-Based Finite-State Machines", AI Game Programming Wisdom 2. Yiskis, E., (2003), "Finite-State Machine Scripting Language for Designers", AI Game Programming Wisdom 2. Subsumption Architectures Borovikov, I., (2006), "Orwellian State Machines", AI Game Programming Wisdom 3. Yiskis, E., (2003), "A Subsumption Architecture For Character-Based Games", AI Game Programming Wisdom 2.

More Related