게임에서 그림과 논리의 분리


11

나는 지금 막 게임 개발에 혼란을 겪고있는 개발자입니다. 저는 .Net 사람이므로 XNA를 엉망으로했으며 이제는 iPhone 용 Cocos2d를 가지고 놀고 있습니다. 내 질문은 실제로 더 일반적입니다.

간단한 탁구 게임을 만들고 있다고 가정 해 봅시다. 나는 거라고 Ball클래스와 Paddle클래스를. 비즈니스 세계 개발에서 나온 첫 번째 본능은 이러한 클래스 중 하나에 그리기 또는 입력 처리 코드가없는 것입니다.

//pseudo code
class Ball
{
   Vector2D position;
   Vector2D velocity;
   Color color;
   void Move(){}
}

볼 클래스의 어떤 것도 입력을 처리하거나 드로잉을 처리하지 않습니다. 그런 다음 Ball을 새로 만들 다른 클래스, 내 Game클래스 또는 내 Scene.m(Cocos2d)가 있고 게임 루프 중에 필요에 따라 공을 조작합니다.

그러나 XNA와 Cocos2d에 대한 많은 자습서에서 다음과 같은 패턴이 보입니다.

//pseudo code
class Ball : SomeUpdatableComponent
{
   Vector2D position;
   Vector2D velocity;
   Color color;
   void Update(){}
   void Draw(){}
   void HandleInput(){}
}

내 질문은, 이것이 맞습니까? 사람들이 게임 개발에 사용하는 패턴입니까? Ball 클래스가 모든 것을 할 수 있도록 익숙한 모든 것에 어긋납니다. 또한이 두 번째 예에서 내 Ball이동 방법을 알고 있는 곳 에서 Paddle? 에 Ball대한 지식 이 필요 Paddle합니까? 내 첫 번째 예제에서는 Game클래스 모두에 대한 참조 것 Ball과를 Paddle다음 몇 가지로 그 오프의 두 배 CollisionDetection각각의 구성 요소는 그 자체로 모든 것을 않는 경우, 관리자 또는 뭔가를하지만, 내가 어떻게 다양한 구성 요소의 복잡성을 처리합니까? (나는 이해하기를 바랍니다 .....)


2
불행히도 그것은 많은 게임에서 실제로 수행되는 방식입니다. 나는 그것이 모범 사례라는 것을 의미하지는 않습니다. 여러분이 읽고있는 많은 튜토리얼은 초보자를 대상으로 할 수 있으므로 독자에게 모델 / 뷰 / 컨트롤러 또는 요크 패턴을 설명하지는 않을 것입니다.
tenpn

@ tenpn, 귀하의 의견은 이것이 좋은 습관이라고 생각하지 않는다고 제안하는 것 같습니다. 추가 설명이 필요하십니까? 필자는 항상 각 유형에 매우 특정한 코드를 포함하는 메소드로 인해 가장 적합한 배열이라고 생각했습니다. 그러나 나는 나 자신의 경험이 거의 없기 때문에 당신의 생각을 듣고 싶습니다.
sebf

1
@sebf 데이터 지향 디자인이라면 작동하지 않으며 객체 지향 디자인을 좋아하면 작동하지 않습니다. Bob 아저씨의 SOLID 원칙 : butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
tenpn

@ 텐프. 그 기사와 관련 문서가 매우 흥미 롭습니다. 감사합니다!
sebf

답변:


10

내 질문은, 이것이 맞습니까? 사람들이 게임 개발에 사용하는 패턴입니까?

게임 개발자는 어떤 것이 든 사용하는 경향이 있습니다. 엄밀하지는 않지만 배송됩니다.

Ball 클래스가 모든 것을 할 수 있도록 익숙한 모든 것에 어긋납니다.

따라서 handleMessages / update / draw에 대한 일반화 된 관용구가 있습니다. 메시지를 많이 사용하는 시스템 (예상 한 장단점이있는 시스템)에서 게임 개체는 관심있는 메시지를 포착하고 해당 메시지에 대한 논리를 수행 한 다음 스스로 그립니다.

draw () 호출이 실제로 엔티티가 putPixel 또는 그 자체를 호출한다는 것을 의미하지는 않습니다. 경우에 따라 나중에 그리기를 담당하는 코드에서 폴링 한 데이터를 업데이트하는 것을 의미 할 수도 있습니다. 보다 고급의 경우, 렌더러에 의해 노출 된 메소드를 호출하여 자체적으로 "그립니다". 내가 지금 작업하고있는 기술에서 객체는 렌더러 호출을 사용하여 그 자체로 그려지며 렌더링 스레드는 모든 객체가 만든 모든 호출을 구성하고 상태 변경과 같은 것을 최적화 한 다음 전체를 끌어냅니다 (모두 게임 로직과 별개의 스레드에서 발생하므로 비동기 렌더링을 얻습니다).

책임 위임은 프로그래머에게 달려 있습니다. 간단한 탁구 게임의 경우 각 객체가 자체 드로잉 (낮은 수준의 호출로 완료)을 완전히 처리하는 것이 좋습니다. 스타일과 지혜의 문제입니다.

또한이 두 번째 예에서 내 공이 어떻게 움직이는 지 알고있는 패들과의 충돌 감지를 어떻게 처리합니까? 공은 패들에 대한 지식이 필요합니까?

따라서 여기서 문제를 해결하는 한 가지 자연스러운 방법은 모든 객체가 충돌을 확인하기위한 모든 종류의 매개 변수로 다른 모든 객체를 가져 가도록하는 것입니다. 이것은 확장 성이 좋지 않으며 이상한 결과를 초래할 수 있습니다.

각 클래스가 일종의 Collidable 인터페이스를 구현 한 다음 게임의 업데이트 단계에서 모든 Collidable 객체를 반복하고 충돌을 처리하여 필요에 따라 객체 위치를 설정하는 고급 수준의 코드를 갖습니다.

다시 한 번, 게임에서 여러 가지 일에 대한 책임을 어떻게 위임해야하는지에 대한 감각을 개발해야합니다. 렌더링은 독방적인 활동이며 진공 상태의 객체로 처리 할 수 ​​있습니다. 충돌과 물리학은 일반적으로 할 수 없습니다.

첫 번째 예에서 Game 클래스는 Ball과 Paddle 모두에 대한 참조를 가지고 있으며 둘 다 CollisionDetection 관리자 또는 다른 사람에게 전달하지만 각 개별 구성 요소가 수행하는 경우 다양한 구성 요소의 복잡성을 처리하는 방법 모든 것 자체?

이에 대한 자세한 내용은 위를 참조하십시오. 인터페이스를 쉽게 지원하는 언어 (예 : Java, C #) 인 경우 쉽습니다. 만약 당신이 C ++에 있다면 이것은 흥미로울 수 있습니다. 구성 요소 구성과 같은 다른 사람들은 메시징을 사용하여 이러한 문제 (클래스가 메시지를 처리하고 다른 메시지는 무시)를 해결하는 데 유리합니다.

다시 말하지만, 가장 효과적이고 가장 쉬운 방법입니다.


2
아, 그리고 항상 기억하십시오 : YAGNI (당신은 그것을 필요로하지 않을 것입니다)는 정말로 여기에서 중요합니다. 가능한 모든 문제를 처리 할 수있는 이상적인 유연한 시스템을 생각해내는 데 많은 시간을 허비 할 수 있으며 아무 것도하지 않아도됩니다. 모든 가능한 결과에 대해 훌륭한 멀티 플레이어 백본을 원한다면 CORBA를 사용하는 것입니다. :)
ChrisE

5

나는 최근에 '엔티티 시스템'을 사용하여 간단한 Space Invadors 게임을 만들었습니다. 속성과 동작을 매우 잘 분리하는 패턴입니다. 완전히 이해하기 위해 몇 번의 반복이 필요했지만 일단 몇 가지 구성 요소를 설계하면 기존 구성 요소를 사용하여 새 객체를 작성하는 것이 매우 간단 해집니다.

이것을 읽어야합니다.

http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

지식이 풍부한 사람이 자주 업데이트합니다. 또한 구체적인 코드 예제가있는 유일한 엔터티 시스템 토론이기도합니다.

내 반복은 다음과 같이 진행되었습니다.

첫 번째 반복에는 Adam이 설명한 "EntitySystem"오브젝트가있었습니다. 그러나 내 구성 요소에는 여전히 메서드가 있습니다. '렌더러 블'구성 요소에는 paint () 메서드가 있고 내 위치 구성 요소에는 move () 메서드가 있습니다. 엔티티를 살살 내기 시작했을 때 구성 요소 업데이트 및 구성 요소 업데이트 실행 순서가 너무 복잡합니다.

그래서 돌아가서 T-machines 블로그를 다시 읽었습니다. 주석 스레드에는 많은 정보가 있으며 실제로 컴포넌트 에는 동작이 없는 컴포넌트가 엔티티 시스템에 의해 제공됨을 강조 합니다. 이러한 방식으로, 순서는 전체 시스템 실행 순서에 따라 결정되므로 구성 요소와 주문 구성 요소 업데이트간에 메시지를 전달할 필요가 없습니다 . 확인. 어쩌면 너무 추상적 일 수도 있습니다.

어쨌든 반복 # 2를 위해 이것은 블로그에서 얻은 것입니다.

EntityManager-특정 유형의 구성 요소를 포함하는 엔티티에 대해 조회 할 수있는 구성 요소 "데이터베이스"역할을합니다. 빠른 액세스를 위해 인 메모리 데이터베이스로 백업 할 수도 있습니다. 자세한 내용은 t-machine part 5를 참조하십시오.

EntitySystem-각 시스템은 기본적으로 일련의 엔트 라이트에서 작동하는 방법입니다. 각 시스템은 엔티티의 구성 요소 x, y 및 z를 사용하여 작업을 수행합니다. 따라서 구성 요소 x, y 및 z가있는 엔티티에 대해 관리자에게 조회 한 다음 해당 결과를 시스템에 전달합니다.

엔터티-long과 같은 id입니다. 엔티티는 컴포넌트 인스턴스 세트를 '엔티티'로 그룹화하는 것입니다.

구성 요소-일련의 필드 .... 동작 없음! 당신이 행동을 추가하기 시작할 때 그것은 단순한 우주 인베이더 게임에서도 지저분 해지 기 시작합니다.

편집하다 : 그런데 'dt'는 마지막 메인 루프 호출 이후의 델타 시간입니다.

제 주요 Invadors 루프는 다음과 같습니다.

Collection<Entity> entitiesWithGuns = manager.getEntitiesWith(Gun.class);
Collection<Entity> entitiesWithDamagable =
manager.getEntitiesWith(BulletDamagable.class);
Collection<Entity> entitiesWithInvadorDamagable = manager.getEntitiesWith(InvadorDamagable.class);

keyboardShipControllerSystem.update(entitiesWithGuns, dt);
touchInputSystem.update(entitiesWithGuns, dt);
Collection<Entity> entitiesWithInvadorMovement = manager.getEntitiesWith(InvadorMovement.class);
invadorMovementSystem.update(entitiesWithInvadorMovement);

Collection<Entity> entitiesWithVelocity = manager.getEntitiesWith(Velocity.class);
movementSystem.move(entitiesWithVelocity, dt);
gunSystem.update(entitiesWithGuns, System.currentTimeMillis());
Collection<Entity> entitiesWithPositionAndForm = manager.getEntitiesWith(Position.class, Form.class);
collisionSystem.checkCollisions(entitiesWithPositionAndForm);

처음에는 조금 이상해 보이지만 매우 유연합니다. 최적화하는 것도 매우 쉽습니다. 다른 구성 요소 유형의 경우 검색을 더 빠르게하기 위해 다른 백업 데이터 스토어를 가질 수 있습니다. 'form'클래스의 경우 충돌 감지를위한 액세스 속도를 높이기 위해 쿼드 트리로 백업 할 수 있습니다.

나는 당신과 같습니다. 나는 노련한 개발자이지만 게임 작성 경험이 없습니다. 나는 개발 패턴을 연구하는 데 약간의 시간을 보냈고, 이것은 내 눈을 사로 잡았습니다. 그것은 일을하는 유일한 방법은 아니지만 매우 직관적이고 강력하다는 것을 알았습니다. 이 패턴은 "Game Programming Gems"시리즈 ( http://www.amazon.com/Game-Programming-Gems/dp/1584500492)의 6 권에서 공식적으로 논의되었다고 생각합니다 . 나는 어떤 책도 읽지 않았지만 게임 프로그래밍에 대한 사실상의 참조라고 들었습니다.


1

게임을 프로그래밍 할 때 따라야 할 명시적인 규칙은 없습니다. 게임 전체에서 동일한 디자인 패턴을 따르는 한 두 패턴을 완벽하게 수용 할 수 있습니다. 게임을위한 더 많은 디자인 패턴이 있다는 것에 놀랄 것입니다. 그 중 일부는 OOP를 넘어선 것도 아닙니다.

이제 개인적 취향에 따라 미니멀리스트 객체를 사용하면서 동작 (그린 클래스 / 스레드, 다른 클래스는 업데이트)으로 코드를 분리하는 것이 좋습니다. 병렬화가 더 쉬워졌으며 종종 적은 수의 파일로 동시에 작업하고있는 경우가 많습니다. 나는 이것이 더 절차적인 방법이라고 말합니다.

그러나 비즈니스 세계 출신이라면 자신을 위해 모든 것을 수행하는 방법을 아는 수업을 작성하는 것이 더 편할 것입니다.

다시 한 번, 가장 자연스러운 느낌을 쓰는 것이 좋습니다.


내 질문을 오해 한 것 같아 나는 모든 것을 스스로 수행하는 수업을 좋아하지 않는다고 말하고 있습니다. 나는 공을 논리적으로 표현해야하는 것처럼 공처럼 떨어졌지만, 게임 루프, 입력 처리 등에 대해서는 아무 것도 알아야합니다.
BFree

공정하게 말하자면, 비즈니스 프로그래밍에서 그것을 쇠약하게한다면, 두 가지 기차가 있습니다 : 스스로로드하고, 유지하고 논리를 수행하는 비즈니스 객체와 DTO + AppLogic + Repository / Persitance Layer ...
Nate

1

'볼'객체에는 속성과 동작이 있습니다. 객체의 고유 한 속성과 동작을 자체 클래스에 포함시키는 것이 합리적이라고 생각합니다. Ball 객체가 업데이트되는 방식은 패들이 업데이트하는 방식과 다르므로 클래스에 포함되도록 보증하는 고유 한 동작이라는 것이 합리적입니다. 그림과 같습니다. 패들을 그리는 방법과 공을 그리는 방식에는 종종 독특한 차이가 있으며 다른 클래스에서 조건부 평가를 수행하여 해결하기보다 개별 객체의 그리기 방법을 이러한 요구에 맞게 수정하는 것이 더 쉽다는 것을 알았습니다.

Pong은 많은 객체와 행동 측면에서 비교적 간단한 게임이지만 수십 또는 수백 개의 고유 한 게임 객체에 들어가면 두 번째 예제가 모든 것을 모듈화하기가 조금 더 쉽다는 것을 알 수 있습니다.

대부분의 사람들은 서비스 또는 정적 클래스를 통해 모든 게임 오브젝트에서 결과를 사용할 수있는 입력 클래스를 사용합니다.


0

비즈니스 세계에서 아마도 익숙한 것은 추상화와 구현을 분리하는 것이라고 생각합니다.

게임 개발 세계에서는 일반적으로 속도 측면에서 생각하고 싶습니다. 더 많은 객체를 사용할수록 더 많은 컨텍스트 전환이 발생하여 현재로드에 따라 속도가 느려질 수 있습니다.

나는 지망생 게임 개발자이지만 전문 개발자이기 때문에 이것은 내 추측 일뿐입니다.


0

아니요, '올바르지 않습니다'또는 '잘못되지 않습니다. 단순한 단순화 일뿐입니다.

프리젠 테이션과 논리를 강제로 분리하는 시스템으로 작업하지 않는 한 일부 비즈니스 코드는 정확히 동일합니다.

여기에, "비즈니스 로직은"(번호 추가)를 GUI 이벤트 핸들러로 작성된 VB.NET 예, - http://www.homeandlearn.co.uk/net/nets1p12.html

각 개별 구성 요소가 모든 것을 스스로 수행하는 경우 다양한 구성 요소의 복잡성을 어떻게 처리합니까?

그렇게 복잡해지면 그것을 인수 분해 할 수 있습니다.

class Ball
{
    GraphicalModel ballVisual;
    void Draw()
    {
        ballVisual.Draw();
    }
};

0

개발 경험에 비추어 볼 때, 작업 그룹에 수용된 관행이 없다면 옳고 그른 방법은 없습니다. 나는 행동, 스킨 등을 분리하는 데 반대하는 개발자의 반대를 만났습니다. 그리고 나는 태양 아래 모든 것을 포함하는 수업을 쓰는 나의 예약에 대해 똑같이 말할 것이라고 확신합니다. 코드를 작성해야 할뿐만 아니라 내일과 미래의 코드를 읽고 디버깅하고 다음 반복에서 빌드 할 수 있어야합니다. 자신과 팀에게 적합한 경로를 선택해야합니다. 다른 사람들이 사용하는 경로를 선택하면 (직관에 반 직관적) 속도가 느려집니다.

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