1 / 28

Beyond Finite State Machines Managing Complex, Intermixing Behavior Hierarchies

Beyond Finite State Machines Managing Complex, Intermixing Behavior Hierarchies. Michael Mateas Georgia Institute of Technology College of Computing & LCC www.lcc.gatech.edu/~mateas. Andrew Stern Interactivestory.net, Zoesis Studios. www.interactivestory.net www.grandtextauto.org.

childsh
Télécharger la présentation

Beyond Finite State Machines Managing Complex, Intermixing Behavior Hierarchies

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. Beyond Finite State MachinesManaging Complex, Intermixing Behavior Hierarchies Michael Mateas Georgia Institute of Technology College of Computing & LCC www.lcc.gatech.edu/~mateas Andrew Stern Interactivestory.net, Zoesis Studios www.interactivestory.net www.grandtextauto.org

  2. New programming constructs for believable characters • In creating Façade, we developed programming constructs for believable characters • We created a new language to support these constructs ABehavior Language– ABL • Based on the CMU Oz-project language Hap • Reactive-planning: characters organized as goals and behaviors • Lessons from these constructs can be generalized beyond ABL A different way of thinking than imperative languages (e.g. C++, Java)

  3. Façade • Dramatic world inhabited by computer controlled characters (believable agents) • The user (player) plays a protagonist within the story, first-person point of view • The player experiences a story with a dramatic arc

  4. Façade character requirements • Moment-by-moment believabilityBody movements, facial expression, behavior mixing • Tightly coordinated actionCharacters work closely together to perform story • Conversational behavior Longer-term, non-linear dialog flow that preserves reactivity

  5. Code support for character requirements • Goals and behaviorsSequencing + reactivity, behavior mixing, hierarchy • Joint goals and behaviorsProtocol supporting multi-character teamwork • Meta-behaviors Canonical behavior sequences are modified by player interaction

  6. beat beat beat beat beat beat beat beat beat beat Selected beat Desired value Current arc(s) story values Player Trip Façade architecture Drama Manager (sequences beats) History Bag of beats Recognizers Previous action time Activity not part of a beat Behavior-basedagents used here surface text discourse acts discourse acts reactions Grace Natural Language Processing Story World

  7. Root behavior WME2 WMEn Sensor1 Behavior1 Behavior2 Behaviorn WME1 Behavior library Act Mental Goal1 Goal3 Goal2 Seq. Behavior1 Par. Behavior2 Sensors A behavior-based agent Active Behavior Tree Working memory Available for execution World

  8. Features of our behavior-based agents • Characters organized as goals and sequential & parallel behaviors • Joint (synchronized) goals and behaivors • Reflection (meta-behaviors) • Generalization of sensory-motor connections • Multiple named working memories • Atomic behaviors (useful for atomic WM updates)

  9. Behaviors Behaviors consist of steps • Similar to the scripts or functions associated with FSM states, but • Can be parallel as well as sequential • Mix together as multiple behaviors are pursued Behaviors are chosen to accomplish a goals • Similar to function calls but • Are dynamically chosen given current game conditions • Can be re-chosen if the first choice doesn’t work out

  10. Example behaviors sequential behavior AnswerTheDoor() { WME w; with success_test { w = (KnockWME) } wait; act sigh(); subgoal OpenDoor(); subgoal GreetGuest(); mental_act { deleteWME(w); } } • To answer the door: • Wait for knock • Sigh • Open the door • Greet the guest sequential behavior OpenDoor() { precondition { (KnockWME doorID :: door) (PosWME spriteID == door pos :: doorPos) (PosWME spriteID == me pos :: myPos) (Util.computeDistance(doorPos, myPos) > 100) } subgoal YellAndWaitForGuestToEnter(doorID); } If there is knock and the door is too far away, yell for guest to come in.

  11. Steps • Subgoal – chooses behaviors • Act – does a physical act in the world • Mental act – a bit of computation (e.g. change memory) • Wait – used with conditions to accomplish demons All steps succeed or failBehavior finished when all steps succeed or one step fails Behavior success and failure propagates up ABT

  12. Continuously monitored conditions • Success tests – spontaneously make a step succeed if test is satisfied • Context conditions – spontaneously make a behavior fail if test is satisfied • Makes behaviors immediately reactive to changes in the world

  13. Seq. behavior1 Root behavior Success TestSucceeds Goal3 Goal2 Mental Goal2 Goal2 Par. behavior2 Seq. behavior1 Remove Seq. behavior3 Remove Act1 Goal3 Seq. behavior3 Fail Fail Mental Act2 Act2 Success and failure propagation ABT

  14. Example: Making a drink Code example showing basic sequential behavior plus hierarchical subgoaling.

  15. Example: Interrupting Code example using a continuous condition to interrupt activity.

  16. Example: Low-level parallelism Performance behavior example.

  17. Example: High-level behavior mixing Example showing two high level behaviors blending together (making a drink + dialog performance). Demonstrates conflicts and priorities.

  18. Joint goals and behaviors Characters sometimes need to coordinate action • Some approaches • Coordinate through sensing (but plan recog. hard) • Explicitly communicate (but ad hoc) • Build it into architecture (but not flexible) Architecture coordinates author-specified joint action

  19. Intention to enter G2 Intention to enter G2 Root behavior Root behavior Goal1 Act Mental Goal5 Seq. Behavior5 Joint Behavior2 Joint Behavior6 Seq. Behavior1 Negotiation Agent1’s ABT Agent2’s ABT Joint Goal2 Joint Goal2

  20. Root behavior Root behavior Root behavior Joint Goal2 Mental Goal5 Act Goal1 Goal3 Goal4 Act Seq. Behavior1 Seq. Behavior3 Joint Behavior4 Joint Behavior2 Conflicting intentions Problem: asynchronous agents enter conflicting states Agent1’s ABT Agent2’s ABT Agent3’s ABT Suspends Succeeds Joint Goal2 Joint Goal2 Fails Resolution: intentions are precedence ordered

  21. Root behavior Joint Goal2 Act Seq. Behavior1 Joint Behavior2 Inconsistent subtree execution ABT Problem: continuing execution leads to ABT inconsistencies Succeeds JointGoal1 G2 Resolution: freeze subtree • Initiate exit intention at the subtree root • Remove all leaf steps • Deactivate all monitored conditions • Negotiate removal of all joint goals • Commit to exit intention at subtree root

  22. Joint Goal2 Goal3 Root behavior Root behavior Joint Goal2 Mental Goal1 Act Mental Joint Behavior4 Seq. Behavior3 Seq. Behavior1 Joint Behavior2 Goal4 Variably coupled agents A tunable spectrum between one-mind and many-minds Agent1’s ABT Agent2’s ABT Effects propagate across ABTs Effects propagate within ABTs

  23. Example: Coordinating dialog Beat goal showing dialog-line level agent coordination. Difficult to get this level of coordination without negotiation support.

  24. Meta-behaviors • Meta-behaviors manipulate the runtime state of other behaviors (e.g. succeed or fail steps). • Ability to match on this runtime state just like it was part of the world (preconditions, context conditions, success tests)

  25. Example: Conversation = joint behaviors + handlers Behaviors for a dramatic beat with default order of activity and handlers to respond to interaction.

  26. Interaction = (Joint) behaviors + handlers • Difficult to specify responsive sequential activity • Implicitly encode in ABT – conditions get complicated fast! • Flat behaviors with declarative state – redundant and error prone • Instead: Joint behaviors + handlers (meta-behaviors) • Explicitly encode sequential activity in ABT • Modify future activity through dynamic ABT modification

  27. Conclusions Behavioral coding vs. FSMs • Behaviors support mixing (can be in more than one “state” at once) • Behavior hierarchy more expressive than flat FSMs • Dynamic coupling between goals and behaviors Behavioral coding vs. rules • Behaviors support sequential activity • Behaviors support hierarchy

  28. For more info www.interactivestory.netFaçade project site (includes latest slides) www.grandtextauto.orgGroup blog on games and new media egl.gatech.eduExperimental Game Lab (includes projects using ABL)

More Related