• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,880
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
38
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 뭘 원하나 ? 계층 로직에는 뭐가 있나 ? 장점은 ? 단점은 ? 그래서 어떻게 해결 ?
  • 완전한 제어를 원해 … 하지만 항상은 아니야 완전한 디자이너 지시 AI 는 자동적으로 행동
  • 목적 지향이어야 해 … 하지만 갑작스러운 변화들에 반응해야해 목적의식이 있는 behaviors Event 에 응답
  • 재밌는 문제 , 10 년 동안 애써왔다 . 업계가 관심을 끝만하다고 짐작한다 .
  • Not just games, robotics, simulation of adaptive behaviors. Great way to find a balance of computation and domain expertise. 계산과 분야 전문지식의 균형을 찾는데 좋은 방법이다
  • Types of hierarchical logic
  • 자기성찰 , 분석하기 어렵다 많은 디자이너들이 접근하기는 어렵다
  • 일반적으로 노동 집약적 목적 지향적으로 만들기 쉽지 않음
  • 자동화를 위해 검색을 사용 자연스럽게 목적 지향적
  • 절차적 코드의 통합 제어와 실행을 무시
  • Intuitive reactive: 직관적인 반응 , 반작용 Integrated flexible: 통합된 유연성 Autonomous purposeful: 자주적인 목적성 Combine to fix each other problems Middle ground
  • 본전은 뽑을 수 있을 만한 가치 의사결정 실행을 제어 & 관찰
  • Reusable Behaviors in Games 게임 AI 의 과제는 context sensitive 한 방법으로 behavior 들을 스케쥴링함을 포함한다 . 그리고 이것은 점점 더 큰 FSMs 를 요구한다 . 로직은 반드시 ... 동적인 목적 과 액터의 태스크에 의존해서 동작해야 한다 . 액터의 현재 상태 에 정응하며 동작해야 한다 . FSM 을 사용함에 있어 어려운 점 추가하려는   각각의 새 context 에 의해서 각 state 의 로직이 exploding 됨을 예방하는 것 이를 효율적으로 하기 위해서는 상태의 responsibility 를 여러 상태들로 쪼개고 다양한 context 들에서 상태들의 로직을 재사용 해야 한다 .   State Break Modularity 전통적인 FSM 에서   state 에 관한 문제는 로직이 있는 그대로는 resusable 하지 않다는 것 State 는 State Machine   내부에서 매우   구체적인 역할을 수행 Transition 은 ... Hardwired   &   명확한 문맥의 양상을 띤다 -> 다른 문제를 풀기 위해 FSM 의 부분을 사용할 수 없다 명확한 상태들과 Transition 들에 의존한다 . -> 요구되는 로직이 없으면 FSM 은 실패한다 . 그래서 ,   State 를 모듈식의 블럭으로 다룰 수 없고 , 로직 내의 다른 문맥에서 그것을 참조할 수 없다 . 새로운 문맥에 대해 명확하게 다른   transitions 로 새로운   상태를 만들어야 한다 .   Resusable Logic 새로운 상태들을 만들기 위해   로직의 덩어리를 어떻게 쉽게 재사용할 수 있을까 ? HFSM 과 BTs 는 이것에 대해 매우 다른 접근법을 가진다 .
  • Is this Good Enough? HFSM 은 분명히 transition 들을 재사용   하는 방법을 제공한다 . 하지만 , 아직 이상적인 solution 은 아니다 . 문제점은 ... Reusing transitions 는 잘 해내기가 쉽지 않다 . 다양한 문맥들에 대한 로직을 생성해야 할 때 , 많은 생각을 요구한다 .   (e.g. dynamic goals, actor status) 우선은 transition 들을 수작업으로 편집하기가 좀 지루하다 다른 해결책은 , 개별의 state 들을 모듈식으로 만듬에 집중하는 것이다 . state 들은 로직의 다양한 부분에서 있는 그대로 쉽게 재사용될 수 있다 . Behavior Trees 는 이 접근법을 취한다 . (hybrid HFSM)
  • BTs 는 다른 접근법을 가진다 .
  • BTs 는 로직을 명백하게 캡슐화해서 (encapsulating logic transparently) state 들의 모듈성을 증가시킴에 초점을 맞춤 중첩 states 비법은 최부   state 들에 대한 transition 들을 제거하여 ,   state 들이   독립 (self-contained) 되게 하는 것 사실 , state 들은 더이상 'states' 가 아니게 된다 . 'transitions' 가 없기 때문인데 , 단지 실행하고 종료하는 behaviors 또는   action 의 집합이 된다 .
  • 프로그래밍 유추 , 유사성 transition 들이 더이상 각 state 내에서 명시적으로 표현되지   않는데 , 어떻게 behavior 들을 차례로 배열할까 ? 각 연산은    successor 에 대한 포인터를 포함하지 않는다 . 다른 문맥에서 이 연산들을 재사용하기 어렵기 때문 . 대신에 , 연산들은   parent scope 에서   삽입된다 . (e.g. 함수 내에서 , 또는   상태 검사를 위해 ) 그리고 , parent scope 의 의미에 따라 실행된다 . 연산 간의 transition 들은 어떤 타입의 parent   scope 가 선택되었냐에   따라 자동적으로 정의된다 .
  • BTs 가 확장성 있게 구현된다면 ( 그래서   아무 타입의 scope 또는 합성 behavior 가 추가될 수 있다면 ) 매우 강력할 것임 sequences 와 selectors 같은 표준 합성이 제공된다면 ,   BTs 는   매우 간단하고 유용해 진다 . custom decorators 를 섞어 넣으면 정말 강력할 뿐만 아니라 매우 직관적이게 된다 . sequences 와 selectors 의 간단한 BT 를 FSM 으로 변환할 수도 있다 . FSM 은 개별적인 transition 들에서 더 많은 제어를 제공하지만 , BT 는 로직이 모듈적이고 재사용이 쉽도록 만든다 .
  • Leaves give …
  • Hungry, tired, entity queries(finding bones) Read-only
  • Game logic(dog bite, decrease health value)
  • Latent computation( 잠재한 계산 )- function runs over time Task – start, update multiple times, and stop Condition- Actoin – playing animation
  • More consistent( 일관성 ) to work with Tasks everywhere. Simpler high-level logic.
  • EXAMPLES of Sequences and Selectors 진행하다가 실패하면 탈출
  • EXAMPLES of Sequences and Selectors 실패해도 계속 진행
  • 한 번 정의하면 , 어디서나 재사용 가능하도록
  • 디자인 원칙 모든 전이들을 편집하기 위한 지침을 제공
  • 더 나은 에러 핸들링 제공 Selectors 를 구축함을 쉽게
  • Embrace: 포괄하다 . 수용하다 . 패턴 High-level task 처럼 구현 더 간단해지고 직관적이다 디자이너가 mix & match 하도록 도와라
  • 객체지향 프로그래밍에서 데코레이터 패턴은 , 추가적인 behavior 를 오리지널 코드의 수정없이 이미 존재하는 객체의 메소드에 추가할 수 있도록 해준다 .
  • 점진적인 개발 이 데코레이터는 원하는데로 구현될 수 있다 모듈식의 스크립트 해석기
  • Why - Multiple goals - Multiple reactions

Transcript

  • 1. Behavior Tree Overview 아꿈사 : http://cafe.naver.com/architect1 김태우 : [email_address]
  • 2.  
  • 3. INDEX
    • Introduction
    • FSM
    • HFSM
    • BTs
  • 4. Introduction
  • 5. Wish List
      • Perfect designer supervision
      • AI behaves autonomously too
    I want full control... ...but not all the time!
  • 6. Wish List
      • Purposeful behaviors
      • Responds to events
    The AI should be goal directed ...yet react to sudden changes!
  • 7.  
  • 8. Hierarchical Logic
  • 9. HFSM Planners HTN Scripting C++ Lua
  • 10. Scripting: The Good
      • Any computation possible
      • Widespread experience
    I've done this for years!
  • 11. Scripting: The Bad
      • Difficult to introspect, analyze
      • Not accessible to many designers
    What's planning?
  • 12. HFSM: The Good
      • Simple and intuitive
      • Full low-level reactive control
    It's actually usable!
  • 13. HFSM: The Bad
      • Generally labor intensive
      • Not easy to build goal directed
    It takes a lot of work...
  • 14. Planning: The Good
      • Uses search for automation
      • Goal directed by default!
    AI can solve many logic problems.
  • 15. Planning: The Bad
      • Integration of procedural code
      • Ignores control & execution
    It's disconnected from the real world?
  • 16. HFSM Planners HTN Scripting C++ Lua
  • 17. intuitive reactive autonomous purposeful integrated flexible Behavior Trees
  • 18. Bang for Buck!
      • Decision making over time
      • Control & monitoring execution
  • 19. FSM
  • 20. Abstract
      • 이론적으로 , FSM 은  logic 의 명확한 형태를 제공
      • 실용적으로도 , FSM 은 해결하려는 문제에 유용
      • A blessing and a curse
        • 처음엔 간단히 시작하지만 ,
        • 규모가 커지게 되면 문제가 생긴다
  • 21. What is state?
    • FSM 은 state 라는 개념에 기반하는데 , state 는 2 가지로 구성된다
      • Set of actions at the same time
        • 애니메이션 , 사운드 , 약간의 대기
      • Set of transitions with conditional check
        • 다음 state 으로 언제 넘어갈 지를 결정
    • State 들은 정말 generic 하고 robust 하게 만들어 질 수 있다 .
      • 간단한 문제에 관해서는 좋은 편이다 .
      • 커다란 문제에 관해서는 더욱 확장성 있는 접근법이 필요하다 .
  • 22.  
  • 23.  
  • 24. HFSM
  • 25. Abstract
    • HFSM 은 재사용 가능한 로직에 대한 약간의 도움을 제공
    • 디자인 절차는 non-HFSM 과 매우 유사
      • state 마다 로직을 구축한다 . transition 들로 state 들을 bottom up 식으로 연결한다 .
      • 새로운 state 들을 생성하는 동안 , transition 들을 공유하기 위해 state 들을 그룹화 한다 .
    • 이렇게 하면 , transition logic 의 중복을 간단히 피할 수 있다 .
  • 26. Super-States and Generalized Transitions
    • Super-States == Groups of States
    • 이 super-states 역시 transition 들을 소유 이론적으로 중복 전이를 예방 가능
      • 전이를 각 상태 마다 개별적으로 적용시키지 말고 , super-states 에 한 번만 적용시킴
      • 이것을 generalized transitions 라고 부름
    • state 들은 전형적으로 하나의 super-state 에 포함되어 , 폴더처럼 엄격한 계층을 가지게 됨
  • 27. Behavior Trees
  • 28. Abstract
    • 게임 AI 의 주 목적 중 하나는 로직을 편집하기 위해 간단하고 확장성있는 솔루션을 찾는 것
    • FSM
      • 장점 : 정말 간단하다
      • 단점 : 큰 시스템에서는 state 들 간에 재사용 가능한 transition 들을 제공하기 위해 HFSM 이 필요함
    • HFSM
      • 장점 : 확장성 있는 로직을 만드는데 분명히 유용
      • 단점 : state 들에 대해 어떤 모듈성도 제공하지 않음
        • 다양한 목적과 상황에 대한 로직을 제공하기 위해 state 들을 재사용할 수 없음
  • 29. State of Behaviors
    • state 들의 모듈성을 증가
      • encapsulating logic transparently
    • state 들이 독립 (self-contained) 되도록
      • state 들에 대한 transition 들을 제거
    • No more 'states‘
      • 'transitions' 가 없기 때문
      • 단지 실행하고 종료하는 behaviors 또는  action 의 집합이 됨
  • 30. A Programming Analogy
    • 어떻게 behavior 들을 차례로 배열할까 ?
      • 각 연산은  successor 에 대한 포인터 없음
      • 대신에 , 연산들은  parent scope 에서 삽입됨 그리고 , parent scope 의 의미에 따라 실행됨
      • 연산 간의 transition 들은 자동적으로 정의됨
  • 31. Why Behavior Trees Work
    • BTs 가 확장성 있게 구현된다면 매우 강력
      • sequences 와 selectors 같은 표준 합성의 제공
      • custom decorators 를 섞어 넣음
    • sequences 와 selectors 의 간단한 BT 를 FSM 으로 변환 가능
      • FSM
        • 개별적인 transition 들에서 더 많은 제어를 제공
      • BT
        • 로직이 모듈적이고 재사용이 쉽도록 만듬
  • 32. Behavior Trees
  • 33. A Guard Dog's AI Woof
  • 34. Example patrol investigate attack look around move bite
    • recursive decomposition
  • 35. Leaves
      • interface between AI and engine
  • 36. Conditions
      • actor state, meta-checks
      • collision, entity queries
  • 37. Actions
      • animation, sound
      • using objects, game logic
  • 38. It's All About Tasks
      • Latent computation
      • Succeed or Fail
    Condition Action Condition Task
  • 39. Building Complexity
    • branches manage the leaves
    • done using composite tasks
  • 40. Sequences keep going bail out
  • 41. Selectors terminate keep trying
  • 42. Dynamic Behavior as Search
  • 43. Behavior Language
      • Standard & high-level composite tasks
      • Rather than custom low-level logic
    So I implement concepts once , and reuse them everywhere?
  • 44. In Practice
  • 45. Improving Your HFSM Does this help me with my state machine ?
  • 46. Improving Your HFSM
      • make it easy to build sequences
      • no need to (re)wire transitions
      • easier to build purposeful behaviors
  • 47. Design Principles That gives me some guidelines to follow for editing all those transitions!
  • 48. Improving Your Scripts How does that help me with my scripts ?
  • 49. Improving Your Scripts
      • provide better dynamic error handling
      • by making it easy to build selectors
  • 50. Software Patterns It'll help me think about my scripts on a higher-level .
  • 51. Scalability
  • 52. Remove Bottlenecks
      • Custom logic takes time to code up..
      • Also much more likely to cause bugs
    ? ? Lua / FSM
  • 53. Embrace Design Patterns
      • find common patterns
      • implement them as high-level tasks
      • it's much simpler and intuitive
      • helps designers mix and match
  • 54. Decorator Tasks “ In object-oriented programming, the decorator pattern allows additional behavior to be added to an existing method of an object without modifying the original code.” original task decorator filter
  • 55. Decorating a Behavior Bark, woof pause wuf multiple times, ignoring voice failures, no more often than every x seconds. at most n times in total, timer counter loop wrapper
  • 56. Incremental Development
      • it's a modular script interpreter
    These decorators can be implemented as they are required.
  • 57. Summary
  • 58. HFSM Planners HTN Scripting C++ Lua BT
  • 59. intuitive reactive autonomous purposeful integrated flexible BT tree editor stack language full planning
  • 60. That's All Folks!
  • 61. References
    • AIGameDev
      • http://aigamedev.com/open/articles/bt-overview/
    • The Artificial Intelligence of Halo 2
      • http://electronics.howstuffworks.com/halo2-ai.htm
    • Halo2 AI and Blah Blah
      • http://www.naimadgames.com/publications/gdc05/gdc05.ppt
  • 62.  
  • 63. Lisence