오늘 메일 박스의
sweng-gamedev 메일링 리스트에서 "Responsibilities in a component system"의 컴포넌트 시스템에 대한 질문이 올라 온 것을 보고 생각난 김에 몇자...
Mangalore의 사용시 해당
게임 플레이와 관련된 코드에만 집중하면 된다. (Mangalore는 컴포넌트 기반의 게임 객체 시스템을 포함한 게임 프레임워크이다. 다시 말하면 게임 프레임워크는 게임 객체 시스템을 포함하는 보다 큰 개념이다)
Mangalore의 소스 디렉토리는 다음과 같이 구성되어 있다.
- application - 응용 프로그램 프레임워크
- attr - 속성
- audio - 사운드 처리 관련 모듈
- bldfiles - 빌드 파일들이 저장되어 있다.
- cegui - CEGUI 관련 모듈, 커뮤니티 코드 베이스에만 포함되어 있다.
- ceui - CEUI 사용자 인터페이스 라이브러리
- db - 객체의 Attribute, 데이터베이스 시스템
- fundation - RTII, Reference Count
- fsm - 유한 상태 기계(finite state machine)
- game - 기본적인 게임 로직 관련 기반 모듈
- graphics - 그래픽 처리
- input - 사용자 입력
- lib - ODE, opcode 등의 외부 라이브러리가 있는 폴더.
- loader - 각종 게임 데이터 카테고리별 로더 모듈.
- manager s - 매니저 클래스, 게임 엔티티의 생성, 저장 등.
- message - 메시지 전달 시스템과 관련한 모듈.
- msg - 프로퍼티 간에 전달되는 게임 메시지들을 정의.
- navigation - 웨이포인트(way-point) 및 네비게이션 메쉬 등과 같은 길찾기 관련 모듈.
- ode - 물리 엔진인 ODE의 헤더 파일들이 있는 폴더.
- opcode - 충돌 라이브러리인 opcode의 헤더 파일들이 있는 폴더.
- physics - 물리 처리를 위한 모듈
- properties - 게임 엔티티의 프로퍼티 클래스 파일들이 있는 폴더.
- script - 스크립트 모듈
- tools - 툴 모듈
- ui - 사용자 인터페이스 모듈
- util - 유틸리티 모듈.
- vfx - 카메라 흔들기(shaking)과 같은 특수 효과 관련 코드
- viewer - 망갈로 뷰어.
properties 디렉토리는 게임 엔티티 클래스의 property 클래스들을 포함하고 있는데 Mangalore에서는 이 property가 바로 컴포넌트이다. 실제로 개발시에는 어떤 property들을 조합하며, 어떤 property들을 만들어야 할까에 대해서 고민하는 일이 대부분이다.
코드의 재사용과 프로세스의 복잡도에 컨트롤을 극대화 시킬 수가 있다.
이것을 팀 프로젝트 레벨에서 보면 새로운 컨텐츠 개발은 임의의 개발자가 상속등의 방법으로 기존의 프로퍼티를 확장하거나 새로운 프로퍼티를 생성하는 일이 된다.
이 때 중요한 것이
메시지 시스템이다.
각 프로퍼티들은 완전하게 디커플링되어 있다. 바꾸어 이야기하면 A 프로퍼티에서 B, C와 같은 다른 프로퍼티의 헤더 파일을 포함(include)하지 않는다. 프로퍼티 간의 통신은 오로지 메시지를 통해서만 이루어진다.
그러므로 새로운 컨텐츠의 개발은 프로퍼티에 대한 처리와 함께 메시지도 고려가 되어야 한다.
딱 요만큼이다. 새로운 컨텐츠를 추가할 때 신경 써야 할 내용들은.
게임이 복잡하더라도 전체에 대해서 신경 써야 할 필요가 없다.
3년간 개발하고 4년간 서비스한 MMORPG 게임이 있다고 가정하자.
새로운 개발자가 입사했다. 입사 전에는 한번도 이 게임을 접해 보지 않았기 때문에 몇 주간 게임을 플레이해 보고 기본적인 시스템을 이해했다. 물론 이 기간 동안 회사 시스템에도 익숙해 졌으리라.
그럼 이제 본격적으로 일을 시작해야 한다.
그런데,
라이브 중인 게임의 컨텐츠를 개발하는 일을 위해서 총 7년간 만들어 낸 코드를 다 이해해야 한다면?
물론 현실이야 이렇게 극단적이지는 않지만,
전체 코드가 마구 뒤엉켜 있다면?
수 십명이 동시에 코드 여기 저기를 휘저으며 작업하고 있다면?
새로 온 신참 입장에서는 한라인 한라인 작성하는 일이 지뢰밭일거다.
이 복잡도를 조절할 수 있는 시스템을 갖추지 못한다면 시간이 지날 수록 개발에 대한 비용은 기하급수적으로 증가하게 된다.
추가된 다른 컨텐츠와의 상관 관계, 복잡도 증가에 따른 QA 비용 증가, 숙련된 엔지니어의 고용 필요성 등으로...
MMORPG라는 단어에는 이미 이 '복잡도'에 대한 내용이 상정되어 있다.
혁신이나 효율, 생산성, 비용 절감...
입은 이런 것들을 이야기하면서 눈은 렌더링, 쉐이더 등과 같은 아이 캔디(eye candy)에 고정되어 있으면 안된다는 말이다. ^^