게임 개발에서 클래스 디자인에 대한 올바른 객체 지향 접근법은 무엇입니까?


31

XNA를 사용하여 Windows 7 Phone 용 2D 스프라이트 기반 게임을 개발하는 중입니다. 사용할 수있는 교육 및 자습서는 매우 유용하지만 내가 직면 한 문제는 각각 클래스 디자인에 다르게 접근하고 코드가 잘 구성되어 있지 않다는 것입니다. 결과적으로 특정 수업에 어떤 책임을 부여해야하는지 잘 이해하기가 어려웠습니다.

예를 들어, BaseSprite자체 그리기, 충돌 확인 등을 알고 있는 기본 스프라이트 클래스 를 가질 수 있습니다. 그런 다음 AnimatedSprite스프라이트 시트, ExplodingSprite클래스 등 을 탐색하는 방법을 알 수있는 클래스 를 가질 수 있습니다 . 이 기술은 Windows 7 Phone Jumpstart Session 2 자료 의 Space Invaders 예제 에서 설명합니다 .

다른 방법으로, 나는 GameScreen수업에 게임 책임을 대량으로 렌더링하고 실행할 수 있습니다 . 해당 클래스와 파생 클래스는 책임 측면에서 양식이나 웹 페이지와 유사하게 작동합니다. 스프라이트 클래스는 로직이 훨씬 적은 더 간단한 컨테이너입니다.

이것은 Windows 7 Phone Training Kit 의 Alien Sprite 게임 및 기타 게임 상태 관리자 예 에서 사용되는 기술 입니다.

게임 개발에서 클래스 디자인에 대한 올바른 객체 지향 접근법은 무엇입니까?

답변:


26

Visual, Collision, Animation, Input 등과 같은 구성 요소가있는 Sprite 클래스를 사용하는보다 구성 요소 지향 접근 방식을 사용합니다.이 접근 방식으로 깊은 클래스 계층 구조를 가지지 않습니다 (좋은) .

구성 요소 지향 디자인에 대한 자세한 내용은 여기를 참조 하십시오 .


2
연결 한 기사 +1이 환상적이었습니다. 나는 순수한 OO 디자인에 초점을 맞추고 구성 요소 / 장식 자 유형 모델을 완전히 간과했습니다.
— Josh E

1
구성 요소 패턴은 실제로 "순수하지 않다"OO :)
— Srekel

2
과연. OO는 종종 상속과 동일합니다. 그러나 상속은 OO가 제공하는 도구 중 하나 일 뿐이며 구성도 다른 도구입니다.
— haffax

그냥. 나는 내 말을 좀 더 정확하게 했어야했다. 내가 의미하는 바는 내가 원하는 것을 달성하는 데 도움이되는 OO 디자인 패턴 / 다른 OO 측면을 생각하는 대신 OO의 상속 측면에 많은 초점을 맞추고 있다는 것입니다.
— Josh E

컴포지션 기반 접근 방식은 매우 명백하고 자주 사용되지만 렌더링 구성 요소를 이식 가능하게 유지하는 솔루션은 아직 보지 못했습니다. 어떤 힌트라도 좋을 것입니다.
— Andreas

11

게임에서 컴포넌트 패턴은 일반적인 솔루션입니다.


그것은 또 다른 환상적인 기사입니다-읽을 가치가 있습니다.
— Josh E

1
위대하고 대단한 기사!
— 케빈

6

SOLID 원칙은 다른 직업으로 게임 코드 디자인에 많이 적용 - 내가 시작 지점으로 첫 번째 예를 사용하는 거라고 그래서 적어도 당신은 최적화에 올 때까지.

BaseSprite가 메가 클래스가되는 경향이있는 것처럼 들리기 때문에 더 나아가고 싶습니다. 단일 책임 원칙 (Single Responsibility Principle)은 클래스 계층 구조의 개별 항목이 아니라 구성 요소가 충돌, 렌더링 및 탐색을 모두 처리해야한다고 지시합니다. 이러한 모든 구성 요소의 유지 클래스는 구성 요소 간의 월드 위치 밀기 만 처리해야합니다.


5

지난 몇 개의 프로젝트에서 저는 MVC 스타일 접근 방식에 더 많이 의지했습니다.

처음에는 이것이 작동하는지 확실하지 않았지만 완벽하게 작동했습니다.

모델

데이터 객체. 순수한 데이터 일뿐입니다. 행동, 렌더링이 없습니다.

데이터 관리자. 데이터 객체의 "목록"만 처리합니다. 풀링을 지원하도록 향상 될 수도 있습니다.

전망

우리는 그것들을 렌더러라고 부릅니다. 모든 데이터 객체 유형마다 렌더러가 있습니다. 관리자와 함께 호출하면 해당 목록의 모든 객체가 렌더링됩니다.

제어 장치

렌더러와 동일하지만 동작을 제어합니다.

예

ShipManager에는 배송 목록이 있습니다. ShipController는 상태에 따라 배송을 이동합니다. ShipRenderer는 상태에 따라 배송을 렌더링합니다.

왜

이런 식으로 뷰와 로직이 엄격하게 분리됩니다. 새로운 플랫폼으로 포팅하는 것이 매우 쉽습니다. XxxManager 내부의 데이터 레이아웃을 최적화하는 것도 매우 쉽습니다.


2
나는 "MVC 사용"을 받아 들일만한 대답으로보기에 아프기 때문에 투표를합니다. 최신 플랫폼에서 개발하는 경우 이미 여러 수준에서 MVC를 사용하고 있습니다. 특정 답변이 아니며 좋은 답변이 아닙니다. 실제로 작업 / 도메인 별 클래스를 구성하는 방법을 사람들에게 알려주지 않기 때문입니다. "클래스 모달 ...; 클래스 뷰 ...; 클래스 컨트롤러 ..."를 쓰는 많은 사람들이 있습니다. MVC는 기존 코드에 대해 이야기 할 때 좋은 수준의 설명 능력을 가진 패턴입니다. 좋은 계획력을 가진 패턴이 아닙니다.

4
@ 조 나는 당신의 요점을 얻지 만, 당신의 선택은 불필요한 무례 함을 찾으십시오. 방금 우리가 어떻게하는지 설명했습니다. 더 높은 수준의 아키텍처를 선택하면 더 낮은 수준의 디자인이 더 이상 사용되지 않으므로 올바른 답변이라고 생각합니다.
— 안드레아스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.