유한 상태 머신을 컴포넌트 기반 아키텍처에 연결하는 방법은 무엇입니까? [닫은]

상태 머신은 컴포넌트 기반 아키텍처에서 유해한 종속성을 유발하는 것으로 보입니다.

특히 상태 시스템과 상태 관련 동작을 수행하는 구성 요소 간의 통신은 어떻게 처리됩니까?

내가있는 곳 :

• 컴포넌트 기반 아키텍처를 처음 사용합니다.
• 나는 그것이 중요하다고 생각하지 않지만 싸우는 게임을 만들고 있습니다. "crouching", "dashing", "blocking"등과 같은 상태를 전환하는 데 사용되는 상태 시스템을 구상합니다.
• 내가 컴포넌트 기반 아키텍처에 대한 가장 자연스러운 시스템으로이 상태 관리 기술을 발견했습니다,하지만 난에 대해 읽은 기술과 충돌 : 변경 가능한 행동 문자에 대한 동적 게임 오브젝트 구성 요소 시스템 그것은 모든 구성 요소가 활성화 제안 / 비활성화 활성화 조건을 지속적으로 확인하여
• "달리기"또는 "걷기"와 같은 동작은 상태로 의미가 있다고 생각합니다. /gamedev//a/7934

• 나는 이것이 유용하지만 모호한 것을 발견했다 : 컴포넌트 기반 게임 아키텍처에서 행동을 구현하는 방법? 상태 머신 만 포함하는 별도의 구성 요소를 갖는 것이 좋습니다. 그러나 이것은 상태 머신 구성 요소와 거의 모든 다른 구성 요소 사이에 어떤 종류의 결합을 필요로한다. 이 커플 링을 어떻게 처리해야하는지 모르겠습니다. 이것들은 몇 가지 추측입니다.

  A. 구성 요소는 상태 시스템에 따라 다릅니다 . 구성 요소는 상태 상수를 반환하는
  상태 시스템 구성 요소에 대한 참조를받습니다 getState(). 구성 요소는 정기적으로 업데이트되며 필요에 따라이를 확인합니다.

  B. 상태 시스템은 구성 요소에 따라 다릅니다
  . 상태 시스템 구성 요소는 모니터링하는 모든 구성 요소에 대한 참조를받습니다. 현재 getState()위치를 확인하기 위해 메소드를 쿼리합니다 .

  C. 그들 사이의 추상화
  이벤트 허브를 사용하십니까? 명령 패턴?

  D. 구성 요소
  상태 패턴 을 참조하는 별도의 상태 객체 가 사용됩니다. 구성 요소 집합을 활성화 / 비활성화하는 별도의 상태 개체가 생성됩니다. 상태 머신은 상태 객체 간을 전환합니다.

• 나는 컴포넌트를 aspect의 구현으로보고있다 . 그들은 그런 측면을 이루기 위해 내부적으로 필요한 모든 것을합니다. 다른 구성 요소에 의존하지 않고 구성 요소가 자체적으로 작동 해야하는 것처럼 보입니다. 일부 종속성이 필요하다는 것을 알고 있지만 상태 시스템은 모든 구성 요소를 제어하려고합니다.

개요는 상당히 밝지 만 작년에 New Game Conf에서 한 프레젠테이션에서 다음 슬라이드를 확인하십시오.

https://docs.google.com/presentation/d/110MxOqut_y7KOW1pNwIdcccisIA3ooJwVR-xm-ecuc4/view

(아래 관련 이미지 참조)

이 기법의 요점은 액션리스트 패턴 (슬라이드에서 다소 나쁘게 설명되어 있음)을 컴포넌트 기반 게임 엔티티에 작용하는 행동 상태 머신과 결합하는 것입니다.

본질적으로 AI 행동을위한 특수한 컴포지션 시스템을 만드는 것과 동일합니다. 이는 단순한 AI 시스템에 필요한 행동 간 통합의 종류에 맞춰져 있습니다.

이 게임에서 가장 좋아하는 부분은 미리 작성된 행동 목록에서 간단히 선택하여 완전히 새로운 유형의 적을 생성하고 원하는 순서대로 게임 객체 (BrainComponent에 있음)의 액션 목록에 넣는 방법이었습니다. 우선 순위와 모든 것이 방금 작동했습니다. Blocking / NonBlocking 작업을 허용하는 작업 목록을 사용하면 구현이 얼마나 간단한 지에도 불구하고 정말 멋진 일을 할 수 있습니다.

실제로 StunBehaviorAction 만 동작 목록 스택의 맨 위로 푸시 한 "stun"과 같은 동작; 기절 된 행동이 활성화되면 (게임 오브젝트의 EarsComponent가 충격적인 충격파 공격을 듣는 것을 관찰 한 후) 내부 상태를 기절 상태로 설정하고 AnimationComponent에 기절 된 애니메이션을 재생하도록 명령하고 동작 상태를 차단으로 설정하고 타이머를 게임 오브젝트의 EnemyParametersComponent에서 가져온 기절 타임 아웃 차단 중이고 작업 목록의 맨 위에 있으므로 작업 목록의 다른 BehaviorAction은 업데이트 메서드를 호출하지 않으므로 기본적으로 해제됩니다. 시간 초과가 만료되면 StunBehaviorAction은 상태를 다시 유휴로 설정하고 작업 상태는 비 차단으로 설정합니다.

우리가 구현 한 다른 동작은 거의 모두 단일 내부 상태 머신으로 구현되었습니다. 실제로 상태 머신이없는 유일한 두 개는 PatrolPathBehaviorAction (유휴 상태 인 경우 일련의 PathAction을 동작 목록에 푸시 함 (이동하여 MoveAction을 푸시 함)) 및 GuardHomeBehaviorAction (항상 맨 아래에 있음) 액션리스트를 만들고 항상 PathAction을 적의 집 위치로 되돌려 놓습니다.) 다른 모든 행동은 상태 머신이었습니다.

이전 회사에서 근무한 상태 기반 AI가있는 구성 요소 기반 시스템이있었습니다. 해당 객체 / 장치의 모든 동작을 제어하는 ​​AI 구성 요소가있었습니다. 방황, 공격 등 AI가 활성화되면 필요한 모든 논리를 수행하기 위해 각 프레임마다 업데이트가 수신됩니다. AI가 유휴 상태이거나 움직이지 않을 때 구성 요소가 비활성화되고 각 프레임이 업데이트되지 않았습니다. 비활성화 된 상태에서 구성 요소는 여전히 이벤트 기반 메시지를 수신 할 수 있으므로 플레이어가 어그로 반경에 들어가는 것과 같은 메시지를 수신하고 AI 구성 요소를 다시 활성화하여 프레임 기반 업데이트를 수행 할 수 있습니다.

AI 구성 요소에는 하위 구성 요소가 있으므로 수행중인 작업 유형에 따라 즉석에서 생성 및 파괴 할 수 있습니다. 예를 들어 방황하는 경우 방황하는 하위 구성 요소를 만들고 방황하는 동안 각 프레임을 업데이트 한 다음 방황하는 동안 aggro'd하면 해당 하위 구성 요소를 닫고 공격 하위 구성 요소를 엽니 다. AI 구성 요소는 객체의 다른 모든 구성 요소와 독립적이어야합니다. 예를 들어, 입력 컴포넌트가 있는데, 이는 단순히 유닛의 이동 값을 쿼리합니다. 그것이 만든 질문은 인간과 AI 객체 모두가 응답 할 수있는 것이었다. 이를 통해 인공 지능 구성 요소는 방황과 같은 상황에서 사람이 제어 할 수있는 구성 요소가 입력 구성 요소가 선택할 수있는 값을 설정하는 것처럼 입력 구성 요소를 포착 할 수 있도록 이동 값을 간단하게 설정할 수있었습니다.

구체적인 예가 없으면 용어가 매우 모호하므로 구성 요소의 의미가 불분명합니다. 종종 게임 엔티티는 상속이 아닌 컴포지션을 사용하여 만들어집니다. 따라서 엔터티에 상태 구성 요소를 추가하여 손상을 입을 수있는 대상으로 만들거나 애니메이션 구성 요소를 추가하여 애니메이션을 만들 수 있습니다. AI를 그러한 구성 요소에 넣을 수도 있습니다. AI 구성 요소에는 의사 결정 논리가 있으며 시스템의 다른 코드와 결합하는 데 관심이있는 경우 AI 논리 만 액세스 할 수있는 정보를 칠판에 수집 할 수 있습니다. AI 시스템의 출력에 의존하는 문제도 있습니다. 기본적으로 AI는 엔티티를 제어하고 있으며 해당 제어에는 인터페이스가 필요합니다. 유용한 개념 중 하나는 컨트롤러 또는 게임 패드입니다. AI는 플레이어 게임 패드가 채울 수있는 유사한 구조를 채울 수 있습니다 (특정 능력에 대한 추가 "버튼"이있을 수 있음). 이제이 구조를 애니메이션 구성 요소로 전달하여 해석하고 적절한 애니메이션을 선택할 수 있습니다. 다른 AI 하위 구성 요소는 구조의 다른 필드 또는 다른 우선 순위를 가진 동일한 필드에 쓸 수도 있습니다. 예를 들어 조준하고 걷기. 다른 AI 하위 구성 요소는 구조의 다른 필드 또는 다른 우선 순위를 가진 동일한 필드에 쓸 수도 있습니다. 예를 들어 조준하고 걷기. 다른 AI 하위 구성 요소는 구조의 다른 필드 또는 다른 우선 순위를 가진 동일한 필드에 쓸 수도 있습니다. 예를 들어 조준하고 걷기.