KGC 행사에 Wolfgang Engel*님을 한번 초청하고 싶었는데 작년에는 개인적인 사정으로 오기 힘들었고, 올해 다시 메일을 보내니 좋다고 하는군요. 올 해 많은 화제가 되었던 GTA4나 최근 이슈가 되고 있는 DX11에 대한 이야기를 들을 수 있을지도 모르겠군요. 기대해 봅니다. ^^
* ShaderX 시리즈의 에디터로 유명하시죠, 현재는 RockStar 스튜디오에서 GTA4 다음 작품을...아마도...할 듯. ^^;
얼마 전 크리스탈 다이나믹스 방문시 보고 온 영상과 대략 비슷한 것이 올라 왔습니다.(물론 게임 플레이도 시연했습니다)
워낙 유명한 시리즈이긴 하지만 툼레이더를 끝까지 플레이해 본 것은 크리스탈 다이나믹스가 제작한 Legend 편부터입니다. 그래픽뿐만 아니라 플레이 자체가 확-달라졌다는 느낌을 받을 수 있는 게임이죠. 조작은 훨씬 쉬워졌고 더욱 재미있어졌다는 것을 한번에 알 수 있는 게임이었습니다.
그리고, 아래는 이번 편과 관련해서 크리스탈 다이나믹스로부터 몇가지 들은 이야기입니다. ^^
그래픽 엔진뿐만 아니라 물리 엔진까지도 모두 자체 제작했다고 합니다.(크리스탈 다이나믹스 1층에는 Shared Technology Group이라는 33명으로 구성된 기술지원팀이 있는데 이 그룹에서 크리스탈 다이나믹스에서 제작되는 모든 게임-현재는 두 팀-에서 사용되는 기술뿐만 아니라 Eidos 산하에서 개발되는 게임에 대한 기술 공유도 함께 이루어 진다고 합니다.)
페르시아 왕자와 유사한 플레이가 많이 등장합니다.
이번 편에서는 모션 캡쳐도 많이 활용했다는 한국인 애니메이터 수나 강님의 설명. 사진이 없는게 아쉽군요. 한 미모하시는데 ^^)
탈 것이 등장합니다. (직접 플레이하는 것을 본 것은 오토바이. 그 외 다른 다른 탈 것은 미지수)
DCC 툴은 마야를 사용하며, 머티리얼의 경우 마야에서 설정한 머티리얼을 익스포트한 후 바로 확인할 수 있는 방법을 사용한다고 합니다.
예산의 경우 툼레이더 애니버서리가 리젠드의 반 정도, 이번 언더월드는 리젠드 보다 좀 더 많은 예산이 들었다고.
오픈 소스가 기업에 적용되려면 필연적으로 '개발자'의 교육 문제가 수반되며 그 교육은 결국 기업 자체가 아닌 커뮤니티에서 이루어진다고 하겠다. 그러한 커뮤니티의 목표는 결국 '소스 코드 공헌을 통한 자기 계발'이며 이것이 '개발자 커뮤니티'의 사명이 되어야 하지 않을까?
결국 중요한 교육의 문제가 커뮤니티에 있음을 이야기하고 있는데 실상 게임과 관련한 대부분의 오픈소스 프로젝트 커뮤니티들 중 이 문제에 대한 모범 답안을 제시하고 있는 커뮤니티는 없어 보입니다.
Nebula 역시 초창기부터 이 문제에 대한 많은 요구들이 있었지만 현재까지도 딱히 만족할만한 수준의 교육(혹은 이에 상응하는 수단)은 없었던 것 같습니다. 6월 경에 게임산업진흥원의 게임아카데미에서 오픈한 직무교육 과정의 하나인 'Open source gmae engine - Nebula Device' 과정도 이러한 요구 사항 때문에 진행된 것이긴 합니다만 아무래도 많은 분들이 함께할 수 없다는 점 때문에 나름의 한계가 있었던 것 같습니다.
그래도 조만간 Nebula 엔진에 평소 관심을 가지고 계신 분들이 좋아할 만한 소식 하나를 준비하고 있으니 조금만 기다려 주세요. ^^
게임을 영화에 비유한다면 게임 엔진은 영화에 있어 전체 스토리를 이끌고 나갈 중요한 핵심 배우에 비유할 수 있지 않을까요.
영화가 흥행하기 위해서는 잘 알려진 스타 배우를 기용하는 것이 중요하지만 모든 영화가 스타 배우를 기용한다고 해서 흥행에 반드시 성공한다는 보장이 없는 것 처럼 AAA 타이틀을 위한 엔진을 구매한다고 해서 그 게임이 대박나는 것은 아닙니다. 그리고 영화를 만드는데 연기 경험이 전무한 배우를 데려와 주연이나 주요 조연 배우를 시킨다며 연기 공부 시켜가며 촬영할 수 없는 것 처럼 게임 만든다고 다짜고짜 엔진부터 개발하는 일은 일견 무모해 보이기도 합니다. 물론 경우에 따라서는 이 영화만을 위한 새로운 배우를 만들어야 하는 경우도 있습니다. 예를 들어 반지의 제왕에 등장한 골룸이 그러한 경우입니다. 영화사 100년에 이 캐릭터만큼 창조의 당위성이 적절해 보이는 캐릭터도 없어 보입니다. 하지만 갈수록 게임 제작이 복잡해 지는 요즘에 개발할 게임에 필요한 모든 기술을 사내에서 개발하고자 한다면 이는 자원과 시간의 낭비로 귀결되는 경우가 대부분입니다.
요는 영화의 경우 개봉 후 기대 성적을 예상하고 이에 맞추어서 배우나 촬영 스케쥴, 개봉 일시를 정하는 것 처럼 게임도 유사한 결과에 대한 예상 방법-데이터든 과정이든-이 있어야 한다는 것입니다. 그리고 그에 맞는 최적의 방법으로 프로젝트를 진행하는 것이 가장 합리적인 방법일 것입니다.
최근에 EA, 남코-반다이, 루카스 아츠, 크리스탈 다이나믹스 등을 방문하고 나서 문득 든 생각입니다. (이들 회사의 공통점은 모두 IP 게임을 개발한다는 것이죠.)
개인적으로는 픽사의 애니메이션 제작 과정 중에 '컬러 스크립트'라는 과정이 무척 흥미로웠습니다. 컬러 스크립트란 인물과 배경의 디테일은 극도로 단순화 시키는 대신 색상 위주로 장면 별 스토리 보다를 만들어서 해당 장면의 느낌이 표현된 색으로 잘 전달되는지를 보기 위한 과정입니다. 픽사의 몇 작품에 대한 컬러 스크립트를 보고 나니 '아-'하는 감탄사가 절로 나옵니다.
도착한 다음날, 일요일입니다. 일정도 없고 시차 적응 때문에 늦게 일어 나 버렸는데 아뿔사, 숙소에 혼자 퀭하니 남겨져 버렸습니다. ㅡ.ㅡ
연락 해 보니 몇 분은 벌써 샌프란시스코 필수 관광 코스 중 하나라는 피셔맨스 워프로 출발, 이동 중이시더군요. 부랴부랴 준비해서 호텔 로비에 가는 길을 물어 봤습니다. 다소 복잡하긴 했지만 형광펜으로 전철 노선 및 환승역을 친절하게 가르쳐 주더군요. ^^
숙소에서 프리몬트(FreMont)까지 버스로 이동한 다음 프리몬트에서 Bart라는 전철로 이동했습니다. 겁도 없지요, 혼자서 말입니다. ^^;
샌프란시스코에는 두 종류의 기차가 있는데 하나가 지금 바트(Bart)이고 다른 하나는 칼트레인(CalTrain)입니다. 그런데 이 바트란 놈이 참 신기한게 한 시간에 2~3대 밖에 지나가지 않는데다.(칼트레인은 두 대 정도 ㅡ.ㅡ) 그것도 지하철 차량 수가 모두 다르다는 겁니다. 그래서 지하철 역 안내 전광판에 보면 이번 열차가 몇 량이라는 표시가 함께 나옵니다. 가령 6량 밖에 안되는 바트인데 뒤 쪽에 서계시다면...네, X나게 뛰셔야죠. ^^;
바트를 타고 샌프란시코의 파웰(Powell) 역에 도착하니 우웃~ 이거 여기는 초겨울입니다. 체감 온도가 상당하다는 이야기는 들었지만 이 정도일 줄이야.[1] 지하철역을 나오니 사진에서나 보던 케이블카가 보입니다. 일행에게 연락해 보니 먼저 도착해 있다고들 하시더군요.
<종점에 도착하면 케이블카를 돌리는데 수동입니다. ㅎ>
매표소에서 케이블카 티켓을 구매한 다음 줄 서서 기다렸습니다. 나중에 알았습니다 - 케이블카 탄 시간보다 줄서서 기다리는 시간이 더 걸려다는걸. ㅡ.ㅡ;
덜커덩 거리며 출발, 밖은 쌀쌀한 터라 안에 앉았습니다. 한참가다 보니 표 검사를 합니다. 케이블카는 승무원이 두 명입니다. 한명은 운전, 한명은 검표 및 푸쉬. ^^; 그런데 아뿔싸, 분명히 5달러 내고 티켓을 구매했는데 어떻게 된 영문인지 제 티켓은 옆 부분이 이미 떨어져 나가 있는게 아닙니까. 이거 영어로 이야기해 준다고 꽤나 애 먹었습니다. ㅡㅡ; 매표소에서부터 잘못된 건지 아니면 모르는 사이에 떨어져 나간 건지(아마 그럴 일은 드물것 같습니다만) 하여간 몇번을 이야기하니 그냥 패스하더군요. ㅡㅡ; 타고 가면서 현금 내도 되는데 말입니다. 쩝.
케이블카 타고 가면서 보이는 집들, 가파르게 경사진 언덕은 크레이지 택시 등에서 보던 바로 그 샌프란시스코입니다. ^^
<아래쪽 경사 보이시죠? 먼저 온 일행 분들은 여길 걸어 오셨답니다 - 짐승스러우셔요 ㅋㅋ>
잠시 후 바다가 보이고 종점에서 내려 일행이 있는 피어39로 이동했습니다.
가는 길에 보니 온 몸에 은색 복장을 입고 얼굴까지 은색으로 분장한 사이버 분위기의 홈리스가 로봇 춤을 추면서 동전을 받고 있습니다. 이 동네도 먹고 살기 힘들다는거죠 ㅋ ^^;
<손에 놓인 사탕을 보고 꼬마가 다가와서 집으려고 하면 재빨리 손을 이동시킨 답니다 ^^>
피어39(Pier 39))에서 유명하다는 바다사자들도 보고 건방지다는 새들도 보았습니다. 알카트래즈 감옥도 멀리 보입니다.
<인생이 이랬으면...하는 분들도 계시죠? ㅋ>
<샌프란시스코의 닭둘기>
피어39에서 연락을 해서 근처에 있는 일행과 합류...했지만 특별한 일은 없죠. 쩝.
피어39에는 예전에 2차 대전 때 사용했다던 전함과 잠수함이 정박해 있는데 여기 옆에 건물에는 예전 아케이드 게임들이 전시되어 있습니다.
<앞쪽이 잠수함, 뒤쪽에는 전함. 사진 왼쪽이 고전 아케이드 머신 박물관입니다>
훔쳐보는 아케이드 머신도 있습니다. ^^
<동전을 넣고 아래쪽 구멍을 보면 뭔가가 보인다고 합니다 ^^;>
돌아오는 길에도 케이블카를 타고 왔습니다. 케이블 카를 기다리는데 케이블카 종점역에서 기타 들고 노래 부르는 흑인이 '호텔 캘리포니아'를 연주합니다. 캘리포니아의 첫걸음이 실감납니다. 이렇게 호텔 캘리포니아를 들으면서 캘리포니아의 첫날이 저뭅니다.
미국 사람들이 차를 많이 가지고 다니기는 하지만 그래도 버스나 지하철과 같은 대중 교통 수단을 이용하는 사람들도 많더군요. 그런데 땅덩어리가 워낙에 넒다 보니 버스 정류장이나 지하철로 이동하는 거리도 만만치 않은지라 버스나 지하철에는 자전거를 가지고 탈 수 있도록 배려해 놓았더군요. 버스의 경우 자전거를 앞쪽에 건 후 탑승하게 됩니다.
<홀더 내려 올 때 보면 트랜스포머 같아요. ^^>
아주 늦은 시간에 숙소에 귀가했습니다. 샌프란시스코의 유니언 스퀘어 거리를 고작 3시간이 채 안되는 시간동안 관광[2]하기 위해서 버스와 전철로 이동한 시간은 왕복 6시간 가까운 시간이 걸린 첫 날이었습니다. 미국...참 넓은 나라죠.(제길슨) ㅡㅡ;
도착해서 며칠 간은 시차 적응하느라 어떻게 보냈는지도 모르겠습니다. 샌프란시스코라지만 머물고 있는 곳은 샌프란시스코 다운타운에서 약 3시간 떨어진 Miltipas입니다. (좌절 ㅡㅡ;) 주변에는 Great Mall(이름 그대로 그레이트합니다)이라는 아주 큰 아울렛 외에는 아무 것도 없는 휑-한 곳이죠. 여긴 모든게 빅-합니다. 건물들도 빅하고, 여자들도 빅하네요. ㅡㅡ;
날씨는 낮에는 따뜻하고 밤에는 춥습니다. 다운타운 쪽 항구에 가면 초겨울입니다.(바람이 센데다 차가워서 체감 온도가 상당합니다)
남들은 음식 걱정하던데 산입에 거미줄 치겠습니까 - 매일 이런 저런 이벤트 만들어서 잘 해먹고 다닙니다. ^^;
그럼, 일주일 뒤 돌아가서 뵙겠습니다~ ^^
(사진은 도착한 다음 날 일요일에 Powell 지하철역 앞 케이블카 승차장에서 줄 서서 기다리며 한-컷)
툼레이더스가 영화로도 성공을 거두면서 많은 게임들이 다시 영화로 (혹은 그 반대의 경우도 이전보다 활발해진 것 같습니다) 만들어 지는 경우가 흔해졌습니다. (여기에는 무기한 연기된 헤일로도 포함이 됩니다)
하드코어한 소재와 독특한 게임 플레이 방식 때문에 출시 전 부터 많은 관심을 받은 Kane and lynch: Dead Men[1]도 이번에 영화로도 만들어 진다고 합니다. 그리고 주인공인 Kane 역으로는 브루스 윌리스가 강력한 후보로 거론되고 있다는 소식입니다. 게임에서의 Kane의 이미지를 생각한다면 괜찮은 캐스팅 같아 보입니다. 단, 브루스 윌리스의 나이가 좀 많은 것이 흠이긴 하지만 말입니다. 제작사인 IO Interactive사는 덴마크에 소재한 회사로 Hitman 시리즈로 유명한 회사입니다. 그러고 보니 Hitman 역시 영화로 만들어졌군요. 특이한 소재에 드라마틱한 이야기의 게임을 제작하는 회사라고 생각하는 것이 저만이 아닌 것 같군요.
앞서 언급한 두 게임 외에 제작사인 IO Interactive사의 또다른 게임으로는 Freedom Fighters가 있습니다. 소련이 미국을 침공한다는 소재의 위험성(?) 때문인지 영화화 되지는 못했지만 IO Interactive사의 게임으로는 엔딩까지 플레이한 게임입니다. 개인적인 플레이 느낌은 맵 디자인이 잘 되어 있다는 것과 나름 잘 짜여진 분대 전투입니다. Kane and Lynch:Dead Men에서의 분대 전투도 이때의 경험이 바탕이 된 것이 아닐까 추측이 됩니다.
브루스 윌리스의 멋진 연기를 기대해 봅니다.
[1] 시간이 없어 아직 XBox360의 데모 버전만 플레이해 봤습니다. 첫 번째 스테이지에서 빌딩을 타고 침입하는 장면이 꽤 인상적이었던터라 다른 스테이지들도 기대가 됩니다.
며칠 전 sweng 메일링 리스트에 올라 온 'C++ memory analyzer' 질문에 대한 답변으로 올라 온 글 중 하나에서 DejaTools라는 툴에 것이 언급된 것을 보았습니다. 답변을 올린 Andrew Finkenstadt씨의 이야기로는 자신이 몸담고 이는 Simutronics사의 MMORPG 엔진인 HeroEngine에 사용하고 있다고 합니다. 사이트에 가서 보니 HeroEngine뿐만 아니라 Bioware의 MASS Effect, THQ의 DarkSiders, 그리고 Pandemic의 Mercenaries2에도 사용이 되었군요. 간단하게 이야기하면 프로그램 분석을 용이하게 할 수 있는 logging tool, debugger 및 profiler를 제공하는 툴로 자사의 사이트에는 이렇게 소개되어 있습니다.
Deja Insight represents the next generation of game development tools. It pulls together key features of logging tools, debuggers, and profilers to provide you with the tools you need to debug and optimize today's complex real-time systems.
Insight provides unparalleled data capture, analysis and visualization tools that enable developers to fully inspect the operation of their systems in real-time.
일반으로 엔진에서는 기본적으로 logging tool, profiler 등을 제공하는 것이 보통입니다만 Deja Insight는 개발중인 애플레케이션에 쉽게 결합하여 분석할 수 있는 도구들을 지원해준다고 볼 수 있을 것 같습니다.
사실 실행 중인 애플리케이션의 인스턴스화 된 객체들을 손쉽게 알 수 있다면 개발 중에 다양한 방법으로 활용할 수 있을 것입니다. Nebula를 처음 접하고 잘 이해가 안되는 것 중에 하나로 NOH(Named Object Hierarchy)를 많이들 이야기합니다. 이 NOH가 바로 현재 인스턴스화 된 클래스 객체들을 디렉토리 구조와 같이 만들어서 보여 주는 메카니즘입니다. 그러면 다시 왜 디렉토리 구조냐는 의문이 들 수 있는데, 이것은 3차원상의 모델들의 관계를 제일 손쉽게 표현할 수 있는 것이 바로 트리 구조이기 때문입니다. 또한 게임 엔진을 OS(Operating System)라고 한다면 OS에서 관련이 있는 파일들을 구분하는 분류할 때 디렉토리를 사용하는 것 처럼 Nebula 엔진에서도 관련이 있는 객체들을 분류할 목적으로 사용하기 위해서 입니다. 예를 들면 WindowsXP에서 시스템 관련 파일들은 'Windows/System32' 등의 디렉토리(폴더)에 저장하고 사용자 문서를 위해서 'Documents and Settings/My Documents'라는 것이 있는 것처럼, Nebula에서는 '/sys/servers/' 아래에 게임 엔진이 제공하는 다양한 서비스를 위한 객체들이, '/usr/scene/' 아래에는 사용자가 만든 객체 중에서도 장면 렌더링에 사용되는 객체들이 위치하게 됩니다. (참고로 최상위 루트에 있는 NOH 객체는 '/'입니다)
하드웨어가 발달하게 되면서 이전에는 제약 때문에 개발이 힘들었던 점들도 하드웨어 스펙의 향상에 힘입어 개발이 단순해진다면 좋겠지만 실상은 더욱 복잡해진 것이 현실입니다. 예를 들어 그래픽 하드웨어가 발달하면서 더욱더 실제와 같은 렌더링을 원하게 되었는데 이렇게 요구되는 렌더링 연산을 위해서는 더욱 많은 수의 데이터와 이에 대한 처리가 필요해졌습니다. 처리해야 할 일들의 종류도 많아졌고 더욱 복잡해졌다는 말입니다. 처리해야 할 데이터가 더욱 많아졌다는 사실은 이를 위해 요구되는 개발자의 수도 더욱 많아 졌다는 것을 의미하며 이것은 다시 개발비의 상승으로 연결 됩니다. 이렇게 보면 오히려 하드웨어의 발달이 프로덕션 파이프라인(Production Pipeline)을 더욱 복잡하게 만들고 있다는 것을 알 수 있습니다. 그래서 과거 어느 때보다도 효율적인 개발을 위한 툴의 중요성이 부각되는 때인것 같습니다. 이러한 의미에서 조금 오래된 글이긴 하지만 Tom Forsyth님의 블로그에 포스팅된 글인 'Smart coder priorities'의 전문을 번역해서 올립니다.(의역한 곳도 많으니 이점 참고해서 읽어 주세요. 원문이 직접 링크되지 않으므로 원문을 읽으실 분은 블로그에서 직접 찾으셔야 합니다.'tool'로 검색하면 쉽게 찾을 수 있습니다.) 그리고 Tom Forsyth님의 포스트에서 언급한 툴의 중요성에 대해서 살펴 본 다음에는 실제로 툴을 개발할 때 도움이 될 만한 몇 가지도 소개 하겠습니다.
현명한 프로그래머의 우선순위(Smart Coder Priorities)
제가 개발자들과 하기 꺼려하는 이야기중에는 다음과 같은 것들이 있습니다.
'이봐 밥, UberGameSoft사 일은 잘 되어 가는가?' '이봐 톰, 잘 되고 말고. 나는 멋진 HDR 시스템을 구현하고 있는 중이고, 짐(Jim)은 굉장한 물리 엔진을 구현하고 있고, 프랭크는 놀라운 포스트-프로세싱 효과를 구현했지.' '훌륭하군, 그럼 자네들은 이제 게임을 구현할 차례겠군.' '그렇긴 한데 말야, 아직도 전체 익스포트 파이프라인에 문제가 있어, 리소스들을 게임 내로 삽입하는데 애를 먹고 있다네.'
이 시점에서 보통 저는 그들을 향해 낄낄거리며 다음 블로그를 포스팅할 준비를 합니다. 그런데 말입니다...
우리 같은 엔지니어가 가지고 놀기 좋아하는 멋지거나 혹은 괴짜스러울 만큼 훌륭한 것들이 많이 있습니다. 또 이런 것들 중 몇몇은 GDC에서도 돋보이는 훌륭한 발표거리가 되기도 합니다. 그러나 이 모든 것들이 이제 이야기할 것에 비하면 전혀 중요하지 않습니다. 이것은 바로 게임을 출시하는데 필요한 것들입니다. 이제는 팀 크기는 50~150명에 이르고 개발 기간은 2년에서 4년이 소요되고 있습니다. 이것은 큰 예산입니다.
우리가 진행하는 프로젝트에는 모두가 효율적으로 일할 수 있다는 것을 확신하게 할 만한 현명한 프로그래머가 필요합니다. 이 현명한 프로그래머란 바로 툴 프로그래머입니다. 네, '툴' 말입니다. 무슨 지저분한 소리를 하는 것 처럼 저를 쳐다보지 마십시오.
문제는 우리 중 대다수가 여전히 베드룸 해커(게으른 프로그래머라는 뜻인듯)라는 것입니다. And that's a great mentality to have - it keeps us honest. But at those numbers, you have to have some of the dreaded word - 'management'. But we're smarter than the average bear, so we can use geek management, not PHB management. And it's not management of people so much as management of data. 자신이 하는 일을 좋아하고 또 자신과 함께 일하는 사람들을 좋아하는 사람들의 경우 그들 자신도 스스로 잘 관리하는 것이 일반적입니다. 문제는 그들 사이에 데이터가 끼어 들어 그들이 같은 데이터에 연관되는 일이 만들어지는 것입니다. 이제 명백하게도 그것은 증거가 충분하지 않습니다. 그런데 사람들은 의존 관계가 명확한 것만을 다룰 수 있다는 것입니다. 마치 여러분이 캐릭터가 리깅(rigging)이 제대로 되어야지 애니메이션을 할 수 있는 것 처럼 말입니다.
문제는 의존관계가 명확하지 않다는 것입니다. 프로그래머인 우리는 그 시스템을 작성한 사람들이기 때문에 우리에게는 그 문제가 명확합니다. And unfortunately the easiest way to write most systems is to have all the source data available at once, throw it in a big post-processing hopper and out comes the DVD image, and then we ship it. Fairly obviously, this is a disaster in practice. 이렇게 하는 대신에 우리는 의존 고리들에 대해서 심사숙고 해 보는 것이 필요합니다. 그리고 어떻게 한 작업자가 변경한 것이 다른 사람의 작업에 영향을 끼치지 않도록 할 것인지와 관련된 것들을 동시에 작업하더라도 망치지 않도록 함으로써 사람들이 동시에 작업할 수 있도록 할지에 대해서 심사 숙고해 볼 필요가 있습니다.
이것은 프로그래머가 안고 있는 또 다른 큰 고민거리인 병렬 처리(parallel processing)과 거의 흡사한 문제입니다. 우리 모두는 병렬 처리가 매우 그리고 굉장히 어렵다는 것을 잘 알고 있습니다. 그래서 우리가 가장 현명한 프로그래머를 그 문제의 해결에 투입하는 것 처럼 툴도 마찬가지입니다. 심지어는 이것은 더욱 큰 병렬 처리에 대한 도전입니다. 게다가 이 문제의 경우에는 다른 병렬 처리의 주제-예를 들어 '물리 연산을 더 빠르게 하는 것'-처럼 잘 정의되어 있지도 않습니다. 왜냐하면 게임을 시작한 후 절반이 지나서도 실제로 어디로 가고 있는지가 분명하지 않기 때문입니다.
그래서 저는 이 문제들에 대한 것들이 머리 속에 정리되면 더 많은 포스팅을 할 생각입니다. 그러나 제가 가장 지적하고 싶은 것은 예전 처럼 그래픽스 기술을 가진 천재 프로그래머가 모든 문제를 해결하던 시대는 갔다는 것입니다. 쉐이더는 그렇게 작성하기 어려운 기술이 아닙니다. HDR은 자세하게 설명된 책이 있으면 충분히 해결할 수 있는 문제이고 그림자는 다소 고통스러울지 모르겠지만 그렇다고 근본적으로 게임을 만들거나 혹은 게임 자체가 만들어지는 것을 방해하는 큰 문제는 아닙니다. 하지만 훌륭한 리소스 관리의 문제는 다른 한편으로 출시와 파산의 차이점을 의미할 수도 있습니다. 그것은 새로운 형태의 천재 프로그래머가 관심을 집중해야 할 필요가 있는 것입니다.
위의 글은 이제는 컨텐츠 양의 증가와 더불어 개발이 더욱 복잡해졌기 때문에 필요한 개발자의 수도 늘어났고 개발자의 수가 증가하면 당연히 이에 대한 관리도 힘들어 지지만 이보다 더 큰 문제는 개발자와 개발자 사이의 처리 프로세스가 복잡해지기 때문에 필연적으로 개발이 지연될 수 밖에 없는데 이를 해결하기 위한 가장 중요한 방법이 툴이므로 툴의 중요성이 그 어느 때보다 두드러지는 때다라는 정도로 요약할 수 있겠습니다.
그런데 대개의 경우 툴 작업을 시키면 얼굴에서 미소가 사라지는 것이 보통입니다 - 툴 이야기 꺼내면 툴툴 거리죠. ^^ 그리고 경력이 많을 수록 이런 현상은 더욱 두드러지는 것이 보통입니다. Tom이 자신의 포스트에서도 툴 이야기를 할 때 dirty word라고 언급한 것으로 보아 그쪽도 우리와 거의 차이가 없어 보이는 것은 매한가지인듯 합니다. 하지만 툴의 중요성을 실감하고 또 작업에 있어 효율적인 방법을 찾는다면 현명한 프로그래머와 성공적인 - 동시에 즐거운 - 게임 개발이라는 두 마리 토끼를 동시에 잡을 수도 있습니다. 그래서 툴 프로그래밍을 할 때 참고할 만한 몇 가지를 이야기하려고 합니다.
지난 토요일 오후에는 게임 아카데미에서 메트릭스의 컴퓨터 그래픽 작업으로도 유명한 EA의 R&D 팀에 있는 George Borshukov씨와의 미팅이 있었습니다.
'최적의 그래픽 효과를 위한 제작 프로세스'라는 주제로 5월 30일 금요일 삼정호텔에서 세미나가 있었지만 이 미팅은 세미나 내용 이외에 다른 비밀(?)들을 캐내기 위해서 업계의 전문가들을 따로 모아 진행된 미팅이었습니다. ^^;
이 친구는 특이하게도 영화쪽에서 일을 하다가 컴퓨터 게임 쪽으로 이동한 경우인데요, 영화 쪽 경력을 보면 딥 블루 씨, 매트릭스 등의 헐리우드 블록버스터의 특수효과를 위한 컴퓨터 그래픽으로 유명한 분입니다. 그가 매트릭스에서 작업한 것을 보면 네오로 분한 키에누 리브스가 컴퓨터 그래픽으로 제작된 영상과 분간할 수 없을 정도로 같은 것을 볼 수 있습니다. (왼쪽 사진 중간의 네오 사진 중 하나는 실제로 촬영한 것이고 다른 하나는 컴퓨터 그래픽으로 작성한 것입니다) 세미나에서 강연한 내용은 이러한 것을 위한 테크닉에 대한 내용이었는데요, 간단하게 요약을 하자면 다음과 같습니다. 컴퓨터 그래픽으로 제작한 것이 실제로 촬영한 것 처럼 보이게 하기 위해서는 분산광(diffuse)에 대한 처리가 중요한데 이것을 처리하기 위해서 사용한 방법이 특수한 카메라를 이용하여 매 프레임마다 텍스쳐 이미지를 캡쳐 받아서 텍스쳐 이미지에 라이팅 정보를 저장하는 방식을 사용하여 표현하는 기술이라는 것이 핵심입니다.(물론 이 외에도 specular나, normal map, subsurface scattering 등이 같이 사용이 되었다고 합니다) 리얼함을 위해서 brute force한 방법으로 해결한 경우라고 볼 수 있는데요, 당장 현재로서는 리얼타임에 사용하기에는 다소 제한적이고 실효성이 떨어지는 면이 없지 않아 있습니다.
하지만.
EA에서는 일은 3~4년 뒤에 보편화될 수준의 그래픽을 위해서 이러한 포지션의 잡(job)을 두고 연구를 진행한다고 합니다. George씨는 바로 이런 일을 맡고 있는 R&D 팀에서 근무하며 지금껏 참여한 게임에는 Fight Night 나 타이거 우즈 게임이 있습니다. (그러나 EA 전체로 보면 이러한 순수 R&D 인력은 극소수라고 합니다)
질문은 영화 쪽 이야기부터 EA에서의 R&D와 관련한 내용 등 다양하게 여러 가지로 이야기가 진행이 되었습니다. 흥미로운 사실 중 하나는 EA의 Criterion의 인수합병에 대한 언급이었습니다. 참석한 패널 중 한분이 현재 진행중인 프로젝트에 렌더웨어를 사용하고 있는데 EA가 Criterion을 인수합병하면서 업데이트 및 지원이 전혀 이루어지지 않아 프로젝트 진행시 겪었던 어려움에 대해서 토로하면서 나온 이야기였는데요, 짐작했던 대로 인수합병은 1) 프랜차이즈 확보 측면과 2) 보유 기술에 대해서 타업체와 공유하지 않기 위해서라고 합니다. 2)번이 무서운 이야기죠. 순간 달리기에서 덩치가 무지막지하게 큰 녀석이 달리기만 잘하는 것이 아니라 옆에서 누가 앞질러 가려고 하면 발까지 거는 모습이 상상이 되었습니다. 다 아는 이야기이지만 이제는 이것이 물 건너 벌어지는 이야기가 아니라 아주 가까이에 온 이야기라는 것입니다.
@ 미팅이 끝나고 식당으로 자리를 옮겨서 이야기를 했습니다. 결혼 이야기가 나와서 자연스럽게 아이 이야기까지 나왔는데 2살된 딸 사진을 보여주더군요. 그래서 저도 4살된 딸 같은 아들 사진을 보여 줬습니다. ^^ 이런 자리에서 늘 느끼지만, 아들 녀석 참 인기 진짜 짱입니다. (쿨럭)
@@ 얼마 전에 포스팅한 히데요 사토씨를 소개한 글과 유사하게 George씨 역시 흔치 않은 경력을 가지고 다른 업계에서 이동한 케이스입니다. 한국 게임 산업은 다른 산업과 비교해서 규모에서 뒤떨어지지 않을 뿐만 아니라 세계적으로도 인정 받고 있음에도 불구하고 밖에서 바라보는 시선에는 아쉬움이 많습니다.
@@@ kogia에 회의 내용이 올라 올지 모르겠지만 여건이 허락한다면 추후에 포스팅하도록 하겠습니다.
주말 내내 시청으로 레이드 뛰었습니다. 파티원(와이프)과 함께 키우는 펫(33개월된 우리 아들)도 같이 갔습니다. ^^; 2시 좀 넘은 시간에 시청 앞 광장에 모여서 아이템(피켓 등)도 챙기고 포션(생수)도 점검하고 을지로를 거쳐 한바퀴 돌았습니다.
해가 지고 나서는 준비해 온 초를 켰습니다. 새벽까지 남아 광화문 앞에서 공성전을 하지는 못했지만 그래도 아주 작은 목소리나마 보태어 봅니다. 세종로에서 촛불 들고 서 있다가 아들 녀석이 칭얼 대길래 아래 쪽 청계천으로 내려 갔습니다. 100여 미터도 떨어지지 않은 곳에서는 집회가 한창인데 이곳은 조용히 흐르는 물가에 연인들, 가족들이 걸터 앉아 건너편에서 들려오는 통기타 노래 소리를 들으며 조곤조곤 이야기를 나누는 정겨운 모습이 가득합니다. (그런데 장소가 청계천인 것이 참 아이러니합니다)
2008년의 대한민국은 이런 모습이 어울립니다. 2009년의 대한민국도, 그 다음 해, 다음 다음 해의 대한 민국이 원하는 것도 이러한 평화로운 모습일 것입니다. 대화를 통해 소통이 되는 그날까지, 대한민국 화이팅입니다~
지난 금요일에는 CATIA 로 유명한 Dassault Systems 의 한국지사를 방문했었습니다. Dassault에서 게임 사업에 진출하기 위해서 개발한 3D 엔진을 보기 위해서였는데요, 왼쪽 사진의 히데요 사토씨의 프리젠테이션도 보고 궁금한 것들에 대한 질문을 할 수 있는 시간도 가졌습니다. EA등에서도 사용하고 있는 프로토타이핑 툴로 잘 알려진 Virtools 도 최근에 Dassault에서 인수했다고 합니다. 아마도 게임 사업을 위한 포석으로 해석이 되어 지는데요, Virtools의 경우 학습이 용이한 점을 이용해서 다양한 곳에 사용이 되고 있는데 금요일에 보니 PSP와 Wii의 개발도 가능하더군요. 사토씨가 그의 개인 노트북으로 보여준 Virtools을 이용한 PSP 게임 개발에 대한 동영상은 꽤 인상적이었습니다.
사토상의 명함을 보면 'Application Engineer'로 나와 있습니다만 추측컨데 풀타임 R&D 팀에 소속되어 개발만을 전담하고 있는 것 같지는 않았습니다. 원래는 대학을 졸업하고 인공위성을 통해 전달되는 데이터를 분석하는 작업 등을 하다가 현재는 Virtools 관련 일을 하고 있다고 하는데요, 전 세계를 돌아다니면서 사용자들에게 새로운 기술이나 기능을 이야기해주고 그들로부터 피드백을 받아 본사(프랑스)의 R&D 팀에게 전달하고 또 신제품에 대한 기능이나 기술을 고개들에게 전달하는 것이 주요한 업무라고 합니다. 덕분에 아직 결혼을 못한 것일지도 모르겠습니다만(^^) 대개의 한국의 게임 개발자들이 회사에서 게임을 개발하는 일, 특히나 프로그래머의 경우 프로그래밍(-이라고 쓰고 코딩이이라고 읽습니다) 외에는 다른 일은 생각을 할 수 없는 환경[1] 때문에 나이가 들면서 타 직종보다 직업의 장래에 대해 더욱 불안해 하는 것을 많이 보았습니다. 우리도 본인의 노력 여하에 따라 선택할 수 있는 다양한 환경이 빨리 만들어졌으면 하는 바램입니다.
- 일본인으로 보이지 않는 유창한 영어 솜씨와 소주 주량. 소주를 잘 마셔서 꽤 놀랐습니다. ㅋ
멀티 코어(multi-core)는 멀티 코어 CPU를 이야기하는 것인데 이것은 두 개 이상의 독립 코어를 단일 집적회로로 이루어진 하나의 패키지로 통합한 것으로 듀얼 코어(dual-core) 프로세서는 두 개의 코어를 포함하고 있으며, 쿼드 코어(quad-core)는 네 개의 코어를 포함하고 있다.
현재 칩 제조사에서 출시하는 신형 CPU들은 이렇게 두 개 이상의 CPU를 내장한 멀티 코어 CPU가 주종을 이루고 있다. 이는 단일 코어에서 더 이상 코어 클럭을 이용해서 성능을 올리는 방법으로는 한계에 도달했기 때문이다.그런데 이러한 하드웨어 환경에서 게임의 성능을 최대한 끌어 올리도록 만들기 위해서는 하드웨어에서 제공하는 여러 개의 코어들을 이용해서 병렬 처리(parallel processing)가 가능한 구조로 게임을 구성을 해야 한다. 왜냐하면 단일 쓰레드를 사용하도록 제작된 프로그램은 여러 개의 코어를 가진 프로그램 내에서 실행이 되더라도 속도가 빨라지지 않기 때문이다. 멀티 코어가 주는 성능을 최대한 이용하기 위해서는 응용 프로그램이 멀티 코어를 지원하도록 작성해야 하는데 문제는 이것이 쉽지 않다는 것이다.
왜 멀티 코어 프로그래밍이 어려운가?
우선 언어적 특성에 기인한 원인이 있다. 일반적으로 게임에 사용하는 C와 C++은 본질적으로 순차적 언어이기 때문에 병렬 처리가 당연한 문제의 경우에도 구현이 쉽지 않는 경우가 많다.
그런데 이런 언어 상의 문제점만 있는 것이 아니라 게임이라는 애플리케이션의 특징에 기인한 문제점도 있는데 이것은 더욱 복잡하고 까다롭다. 첫 번째로 다른 응용 프로그램과 비교할 때 게임은 인공지능, 물리 시뮬레이션, 네트워킹, 애니메이션, 렌더링 시스템 등과 같은 다양한 서브 시스템으로 구성이 되어 있는 것이 보통이다. 그런데 이들 서브 시스템은 서로 결합되어 작동되는 것이 보통이므로 단순한 서브 시스템의 조합으로 구성된 응용 프로그램과 비교할 때 훨씬 더 복잡한 구조를 가지고 있다. 즉, 서브 시스템 간의 의존도가 높기 때문에 병렬 처리하는 것이 어렵다. 두 번째는 게임이 이벤트 중심의 애플리케이션이라는 점이다. 게임은 사용자의 입력이나 네트워크를 통해 전송되는 패킷, 게임 내에 정의된 시나리오, 물리 시뮬레이션 등에 의해서 수시로 변경되며 서로 상호작용해서 작동되는 것이 보통이다. 그리고 이런 이벤트들을 전체 시스템의 관점에서 보면 정해진 규칙은 있지만 순서는 없다. 이러한 이벤트들은 여러 개의 서브 시스템에서 처리하여 그 결과를 이용하게 되는데 게임에서는 이렇게 각 서브 시스템간에 데이터 정보를 공유해야 하므로 서브 시스템들을 독립적으로 병렬 처리하는 것이 어렵다.
그리고 세 번째로는 게임의 실시간성에 따른 프레임에 관한 문제이다. 게임은 실시간으로 작동되어야 하기 때문에 게임은 매 프레임을 순차적으로 처리해서 렌더링 하게 되는데 현재의 프레임은 이전 프레임에 의존적이기 때문에 프레임들을 병렬 처리할 수가 없다. 이것도 게임을 병렬 처리 하기 어려운 이유 중의 하나이다.
그러면 멀티 코어 프로그래밍은 어떻게 접근해야 할까?
멀티 코어 시스템은 여러 개의 프로세서를 처리하므로 프로세서 간 통신을 위한 효율적이고 유연한 소프트웨어 아키텍쳐를 필요로 한다. 이 소프트웨어 아키텍쳐란 각 서브 시스템 간의 교환되는 데이터의 동기화가 용이한 모델에 초점을 맞춘 것을 말하는 것으로 데이터의 동기화 뿐만 아니라 코어의 개수가 서로 다른 환경에서도 안정적으로 작동될 수 있어야 한다. 이러한 병렬 처리 데이터 동기화의 모델 중에서 게임에 적합한 모델로는 비동기화 함수 병렬 모델(Asynchronous parallel model)이라는 것이 있다. 게임에서는 보통 게임 로직, 물리 연산, 렌더링의 순서로 작업이 행해 것이 보통인데 비동기화 함수 병렬 모델에서는 이 세 가지를 각각의 코어로 실행하고 이들 코어간의 동기화는 최신 결과를 기다리지 않고 이전 결과를 가지고 작업을 수행하는 것이다. 예를 들어 렌더링에서는 이번 프레임에서의 물리 연산의 결과를 기다려서 렌더링 작업을 수행하는 것이 아니라 이전 물리 연산 결과를 이용하여 렌더링하게 된다. 이것은 게임이라는 응용 프로그램이 적당한 응답성만을 보장하면 되는 특성에 기인한 것으로 이 방법을 사용하면 각 서브 시스템간의 분리 뿐만 아니라 병렬 처리도 용이해 진다는 장점이 있다.
디버깅에서도 차이가 있다. 일반적으로 멀티코어 시스템의 디버깅은 단일 시스템의 디버깅보다 더 복잡하고 어플리케이션에 영향을 미칠 수 있다. 하나의 코어 또는 코어의 하위 집합만이 정지되는 경우에는 다른 코어가 정지된 코어로 데이터를 전송하거나 수신할 수 있기 때문에 단일 쓰레드에서의 디버깅과는 다를 수 있다.
이상 언급한 것은 소프트웨어적인 측면인데 이런 소프트웨어적인 측면 뿐만 아니라 하드웨어적인 측면에서도 고려해야 하는 점이 있다. 예를 들어 메모리나 버스의 경우에도 사용 가능한 대역폭을 코어 간에 공유해야 한다는 점에 주의해야 한다. 소프트웨어 아키텍처가 아무리 잘 설계가 되어 있다고 하더라도 이러한 부분에서 병목 현상이 발생하게 되면 당연히 퍼포먼스에 영향을 미치게 되기 때문이다.
실제로는 이보다 더 많은 내용들이 있겠지만 여기까지만 살펴 보더라도 멀티 코어로의 패러다임의 전환은 그 어느때보다 소프트웨어 특히 병렬 처리와 관련한 소프트웨어를 잘 다룰 줄 아는 프로그래머의 역할이 중요해졌다는 것을 알 수 있다.
멀티 코어가 대세가 되는 시대에는 더 이상 하드웨어의 업그레이드 만으로는 프로그램의 빠른 실행을 기대할 수가 없게 되었다. 이제는 기술 진보의 의미가 클러 수의 증가로 하드웨어가 빨라 지는 것을 의미하는 것이 아니라 병렬 처리가 가능한 코어의 증가로 동시 처리의 증가를 의미하는 시대가 도래 되었다. 이것은 주어진 문제를 여러 개로 분리해서 가장 효율적으로 처리할 , 수 있는 방법이 중요한 이슈로 부상했다는 것을 의미한다.
참조
[1] 위키피디아 - 멀티코어, http://ko.wikipedia.org/
[2] Multithreaded Game Engine Architectures, Gamasutra,
