플레이어와 월드 간의 순환 종속성을 피하는 방법은 무엇입니까?

위, 아래, 왼쪽 및 오른쪽으로 움직일 수있는 2D 게임을 만들고 있습니다. 본질적으로 두 가지 게임 로직 객체가 있습니다.

• 플레이어 : 세계에 대한 입장
• 월드 : 맵과 플레이어를 그립니다.

지금까지 월드 는 플레이어에 의존합니다 (즉, 참조가 있습니다). 플레이어 캐릭터를 그릴 위치와 그릴 맵의 위치를 ​​알아 내기위한 위치가 필요합니다.

이제 플레이어가 벽을 통과 할 수 없도록 충돌 감지를 추가하고 싶습니다.

내가 생각할 수있는 가장 간단한 방법은 플레이어 가 의도 한 움직임이 가능한지 세계에 묻도록 하는 것입니다. 그러나 그것은 Player 와 World 사이에 순환 의존성을 유발할 것입니다 (즉, 각각은 다른 것에 대한 참조를 보유합니다). 내가 생각해 낸 유일한 방법은 월드 가 플레이어를 움직이게하는 것입니다.

최선의 선택은 무엇입니까? 아니면 가치가없는 순환 의존성을 피하고 있습니까?

세상은 스스로를 그려서는 안됩니다. 렌더러는 월드를 그려야합니다. 플레이어는 스스로를 끌어 당기지 않아야합니다. 렌더러는 월드를 기준으로 플레이어를 그려야합니다.

플레이어는 월드에 충돌 감지를 요청해야합니다. 또는 충돌은 정적 세계뿐만 아니라 다른 액터에 대해서도 충돌 감지를 확인하는 별도의 클래스로 처리해야합니다.

전 세계가 플레이어를 전혀 인식하지 않아야한다고 생각합니다. 신의 대상이 아닌 저수준의 기본 체 여야합니다. 플레이어는 아마도 간접적으로 (충돌 감지 또는 대화 형 객체 확인 등) 일부 World 메서드를 호출해야 할 것입니다.

일반적인 렌더링 엔진이 이러한 작업을 처리하는 방법은 다음과 같습니다.

공간 안에 물체가있는 위치와 물체가 그려지는 방법에는 근본적인 차이가 있습니다.

1. 객체 그리기

   일반적으로이를 수행하는 렌더러 클래스가 있습니다. 단순히 객체 (Model)를 가져 와서 화면에 그립니다. drawSprite (Sprite), drawLine (..), drawModel (Model)과 같은 메소드가 필요할 때마다 사용할 수 있습니다. 렌더러이므로이 모든 작업을 수행해야합니다. 또한 아래에있는 모든 API를 사용하므로 OpenGL을 사용하는 렌더러와 DirectX를 사용하는 렌더러를 사용할 수 있습니다. 게임을 다른 플랫폼으로 이식하려면 새 렌더러를 작성하여 사용하십시오. "그것"은 쉽다.

2. 객체 이동

   각 객체는 SceneNode 라고 부르는 것에 부착됩니다 . 당신은 구성을 통해 이것을 달성합니다. SceneNode에는 객체가 포함되어 있습니다. 그게 다야. SceneNode 란 무엇입니까? 객체의 모든 변형 (위치, 회전, 스케일) (일반적으로 다른 SceneNode 기준)을 실제 객체와 함께 포함하는 간단한 클래스입니다.

3. 객체 관리

   SceneNode는 어떻게 관리됩니까? SceneManager를 통해 . 이 클래스는 장면의 모든 SceneNode를 만들고 추적합니다. 특정 SceneNode (일반적으로 "Player"또는 "Table"과 같은 문자열 이름으로 식별) 또는 모든 노드 목록을 요청할 수 있습니다.

4. 세계를 그리기

   이것은 지금까지 분명합니다. 씬의 모든 SceneNode를 살펴보고 렌더러가 올바른 위치에 그리도록하십시오. 렌더러가 렌더링하기 전에 객체의 변형을 저장하도록하여 올바른 위치에 그릴 수 있습니다.

5. 충돌 감지

   항상 사소한 것은 아닙니다. 일반적으로 공간의 특정 지점에있는 물체 또는 광선이 교차 할 물체에 대해 장면을 쿼리 할 수 ​​있습니다. 이런 식으로 플레이어의 움직임 방향으로 광선을 만들고 장면 관리자에게 광선이 가장 먼저 교차하는 물체를 물어볼 수 있습니다. 그런 다음 플레이어를 새로운 위치로 옮기거나, 더 작은 양만큼 움직이거나 (충돌하는 물체 옆에 놓기 위해) 움직이지 않도록 선택할 수 있습니다. 이러한 쿼리는 별도의 클래스에서 처리해야합니다. SceneManager에 SceneNode 목록을 요청해야하지만 SceneNode가 공간의 한 점을 덮는 지 또는 광선과 교차하는지 여부를 결정하는 것은 또 다른 작업입니다. SceneManager는 노드 만 작성하고 저장합니다.

그렇다면 플레이어는 무엇이며 세상은 무엇입니까?

Player는 SceneNode를 포함하는 클래스 일 수 있으며, 여기에는 렌더링 할 모델이 포함됩니다. 장면 노드의 위치를 ​​변경하여 플레이어를 이동시킵니다. 세계는 단순히 SceneManager의 인스턴스입니다. SceneNodes를 통해 모든 객체를 포함합니다. 장면의 현재 상태를 쿼리하여 충돌 감지를 처리합니다.

이는 대부분의 엔진에서 발생하는 일에 대한 완전하고 정확한 설명과는 거리가 먼데, 기본 사항을 이해하는 데 도움이되고 SOLID에 의해 밑줄이 표시된 OOP 원칙을 준수하는 것이 중요한 이유가됩니다 . 코드를 재구성하기가 너무 어렵거나 실제로 도움이되지 않는다는 생각에 자신을 사임하지 마십시오. 신중하게 코드를 디자인하면 앞으로 더 많은 것을 얻을 수 있습니다.

왜 피하고 싶습니까? 재사용 가능한 클래스를 만들려면 순환 종속성을 피해야합니다. 그러나 플레이어는 재사용이 필요한 클래스가 아닙니다. 세계없이 플레이어를 사용하고 싶습니까? 아마 아닙니다.

클래스는 기능 모음에 지나지 않습니다. 문제는 기능을 어떻게 나누는가하는 것입니다. 당신이해야 할 일을하십시오. 순환 퇴폐가 필요한 경우에도 마찬가지입니다. (OOP 기능도 마찬가지입니다. 목적에 맞는 방식으로 코드를 작성하고 패러다임을 맹목적으로 따르지 마십시오.)

편집
질문에 대답하기 위해 콜백을 사용하여 플레이어가 충돌 확인을 위해 월드를 알아야한다는 것을 피할 수 있습니다.

World::checkForCollisions()
{
  [...]
  foreach(entityA in entityList)
    foreach(entityB in entityList)
      if([... entityA and entityB have collided ...])
         entityA.onCollision(entityB);
}

Player::onCollision(other)
{
  [... react on the collision ...]
}

엔터티의 속도를 노출하면 질문에 설명 된 물리의 종류를 세계에서 처리 할 수 ​​있습니다.

World::calculatePhysics()
{ 
  foreach(entityA in entityList)
    foreach(entityB in entityList)
    {
      [... move entityA according to its velocity as far as possible ...]
      if([... entityA has collided with the world ...])
         entityA.onWorldCollision();
      [... calculate the movement of entityB in order to know if A has collided with B ...]
      if([... entityA and entityB have collided ...])
         entityA.onCollision(entityB);
    }
}

그러나 조만간 세계에 대한 의존성이 필요할 것입니다. 즉, 세계의 기능이 필요할 때마다 가장 가까운 적의 위치를 ​​알고 싶습니까? 다음 난간이 얼마나 멀리 떨어져 있는지 알고 싶습니까? 의존성입니다.

현재 설계는 SOLID 설계 의 첫 번째 원칙에 위배되는 것 같습니다 .

"단일 책임 원칙"이라고하는이 첫 번째 원칙은 일반적으로 디자인에 항상 해를 끼치는 모 놀리 식의 모든 것을 생성하지 않기 위해 따라야 할 훌륭한 지침입니다.

구체화하기 위해 World객체는 게임 상태를 업데이트 및 유지하고 모든 것을 그리는 책임이 있습니다.

렌더링 코드가 변경되거나 변경되면 어떻게됩니까? 실제로 렌더링과 관련이없는 두 클래스를 모두 업데이트해야하는 이유는 무엇입니까? Liosan이 이미 말했듯이 Renderer.

이제 실제 질문에 대답하기 위해 ...

이를 수행하는 방법에는 여러 가지가 있으며, 이는 분리하는 한 가지 방법 일뿐입니다.

1. 세계는 플레이어가 무엇인지 모른다.
   • Object그러나 플레이어가 있는의 목록이 있지만 플레이어 클래스에 의존하지 않습니다 (상속을 사용하여 달성하십시오).
2. 플레이어는 일부에 의해 업데이트됩니다 InputManager.
3. 세계는 움직임과 충돌 감지를 처리하여 적절한 물리적 변경 사항을 적용하고 객체에 업데이트를 보냅니다.
   • 예를 들어, 객체 A와 객체 B가 충돌하면 세계가이를 알리고 스스로 처리 할 수 ​​있습니다.
   • 세상은 여전히 ​​물리를 다룰 것입니다 (디자인이 그런 경우).
   • 그런 다음 두 객체 모두 충돌이 관심이 있는지 여부를 확인할 수 있습니다. 예를 들어, 물체 A가 플레이어이고 물체 B가 스파이크 인 경우 플레이어는 자신에게 피해를 줄 수 있습니다.
   • 그러나 이것은 다른 방법으로 해결할 수 있습니다.
4. 는 Renderer모든 개체를 그립니다.

플레이어는 충돌 감지와 같은 것들에 대해 세계에 문의해야합니다. 순환 의존성을 피하는 방법은 월드가 플레이어에 의존하지 않는 것입니다. 월드는 드로잉 자체의 위치를 ​​알아야합니다. 아마도 추적 할 엔티티에 대한 참조를 보유 할 수있는 Camera 오브젝트에 대한 참조를 통해 더 멀리 추상화되기를 원할 것입니다.

순환 참조의 관점에서 피하고 싶은 것은 서로에 대한 참조를 많이 보유하는 것이 아니라 코드에서 서로를 명시 적으로 참조하는 것입니다.

서로 다른 두 가지 유형의 객체가 서로를 요청할 수 있습니다. 메소드를 호출하기 위해 다른 것에 대한 참조를 보유해야하기 때문에 서로 의존합니다.

월드가 플레이어에게 요청함으로써 순환 의존성을 피할 수 있지만 플레이어는 월드에 요청할 수 없으며 그 반대도 마찬가지입니다. 이런 식으로 월드는 플레이어를 언급하지만 플레이어는 월드를 참조 할 필요는 없습니다. 혹은 그 반대로도. 그러나 이것은 세계가 플레이어에게 물어볼 것이 있는지 물어보고 다음 전화에서 알려야하기 때문에 문제를 해결하지 못할 것입니다 ...

따라서이 "문제"를 실제로 해결할 수 없으며 걱정할 필요가 없습니다. 최대한 바보 같은 디자인을 유지하십시오.

플레이어와 월드에 대한 세부 정보를 제거하면 두 객체 사이에 순환 종속성을 도입하지 않으려는 간단한 경우가 있습니다 (언어에 따라 중요하지 않을 수도 있지만 Fuhrmanator의 의견 링크를 참조하십시오). 이 문제와 비슷한 문제에 적용 할 수있는 매우 간단한 구조 솔루션이 두 가지 이상 있습니다.

1) 세계적 수준 의 싱글 톤 패턴을 소개하십시오 . 이를 통해 플레이어 (및 다른 모든 객체)는 값 비싼 검색이나 영구적으로 유지되는 링크없이 월드 객체를 쉽게 찾을 수 있습니다. 이 패턴의 요점은 클래스가 해당 클래스의 유일한 인스턴스에 대한 정적 참조를 가지고 있다는 것입니다.이 인스턴스는 객체의 인스턴스화에 따라 설정되고 삭제되면 지워집니다.

개발 언어와 원하는 복잡성에 따라이 클래스를 수퍼 클래스 또는 인터페이스로 쉽게 구현하고 프로젝트에서 둘 이상을 기대하지 않는 많은 주요 클래스에 재사용 할 수 있습니다.

2) 개발중인 언어가 지원하는 언어라면 (많은 언어), 약한 참조를 사용하십시오 . 이것은 가비지 콜렉션과 같은 것에 영향을 미치지 않는 참조입니다. 이 경우 정확히 유용합니다. 참조가 약한 객체가 여전히 존재하는지 여부를 가정하지 마십시오.

특별한 경우 플레이어는 세계에 대한 약한 참조를 보유 할 수 있습니다. (단일 톤과 마찬가지로) 이것의 장점은 각 프레임을 어떻게 든 월드 오브젝트를 검색 할 필요가 없거나 가비지 콜렉션과 같은 순환 참조의 영향을받는 프로세스를 방해 할 영구 참조를 가질 필요가 없다는 것입니다.

다른 사람이 말했듯이, 당신의 생각 World은에 노력하고있다 : 너무 많은 한 일을하고 두 경기 포함 Map(별개의 법인이어야 함) 및 일 Renderer같은 시간에.

따라서 , 가능하면 라는 새 객체를 만들고 GameMap지도 수준 데이터를 저장합니다. 현재지도와 상호 작용하는 함수를 작성하십시오.

그런 다음 객체 도 필요 Renderer합니다. 당신은 할 수 이 있도록 Renderer객체 양쪽 물건 포함 GameMap 하고 Player(뿐만 아니라 Enemies), 또한 그것들을 그립니다.

변수를 멤버로 추가하지 않으면 순환 종속성을 피할 수 있습니다. 플레이어 또는 이와 유사한 것에 정적 CurrentWorld () 함수를 사용하십시오. 월드에서 이미 구현 된 것과 다른 인터페이스를 발명하지 마십시오. 이것은 완전히 불필요합니다.

순환 참조로 인한 문제를 효과적으로 막기 위해 플레이어 객체를 파괴하기 전에 / 제거하는 동안 참조를 파괴 할 수도 있습니다.