2008년 11월 04일
Mangalore - Component based Entity System
오늘 메일 박스의 sweng-gamedev 메일링 리스트에서 "Responsibilities in a component system"의 컴포넌트 시스템에 대한 질문이 올라 온 것을 보고 생각난 김에 몇자...
Mangalore의 사용시 해당 게임 플레이와 관련된 코드에만 집중하면 된다. (Mangalore는 컴포넌트 기반의 게임 객체 시스템을 포함한 게임 프레임워크이다. 다시 말하면 게임 프레임워크는 게임 객체 시스템을 포함하는 보다 큰 개념이다)
Mangalore의 소스 디렉토리는 다음과 같이 구성되어 있다.
코드의 재사용과 프로세스의 복잡도에 컨트롤을 극대화 시킬 수가 있다.
이것을 팀 프로젝트 레벨에서 보면 새로운 컨텐츠 개발은 임의의 개발자가 상속등의 방법으로 기존의 프로퍼티를 확장하거나 새로운 프로퍼티를 생성하는 일이 된다.
이 때 중요한 것이 메시지 시스템이다.
각 프로퍼티들은 완전하게 디커플링되어 있다. 바꾸어 이야기하면 A 프로퍼티에서 B, C와 같은 다른 프로퍼티의 헤더 파일을 포함(include)하지 않는다. 프로퍼티 간의 통신은 오로지 메시지를 통해서만 이루어진다.
그러므로 새로운 컨텐츠의 개발은 프로퍼티에 대한 처리와 함께 메시지도 고려가 되어야 한다.
딱 요만큼이다. 새로운 컨텐츠를 추가할 때 신경 써야 할 내용들은.
게임이 복잡하더라도 전체에 대해서 신경 써야 할 필요가 없다.
3년간 개발하고 4년간 서비스한 MMORPG 게임이 있다고 가정하자.
새로운 개발자가 입사했다. 입사 전에는 한번도 이 게임을 접해 보지 않았기 때문에 몇 주간 게임을 플레이해 보고 기본적인 시스템을 이해했다. 물론 이 기간 동안 회사 시스템에도 익숙해 졌으리라.
그럼 이제 본격적으로 일을 시작해야 한다.
그런데,
라이브 중인 게임의 컨텐츠를 개발하는 일을 위해서 총 7년간 만들어 낸 코드를 다 이해해야 한다면?
물론 현실이야 이렇게 극단적이지는 않지만,
전체 코드가 마구 뒤엉켜 있다면?
수 십명이 동시에 코드 여기 저기를 휘저으며 작업하고 있다면?
새로 온 신참 입장에서는 한라인 한라인 작성하는 일이 지뢰밭일거다.
이 복잡도를 조절할 수 있는 시스템을 갖추지 못한다면 시간이 지날 수록 개발에 대한 비용은 기하급수적으로 증가하게 된다.
추가된 다른 컨텐츠와의 상관 관계, 복잡도 증가에 따른 QA 비용 증가, 숙련된 엔지니어의 고용 필요성 등으로...
MMORPG라는 단어에는 이미 이 '복잡도'에 대한 내용이 상정되어 있다.
혁신이나 효율, 생산성, 비용 절감...
입은 이런 것들을 이야기하면서 눈은 렌더링, 쉐이더 등과 같은 아이 캔디(eye candy)에 고정되어 있으면 안된다는 말이다. ^^
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 - 망갈로 뷰어.
코드의 재사용과 프로세스의 복잡도에 컨트롤을 극대화 시킬 수가 있다.
이것을 팀 프로젝트 레벨에서 보면 새로운 컨텐츠 개발은 임의의 개발자가 상속등의 방법으로 기존의 프로퍼티를 확장하거나 새로운 프로퍼티를 생성하는 일이 된다.
이 때 중요한 것이 메시지 시스템이다.
각 프로퍼티들은 완전하게 디커플링되어 있다. 바꾸어 이야기하면 A 프로퍼티에서 B, C와 같은 다른 프로퍼티의 헤더 파일을 포함(include)하지 않는다. 프로퍼티 간의 통신은 오로지 메시지를 통해서만 이루어진다.
그러므로 새로운 컨텐츠의 개발은 프로퍼티에 대한 처리와 함께 메시지도 고려가 되어야 한다.
딱 요만큼이다. 새로운 컨텐츠를 추가할 때 신경 써야 할 내용들은.
게임이 복잡하더라도 전체에 대해서 신경 써야 할 필요가 없다.
3년간 개발하고 4년간 서비스한 MMORPG 게임이 있다고 가정하자.
새로운 개발자가 입사했다. 입사 전에는 한번도 이 게임을 접해 보지 않았기 때문에 몇 주간 게임을 플레이해 보고 기본적인 시스템을 이해했다. 물론 이 기간 동안 회사 시스템에도 익숙해 졌으리라.
그럼 이제 본격적으로 일을 시작해야 한다.
그런데,
라이브 중인 게임의 컨텐츠를 개발하는 일을 위해서 총 7년간 만들어 낸 코드를 다 이해해야 한다면?
물론 현실이야 이렇게 극단적이지는 않지만,
전체 코드가 마구 뒤엉켜 있다면?
수 십명이 동시에 코드 여기 저기를 휘저으며 작업하고 있다면?
새로 온 신참 입장에서는 한라인 한라인 작성하는 일이 지뢰밭일거다.
이 복잡도를 조절할 수 있는 시스템을 갖추지 못한다면 시간이 지날 수록 개발에 대한 비용은 기하급수적으로 증가하게 된다.
추가된 다른 컨텐츠와의 상관 관계, 복잡도 증가에 따른 QA 비용 증가, 숙련된 엔지니어의 고용 필요성 등으로...
MMORPG라는 단어에는 이미 이 '복잡도'에 대한 내용이 상정되어 있다.
혁신이나 효율, 생산성, 비용 절감...
입은 이런 것들을 이야기하면서 눈은 렌더링, 쉐이더 등과 같은 아이 캔디(eye candy)에 고정되어 있으면 안된다는 말이다. ^^
# by | 2008/11/04 09:43 | Nebula Croquis | 트랙백(2) | 덧글(4)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : [KASA발표] 컴포넌트 시스템 도입기?! 2탄
[발표자료] 컴포넌트 도입기 1탄 - By김학현 학현님하고 2주에 걸쳐서 KASA에서 컴포넌트 시스템을 도입에 관련한 내용을 이야기 합니다. 아직 부족한 것이 많은데, 역시 경험이 쌓여야 하나 봅니다. 컴포넌트 시스템은 작은 규모의 프로젝트에서는 별 의미가 없습니다. 그냥 상속을 이용해서 작업하세요.. 대규모 프로젝트라면 한번 정도는 생각해봐도 좋을 것 같군요.. KGC08에 보니까.. 김사마님이 Game Framewo......more
제목 : 게임의 객체 시스템
개발 카테고리에 진지하게 글을 쓴 게 꽤 오래됐네요. 일단 블로그에 글을 쓴 것 자체가 굉장히 오래되었으니 당연하긴 한데…. 쓰자고 생각을 하고 보면 별 대단한 내용 아니긴 해도 현재 개발중인 프로젝트의 보안에 직결된 내용이 많은지라 쉽게 쓰질 못 했는데, 올해부터는 간간히 공개할 수 있는 것들은 공개하는 게 어떨까 생각하고 있습니다. 그 첫 번째 이야깃 거리로…. 굉장히 오랜 시간 동안 고민했던 것 중의 하나가 게임 로직에서......more
관점과 설계철학에서 용어가 나오다보니 디게 다양하게 나오는듯.. 한번쯤 cagetu님이나 kimsama님과 이야기할때는 용어의 통일이 필요할듯 해욤..ㅋ
Game Object - 실제 게임 행위를 기술하는 객체 및 클래스 계층 - App 계층
|
Component - 게임 행위의 단위 모듈 - App 계층
|
Property - 드라이버와 연동하는 데이터 관점에서의 Component - Native 계층
|
Driver - 하부 커널 드라이버 및 시스템 API와 연동하는 추상 드라이버(대표적으로 우리는 Renderer등으로 부르는 것들) - Native 계층
정도는 어떨까요?ㅋㅋ