2D 게임의 객체가 스스로 렌더링해야합니까?


16

타일 ​​기반이 아닌 2D 스트리트 파이터와 유사한 게임을 만들고 있습니다. 일반적으로 사람들은 자신을 렌더링하는 것이 아니라 렌더링하는 렌더러에 엔티티를 제공하는 것이 좋습니다.

왜 하나가 다른 것보다 낫습니까?

감사


왜 그 반대가 더 낫다고 생각합니까?

1
@Martin 객체는 어쨌든 사용할 비트 맵을 암시하므로 object-> render ();
jmasterx

답변:


11

몇 가지 고려 사항 :

  • 언급했듯이 각 스프라이트는 사용할 비트 맵을 "힌트"해야하지만 엔터티가 자체 렌더링해야하는 경우입니다. '힌트'는 무엇입니까? 각 스프라이트에 대해 다른 비트 맵, 스프라이트 시트 등을 참조하는 경우 필요 이상의 메모리를 사용하거나 해당 메모리를 관리하는 데 문제가있을 수 있습니다. 별도의 렌더러의 장점은 자산 관리를 담당하는 클래스가 하나뿐이라는 것입니다. SF2와 같은 격투 게임에서는 두 개의 스프라이트 만 가질 수 있습니다.)

  • 다른 곳에서 언급했듯이 그래픽 API를 변경할 때마다 모든 스프라이트의 코드를 변경해야합니다.

  • 일부 그래픽 컨텍스트에 대한 참조없이 렌더링은 거의 수행되지 않습니다. 따라서이 개념을 나타내는 전역 변수가 있거나 각 스프라이트에는 render (GraphicalContext ctx) 인터페이스가 있습니다. 그래픽 API와 게임의 논리 (일부 사람들이 부적절하다고 생각하는 논리)를 혼합하여 컴파일 문제를 일으킬 수 있습니다.

  • 필자는 개인적으로 렌더링을 개별 엔티티에서 분리하는 것이 그래픽을 전혀 필요로하지 않는 시스템으로 게임을 보는 방향에서 흥미로운 첫 번째 단계라는 것을 알고 있습니다. 내 말은 렌더링을 방해 할 때 엔터티, 내부 상태 등의 좌표가 중요한 "그래픽이 아닌 세계"에서 많은 게임 플레이가 발생한다는 것을 깨닫게됩니다. 이것은 자동화 된 테스트, 더 많은 분리 된 시스템 등의 문을 엽니 다.

대체로 렌더링이 별도의 클래스에 의해 수행되는 시스템을 선호하는 경향이 있습니다. 그렇다고해서 렌더러를보다 쉽게 ​​작성하거나 더 효율적으로 만들 수있는 경우 스프라이트에 "그래픽 관련"(애니메이션 이름, 애니메이션 프레임, 높이 x 너비, 스프라이트 ID 등) 속성을 가질 수는 없습니다.

그리고 이것이 3D에 적용되는지 알지 못합니다 (메시 개념과 사용하는 좌표 변수가 3D API와 관련이있을 것입니다 .x, y, h, w는 2D와 거의 무관합니다) API).

도움이되기를 바랍니다.


11

렌더링 시스템이 언제 그려지는 것을 제어하기를 원합니다. 대신 스프라이트가 렌더링을 제어하는 ​​경우 많은 효율성 향상과 유연성을 잃게됩니다. 제어 시스템에 렌더링 시스템을 사용하면 코드가 깨끗해진다는 의견이 있습니다.

중앙 집중식 렌더링의 몇 가지 장점 :

  • z 순서 :
    게임 오브젝트 자체가 렌더링을 담당하는 경우 올바른 순서로 호출해야합니다. 그렇지 않으면 배경 객체가 전경 객체 위에 그려 질 수 있습니다.
    렌더 시스템을 제어하면 모든 렌더 객체를 정렬하고 렌더 타임에 겹친 부분을 감지하여 렌더링하거나 그냥 함께 주문하는 것을 선택할 수 있습니다. 요점은 이제 쉽게 결정을 내릴 수 있다는 것입니다.
  • 배치 :
    렌더 시스템을 제어 할 수있는 또 다른 확실한 이점은 배치입니다. 여기서 다시 렌더링 시스템은 스프라이트 렌더링에 텍스처를 공유하는 옵션을 배치해야합니다. 삼각형 슬라이싱을 사용 하여 한 번의 호출로 모든 것을 렌더링 할 수 있습니다 . 렌더링 계산을 캐시 할 수 있습니다. 또는 그 멋진 물건으로 각 스프라이트를 차례로 렌더링 할 수 있습니다. (참고 : 각 객체가 스스로 렌더링 될 때 배치가 가능하지만 문제는 덜 효율적이고 복잡합니다).

게임에서 이것을 구현하는 방법은 게임 오브젝트가 렌더링 시스템으로 그린 ​​스프라이트를 등록하도록합니다. 오브젝트가 더 이상 오브젝트를 그리 길 원하지 않으면 스프라이트를 등록 해제하거나 비활성 상태로 표시합니다.

그게 다야 게임 오브젝트를 스스로 렌더링하는 것이 더 쉬운 경우에는 반드시 그렇게하십시오. 완벽한 아키텍처를 구축하는 것보다 발전하고 무언가를 끌어내는 것이 훨씬 중요합니다.


객체가 스스로 그려지는 경우 z 순서화 정보 시스템이 그리기 방법을 호출하는 순서를 결정할 수 없습니까? 중앙 집중식과 비 중앙 집중식은 z 순서에 아무런 영향을 미치지 않는 것 같습니다.
GorillaApe

3

면책 조항 : 귀하의 질문에 자세한 내용이 없으므로 일반적인 원칙으로 답변하고 있습니다. 내가 당신의 사용 또는 '렌더링'을 오해 한 경우 실례합니다.

나는 일반적으로 외부 객체를 사용하여 장면의 다양한 액터를 개별 '액터 객체'외부의 장면 레벨 속성 및 메소드를 캡슐화하는 방법으로 렌더링합니다. 장면의 오브젝트는 내부 메소드와 속성 만 포함해야합니다. 그들은 자신이 무엇이며 무엇을하는지 알아야합니다. 아마도 사용자 입력뿐만 아니라 게임의 다른 개체의 영향을받을 것입니다. 이것은 화면에서 렌더링 방법에 따라 달라집니다. 예를 들어 '디렉터 객체'는 'w'키를 눌러 점프 한 다음 액터 객체에 .jump ()를 알려줍니다. 이러한 디렉터 레벨 로직은 액터에게 장면에 완전히 들어가거나 나가도록 지시 할 수도 있습니다.

건배, 데이비드


그러나 그런 의미에서 감독은 acton-> setVisible (false)라고 말할 수 없었습니다. ?
jmasterx

setVisible (false) 경우에도 액터의 보이는 변수를 확인하고 참인 경우에만 렌더링하여 렌더링을 수행하는 외부 엔티티입니다.
Nav

액터를 보이지 않게 만드는 것만으로도 장면에서 제거되지는 않습니다. 또한 충돌 등의 참여를 중단해야합니다.
finnw

3

언젠가 게임을 다른 해상도 (예 : iPhone 및 친구)로 이식하려면 어떻게해야합니까? 따라서 변경 사항 렌더링에 대한 전역 속성, 코드를 쉽게 업데이트하는 방법은 무엇입니까?


3

내가 사용한 것은 관찰자 기반 디자인이었습니다. 클래스의 인스턴스를 만들 때 렌더링하고 싶었고 포인터를 중앙 렌더러 클래스에 저장했습니다. 을 호출 RenderFrame()하면 렌더러에는 이미 렌더링해야하는 기존 객체가 모두 있고 속성에 액세스하여이를 수행합니다. 수업 자체는 전혀 렌더링 될지 몰랐습니다. 이 API는 훌륭하고 깨끗하며 사용하기 쉽습니다.


1
흥미로운 +1. 그래픽에 방문자 패턴 을 사용하는 동안이 방법을 사운드에 사용했습니다 . 그래픽과 AI가 같은 시계에서 실행되는 동안 오디오 믹서가 다른 시계에서 실행되므로 이벤트 모델이 더 쉬워서 이것이 사운드에 더 적합하다고 생각했습니다. 움직임 이벤트 (오디오 채널의 팬 / 리버가 변경되는)가 밀리 초 늦게 도착하는 경우에도 중요하지 않지만 스프라이트가 잘못된 상태로 그려지는 경우에도 중요합니다.
finnw

2

일반적으로 코드를 유지하고 확장하는 것이 얼마나 쉬운 지 항상 중요합니다. 내일은 현재 사용중인 그래픽 API가 마음에 들지 않고 전환하고 싶다는 것을 알았습니다. 이제 모든 객체 클래스를 살펴보고 모든 것을 변경해야합니까, 아니면 여전히 프로젝트의 한 중심점에서 코드를 변경해야합니까?

render ()를 호출 할 때 객체가 실제로 수행하는 작업에 따라 다릅니다. 그들이 그래픽 엔진 주위에 메소드 호출을 감싸는 한, 논리 <-> 그래픽 구별이 여전히 주어지기 때문에 완전히 괜찮습니다.

예를 들어, render () 메소드가 기본적으로 편리한 메소드이고 다음과 같은 경우 :

void MyClass::render(const Graphics &g)
{
    g.draw(this);
}

또는

void MyClass::render()
{
   mySprite->render();
}

또는

void MyClass::render()
{
    mySprite->UseShader(thatshader);
    mySprite->render();
}

또는 그와 가까운 곳에서는 그것이 문제라고 생각하지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.