East Agent's Blog

Nebula Philosophy - Nebula is an operating system for games - Nebula 엔진과 Mangalore 게임 프레임워크에 대한 꽤 오래된 글...

올리고 보니 생각나는 것 하나.

며칠 전에 A팀장이 게임 엔진 몇개에 대해서 물어왔다.

Orge, Irricht, Crystal Dynamics, Reality Factory, Nebula, Open Scene Graph...(한 10 여가지였던 것 같은데 다 기억나지는 않는다) 들 중에서 어떤 것이 좋냐고.

Crystal Dynamics는 보지 말것, Orge는 글쎄로, Reality Factory는 너무 낡았고, OSG도 잘...

추려내고 남은 것이 Irricht과 Nebula 두 가지인데, 내 대답이 뻔할 뻔자 Nebula이고.

T가 두 가지를 구분하는 방법은 Nebula에는 아키텍쳐가 있다는 것이고 Irricht은 그냥 렌더러라는 것. 틀린 것은 아닌데 너무 함축적이라 다소 이해가 난해하다.

Nebula의 경우 다년 간 실제 상용 게임들을 만들면서 부닥친 수 많은 문제점들에 대한 해결책이 엔진에 녹아 있다는 점이다. 그래서 엔진의 API를 보고 이것이 어떤 처리를 하는 것인지를 이해하는 것도 중요하지만 더 중요한 것은 왜 이렇게 해결하고 있는지에 대한 것을 이해하는 것이다. 그래서 RadonLabs라는 개발사의 히스토리를 이해하는 일이나 이제껏 개발한 게임들을 아는 일이 때로는 엔진을 이해하는데 많은 도움이 된다.

Irricht은 플랫폼 그래픽스 API의 래퍼 아닌가. 그 이상도 그 이하도 아닌. 이런 류의 미들웨어는 많다. 게임브리오도 여기에 속하고. Irricht은 그런 류의 미들웨어 중에서도 간결함에 있어서 상당히 좋은 평을 받는 것 중의 하나이다.

이렇게 보면 또 Nebula 쪽으로 편향된 것처럼 보일지 모르겠지만 둘 다 맞는 곳이 있다는 이야기다. Nebula처럼 자신의 아키텍쳐가 있는 것들은 이 아키텍쳐를 바꾸어야 하는 곳에서는 쥐약이다. 그런 쪽에는 차라리 Irricht이 더 나은 선택일 것이다.

하지만 시간이 좀 걸리더라도 게임 개발 전체에 대한 여러가지를 배우려면 Nebula를 권한다. 전문적인 개발에서 부닥친 여러 문제점에 대한 실용적인 해답도 그 속에 함께 있기 때문이다.

아래 리플렉션(Reflection) 이야기에 이어 다시 리플렉션 이야기.

리플렉션을 이용해서 편리하게 구현할 수 있는 것 중의 하나가 바로 툴이다.

지난 포스팅 중에 하나로 올 초에 구상 중이던 것으로 툴 제작을 간편하게 할 수 있는 미들웨어가 있었는데 Nocturnal이 있으므로 자동 패스. -_-; (http://kimsama.egloos.com/1730141)

리플렉션이 툴 개발에 편리하다라고만 이야기하면 사실 잘 안와닿는데 언리얼 에디터의 속성 창이 바로 이 리플렉션을 사용해서 구현한 것이다. (언리얼 코드를 볼 수 없는 사람들은 Nocturnal Initiative를 보자.)

실제로는 편리하다는 표현만으로는 무안할 지경이다. 새로운 객체가 추가되더라도 UI는 더 이상 만들어야 할 필요가 없으니 말이다.

망갈로 관련해서 작년 7월에 작성하고 마무리 못하고 비공개로 해 놓은 글이 하니 있군요. 망갈로의 리플렉션과 관련한 내용은 자세하게 정리가 된 글이 있지만 공개 여부는 아직 모르겠습니다. 우선 이전의 비공개글들을 하나씩 정리해서 공개하는 차원에서 포스팅합니다.

Reflection of Mangalore

게임과 관련한 리플렉션에 대한 글은 GPG 5권의 "Using Templates for Reflection in C++"에 나와 있지만 기본 지식이 없는 사람이 이해하기는 다소 어렵다고 느껴집니다. 또 핵심만 이야기해 놓은 것도 아니구요.

개인적으로는  Detlef Vollmann의 "Metaclasses and Reflection in C++"이 처음 접하는 사람도 쉽게 이해할 수 있는 글이라 추천하고 싶네요.

약간 길다고 느껴지면 GDMag 2007년 12월에 소개된 Mick West의 글이 있습니다. 온라인상에서 볼 수 있는지는 모르겠지만 소스는 여기에서 구할 수 있습니다.

그리고 Insomniac의 Nocturnal Initiative 프로젝트의 ToolFramework라는 것도 있습니다. 리플렉션과 관련해서는 실전 종합편이랄까요. 툴 프레임워크지만 게임과 관련해서 프레임워크에 대한 의미도 한번 되새겨 볼 수 있는 오픈소스 라이브러리입니다.

새로운 기술을 개발하고 이를 정의한 아키텍쳐에 맞추어서 프레임워크로 발전 시키는 것이 소프트웨어 개발사의 바람직한 모습이라고 할 때 Nocturnal Initiative 프로젝트야 말로 이러한 개발의 모범 사례가 아닐까요.

아침에 그 덧글을 보고 처음에는 그냥 피-식 웃었다.

별 뜻이 있는 것은 아니고,

화까지 났다고 하니까... ㅎ...그럴 정도의 일은 아닌 듯 한데 해서.


글 마지막에 있는 이분이 원하는 답만 하면 간단하긴 한데

그래서는 앞으로 Nebula는 물론이고 다른 오픈소스 프로젝트와도 친하게 못 지내실 듯 하다.

그래서 이왕지사, 길더라도 종합편으루다 한번 올려 보는 것도 좋을 듯 하다는 생각이 들었다.

아래는 덧글의 원문이다. (해당 포스팅은 여기)

------------------->
nebula2로 상용 게임도 만들고 nebula3로는 새게임을 만들고 있다고 하는데

도대체 커뮤니티 버전은 관리가 되고 있는 겁니까? (화내서 죄송--^)

논리적 오류도 아니고 몇일째 컴파일에러와 빌드에러만 고치고 있습니다.

튜토리얼이라고 고작 2~3개 있는데 버전 관리가 안되있어 스트레스만 쌓이네요.

굳이 알필요도 없는 에러 패턴에 대한 지식만 축적하고 있습니다.

(독특한 객체 시스템으로 "이름"을 사용하지만 이 이름이 제대로 맞지 않아 실행시 로드에러가 많이 납니다.)
("shaderPath" 여야 되는데 "shaderpath"로 되있어 한참 찾았습니다.)

Nebula2SDK_2005_06_19.exe 에는 Mangalore가 없고
svn nebula2는 버전관리가 안되있어 에러고치려면 구글의 힘이 필요하고

N3SDK_Sep2008.exe는 아직 render층의 기능이 부족한 상태고
svn nebula3의 audiotest_win32 예제는 XACTAudioDevice::WaitForWaveBankPrepared()에서
동기화가 안되어 무한루프를 돌고있고

그냥 하소연했습니다.;;

혹시 안정된 nubula2 sdk 구할 수 없을까요?

nubula2 conrib에 예제(openaldemo)도 만드신거 봤습니다.
------------------->

우선 기다리셨을테니 질문에 대한 답변부터.

소스포지에서는 SVN 버전을 사용하시고 Nebula2SDK_2005_06_19.exe와 같이 다운로드 버전은 사용하지 말기 바랍니다.

SVN으로 직접 소스 코드를 다운 받아서 사용해야 합니다.

최근까지 확인한 바로는 빌드 상의 문제는 최신의 DX SDK와 호환이 되지 않아서 실행시 관련 에러가 발생하는 것 외에는 기타 알려진 컴파일 에러나 런타임 에러는 없습니다.

이 부분은 커뮤니티 포럼 게시판(http://nebuladevice.cubik.org/forum/index.php)을 검색하거나 질문을 올리면 더욱 빠르게 원하는 답변을 받을 수도 있을 것 같습니다.


튜토리얼이라고 고작 2~3개 있는데 버전 관리가 안되있어 스트레스만 쌓이네요.
이 튜토리얼 디렉토리에 있는 것들은 보지 마시길 -_-; 빌드도 제대로 되는지 모르겠고 큰 도움이 안됩니다. 차라리 위에 포럼에서 찾아 보시면 튜토리얼이라고 올려 진게 있는데 훨씬 더 도움이 됩니다.

(독특한 객체 시스템으로 "이름"을 사용하지만 이 이름이 제대로 맞지 않아 실행시 로드에러가 많이 납니다.)
어떠한 의미인지요? 그리고, 실행시 발생하는 로드 에러는 어떤 것들인가요?

("shaderPath" 여야 되는데 "shaderpath"로 되있어 한참 찾았습니다.)
이 부분은 어느 파일인지 조금 자세하게 설명해 주시기 바랍니다.


N3SDK_Sep2008.exe는 아직 render층의 기능이 부족한 상태고
덧글의 제약 때문에 자세한 내용을 언급하지 못한 듯 한데, 어떤 기능이 부족한지 또 부족한 것을 보완할 좋은 방법은 무엇인지와 같은 의견을 주시면 개발에 많은 도움이 됩니다.

svn nebula3의 audiotest_win32 예제는 XACTAudioDevice::WaitForWaveBankPrepared()에서
동기화가 안되어 무한루프를 돌고있고
이 내용은 버그 리포팅해야겠군요. 구글코드의 svn에는 현재 개발자가 그리 많지 않습니다. 현재는 enlight 혼자서 대부분의 일을 처리하고 있습니다. Floh씨 블로그 사이트의 원본이 잘못된 것인지 아니면 머지하다고 생긴 버그인지 확인하는 일부터 필요하겠군요. 버그를 알려 주시면 제가 메일로 올리겠습니다.


nubula2 conrib에 예제(openaldemo)도 만드신거 봤습니다.
OpenAL 모듈 이야기로군요. 문서는 아마 제가 작성했을지도 모르겠습니다만, 코드는 제가 작성하지는 않았습니다. 2004년 경이었을 듯 한데요... 제 팀원 중 한분이 작성한 모듈입니다. 지금은 회사 만드셔서 개발이사신데... 바빠서 아마 수정 사항이 있어도 못하실 듯 ㅡ,.ㅡ

...


사실 기술적인 질문은 덧글로는 힘든 경우가 많다.

내용도 길고, 몇 차례 회신이 오고 가야 하는 내용도 있고,

가끔씩 메신저로 질문해 오시는 분들도 있는데

메신저는 더 힘들다.

그런데 메신저는 진짜 예의가 아니다. ㅋ

자리 이동할 때마다 메신저에 표시하는 사람들도 있지만

나는 그렇게는 안한다...귀찮아서 -_-;

그래서 항상 온라인인거다.
(그래야지 사장님이 보면 또 항상 자리에 있는걸로도 보이고, ^^;  --> 농담이다 ㅡㅡ;)

메일이 기본이다. 질문에는.

소스포지는 개발자한테 메일 보내면 소스포지 메일 서버가 개발자 개인 메일 계정으로 redirect 해준다.

그러니까 관련된 메일은 소스포지 메일로 보내자.


도대체 커뮤니티 버전은 관리가 되고 있는 겁니까? (화내서 죄송--^)

내가 난독증이 있는 것이 아니라면,

그리고 내가 이 라인 제대로 해석한 거라면

좀 어이가 없긴 하다.

나는 그냥 오픈 소스 프로젝트 개발자일 뿐

이 분(뉘신지도 모르고)한테  소스코드를 대가로 하등의 무엇인가를 받은 적이 없다.

라이센스를 완전히 오해하고 있는 케이스다. 아니면 관심 조차 없거나.

하기야 일면도 없는 나한테 화내시기야 했겠냐 만은

아마도...

모르긴 해도 빌드하다 잘 안되고

이것저것 다운도 받고 이리저리 메뉴얼 찾아서 읽고 빌드했는데...

에러만 막 난다...

짜증스러울 수도 있겠다.

또 Nebula2 가 대부분의 윈도우즈 개발자에게는 익숙하지 않은 컨셉이 많은 것도 한 원인이겠다.

그래도...

화부터 내지는 말자...

마음을 좀 가다듬고...

...

개발이라는 이짓거리가 밥벌이인지라...

힘들다고 내려 놓을 수 있는 짐이 아닌데...

말이 게임 개발이지... 게임이라는 단어는 그냥 치장 아닌가.

밥벌이가 즐거울리 만무하다.

그래도 말이다...

코드하고 싸우지는 말자.

잘 보듬자. 너무 스트레스 받지 말고.

열 낸다고 버그가 해결되고 에러가 없어지면

나는 진작에 강마에 되었겠다. ㅋㅋㅋ

그리고,

다른 분들은 Nebula 엔진을 어떤 용도로 보고 계신지는 모르겠지만...

적어도 나한테 이 프로젝트는 밥벌이가 아니다.

이 프로젝트 자체로 직접 돈벌이를 하거나 회사 프로젝트에 직접 사용한다면 모를까...

이 프로젝트가 내 밥벌이가 아니라는 이야기는

이 프로젝트는 내가 개발자로서 개발을 (진짜!) 즐길 수 있는 꺼리라는 이야기다.

처음 Nebula를 본 게 1999년 하반기 쯤이었던가...

본격적인 사용이 2001년부터니까

첫만남부터 따지면 이제 거의 10년이 다 되어 간다.

애착이 남 다를 수 밖에...

처음에는 모든게 부족한 것 투성이었다.

코드 수정하고,

IRC에서 토론하고,

3DS Max 플러그인 만들고,

도큐먼트 작성해서 올리고,

질문에 답해 주고,

그리고, ShaderX5에 기고한 일도 있구나.

이렇게 하나 하나 배웠다.

그러다 보니 엔진만 배우는 것이 아니라 개발 방법에 대한 깨우침도 오더라...

책에 나오는 수 많은 개발 방법론들...

사실 회사에서는 적용하기가 힘들다.

왜?

이상이 현실에 맞을리가 있나 - 그게 책이 나오는 이유 아니었던가? ㅎㅎ

그런데 이런 것들도 오픈소스의 세계에서는 가능하다.

회사라는 제한이 없으니까

그래서 오픈소스 프로젝트는 그 자체로 즐겁다. (밥벌이가 아니라서 더욱!)

이게 오픈 소스 프로젝트다.

오픈이 중요한거다 오픈이.

마인드가 오픈되어 있지 않으면

오픈 소스 프로젝트에 참여하기 힘들다. 
(혹시 참여는 안하고 필요한 것만 빼 가시겠다는 분들? 꿈도 야무지시다 ㅋ)

화내고 다가오는 사람에게

마음이 열릴리 만무하다.

굳이 알필요도 없는 에러 패턴에 대한 지식만 축적하고 있습니다.

이 마인드라면 나는 먼가.

굳이 가르쳐 줄 필요 없는데 남이야 빌드하던 말던 나만 할 줄 알면 됐지.

그런데 꼭 그렇지는 않다.

물론 본인에게 중요한 지식이 아니라서 삽질했다는 생각이 화를 더 부추겼을 수도 있겠다.

그런데,

꼭 그 에러들이 알 필요 없는 것들이었을까?

당사자에게는 그럴 수도 있겠지만,

이제 Nebula를 사용해서 똑같은 에러를 만난 사람에게는 해결을 이야기할 수 있는 방법이 생겼다고 생각하면 안될까?

다른 이에게 나눠 줄 수 있는 (Nebula로) 무엇인가가 생긴거다.

공유할 수 있는 그 무엇인가가.

이게 오픈 소스 프로젝트 아니었던가.

자기가 알고 싶은 것만 알면 편하겠지만, 또 효율적이겠고.

그래도

받은 만큼 주는게 세상 이치 아닌가.

새로움에는 진입 장벽이 있을 수도 있다.

그래도 배움이라는 것은 즐거운 일이다.

그리고 배운 것을 남들에게 알려 주는 일은 더 즐겁다.

게다가 남들과 함께 알아 가는 일은 더더욱 즐겁다.


이 방식의 프로젝트라는 것이

따라가는거지 무작정 왔으니까 답을 내놓으라는 식은 곤란하다.

처음에는 힘들 수도 있다.

하지만 코드던 사람에게든

화내지 말자...침착하게, 하지만 냉정하게.

그리고, 늘 따뜻한 마음으로.

느려도 즐겁게 한걸음씩.

그런데,

계속 느리지만은 않을거다.

미친듯이 가속이 붙는 때가 온다.

오픈소스 프로젝트의 이 플로우(flow)를 즐기려면,

그냥 조금씩 따라가면 된다.

단,

즐거운 마음으로,

남들과 함께.




악기는 연주하기 전에 튜닝이 필요합니다.

그런데 악기 중에는 튜닝이 힘든 악기도 있습니다.

누구에게는 Nebula가 그런 악기일 수도 있습니다.

하지만 튜닝이 끝나고 연주할 때에는

멋진 소리가 나오는 악기임에는 틀림이 없습니다.

Nebula 엔진 사용하시는 모든 분들,

화이팅 하세요~ ^^

Nebula2 엔진의 스크립트 시스템에 대한 다이어그램


아래 내용은 Nebula2의 스크립트 시스템의 함수 바인딩 방법에 대한 것이다.


우선 스크립트 시스템의 가장 기본적이면서도 중요한 처리는 게임 엔진의 클래스 객체의 멤버 함수를 호출하는 일이다.

위의 그림은 이에 대해서 Nebula2 엔진의 스크립트 시스템에서의 메카니즘을 나타낸 다이어그램이다. 설명은 다음과 같다.

1) 게임 엔진의 클래스들 중에서 스크립트(맨 아래쪽)에서 엔진의 API를 호출할 수 있도록 하려면 nRoot 클래스를 상속받아야 한다.

2) 스크립트 언어에 독립적인 소통 방법이 필요하다. 바꾸어서 이야기하면 어떤 스크립트 언어(Tcl, Python, Lua, Ruby 등...)를 사용하던지 간에 같은 방법으로 게임 엔진의 API를 호출하는 방법이 필요하다. (스크립트 언어가 바뀌는 경우 모든 관련 시스템을 다 바꾸어야 한다면 곤란하지 않은가)

3) 스크립트 서버는 게임 엔진과 스크립트 사이의 중간에서 상호 소통을 위한 동시 통역사의 역할을 한다.

4) 함수 호출에 대한 처리는 nCmd 클래스로 처리한다. 함수 호출을 위해 알아야 할 내용은 리턴값, 각 인자의 개수, 인자별 데이터형(type), 함수 포인터가 있다. nCmd 클래스 객체의 인스턴스는 이 정보를 가진다. nRoot 클래스를 상속한 클래스는 스크립트 인터페이스 함수의 개수에 따라 복수개의 nCmd 클래스를 가진다. 스크립트 인터페이스 함수란 nRoot 클래스를 상속한 클래스의 멤버 함수 중에서 스크립트 코드에서 호출할 수 있도록 만든 함수를 말한다.

5) 멤버 함수의 인자의 실제 값은 nArg 클래스에 저장된다.

6) 원으로 그래진 도형들은 색상을 주의 깊게 볼 것. nRoot 클래스의 멤버 함수들 중에서 스크립트 인터페이스를 가지는 멤버함수들은 이에 대응하는 각각의 nCmd 클래스가 있고, nCmd 클래스는 대응하는 멤버 함수가 가지는 인자의 개수만큼 nArg 클래스의 인스턴스를 가진다.

7) 그러면, 왜 nArg 클래스를 사용해서 인자를 처리할까라는 의문이 생긴다.(이런 의문이 저절로 생겨야 한다 -_-)

8) 대부분의 스크립트 언어에서는 데이터의 형 검사가 엄격하지 않다. 설사 데이터형을 구분한다고 하더라도 C++과는 다른 것이 보통이다. 이를 위한 universal[1]한 데이터형이 필요한데 이것이 바로 nArg 클래스이다.





[1] universal - 적절히 번역할만한 단어가 떠오르지 않는군요...-_-;

@ Property와 Reflection, 그리고 이를 다시 툴 프로그래밍에까지 연결시키는 설명이 뒤따르는데 시간 관계상 주말에는 여기까지 옮깁니다.

@@ 요점만 간추렸는데 Nebula2 스크립트 시스템을 코드를 찾아 보면서 이해하려니 힘들다는 분들에게는 조금이나마 도움이 되었을려나요. ^^

오늘 메일 박스의 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)에 고정되어 있으면 안된다는 말이다. ^^