View

분류:번역 분류:설계패턴


뷰(View)

Submitted by Zachary Booth Simpson on 12/5/2000

$c$ 2000 - Zachary Booth Simpson.잺opied with permission from http://www.totempole.net. If you find any of this work useful, please sign Zack's guest book: http://www.totempole.net/cgi-bin/gbook.cgi.


간단한 의견 교환은 여기에....


의도:

주어진 P.O.V.에서 보이는 모델 들을 그린다(render).

문제:

게임 마다 서로 가장 다른 부분이 바로 렌더러일 것이다. 렌더러는 종종 게임의 기술력을 결정하기도 하고 설계의 외형을 결정하기도 한다. 따라서, 조직화나 관리 편의성을 희생하더라도 렌더러를 극도로 최적화하는 경우가 많다.

해결책:

뷰는 공간적 색인 를 통해서 모델 데이터베이스 를 읽지만, 모델 데이터베이스를 수정하지는 않는다. 일반적으로:

공간적 색인과 뷰 사이의 통신은 종종 게임 성능의 결정적인 요인이 되며, 따라서 세심한 주의가 필요하다. 종종 공간적 색인이 뷰 코드로 간주될 정도로 공간적 색인과 뷰는 직접적으로 관련되어 있다. 그러나 공간적 색인은 모델에 대한 읽기-쓰기가 가능하다는 점에서 모델의 영역에 들어가야 한다고 볼 수도 있다(공간적 색인 의 구현 부분 참고).

대부분의 뷰 구현들은 하나의 모델 '상태'를 하나의 '외형'으로 해석한다. 예를 들어서, 뷰는 하나의 모델 인스턴스 'orc1'로부터 type==ORC_TYPE 와 frame==10 같은 상태를 읽고 그것으로부터 어떠한 그래픽 데이터에 대한 포인터를 얻은 후 실제로 화면에 그린다.

'상태'로부터 '외형'으로의 해석은 렌더링 코드 안에 뒤엉켜서 존재할 수도 있다(RenderDelegationAppearanceMap 참고).

하나의 게임 안이 여러 개의 뷰 구현들을 가지는 경우도 흔하다. 예를 들어서 드라이빙 게임의 커스텀 백미러나 전략 게임의 톱다운 방식 미니맵 등. 그러나, 주가 되는 뷰 구현은 하나만 존재하는 것이 일반적이다.

구조:

지금은 없음.

예:

지금은 없음

문제점과 위험:

지금은 없음

관련 패턴들:

뷰는 공간적 색인 를 통해서 모델 데이터베이스 안의 해당 모델 을 찾고 그것을 화면 등에 표현한다.

종종 뷰는 타입 데이터베이스로부터 아트웍 포인터들을 가져오기도 한다.

뷰는 RenderDelegation을 통해서 커스텀화된 표현을 다른 뷰에 위임하기도 한다.

뷰는 AppearanceMap을 통해서 모델의 상태를 외형으로 해석하기도 한다.