Flowers bloom in sunlight

최근에 회사에서 AI 작업을 하는데 비헤이비어 트리(Behavior Tree)를 작성해보며 느낀 점을 간략히 적어봅니다. 장점이야 익히 알려져 있다시피 기존에 주로 쓰이던 FSM/HFSM과 달리 중복 코드가 없어지고 더 깨끗하게 모듈화가 된다는 점이구요. 여기서는 단점을 좀 적어볼게요. 비헤이비어 트리(이하 BT)는 기법 이름이 나타내듯 AI가 하나의 트리로 구성이 되는데, 이게 코드/스크립트로 수정하기에는 직관성이 아주 떨어집니다. 기존의 FSM/HFSM은 기본적으로 스크립트를 읽으면 AI의 동작이 그대로 읽혀서 머릿속으로 시뮬레이션이 편하게 되는데, BT는 스크립트로 트리를 구성하므로 사람이 읽기가 나빠요. 동작 하나를 수정하려 해도 트리를 수정하려면 코드를 수정하는것과 감각이 아주 달라서 프로그래머 입장에서 편하게 작업할 수 있는 환경이 아닙니다. 이걸 편하게 하려면 결국 시각적인 편집 도구를 따로 제공하는 수 밖에 없어요. 근데 쓸만한 시각적인 편집도구를 지원하는게 쉬운 일은 아니잖아요? 참고 삼아 써보니 UnrealEngine4의 경우에는 블루프린트 기반의 BT 편집도구를 제공하는데, 이것도 BT의 특성을 고스란히 반영하는 물건은 아니고, 블루프린트를 BT에 끼워 맞춘듯한 도구더군요. 적당히 편집이 되고 어느정도 디버깅이 된다 정도지 BT를 편하게 편집하는 도구라는 인상은 받을 수가 없어요. 물론 BT를 손으로 직접 편집하는 것에 비하면 훨씬 편한 도구임은 분명하죠. 어찌됐든 BT는 편집도구가 가장 큰 문제가 되더군요. 앞서 이야기한 편집 문제를 겪으며 개인적으로 얻은 결론인데, BT는 편집도구까지 개발해서 기획팀이 AI를 수정하는 작업 방식일 때 쓰는게 가장 좋을 듯해요. 기획팀이 수정하지 않더라도 AI 개발이 많아서 시각적인 개발 및 디버깅 도구를 지원할 필요가 있을때 채용하면 효과가 좋을 것 같습니다. AI 개발을 많이 할 게 아니면 그냥 FSM/HFSM으로 개발하는게 개발 효율면에서 나을 것 같습니다. 중복 코드가 좀 나오더라도 편집의 어려움을...

CMake 를 오랜만에 사용할 일이 생긴 김에 예전 생각이 나서 끄적여 봅니다. CMake에 대한 기억을 떠올려 보면, 예전에 어떤 작업을 하느라 FireBreath 로 플러그인을 작성하면서 처음으로 써 본 기억에서부터 이야기를 풀어 나가야 할 것 같네요. FireBreath는 ActiveX와 NPAPI를 동시에 래핑 해주는 플러그인을 생성해주는 프레임웤인데요. 그때 마침 IE와 non-IE 브라우저를 모두 지원하는 플러그인을 만들 필요가 생겨서 이걸 한번 써보기로 했습니다. FireBreath는 구글의 지원으로 개발되는 프레임웤인데요. 다양한 컴파일러를 지원하기 위해 CMake를 이용한다고 해서 처음으로 써보게 되었죠. CMake 문서를 처음 열었을 때만 해도 별 느낌이 없었는데, 대충 읽어보고 FireBreath를 빌드하면서 깨달은 게 있었죠. 아 이거 쥐약이구나. CMake는 멀티플랫폼 빌드를 지원하기 위해 플랫폼에 맞춰 빌드 파일을 생성해주는 도구이고, 이 빌드 파일을 돌려서 실제 빌드를 수행하는데요. 이 과정에서 모든 경로를 절대경로로 생성합니다. 이게 당시 개발팀의(그리고 아마도 대부분의 Windows 개발자들의) 개발환경과는 맞지가 않아요. 당시에 제가 있던 개발팀이 그러하듯 모든 사용자가 각자 마음대로 시스템을 구성하고 각자 편한 위치에 소스를 내려 받아서 개발하기 위해서는 소스코드 저장소에 절대경로가 없어야 하는데, CMake를 사용하려면 필연적으로 빌드 환경에 절대경로가 박혀버려요. 이거 아주 지저분하죠. CMake 공홈에 나와있는 FAQ에는 이렇게 설명하고 있습니다. Why does CMake use full paths, or can I copy my build tree? CMake uses full paths because: configured header files may have full paths in them, and moving those files without re-configuring would cause upred...

하복의 공개 모바일 3D 엔진인 프로젝트 아나키 가 어제 출시됐습니다. 1.0 beta 상태군요. 다운받아서 일단 샘플 프로젝트를 열고 돌려만 봤습니다. 잘 만들었더군요. 이제 시간을 내서 찬찬히 뜯어봐야죠. 개인적으로 만들고 있는 작은 게임 엔진이 있는데, 당연한 얘기지만 모티베이션이 약하고 투입할 수 있는 시간도 별로 없으니 진도가 잘 안 나갑니다. 원래는 Windows를 타겟 플랫폼으로 잡고 시작했는데, 모바일 시대가 도래하면서 모바일 플랫폼 위주로 바꿔서 작업하고 있습니다. 중간에 한번 크게 갈아엎었지만 시작한지 몇 년은 됐다는 얘기죠. 그런데 나 혼자라도 쓸만한 수준까지 올라가는 데만도 얼마나 걸릴지 감을 잡기가 어려워요. 최근에 공개 모바일 3D 엔진을 몇 개 찾아서 돌려봤는데, 역시 상용엔진의 발끝이나마 따라갈만한 퀄리티를 가진 것 조차 단 하나도 없더군요. 그런데 제작기간을 보면 막 10년씩 작업한 엔진이고 그래요. 제가 만드는 엔진도 그나마 서브시스템들 대충 갖추고 간단한 에디터까지 붙이려면 지금 속도로는 10년은 걸리지 않을까 싶은데, 이걸 계속 하는 게 의미가 있는 일일까 하는 근본적인 의문이 생겨나는 건 어쩔 수 없는 것 같습니다. 

안드로이드로 뭔가 개발해보려고 SDK를 깔고 샘플을 몇 개 빌드 해 봤는데요. 가볍게 뭔가 만들어 보려고 하니 오랜만에 이클립스를 쓰는 것부터 귀찮네요.(한 6~7년 만에 써보는 것 같은데..) 회사에서는 비쥬얼 스튜디오 2008을 쓰는데, 그걸 쓰다가 간만에 써보는 이클립스는 좀 귀찮은 게 많아요. 게다가 안드로이드는 에뮬레이터가 매우 느리죠.. CHM을 제공해 주면 좋았겠지만 아쉬운 데로 도움말이 로컬 하드디스크에 HTML 형식으로 깔려있기는 한데, 어떤 이유에선지 웹브라우저로 로컬 브라우징을 하려고 하면 브라우징이 안되고.. 한마디로 말해서 하나부터 열까지 윈도우 사용자를 위한 배려가 부족하다 보니 조금씩 불편한 게 쌓여서 꽤나 거슬립니다. 뭐 안드로이드 앱이 수익성이 없는 건 누구나 다 아는 사실이니 별 상관 없는데, 무료로 뿌리기 위해 가볍게 뭔가를 만들고자 하는데 사람을 귀찮게 하니 의욕이 떨어지는 거죠. 내가 무료로 뭔가를 만들어 제공하려고 했는데 이렇게까지 귀찮은걸 신경 써서 세팅 하는데 시간을 들여야 하나 하는 생각이 드는 거죠. 결국 하나하나 해결하면서 진행해서 만들기는 하겠지만, 좀 더 설치 과정이나 환경 설정 등을 다듬고 에뮬레이터 품질도 개선해야 하지 않을까 싶네요.

최근에 제가 회사에서 하는 작업은 서비스 중인 저희 회사 게임에 런타임 보안 솔루션을 적용하는 일입니다. 한마디로 핵 방지 작업이죠. 실시간 메모리 변조 방지, 코드 변조 방지, 리소스 변조 방지 등의 작업인데, 보안 전문 프로그래머나 해커도 아니고 게임만 짜던 게임 프로그래머가 이런걸 잘 할 수 있을 리가 없으므로, 당연히 상용 솔루션을 적용하게 됩니다. 요즘 적용하고 있는 상용 솔루션은 업계에서 흔히 사용하는 N모 제품이나 T모 제품이 아니라 정교하다고 알려진 매우 고가의 제품인데, 이걸 적용하다 깨닫게 된 사실이 있습니다. 당연하게도 보안 솔루션을 적용하면서 보안 수준을 높게 설정해서 적용하면 그 때문에 게임이 느려집니다. 실행도 느려지고 로딩도 느려지는데, 저희 게임의 경우에는 게임의 특성상 실행이 느려지는 건 그다지 눈에 띄지 않지만 로딩이 느려지는 건 정확히 체감이 되기 때문인지 상당히 눈에 띄더군요. 너무 느려지면 보안 솔루션의 세부 구성을 수정하여 보안 수준을 그다지 낮추지 않으면서도 덜 느려지는 구성을 찾게 되는데, 이런 작업을 하다 보니 최근에 제가 “와, 이 게임 정말 발적화구나"하고 욕했던-_- 게임이 하나 생각나더군요. 바로 스타크래프트2. 게임을 하면서 게임에서 돌아가는 리소스 등에 비하여 로딩이나 실행이 많이 느리다는 생각을 했는데, 아무래도 스타1때의 일을 거울삼아 상당한 수준의 런타임 보안이 들어간 게 아닐까 싶습니다. 아직까지 스타2에 핵이 나오지 않은 것을 보면 스타2에 런타임 보안 솔루션이 강력하게 적용되어 있을 건 너무나 자명한 일이고, 또한 이것이 부정 사용자를 막기 위해 필요한 일이기는 하지만, 일부 크래커들 때문에 대다수의 사용자가 느려진 로딩 및 실행 속도를 감수하고 있을 거라는 건 안타까운 일입니다. 뭐 곧 있으면 저희 게임의 사용자들도 겪게 될 일이지만요.

요즘 게임 관련 게시판을 돌아다니다 보면 몇몇 호사가? 신기술 매니아? 들이 게임과 클라우드 컴퓨팅의 접목에 대하여 이야기 하는 것을 보게 됩니다. 이런 글들을 볼 때면, 확실히 미래 기술을 보는 쪽과 현업 사이의 간극이 크다는 것을 느끼게 됩니다. 특정 게임을 예로 들어서 좀 그렇지만, 테라가 기술적으로 대단한 점은 MMORPG에서 3D 공간에 대한 서버 사이드 시뮬레이션을 하기 때문입니다. 뭐 다른 MMO들도 일부 하고 있겠지만, 테라와 같이 논타겟팅 액션 MMORPG를 지향한다면 서버에서 실시간으로 거의 클라이언트에 가까운 3D 시뮬레이션을 돌려야 합니다. 현재의 CPU 파워로는 못할 것도 없지만, 문제는 네트웍이죠. 제 경우엔 테라를 플레이 해보진 않았지만, 현재의 네트웍 대역폭의 한계를 감안하면 우리가 일반적으로 생각하는 정말 액션 다운 액션을 플레이 하기엔 무리가 따를 것이라는 예상은 가능합니다. 정교한 시뮬레이션을 하려면 필연적으로 많은 정보가 필요합니다. 서버가 아무리 좋은 반응성을 갖더라도 해당 정보가 클라이언트에 제때에 도착할 수 있느냐 하는 건 별개의 문제고, 결국 현재의 인터넷 방식의 대역폭이나 속도의 한계상 제대로 된 액션이 나온다는 건 상상하기 어렵습니다. 실제로 플레이어들은 테라의 움직임이 어정쩡하다는 반응인데, 어정쩡하다는 건 어쨌든 돌아는 간다는 소리니까 개발자로서는 그 정도만 해도 대단한 거라고 말하고 싶습니다. 물론 사업부나 마케팅에서는 쟤들 왜 저거밖에 못하냐고 생각할지도 모르지만요. -_- 마찬가지로 현재의 fat client가 나온 배경을 생각해보면, 게임은 클라우드 컴퓨팅에는 적합하지 않다고 생각이 듭니다. 아무리 latency를 줄여도 실시간으로 로컬에서 도는 것만큼 빠르게는 안되죠. 현재 기술로 국내 네트웍 환경에서 서비스를 하기엔 15fps도 무리라고 보지만(네트웍 대역폭에 사용자마다의 격차가 심해서, 대부분의 사용자에게 안정적인 프레임 레이트를 제공하기엔 15fps도 어려울 것 같습니다), ...

요즘 개발자들 사이에서는 앱 개발이 크게 화제가 되고 있습니다. 다들 아시다시피 업무 특성상 부업-_-을 하기 힘든 프로그래머들이 특히 눈독을 들이는 것 같은데요. 각 플랫폼이 어떠한 가능성을 갖고 있을지, 어느 쪽이 더 나을지 검토를 해 봤습니다. 아이폰 장점 단일 성능, 단일 해상도, 단일 OS의 안정적인 플랫폼 간편한 결제 시스템의 검증된 수익성 개발 환경이 안정화 되어있음 단점 안드로이드 보다 하드웨어 스펙이 약간 떨어짐 개발 환경 구축에 비용이 많이 듦 생소한 개발 환경 안드로이드 장점 개발 환경 구축에 비용이 들지 않음 친숙한 개발 언어 하드웨어 스펙이 아이폰 보다 앞섬 단점 외견상으로는 통일되어 있지만, 실질적으로는 약간씩 동작의 차이가 있는 플랫폼 결제 시스템이 부실하고 수익성이 떨어짐 개발 환경 안정화가 아직도 진행중임 상호 비교이다 보니 한쪽의 장점이 반대쪽의 단점이 되는 식으로 정리되는데요. WIPI, MIDP 등의 모바일 플랫폼에서 약간 개발해본 경험으로 봐서는 안드로이드 플랫폼에서 실제로 모든 기기에서 동일하게 동작하는 게임을 만들기가 쉽지 않을 것 같습니다. 하드웨어의 미묘한 차이가 게임 플레이에 상당히 큰 영향을 미치는 경우가 많거든요. 특히 키 입력 같은 건 그러한 차이가 크게 나타나는 대목이라, 하드웨어가 통일되어 있지 않으면 제대로 만드는 게 쉽지 않습니다. 해상도가 여러 개 인 것도 대응하기가 쉽지 않은 문제구요. 게다가 안드로이드는 결제 시스템이 영 허술하다는 평가라, 사용자가 결제를 하지 않는 플랫폼에서 돈을 번다는 건 어불성설이죠. 결국 현재 레드오션으로 변했다는 아이폰 외에는 대안이 없는 상황인 듯 싶습니다. 안드로이드의 경우에는 어디선가 다른 곳에서 과금을 하고 스마트폰을 클라이언트로만 활용하는 서비스가 더 적합하지 않을까 하는 생각이 드네요.

이전에는 구글의 블로거닷컴에 둥지를 틀고 블로그를 운영했는데요. 블로거닷컴이 여러 가지로 우리나라 인터넷 사용자의 요구를 반영하지 못하기에 호시탐탐 이사할 기회를 노리고 있었습니다. 블로거닷컴이 불편한 점의 예를 들자면, 태그는 달 수 있지만 카테고리 별 분류를 지원하지 않아서 게시물을 큰 단위로 묶는 게 안되고, 우리나라 블로그들이 즐겨 쓰는 트랙백도 안되고, 댓글 달기도 불편하게 되어있고, 미묘하게 느린데다 레이아웃이 큼지막해서 우리나라 사용자들이 좋아하는 스타일도 아니구요. 맘에 드는 이사처-_-를 찾지 못하고 시간을 보내다 텍스트큐브로 옮기기로 정하고 계정을 만든게 2009년 5월인가 그랬습니다. 근데 막상 이사하려고 보니 게시물을 옮겨오는게 안된다는 치명적인 문제점이 드러났습니다. 블로거닷컴이 게시물을 파일로 묶어주는 형식과 텍스트큐브가 게시물을 파일에서 복원하는 형식이 서로 호환되지 않아서 옮겨올 수가 없는 거였습니다. 새 글만 텍스트큐브쪽에 올리고 이전 글은 블로거닷컴쪽을 유지하는 방법도 있었지만, 그렇게 하기엔 좀 지저분한 느낌이고, 이전 글에는 얽힌 트랙백도 없는데다 댓글도 별로 없으니 아쉽지도 않아서 과감히 다 옮기기로 정했는데, 막상 이사가 안 되는 거에요. 그래서 일단 보류했죠. 그리고 또 몇 달이 지나 2010년 3월이 됐는데, 아무래도 이사를 해야 할 것 같아서 아예 제가 변환프로그램을 만들기로 결심을 한 겁니다. -_- 자세한 개발 과정을 적는건 좀 귀찮기도 하고(소스코드에 주석 한줄도 안 달았는데!!) 어차피 알아들을 사람만 알아들을테니 그냥 프로그램을 공개할까 합니다. 블로거닷컴은 Formatted ATOM 형식으로 블로그를 내보내거나 불러올 수 있고, 텍스트큐브는 TTXML 형식으로 블로그를 내보내거나 불러오게 되어 있습니다. 따라서 Formatted ATOM 형식으로 블로거닷컴 블로그를 받아온 후에 TTXML 형식으로 변환한 다음 텍스트큐브에서 읽어오면 블로그를 이사할 수 있게 됩니다. 제가 작성한...

회사에서 사용하는 컴파일러는 Visual Studio 2005입니다. 이전 회사에서는 2008을 썼는데, 작년 말에 옮긴 회사는 2005를 쓰고 있어서 역변태-_-를 하게 됐습니다. 그래서 2010이 어느덧 출시를 목전에 둔 RC(Release Candidate)버전까지 나왔다는 소식은 웹 상에서 들었지만 별 관심을 갖지 못하고 있었는데, 오전에 잠시 짬이 난 틈에 2010의 C++ 컴파일러에 어떤 변화가 있는지 찾아보게 되었습니다. 와우. 완전히 새로운 IDE에 컴파일러와 직접 통합된 IntelliSense, 새로운 C++ 표준 지원까지. 정말 좋아진 것 같습니다. IntelliSense의 데이터베이스로 SQL Express를 사용한다니 개발 PC의 요구사항이 꽤 높아질 것 같아서 약간 우려되지만, 기능면에서는 그야말로 막강해질 듯 하네요. 이번에도 Express 버전이 나오겠죠? 회사에서는 못 써볼 것 같으니 출시되면 집에서 Express라도 써봐야겠네요.

모든 개발팀이 문서화 정책을 갖고 있겠죠. 팀마다의 상황이 다르고 개인차도 있겠지만, 이 글에서는 제가 지금까지 경험해 본 문서화에 대한 내용들을 좀 정리해 볼까 합니다. 우선, Doxygen(을 포함한 자동 문서 생성 도구)은 별로 쓸모가 없었습니다. 최근의 IDE들은 프로그래머들에게 다양한 정보를 제공해 줍니다. VC의 IntelliSense는 상당히 잘 동작하고, 그걸로는 부족하다고 생각하는 개발팀들의 경우엔 VisualAssist를 사용합니다. 이런 상황에서 Doxygen이 생성하는 클래스 및 함수 목록은 별반 도움이 안 됩니다. 다만 클래스 계통도를 뽑아두면 한 눈에 전체 구조를 볼 수 있다는 점 정도가 약간 쓸모가 있을 뿐인데, 주석이 없어도 되는 그 정도의 작업을 위해 소스 코드에 Doxygen 형식의 주석을 달아두는건 별로 좋은 방법이 아닌 것 같습니다. 코드가 지저분해 질 뿐이죠. 하지만 최신 IDE에서는 Doxygen 형식으로 함수나 클래스의 요약을 정리한 주석을 약간 달아두면 툴팁으로 확인할 수도 있으니(이것도 꼭 Doxygen 형식일 필요는 없지만;;) 약간 정도는 주석을 달아준다고 칩시다. 이런 경우에는 어디까지 주석을 달아야 할 지가 문제인데, 제가 보기에는 소스코드의 작성자가 필요하다고 생각되는 곳에 필요하다고 생각되는 내용만큼만 달면 됩니다. 다만 최소한의 원칙을 정한다면 brief 태그를 주로 사용하는 걸로 하고 author 태그를 금지해야 합니다. author 태그는 여러 프로그래머가 같이 작업하는 요즘의 게임 개발 프로젝트에서 거의 아무런 쓸모가 없고, 함수를 업데이트 하는 경우에 갱신하기도 애매해서 방치하다 보면 정보를 전혀 제공하지 않는 의미 없는 태그가 됩니다. 지금까지 해본 여러 가지 형식의 문서화 중에 가장 성공적인 경우는 Wiki를 사용했을 때입니다. 모듈 하나를 완성하면 그 모듈의 사용법에 대한 레퍼런스를 작성하는 방식으로 했을 때가 그나마-_- 가장 문서화가 잘 됐던 것 같아요. 문서화에 대...

아무래도 제가 프로그래머이기 때문에, 프로그래머 관점에서 봤을때 정말 좋았다고 느꼈던 기획에 대한 문서들의 링크를 걸어봅니다. 첫째. 기획은 이렇게 해주세요. How to Write Great Design Documents 기획 문서라는게 기획팀 내부의 커뮤니케이션 외에도 프로그래머에게 전달하는 목적을 갖고 있기 때문에, 이왕이면 처음부터 프로그래머가 이해하기 쉽게 작성하는 쪽이 커뮤니케이션 비용을 줄일 수 있겠죠. 그런 관점에서 정말 강추하는 문서입니다. 이런 식으로 문서를 넘겨주는 기획자가 있다면 정말 쵝오. 둘째. 이런 기획은 절대로 하지 말아주세요. (자기만 대단하다고 생각하는) 흔한 게임 아이디어들 (좀 많이 곤란한) 게임 기획과 사업 키워드 이런 식으로 프로그래머들이 기획에 제동을 거니까 온라인 게임 업계가 매너리즘에 빠지는거 아니냐고 하시는 분들도 있겠지만, 물리적으로 안되는건(예를 들어 언리얼3급 캐릭터가 100대 100으로 한 화면에 다 보이는 상태에서 FPS 스타일의 전투 따위) 안되는거니까요. 링크된 문서에서 제시하는 이런 기획들은 현실적인 제약을 넘을 수가 없어요..

언리얼 토너먼트 3에 포함된 언리얼 엔진 3를 이용하여 게이머들이 직접 게임(MOD)을 만드는 Make Something Unreal Contest 가 열리고 있네요. 인텔의 후원을 얻어 총 상금이 백만달러 규모입니다.(대충 한 10억 되죠?) 우리나라의 경우엔 MOD를 만드는 개발자는 거의 없고, 게임 개발을 공부하는 사람들의 목표도 취미가 아닌 취업이기 때문에 아마추어 개발자가 거의 전멸하다시피 한 상황이라 참가할 팀이 얼마나 될지 모르겠네요. 게다가 MOD 개발 환경은 한글화도 안 되기 때문에 쉽사리 접근하기가 어렵죠. 컨테스트는 4단계로 나뉘어 진행됩니다. 2008년 6월 27일까지가 Phase 1, 2008년 10월 17일까지가 Phase 2, 2009년 5월 15일까지가 Phase 3, 2009년 8월 31일까지가 Phase 4입니다. 각 단계마다 게임을 수정해가며 계속 제출할 수 있는 방식입니다. 수상작은 4단계까지 마친 후에 공식홈페이지에서 발표합니다. 이런 방식이면 공모전 대비하듯 벼락치기로 게임을 만들어서 제출하기엔 어려울듯 하고, 실제로 MOD를 만드는데 흥미가 있어야 끝까지 진행할 수 있을것 같습니다. 시상 부문은 다음과 같습니다. Best Mutator Enter during Phase 1 Mutators are one way to modify a game, and we are looking for changes to a UT3 game type for the Best Mutator category. Mutators are "mini mods": they adjust settings such as speed or gravity, add a weapon or a power-up, and so on. Players should be able to set and configure mutators like extra game options. These can be a lot of fun, ...

다음 링크는 한동안 일부 게임 개발 관련 커뮤니티에 광풍을 불고왔던 토론 게시물입니다.. (링크) 기획자 없는 게임 개발은 가능할까? 만약 아직 안 읽어보셨다면 굳이 링크를 클릭하실 필요는 없습니다. 제 관점에선 약간 삐뚤어진 발제에서 시작해서 서로간에 가시돋힌 공방을 주고 받다가 흐지부지 끝난 토론이라고 생각하니까요. 윗 글에서 다루어진 논의들은 대부분 엇갈려 있어서 별 의미가 없는 것들입니다. 결국 기획, 프로그램, 그래픽 중에 어느 한 파트라도 허술한 결과물을 내놓는다면 제대로 된 게임이 나올수가 없으니까요. 다만 제가 보기에 업계가 지향해야 할 방향과 관련해서 한가지만 짚어볼까 합니다. 기획자, 프로그래머, 디자이너가 작업을 하고 있습니다. 여기서 문제. 누구의 작업이 잘못된 채로 진행됐을때 가장 큰 복구 비용이 발생할까요? 정답은, 시기적으로 먼저 작업하는 사람의 결과물이 잘못될수록, 이후의 작업이 크게 의존하는 작업물이 잘못될수록 복구 비용이 커지게 됩니다. 윗 글의 문제는 여기에 있습니다. 누가 하는 작업인가가 아니라 언제 하는 작업인가에 초점을 맞춰야 합니다. 앞에서 하는 작업은 나중에 하는 작업에 영향을 미치게 되고, 특히 프로젝트의 가장 초기에 하는 작업들은 전체 프로젝트의 방향을 결정하는 작업이 되므로 더 크게 의존하는 작업이 됩니다. 기획자가 성토의 대상이 된것은 기획자가 싫어서가 아니라 기획자가 가장 먼저 작업하는 사람이기 때문입니다. 비슷한 경우를 다른 포지션에서도 찾아볼 수 있습니다. 다른 프로그래머들이 모두 의존하는 핵심 공통 모듈을 만드는 프로그래머나 다른 디자이너들이 모두 의존하는 원화를 디자인하는 디자이너도 비슷한 정도의 책임을 지게 됩니다. 그렇지만 게임 개발의 전체 프로세스를 감안하면 기획자의 책임이 가장 큰 것임은 부인할 수가 없습니다. 한국 영화 산업이 지금과 같이 발전하게 된 계기가 무엇이라고 생각하십니까? 어떤 인터뷰 기사에서 읽은건데, "대본이 나오면 그대로 찍을 수 있게 되면서" 라고 하더...