"게임 오브젝트"및 컴포넌트 기반 디자인

지난 3-4 년 동안 몇 가지 취미 프로젝트를 진행하고 있습니다. 간단한 2D 및 3D 게임. 그러나 최근에 더 큰 프로젝트를 시작했습니다. 지난 몇 달 동안 나는 모든 게임 객체의 기본이 될 수있는 게임 객체 클래스를 디자인하려고 노력했습니다. 따라서 많은 시험 및 다이 테스트를 거친 후 Google로 전환하여 GDC PDF 및 PowerPoint를 빠르게 가리 켰습니다. 이제 컴포넌트 기반 게임 오브젝트를 파악하려고합니다.

엔진이 게임 오브젝트를 만든 다음 건강, 물리, 네트워킹 및 사용자가하는 모든 것을 처리하는 다른 구성 요소를 연결한다는 것을 이해합니다. 그러나 내가 이해하지 못하는 것은 Y가 객체의 상태를 변경했는지 구성 요소 X가 어떻게 알 수 있는지입니다. 건강이 HealthComponent ..에 의해 제어되기 때문에 PhysicsComponent가 플레이어의 생존 여부를 어떻게 알 수 있습니까? 그리고 HealthComponent는 어떻게 "플레이어 사망 애니메이션"을 재생합니까?

나는 이것이 다음과 같은 인상을 받았다 (HealthComponent에서) :

if(Health < 0) {
   AnimationComponent.PlayAnimation("played-died-animation")
}

그러나 HealthComponent가 연결된 게임 오브젝트에 AnimationComponent가 연결되어 있음을 어떻게 알 수 있습니까? 내가 볼 수있는 유일한 해결책은

1. AnimationComponent가 연결되어 있는지 확인하십시오 (컴포넌트 코드 내부 또는 엔진 쪽).

2. 구성 요소에 다른 구성 요소가 필요하지만 전체 구성 요소 디자인과 싸우는 것 같습니다.

3. HealthWithAnimationComponent, HealthNoAnimationComponent, soo on과 같이 쓰고 전체 컴포넌트 디자인 아이디어와 싸우는 것처럼 보입니다.

모든 예에서 끔찍한 문제가 있습니다. 상태 구성 요소는 엔터티 사망에 응답해야하는 모든 구성 요소 유형에 대해 알아야합니다. 따라서 적합한 시나리오가 없습니다. 귀하의 법인은 건강 구성 요소를 가지고 있습니다. 애니메이션 구성 요소가 있습니다. 다른쪽에 의존하거나 알지 마십시오. 그들은 메시징 시스템을 통해 통신합니다.

상태 구성 요소가 엔터티가 '죽었다'는 것을 감지하면 '나는 죽었습니다'메시지를 보냅니다. 적절한 애니메이션을 재생하여이 메시지에 응답하는 것은 애니메이션 구성 요소의 책임입니다.

상태 구성 요소는 메시지를 애니메이션 구성 요소로 직접 보내지 않습니다. 어쩌면 그것은 그것을 엔티티의 모든 구성 요소, 전체 시스템에 브로드 캐스트 할 수도 있습니다. 애니메이션 구성 요소는 메시징 시스템에 '내가 죽었다'는 메시지에 관심이 있음을 알려야합니다. 메시징 시스템을 구현하는 방법에는 여러 가지가 있습니다. 그러나 구현할 때는 요점은 건강 구성 요소와 애니메이션 구성 요소가 다른 구성 요소가 존재하는지 알거나 신경 쓸 필요가 없으며 새 구성 요소를 추가해도 기존 구성 요소를 수정하여 적절한 메시지를 보내지 않아도된다는 것입니다.

하는 방식 아르테미스이 문제를 해결는 구성 요소에서 처리하지 않을 것입니다. 구성 요소에는 필요한 데이터 만 포함됩니다. 시스템은 여러 구성 요소 유형을 읽고 필요한 처리를 수행합니다.

따라서 귀하의 경우 HealthComponent (및 기타)를 읽고 적절한 애니메이션을 큐에서 재생하는 RenderSystem이있을 수 있습니다. 이런 방식으로 기능에서 데이터를 분리하면 종속성을 올바르게 관리하기가 쉬워집니다.

코드에는 객체가 상태가 변경되었는지 알 수있는 방법이 있습니다 (필자는 다른 방법이있을 수 있습니다).

1. 문자 보내.
2. 구성 요소에서 직접 데이터를 읽습니다.

1) AnimationComponent가 부착되어 있는지 확인하십시오 (컴포넌트 코드 내부 또는 엔진 쪽)

이를 위해 1. GameObject의 HasComponent 기능을 사용했습니다. 2. 구성 요소를 연결할 때 일부 구성 함수에서 종속성을 확인할 수 있습니다.

2) 구성 요소에 다른 구성 요소가 필요하지만 전체 구성 요소 디자인과 싸우는 것 같습니다.

내가 읽은 일부 기사에서 Ideal 시스템 구성 요소는 서로 의존하지 않지만 실제로는 그렇지 않습니다.

3) HealthWithAnimationComponent, HealthNoAnimationComponent, soo on과 같이 쓰면 전체 구성 요소 디자인 아이디어와 싸우는 것처럼 보입니다.

이러한 구성 요소를 작성하는 것은 나쁜 생각입니다. 내 앱에서 Health 구성 요소를 가장 독립적으로 만들었습니다. 이제 가입자에게 특정 이벤트 (예 : "적중", "치료"등)를 알리는 관찰자 패턴에 대해 생각하고 있습니다. 따라서 AnimationComponent는 애니메이션 재생시기를 스스로 결정해야합니다.

그러나 CBES에 관한 기사를 읽었을 때 감동을 받았으므로 CBES를 사용하고 새로운 가능성을 발견하면 매우 기쁩니다.

마이클, 패트릭 휴즈, 블레 키도 마찬가지다. 단순히 문제를 해결하는 것을 피하는 해결책은 문제를 일으키는 이데올로기를 포기하는 것입니다.

OOD가 적고 기능 프로그래밍과 비슷합니다. Component-Based Design으로 실험을 시작했을 때이 문제를 발견했습니다. 나는 더 많은 것을 봤는데, "Functive Reactive Programming"이 해결책이라는 것을 알았습니다.

이제 내 구성 요소는 현재 상태를 설명하는 변수 및 필드 모음 일뿐입니다. 그런 다음 관련된 모든 구성 요소를 업데이트하는 많은 "시스템"클래스가 있습니다. 반응 부분은 시스템을 잘 정의 된 순서대로 실행하여 달성됩니다. 이를 통해 처리 및 업데이트를 수행하기 위해 다음 시스템이 무엇이든, 읽고 업데이트하려는 구성 요소 및 엔티티가 무엇이든 항상 최신 데이터를 처리 할 수 ​​있습니다.

그러나 어떤 식 으로든 여전히 문제가 다시 이동했다고 주장 할 수 있습니다. 시스템이 어떤 순서로 실행되어야하는지에 대해서는 어떨까요? if-else와 switch 문을 엉망으로 만들기 전에 주기적 관계와 시간 문제 만 있다면 어떨까요? 암시적인 형태의 메시징입니다. 언뜻보기에는 작은 위험이 있다고 생각합니다. 일반적으로 사물은 순서대로 처리됩니다. 플레이어 입력-> 엔티티 위치-> 충돌 감지-> 게임 로직-> 렌더링-> 다시 시작합니다. 이 경우 각 시스템마다 하나의 시스템이 있고 각 시스템에 update () 메서드를 제공 한 다음 게임 루프에서 순서대로 실행합니다.