All about productivity - since 2003
by kimsama
ROOF OF THE POSTS
- For whom he or she is not a native or does not use Korean for their primary language, translation button(coarse though) for Japanes and English are provided below the visitor location viewer right side of the page. And any comments except spam are welcome. =)
by kimsama | 2009/12/31 23:59 | General | 트랙백 | 덧글(0) |
브루스 윌리스 - Kane and Lynch: Dead Men 영화 주인공의 강력한 후보로
원문: Bruce Willis on board for Kane and Lynch: Dead Men movie

툼레이더스가 영화로도 성공을 거두면서 많은 게임들이 다시 영화로 (혹은 그 반대의 경우도 이전보다 활발해진 것 같습니다) 만들어 지는 경우가 흔해졌습니다. (여기에는 무기한 연기된 헤일로도 포함이 됩니다)

하드코어한 소재와 독특한 게임 플레이 방식 때문에 출시 전 부터 많은 관심을 받은 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의 데모 버전만 플레이해 봤습니다. 첫 번째 스테이지에서 빌딩을 타고 침입하는 장면이 꽤 인상적이었던터라 다른 스테이지들도 기대가 됩니다.
by kimsama | 2008/06/08 13:34 | Lifetamine | 트랙백 | 덧글(0) |
Tool - Deja Insight

며칠 전 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 객체는 '/'입니다)

- 그러니까 다시 한번 강조하지만, 가장 스마트한 프로그래머는 툴 프로그래머라는 이야기입니다 ^^

by kimsama | 2008/06/07 14:24 | General | 트랙백(1) | 핑백(1) | 덧글(0) |
The Smartest programmers(1)
하드웨어가 발달하게 되면서 이전에는 제약 때문에 개발이 힘들었던 점들도 하드웨어 스펙의 향상에 힘입어 개발이 단순해진다면 좋겠지만 실상은 더욱 복잡해진 것이 현실입니다. 예를 들어 그래픽 하드웨어가 발달하면서 더욱더 실제와 같은 렌더링을 원하게 되었는데 이렇게 요구되는 렌더링 연산을 위해서는 더욱 많은 수의 데이터와 이에 대한 처리가 필요해졌습니다. 처리해야 할 일들의 종류도 많아졌고 더욱 복잡해졌다는 말입니다. 처리해야 할 데이터가 더욱 많아졌다는 사실은 이를 위해 요구되는 개발자의 수도 더욱 많아 졌다는 것을 의미하며 이것은 다시 개발비의 상승으로 연결 됩니다. 이렇게 보면 오히려 하드웨어의 발달이 프로덕션 파이프라인(Production Pipeline)을 더욱 복잡하게 만들고 있다는 것을 알 수 있습니다. 그래서 과거 어느 때보다도 효율적인 개발을 위한 툴의 중요성이 부각되는 때인것 같습니다.
이러한 의미에서 조금 오래된 글이긴 하지만
Tom Forsyth님의 블로그에 포스팅된 글인 'Smart coder priorities'의 전문을 번역해서 올립니다.(의역한 곳도 많으니 이점 참고해서 읽어 주세요. 원문이 직접 링크되지 않으므로 원문을 읽으실 분은 블로그에서 직접 찾으셔야 합니다.'tool'로 검색하면 쉽게 찾을 수 있습니다.) 그리고 Tom Forsyth님의 포스트에서 언급한 툴의 중요성에 대해서 살펴 본 다음에는 실제로 툴을 개발할 때 도움이 될 만한 몇 가지도 소개 하겠습니다.

현명한 프로그래머의 우선순위(Smart Coder Priorities)

제가 개발자들과 하기 꺼려하는 이야기중에는 다음과 같은 것들이 있습니다.

"이봐 밥, UberGameSoft사 일은 잘 되어 가는가?"
"이봐 톰, 잘 되고 말고. 나는 멋진 HDR 시스템을 구현하고 있는 중이고, 짐(Jim)은 굉장한 물리 엔진을 구현하고 있고, 프랭크는 놀라운 포스트-프로세싱 효과를 구현했지."
"훌륭하군, 그럼 자네들은 이제 게임을 구현할 차례겠군."
"그렇긴 한데 말야, 아직도 전체 익스포트 파이프라인에 문제가 있어, 리소스들을 게임 내로 삽입하는데 애를 먹고 있다네."

이 시점에서 보통 저는 그들을 향해 낄낄거리며 다음 블로그를 포스팅할 준비를 합니다. 그런데 말입니다...

우리 같은 엔지니어가 가지고 놀기 좋아하는 멋지거나 혹은 괴짜스러울 만큼 훌륭한 것들이 많이 있습니다. 또 이런 것들 중 몇몇은 GDC에서도 돋보이는 훌륭한 발표거리가 되기도 합니다. 그러나 이 모든 것들이 이제 이야기할 것에 비하면 전혀 중요하지 않습니다. 이것은 바로 게임을 출시하는데 필요한 것들입니다. 이제는 팀 크기는 50~150명에 이르고 개발 기간은 2년에서 4년이 소요되고 있습니다. 이것은 큰 예산입니다.

우리가 진행하는 프로젝트에는 모두가 효율적으로 일할 수 있다는 것을 확신하게 할 만한 현명한 프로그래머가 필요합니다. 이 현명한 프로그래머란 바로 툴 프로그래머입니다. 네, '툴' 말입니다. 무슨 지저분한 소리를 하는 것 처럼 저를 쳐다보지 마십시오.

문제는 우리 중 대다수가 여전히 베드룸 해커(게으른 프로그래머라는 뜻인듯)라는 것입니다. 숨길 필요는 없습니다 - 솔직한 것이 좋잖아요. 하지만 그만큼 두려운 단어를 떠올릴 수 있어야 합니다. 바로 '관리'라는 단어 말입니다. 하지만 우리는 평균 이상으로 똑똑하다고 자부할 수 있기 때문에 PHB 관리 말고도 훌륭한 관리 방법을 사용할 수 있습니다. 그리고 그것은 데이터에 대한 관리가 아닐 뿐만 아니라 사람에 대한 관리도 아닙니다. 자신이 하는 일을 좋아하고 또 자신과 함께 일하는 사람들을 좋아하는 사람들의 경우 그들 자신도 스스로 잘 관리하는 것이 일반적입니다. 문제는 그들 사이에 데이터가 끼어 들어 그들이 같은 데이터에 연관되는 일이 만들어지는 것입니다. 이제 명백하게도 그것은 증거가 충분하지 않습니다. 그런데 사람들은 의존 관계가 명확한 것만을 다룰 수 있다는 것입니다. 마치 여러분이 캐릭터가 리깅(rigging)이 제대로 되어 있어야지 애니메이션을 할 수 있는 것 처럼 말입니다.

문제는 바로 의존관계가 명확하지 않다는 것입니다. 프로그래머인 우리는 그 시스템을 작성한 사람들이기 때문에 우리에게는 그 문제가 명확합니다. 안타까운 것은, 시스템을 만드는 가장 쉬운 방법이라는 것이 필요한 모든 데이타를 한 번에 다 준비한 다음에 전부 다 후처리 작업(post-processing)용 큰 깔때기에 쑤셔 넣고 거기에서 DVD를 떠서 시장에 내 놓는 것입니다. 물론 이런 짓을 했다가는 망하는 것은 불보듯 뻔한 일일 것입니다. 이렇게 하는 대신에 우리는 의존 고리들에 대해서 심사숙고 해 보아야 합니다. 그리고 어떻게 한 작업자가 변경한 것이 다른 사람의 작업에 영향을 끼치지 않도록 할 것인지와 관련된 것들을 동시에 작업하더라도 (서로) 망치지 않도록 함으로써 사람들이 동시에 작업할 수 있는 방법에 대해서 심사 숙고해 보아야 합니다.

이것은 프로그래머가 안고 있는 또 다른 큰 고민거리인 병렬 처리(parallel processing)와 거의 흡사한 문제입니다. 우리 모두는 병렬 처리가 매우 그리고 굉장히 어렵다는 것을 잘 알고 있습니다. 그래서 우리가 가장 현명한 프로그래머를 그 문제의 해결에 투입하는 것 처럼 툴도 마찬가지입니다. 심지어는 이것은 더욱 큰 병렬 처리에 대한 도전입니다. 게다가 이 문제의 경우에는 다른 병렬 처리의 주제-예를 들어 '물리 연산을 더 빠르게 하는 것'-처럼 잘 정의되어 있지도 않습니다. 왜냐하면 게임을 시작한 후 절반이 지나서도 실제로 (프로젝트가)어디로 가고 있는지가 분명하지 않기 때문입니다.

그래서 저는 이 문제들에 대한 것들이 머리 속에 정리되면 더 많은 포스팅을 할 생각입니다. 그러나 제가 가장 지적하고 싶은 것은 예전 처럼 그래픽스 기술을 가진 천재 프로그래머가 모든 문제를 해결하던 시대는 갔다는 것입니다. 쉐이더는 그렇게 작성하기 어려운 기술이 아닙니다. HDR은 자세하게 설명된 책이 있으면 충분히 해결할 수 있는 문제이고 그림자는 다소 고통스러울지 모르겠지만 그렇다고 근본적으로 게임을 만들거나 혹은 게임 자체가 만들어지는 것을 방해할만큼 큰 문제는 아닙니다. 하지만 훌륭한 리소스 관리의 문제는 다른 한편으로 출시와 파산의 차이점을 의미할 수도 있습니다. 그것은 새로운 형태의 천재 프로그래머가 관심을 집중해야 할 필요가 있는 것입니다.

위의 글은 이제는 컨텐츠 양의 증가와 더불어 개발이 더욱 복잡해졌기 때문에 필요한 개발자의 수도 늘어났고 개발자의 수가 증가하면 당연히 이에 대한 관리도 힘들어 지지만 이보다 더 큰 문제는 개발자와 개발자 사이의 처리 프로세스가 복잡해지기 때문에 필연적으로 개발이 지연될 수 밖에 없는데 이를 해결하기 위한 가장 중요한 방법이 툴이므로 툴의 중요성이 그 어느 때보다 두드러지는 때다라는 정도로 요약할 수 있겠습니다.

그런데 대개의 경우 툴 작업을 시키면 얼굴에서 미소가 사라지는 것이 보통인 것 같습니다 - 툴 이야기 꺼내면 툴툴 거리죠. ^^ 그리고 경력이 많을 수록 이런 현상은 더욱 두드러지는 것이 보통입니다. Tom이 자신의 포스트에서도 툴 이야기를 할 때 dirty word라고 언급한 것으로 보아 그쪽도 우리와 거의 차이가 없어 보이는 것은 매한가지인듯 합니다. 하지만 툴의 중요성을 실감하고 또 작업에 있어 효율적인 방법을 찾는다면 현명한 프로그래머와 성공적인 - 동시에 즐거운 - 게임 개발이라는 두 마리 토끼를 동시에 잡을 수도 있습니다. 그래서 툴 프로그래밍을 할 때 참고할 만한 몇 가지에 대해서 시간이 나는대로 지면에 옮겨 볼까 합니다.

(계속)

by kimsama | 2008/06/03 19:02 | General | 트랙백 | 핑백(1) | 덧글(3) |
EA - George Borshukov

지난 토요일 오후에는 게임 아카데미에서 메트릭스의 컴퓨터 그래픽 작업으로도 유명한 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)번이 무서운 이야기죠. 순간 달리기에서 덩치가 무지막지하게 큰 녀석이 달리기만 잘하는 것이 아니라 옆에서 누가 앞질러 가려고 하면 발까지 거는 모습이 상상이 되었습니다. 다 아는 이야기이지만 이제는 이것이 물 건너 벌어지는 이야기가 아니라 아주 가까이에 온 이야기라는 것입니다.

George씨, 짧은 시간이었지만 만나서 반가웠구요, 캐나다에 놀러가면 꼬-옥 연락하도록 노력해 보겠습니다. ^^

@
미팅이 끝나고 식당으로 자리를 옮겨서 이야기를 했습니다. 결혼 이야기가 나와서 자연스럽게 아이 이야기까지 나왔는데 2살된 딸 사진을 보여주더군요. 그래서 저도 4살된 딸 같은 아들 사진을 보여 줬습니다. ^^ 이런 자리에서 늘 느끼지만, 아들 녀석 참 인기 진짜 짱입니다. (쿨럭)

@@
얼마 전에 포스팅한 히데요 사토씨를 소개한 글과 유사하게 George씨 역시 흔치 않은 경력을 가지고 다른 업계에서 이동한 케이스입니다. 한국 게임 산업은 다른 산업과 비교해서 규모에서 뒤떨어지지 않을 뿐만 아니라 세계적으로도 인정 받고 있음에도 불구하고 밖에서 바라보는 시선에는 아쉬움이 많습니다.

@@@
kogia에 회의 내용이 올라 올지 모르겠지만 여건이 허락한다면 추후에 포스팅하도록 하겠습니다.

by kimsama | 2008/06/02 19:53 | Lifetamine | 트랙백 | 덧글(3) |
주말 레이드

주말 내내 시청으로 레이드 뛰었습니다. 파티원(와이프)과 함께 키우는 펫(33개월된 우리 아들)도 같이 갔습니다. ^^; 2시 좀 넘은 시간에 시청 앞 광장에 모여서 아이템(피켓 등)도 챙기고 포션(생수)도 점검하고 을지로를 거쳐 한바퀴 돌았습니다.

해가 지고 나서는 준비해 온 초를 켰습니다. 새벽까지 남아 광화문 앞에서 공성전을 하지는 못했지만 그래도 아주 작은 목소리나마 보태어 봅니다. 세종로에서 촛불 들고 서 있다가 아들 녀석이 칭얼 대길래 아래 쪽 청계천으로 내려 갔습니다. 100여 미터도 떨어지지 않은 곳에서는 집회가 한창인데 이곳은 조용히 흐르는 물가에 연인들, 가족들이 걸터 앉아 건너편에서 들려오는 통기타 노래 소리를 들으며 조곤조곤 이야기를 나누는 정겨운 모습이 가득합니다. (그런데 장소가 청계천인 것이 참 아이러니합니다)

2008년의 대한민국은 이런 모습이 어울립니다. 2009년의 대한민국도, 그 다음 해, 다음 다음 해의 대한 민국이 원하는 것도 이러한 평화로운 모습일 것입니다. 대화를 통해 소통이 되는 그날까지, 대한민국 화이팅입니다~

by kimsama | 2008/06/01 19:52 | Lifetamine | 트랙백 | 덧글(0) |
< 이전페이지

카테고리
이글루 링크
Other Links
이글루 파인더
라이프 로그
포토로그
태그
rss

skin by jesse