컴포넌트 기반 게임 아키텍처에서 동작을 구현하는 방법은 무엇입니까?


21

게임에서 플레이어와 적 AI를 구현하기 시작했지만 구성 요소 기반 게임 아키텍처에서이를 가장 잘 구현하는 방법에 대해 혼란스러워합니다.

고정되어 달리고 칼을 휘두를 수있는 다음과 같은 플레이어 캐릭터가 있다고 가정 해 봅시다. 플레이어는 정지 상태와 달리기 상태 모두에서 스윙 소드 상태로 전환 할 수 있지만 플레이어가 서 있거나 뛰어 다니기 전에 스윙을 완료해야합니다. 스윙 중에는 플레이어가 걸을 수 없습니다.

내가 알듯이 두 가지 구현 방법이 있습니다.

  • 모든 플레이어 로직을 포함하는 단일 AI 구성 요소를 만듭니다 (실제 구성 요소에서 분리되거나 PlayerAIComponent로 포함). 플레이어 엔터티를 구성하는 개별 구성 요소간에 연결을 만들지 않고 상태 제한을 적용하는 방법을 쉽게 할 수 있습니다. 그러나 AI 구성 요소는 분해 할 수 없습니다. 예를 들어 서서 만 걸어 다닐 수 있거나 걸어 다닐 수 있고 때로는 칼을 휘두르는 적이 있다면 새로운 AI 구성 요소를 만들어야합니다.
  • 구성 요소에서 동작을 분리하여 각각 특정 상태를 식별합니다. 그런 다음 StandComponent, WalkComponent 및 SwingComponent를 얻습니다. 전환 규칙을 시행하려면 각 구성 요소를 연결해야합니다. SwingComponent는 스윙 기간 동안 StandComponent 및 WalkComponent를 비활성화해야합니다. 가끔씩 만 서서 칼을 휘두르는 적이있을 때 SwingComponent가있는 경우에만 WalkComponent를 비활성화해야합니다. 이것은 더 나은 믹스 앤 매치 구성 요소를 허용하지만, 종속성이 추가 될 때마다 유지 관리의 악몽을 초래할 수 있지만, 기존 구성 요소는 캐릭터에 대한 종속성의 새로운 요구 사항에 따라 잘 재생되도록 업데이트되어야합니다.

이상적인 상황은 디자이너가 한 줄의 엔진 또는 스크립트 코드를 건드리지 않고도 구성 요소를 컨테이너로 드래그하여 새로운 적 / 플레이어를 만들 수 있다는 것입니다. 스크립트 코딩을 피할 수는 없지만 가능한 한 간단하게 유지하고 싶습니다.

요약하자면, 모든 AI 로직을 하나의 컴포넌트로 작성하거나 각 로직 상태를 별도의 컴포넌트로 분리하여 엔티티 변형을 더 쉽게 만들어야합니까?

편집 : 나는 첫 번째와 두 번째 상황에 대한 의미에 혼란이 있다고 생각합니다. 아래 다이어그램에서 설명하려고했습니다.

구성 요소 다이어그램

개별 상태와 엔티티 간의 관계에 유의하십시오. 첫 번째 상황에서는 AI 구성 요소가 엔티티에 넣기 전에 사전 빌드됩니다. 디자이너는 프로그래머가 사용할 수있는 고유 한 AIComponent 세트 만 선택할 수 있습니다. 두 번째 상황은 다른 구성 요소와 같은 수준에서 다른 상태입니다. 디자이너는 이제 프로그래머의 간섭없이 고유 한 AI로 개체를 만들 수 있습니다.

문제는 이것들이 컴포넌트 기반 엔터티에서 AI를 구조화하는 유일한 두 가지 옵션이며, 그렇다면 최대의 유연성을 제공하는 것은 무엇입니까?


좋은 답변은 당신이 행동의 독점 성을 어디에 적용하고 싶은가에 달려 있다고 생각합니다. 객체 자체에 있기를 원한다면 드래그 앤 드롭 인터페이스를 통해 디자인과 달리 디자인이 크게 다를 수 있습니다 (이 상태는 이미 움직임 동작이 있으므로 다른 상태를 가질 수 없으므로이 상태 전이 컨테이너에는 이미 포함되어 있습니다) 시간 기반 종료 상태 등).
James

2는 실행 가능한 옵션이 아닙니다.
코요테

답변:


6

당신이 지금 상상할 수없는 더 많은 적이나 플레이어를 원한다면, 분명히 그것을 깨뜨려야합니다. 두 번째 요점에서 설명하는 것은 기본적으로 state 패턴 입니다.

그레고리에 동의하면 별도의 스탠드 및 워크 상태 구성 요소가 없어야합니다. 속도가 0 인 이동 구성 요소 일뿐입니다. 이동할 수없는 물체가있는 경우, 물체를 분리하거나 이동 상태에서 속도가 0이 아닌 것을 방지하는 일종의 부울 제한을 설정해야합니다. .

플레이어에게는 완전히 분리 될 필요가 없다고 생각합니다. 입력 구성 요소를 추가하여 다른 모든 구성 요소를 계속 사용할 수 있습니다. 이 구성 요소는 상태 간의 전환을 주도하는 반면, 적의 경우 기본 AI 또는 원하는 경우 적의 설계자가 선택할 수있는 다른 AI 하위 클래스로 제어됩니다.

편집 : 실제로, 이동 구성 요소를 제한하지 않고 고정 적에게 움직이지 않는 고정 AI 구성 요소를 제공하십시오.


상태 패턴이 첫 번째 상황을 의미하지 않습니까? 결과적으로 하나의 AIComponent가 다른 상태 객체를 포함하는 상태 머신을 구현합니다. 두 번째 옵션으로 의미하는 것은 WalkComponent 및 SwingComponent가 RenderComponent 및 PhysicsComponent와 동일한 유형이라는 것입니다.
고스트

@ghostonline 아이디어가 진행되는 한. 실제로는 아닙니다. AIComponent는 두 번째 다이어그램과 같이 분리됩니다. 다른 구성 요소를 포함하지 않습니다. 두 번째 상황에서 가장 중요한 질문은 설계자가 프로그래머없이 구성 요소를 선택하는 경우 상태 변경시기를 어떻게 알 수 있습니까? 다른 상태는 다른 상태 전이를 의미합니다. 누군가가 여전히 상태를 지정해야합니다.
Tesserex 2019

스탠드 / 워크 / 스윙 컴포넌트를 제어하는 ​​다이어그램 2의 엔티티에 AIComponent를 추가한다는 의미입니까? 내 생각은 구성 요소가 특정 조건에서 블록 또는 활성화 신호를 보내는 것입니다. 예를 들어, SwingComponent는 일반 신호 (예 : 시작시 "bound_feet"신호, 스윙 완료시 "release_feet")를 방출합니다. WalkComponent는이 신호에 따라 자체적으로 비활성화 및 활성화됩니다. '상태 전이'는 구성 요소 자체에 캡슐화되므로 설계자는 구성 요소를 함께 연결하는 프로그래머가 필요하지 않습니다.
유령

@ghostonline "스윙 중 걸을 수 없다"와 같은 규칙을 고쳤지만 스탠드와 워크 사이의 전환은 어떻습니까? 서있는 것이 통제력이 있다면, 걷기를 시도하는 것을 어떻게 알 수 있습니까? 스탠딩 로직은 보행 능력의 부재로 인해 영향을받는 보행 또는 스윙을 선택할 수 있습니다.이 경우 항상 스윙을 선택해야합니다. 그러나 나는 당신이 올바른 길을 가고 있다고 생각합니다.
Tesserex 2019

2

최소한 Player AI (또는 Player Controller라고 부르는 것)를 자체 구성 요소로 유지합니다. 대부분의 게임에서 플레이어는 히트 포인트와 같은 기본 사항을 제외하고는 서로간에 일반화 할 수없는 NPC와 근본적으로 다릅니다.

NPC의 경우 StandComponent와 WalkComponent를 같은 측면으로 봅니다. StandComponent없이 WalkComponent를 사용하겠습니까? 나는 그것을 의심한다. 마찬가지로 RunComponent는 더 빠른 속도와 다른 애니메이션을 가진 WalkComponent 일뿐입니다. NPCMovementComponent와 별도의 NPCSwordFighterComponent를 갖는 가치를 볼 수는 있지만 지나치게 엔지니어링 된 것처럼 느껴집니다.


나는 NPC 움직임과 플레이어 움직임을 그렇게 많이 분리하지 않을 것입니다. 애니메이션과 물리를 움직이는 운동 동작은 확실히 공유 될 수 있습니다. 그것은 다른 행동이나 전환을 선택하는 것입니다 (AI는 AI입니다 ... PlayerController가 있지만 동의합니다. AIController도 있습니다. 둘 다 Movement Components / Swing Components를 사용하여 실제 애니메이션 / 물리 작업을 수행 할 수 있습니다.
homebrew

참된. 모든 움직이는 객체에는 모션을 처리하는 PhysicsComponent 또는 MovementComponent가 있고 PlayerController 및 AIController가이를 사용하여 이동을 처리한다고 가정합니다. 인공 지능이 없거나 가능한 가장 간단한 인공 지능 (상자 또는 쓰레기와 같은 멍청한 물리 객체)이 필요한 이동이 필요할 수 있으므로 이동은 반드시 별도의 구성 요소 여야합니다.
Gregory Avery-Weir

2

먼저 State 구성 요소를 만든 다음 전환을 처리 할 상태 시스템을 만듭니다. 이것을 플레이어와 AI에 사용할 수있을 정도로 일반화하십시오. 이렇게하면 AI가 동일한 규칙에 따라 재생되며 플레이어 상태가 AI 상태와 비교하여 작동 방식을 변경할 때 논리를 변경할 필요가 없습니다.

유한 상태 머신 C ++

위의 내용은 플레이어와 AI가 모두 사용할 수있는 c ++의 상태 머신에 대한 구체적인 예입니다.


1

당신이 원하는 것은 캐릭터 (플레이어와 NPC)의 움직임을 처리하는 구성 요소입니다. AI 구성 요소 또는 플레이어 구성 요소가이 이동 구성 요소에 명령을 보내고 동작을 시작할 수 있는지 확인합니다. 이동 제약 조건을 하나의 단일 구성 요소로 캡슐화합니다. AI 코드와 플레이어 코드는 스윙 소드가 어떻게 실행되는지 알 필요가 없습니다. AI에는 유휴, 공격, 도망과 같은 내부 상태가 있습니다.


1
TYPO : AI 컴포넌트에서 "수신 ..."은 무엇 입니까?
강아지
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.