![](/knowledge/abroad/indu/__icsFiles/artimage/2010/11/30/Gamasutra.jpg)
포스트모템: 벡터 유닛의 ‘하이드로 썬더 허리케인’
매트 스몰
[EA와 스톰프론트 스튜디오(Stormfront Studios)의 베테랑 매트 스몰(Matt Small)은 Xbox Live Arcade용 하이드로 썬더 허리케인(Hydro Thunder Hurricane)을 개발하면서 큰 스튜디오에서 작은 소규모 회사에 이르기까지 그가 이끈 소규모 팀의 변천사를 통해 겪은 성공과 실패를 공유한다.]
"그래서, 나는 게임과 관련된 사소한 일을 중단하고 게임을 하는 것에 대한…이러한 생각을 하고 있었어."
2007년 여름 밤 내 채팅 창에는 위와 같은 말이 오고 갔다. 나의 친구 랄프 크노에셀(Ralf Knoesel)과 나는 아동용 작은 게임 프로젝트를 진행하고 있었던 것 같다. 아니면 최소한 이 프로젝트에 대해 논의하고 있었다. 문제는 그 당시 우리가 우리의 삶으로 생각했던 월급을 받는 다른 직업을 가지고 있었다는 것이다. 그렇기에, 프로젝트 진도는 매우 더디게 나갔다.
내가 아는 모든 개발자들은 언젠가는 현 상황에서 탈출해 그들만의 게임을 만들겠다는 백일몽에 빠져 있다. 랄프와 나는 회사를 설립하기 위해 각각 12년 넘게 노력했다. 최근에 나는 EA 레드우드 쇼어스(EA Redwood Shores)의 아트 리더로서, 랄프는 스톰프론트 스튜디오의 프로그래밍 리더로서 활동했다. 우리는 약간의 돈을 모았고, 더 맨(The Man) 작업에 싫증이 난 상태였다. 랄프의 뜻밖의 제안은 내가 필요로 했던 모든 시도였다.
2008년 1월, 우리는 직업을 그만두었다. 개인적인 자산을 모두 청산하고 우리 PC를 업그레이드하여 벡터 유닛(Vector Unit)이란 새로운 회사를 설립했다. 우리는 직원이었을때는 생각지 못한 세세한 여러 사항을 처리했다. 작은 비즈니스 관리, 계약 협상, 단체 건강보험 등에 대한 내용이었다.
우리가 만들기로 한 게임은 처음에는 SF 러시(SF Rush)와 하이드로 썬더(Hydro Thunder) 같은 고전 아카이드 레이서로의 회귀인 스케일은 작지만 거대한 XBLA나 PSN용 워터 레이싱 게임이었다.
우리는 역동적인 수면으로부터의 탈출을 좋아하기 때문에 물을 소재로 한 게임을 생각했다. 위 스포츠(Wii Sports) 같은 미니 게임은 제외하고 지난 10년 동안 괜찮은 워터 레이싱게임은 출시되지 않았다. 또한, 보트를 이용해 전투를 즐기는 첫 Xbox용 블러드 웨이크(Blood Wake)가 출시되기 전 수 년 동안 우리는 함께 일을 했다. 우리는 우리가 만들 수 있을 거라고 판단한 무엇인가에 대해 착수하기로 했다.
6개월 후 우리는 친구들 앞에서 수 많이 연습했고 잘 때도 읊었던 파워포인트 피치, 게임엔진, 경기하기 쉬운 PC 프로토타입을 갖게 되었다. 우리는 이를 이곳 저곳에 알렸고 결국 Microsoft Game Studios의 관심을 이끌어 냈다.
하이드로 썬더 라이센스를 충족하기 위해 우리의 디자인을 변경하면 어떻겠냐는 생각이 마이크로소프트와의 대화가운데 나왔다. 우리는 우리의 프로토타입을 믿었지만 알려진 라이센스로 인해 새로운 스튜디오로서 첫 작품에 매우 필요한 언론의 관심을 받을 것이라는 것을 알고 있었다.
MGS는 최근엔 사용하지 않은 미드웨이 게임즈(Midway Games)로부터 라이센스를 구입한 워너 브라더스로부터 판매권을 얻었다. 우리는 우리의 디자인 문서를 다시 작성하고 범위를 3배 늘려 계약 협상을 통해 우리의 갈 바를 법적으로 정했다.
2008년 4월 우리는 최종적으로 거래에 서명을 했고 첫 기금과 360개의 첫 개발 키트를 받았다. 하이드로 썬더 허리케인의 진행 상황은 가다 서다를 반복했다.
"가다"는 약간 과장일 수 있었다. 우리는 여전히 팀을 구성하고 사무실을 찾으며 업데이트된 프로토타입에 우리의 새 디자인을 만족스럽게 적용해야 했다. 그리고 360에서 구동중인 우리의 PC 엔진을 구해야 했다.
우리가 벡터 유닛을 설립할 때 기존의 게임 개발 스튜디오에서 대규모 팀을 관리했던 경험을 통해 좀 더 작은 게임 프로젝트 개발을 원활하게 관리할 수 있을 것으로 생각했다. 오히려, 더 쉬울 것이라 생각했다. 돌아서 생각해 보니 어느 정도 맞는 판단이었다. 작은 게임 개발이 우리에게 보여주는 수 많은 작고 놀라운 소식을 우리는 믿지 않았다.
잘한 일
1. 툴이 있었던 초기
우리의 원 프로토타입을 작업했던 초기, 게임 엔진에 대한 작업 이전에 수행했던 첫 기술적인 작업은 제작 툴 세트에 관한 것이었다. 우리는 컨텐츠 제작이 우리에게 중요한 일이고, 우리의 핵심 팀을 작게 유지하고 대부분의 아트를 외주를 주는 것이 계획이었다.
계약자가 최소 빌드 타임을 재빨리 반복하도록 하고 기존의 자산을 다시 구축할 필요없이 필요한 대로 기능을 추가할 수 있도록 조정하기 쉬운 파이프라인이 필요했다.
우리는 수 많은 타사 게임 개발 세트를 연구했다. 하지만 이들에 대해 부정적이었다. Unreal같은 엔진은 우리의 예산 범위를 초과했고 우리가 실제로 필요로 수준보다 더 많은 파워를 전달했다. 그리고, XNA와 토크(Torque)같은 독립 세트는 우리가 필요하다고 판단하는 낮은 수준의 제어를 제공하지 않았다. 그래서, 우리는 애초에 우리만의 것을 만들기로 결정했다. 이는 우리의 최고 결정 중 하나가 되었다.
![](/knowledge/abroad/indu/__icsFiles/artimage/2010/11/30/2_1.jpg)
기본 아트 자산 파이프라인이 최우선 고려 사항이었다. 랄프는 데이터 중심의 세이더시스템을 개발했다. 이 시스템은 게임 쉐이더 코드를 사용한 쉐이드 뷰포인트에서 완전한 하드웨어 렌더링을 지원하는 쉐이더 플러그인을 통해 Maya로 통합된다. 아티스트들은 일반적이거나 상세한 매핑 같은 쉐이더 레이어를 추가하고, 변경 결과를 즉시 볼 수 있으며, 게임으로 내보내지 않고 자유롭게 반복할 수 있었다. 개발 과정 동안 이러한 단순한 기능은 개발 시간을 수 주 단축하는데 도움이 되었다. 아티스트들은 자연스럽게 느끼는 방법으로 작업을 할 수 있었다.
게임 에디터, PFX 에디터, 기타 툴은 모두 공통 포맷(xml 또는 json)으로 내보낸다. 이러한 포맷은 게임 자체가 실행 시간에 구축되고 업데이트 자산을 요구한 대로 제작한다. 아티스트들에게 있어서 이는 가장 폴리 헤비(poly-heavy)하고 텍스트가 많은 자산 측면에 대해서도 Maya에서 보내기 버튼을 누르는 것부터 게임에서 자산을 바삐 돌아다니게 하는데 걸리는 시간은 30초를 넘지 않고 보통 이보다 훨씬 적다. 이 툴은 또한 모든 파라미터를 변경할 때 다시 구축해야 할 필요를 줄이는 생생한 원격 측정을 지원한다.
최종적으로, 개발하는 동안 우리는 게임의 작업 PC 빌드를 유지했다. 최종 자산이 항상 360에서 테스트받고 TV에서 평가된다고 해도 PC 빌드는 우리가 외주업체를 위한 개발 또는 디버그 키트를 제공해야 하는 의무감에서 벗어날 수 있도록 하고, 팀원들이 집에서 일하고 융통성있게 시간을 사용하도록 한다.
또한, 모든 것을 구축하지 않았다라는 것을 말하고 싶다. 우리는 오디오를 위해 FMOD, 충돌과 강체 물리(rigid body physics)를 위해 Bullet을, 버전 제어를 위해 진정으로 놀라운 Subversion(특별히, TortoiseSVN)을 사용했다.
2. 배위에 있는 나!
우리가 워터 기반 게임을 엄청나게 좋아하는 팬이라는 것을 처음에 언급했다. 요동치는 파도를 헤치고 나가는 파워풀한 보트의 느낌을 주는 것이 게임의 성패를 좌우하는 핵심이 될 것이라는 것을 처음에 감지했다.
유체 역학 시뮬레이션은 게임 엔진의 첫 부분으로서 온라인으로 실현될 부분이었다. 로우-폴리 "유체" 선체 주변을 모델로 한 부력과 흐름 계산을 기반으로 하지 않았고 물에서 실질적인 보트의 움직임을 꽤 정확하게 모델로 삼아 작업했다.
이러한 정확성으로 인해 우리는 선체의 모양을 기반으로 사실적으로 생동감있는 다양한 보트 제어모델을 제작할 수 있었다. V 모양의 고속 모터보트 선체는 속력을 내면 사실감있게 물 밖으로 떠오른다. 쌍동선 폰툰(catamaran pontoon)은 번갈아 측면 안정성을 유지하고, 바닥이 평평한 선체 수상비행기가 고속으로 수면을 가로질러 난다.
그러나, 이러한 리얼리티는 필요 이상으로…사실적이라는 것을 초기에 깨달았다. 실질적인 연안의 모터 보트는 일반적으로 잔잔한 수면에서 최대 100mph의 속도를 낼 수 있지만, 우리는 보트가 파도가 치는 상황에서도 200mph가 넘는 속도를 낼 수 있도록 했다.
우리는 인공적인 다운 포스를 추가했고 고속으로 부력을 줄였으며 과장된 아카이드 레이싱 경험에 필요한 정신 없이 빠른 속도를 실현할 수 있을 때까지 수많은 수를 변경했다.
우리는 프로토타입 단계에서 초기에 사용자 테스팅을 시작했고 시간을 낼 수 있는 친구들을 불러 모아서 이 게임을 어떻게 하는지 방법을 알려주지 않고 컨트롤러를 주고 게임을 해보라고 했다. 첫 경험의 결과는 초라했다. 수 주 동안 우리는 우리의 테스트 트랙에서 안정적으로 레이싱을 했다. 우리의 첫 테스트 대상은 이 벽에서 저 벽으로 왔다 갔다 세게 부딪히는 데에 게임 플레이의 대부분이었다.
이는 고전적인 디자인의 에러였고, 디자이너는 제어 방식에 너무 가까이 있어서 결국 이러한 특이한 성격에 익숙해진다는 사실을 다시금 깨달았다. 여러 차례 반복한 후 우리는 단순화된 회전 모델을 제작할 수 있었다. 이 모델은 충분히 리얼리티가 살아 있지만 게임을 처음하는 사람이 제어하려면 직관에 의지해야 했다.
첫 프로토타입의 구동 방법은 결국 HTH를 사용한 것에서 여전히 요원했다. 하지만, 컨셉을 성공적으로 실현하기 위해 그리고 게임의 반응이 좋을 것이라고 퍼블리셔를 확신시키기위해 거의 충분했다 사용자 테스팅을 통해 얻은 교훈을 개발 기간 동안 계속 상기했고 방법을 조정하고 개선하는데 이를 사용했다. 우리는 우리가 제공한 제품에 대해 자부심을 느낀다. 한 리뷰어가 말한 대로 "이는 버터와 같은 것을 다루는 것이다."
3. The Man과 친구하기
이는 마치 졸졸 따라다니며 아부하는 꼴이다. 하지만 이를 “올바른 일”로서 열거하지 않은것은 태만이다. Microsoft Game Studios는 훌륭한 퍼블리싱 파트너이다.
변덕스러운 퍼블리싱 파트너와의 좋지 않은 관계는 잘 짜인 계획을 망칠 수 있다. 퍼블리셔가 디자인 권한에 달려있고 그들이 계약상 지불해야 할 의무가 있는 마지막 순간까지 마일스톤 지불을 보류하여 유능한 소규모 독립 회사가 당황하는 경우를 봤다.
MGS는 훌륭했다. 우리의 프로듀서는 우리가 원한 창조적인 자유를 주었고 실질적으로 게임을 좀 더 잘 만들 수 있도록 편집 피드백을 제공했다. 그는 항상 우리가 협의하지 못한 점에 대해 논하고 타협하려고 했다. MGS 팀은 복잡하고 상세한 차트와 도표를 제공할 필요없이 우리의 SCRUM-lite 스케줄링 방법을 사용해서 함께 작업하는 데에 동의했다. 그리고, 이들은 항상 마일스톤 승인에 즉시 지불했다.
우리는 이 모든 것을 무료로 얻었다. 퍼블리셔와의 관계는 의식적인 노력을 기울여 관리해야 한다. 무엇보다 우리는 적기(red flag)를 피하기 위해 무진 애를 썼다. 우리는 정시에 마일스톤을 제공했고 이들을 사전에 완전하게 테스트해서 우리가 합의한 대로 인도물을 작업하도록 한다.
일정의 후반부로 갈수록 우리는 우선적인 내부 MAT 테스팅을 통해 원활하게 성공적으로 준수했다. MSG가 제기한 문제 또는 우려 사항에 재빠르게 대처했다. 그리고, 우리는 새로운 컨텐츠와 데모가 준비된 빌드 플로우를 계속 제공했다. 그래서, 항상 새롭고 매력적이거나 웃긴 무언가가 있어서 리뷰 미팅에서 자랑스럽게 선보일 수 있었다.
이러한 노력은 성공적이었다. 우리는 마일스톤을 거절당한 적이 없었다. 마일스톤을 통해 돈을 벌고 회사는 탄탄대로를 걸었다. 그리고, 우리의 프로듀서를 행복하게 하여 우리가 원한 창조적인 휴식의 장을 주었다.
※ 자세한 내용은 첨부(PDF)화일을 참고하시기 바랍니다.
![인쇄](/images/common/btn/btn_print.gif)
|