Rainbow Six

서문 ----

컨셉 ----

HRT가 레인보우 식스가 되기까지는 기나긴 여정이 필요했지만, 도중에 타이틀의 기본적인 아웃라인은 거의 바뀌지 않았다. 우리는 미션 임파서블이나 더티도즌 같은 영화에서의 흥분감 - 최고의 전문가팀이 초단위로 정밀한 작전을 수행하는 것을 보는 스릴 - 을 옮기고 싶었다. 또한 전략적 요소가 강한 액션게임 - 어지러운 퀘이크와는 다른 재미의 리얼한 사격의 - 을 만들고 싶었다.

시작시기에서부터, 이 타이틀은 스스로가 바로 디자인 그 자체였던 것 같다. 처음 몇 주후에 게임 플레이 구상이 거의 자리잡혔다. 인질구출뿐 아니라 여러가지 특수임무로 개념을 확장하고, 게임플레이는 계획 단계에서 여러가지 장단점을 가진 멤버들을 골라 팀을 구성하고 전략을 세우고 나서, 비로소 액션 단계로 넘어가 실 게임을 진행 된다. 전투는 신속하고 치명적이며 리얼해야 한다. 한 방에 사살할수 있으며, 전형적인 1인칭 슈팅게임처럼 달리며 총을 쏘는 일은 어렵다.

아이러니컬하게도 초기에 우리가 결정하지 못한 것은 탐 클랜시의 소설에 내용을 맞추는 일이었다. 그는 브레인스토밍에서 HRT를 구상했지만 완전히 결정하지 못했다. 2차대전이나 60년대 냉전기, 근미래등 여러가지 미션을 구상하다 결국 97년 초에야 레인보우식스의 배경줄거리를 설정할수 있었다.(소설과 게임은 결말이 다르다. 스케쥴때문에 소설이 완성되기 전에 미션을 완성해야했기 때문이다. 병렬식 제작의 단점이다..)

제작 ----

원래 레인보우 식스팀은 나와 다른 프로그래머 1명으로 구성되어 있었다. 레드스톰은 4타이틀을 준비하고 있었고, 각 팀 모두 첫 몇 달간 엄청난 인원부족 현상을 겪었다. 레인보우 식스의 첫 아티스트와, 풀타임 프로듀서는 97년 봄에야 팀에 합류했다. 이런 소수 그룹으로 진행은 느릴수밖에 없었다. 첫 겨울과 봄에 우리는 대충의 프레임워크를 설정하면서 모든 시간을 보냈다. 이런 자원의 부족현상은 나중에도 우리를 괴롭혔다.

우리는 인원이 부족했기 때문에 주요 기술들을 라이센스해서 쓰는 것으로 보충을 하려했다. 첫번째는 바로 3D 렌더러였다. 우리의 모회사 버투스(Virtus)사는 자신들의 3D툴 제품을 위해 차세대 렌더링 라이브러리를 작업하고 있었다. 우리는 직접 만들기보단, 버투스 렌더러 기반으로 제작해서 우리의 작업량을 줄이려고 했다. 처음에는 이것이 우리 문제에 이상적인 해결안으로 보였다. 버투스는 몇년간 3D 어플리케이션을 개발했고 여러종류의 하드웨어 가속에서 잘 동작하는 보편적인 크로스플랫폼 솔루션을 지니고 있었다.

우리는 또한 네트워킹 기술도 외부에서 조달하려고 했다. 우리는 MS의 다이렉트 플레이를 포함한 여러종류의 서드파티 솔루션을 살펴봤지만 딱히 만족스러운게 없었다. 우리가 스스로 라이브러리를 작성하려고 했을때쯤에, IBM의 한 개발팀과 접촉하게 됐다. 그들은 새로 개발한 강력한 자바 기반의 클라이언트/서버기술을 사용할 곳을 찾고 있었다. 인버스(Inverse)라 불리운 그 기술은 많은 수의 자바 애플릿을 받아들일수 있도록 설계되었다. IBM의 기술자들은 게임을 포함한 여러종류의 응용을 하고 싶어했고, 인버스는 네트워크 시간 동기화, 안정적인 접속종료 검출 등 우리가 원하는 기능을 모두 지원하고 있었기 때문에 우리는 레인보우 식스에 그를 사용하기로 결정했다. 그러나 결과적으로, 프로젝트 말기 몇 달 쯤부터 우리는 서드파티 기술을 사용하기로 한 이 두가지 결정 모두에 대해 후회하게 되었다.

97년 여름, 우리는 게임에서 캐릭터 애니메이션으로 사용할 모션캡처 데이터의 대부분을 얻어냈다.

탐 클랜시와 일하는 강점 중 하나는 그는 매우 신속히 폭넓은 종류의 컨설턴트들과 접촉할 기회를 만들어준다는 점이다. 테러방지에 대한 배경지식을 얻기위해 우리가 만난 수많은 전문가들중에서는 무기제작사 H&K에서 일한 2명의 근접전투 교관이 있었는데, 모션캡처를 할 시기가 되자 그들이 배우(모션캡처하는 actor를 말함)로 자원했다.

그들은 캘리포니아의 바이오비전(모션캡처장비 유명한 회사) 스튜디오에서 며칠간을 보내며 게임에 필요한 모든 동작을 비디오로 녹화하고 캡처했다. 실제 전투 교관을 모션캡처한 것은 아주 적절한 판단이었다. 프로 배우들이라면 효과를 위해 오버액션을 하는 반면, 이 친구들은 매우 절도있는 동작을 시연했기때문에 매우 인상적인 결과를 낳았다. 게임 캐릭터들은 몇 배나 더 진지해졌다.

97년 10월 위기가 왔다. 우리는 여름내내 열심히 일했지만 스케쥴과는 자꾸자꾸 멀어지고만 있었다. 책임의 일부는 내가 맡은 너무나 과도한 업무량 때문이었고, 또 일부는 탐 클랜시의 소설이 우리의 레벨 디자인을 혹사하고 있었기 때문이며, -우리는 완전히 별개인 16개의 공간을 만들자는 결정을 저질러버렸기 때문에 미술(아트) 쪽에 막심한 부하가 걸렸다- 또한, 우리의 "시간절약" 라이센스 기술들이 별 도움이 안된다는 결과 때문이었다.

인버스는 대단한 네트워킹 솔루션-그러나 자바를 위한- 이었다. 불운하게도 레인보우 식스는 C++로 작성되었다. 초기 리서치때는 이 두가지 언어를 섞는 것은 대단치 않은일이라 생각했다. 그러나 사실상 동시에 두가지의 다른 언어를 이용해서 어플리케이션을 작성하고 디버깅하는 일에서 생긴 오버헤드는 엄청났다. 두 파트를 이어주는 인터페이스 코드가 전체 네트워킹 라이브러리보다 더 거대했다. 제품을 출시하려면 인버스를 걷어내고 우리 자체의 네트워킹 솔루션을 작성해야만 한다는 상황이 명백했다. (덧붙여 말하면 우리의 자바기반의 제품들에는 계속 인버스를 사용하고 있다. 문제는 코드자체가 아니고 두개의 개발환경을 통합하는 일이었다)

또한 버투스 렌더링 라이브러리에서도 문제가 있었다. 레인보우 식스 작업을 깊이 들어갈수록, 우리는 게임을 할만한 프레임레이트를 위해선 수많은 렌더러 최적화가 필요하다는 사실을 느끼게 되었다. 불운하게도 버투스 렌더러는 블랙박스와 같았다. 마치 스위스칼처럼 다양한 상황에서 다목적으로 사용하도록 설계되어 있었다. 고사양 시스템에서조차 한 자리수 프레임레이트밖에 나오지 않게되자, 우리는 다목적보다는 전문목적의 솔루션이 필요하다는 걸 깨달았다.

97년 11월초, 우리는 위기극복 계획을 짰다. 우선 팀내에 인력을 보충했다. 문제 해결을 위해 수석 그래픽 프로그래머로 Erik Erikson, 수석 네트워크 프로그래머로 Dave Weinstein을 초빙했다. 나는 리드 엔지니어를 그만두고 프로듀서인 Carl Schnurr가 게임 디자인에 더 많은 책임을 맡게 됐다. 봄에 출시하기로 한 원래 계획은 4개월 후퇴시켰다. 아티스트들은 새 출시일까지 맞추기 위해 빠른 속도로 레벨을 제작하도록 파이프라인(아티스트들의 작업순서에 의한 팀을 말하는 것 같음)을 순환 풀가동시켰다.

마지막으로, 우리는 서드파티 소프트웨어에 더이상 의존하지 않기로 하고 즉시 행동을 개시했다. 전체 네트워킹 라이브러리에서 자바부분을 걷어내고 새로 작성했다. 버투스는 친절하게 소스코드를 제공했고 우리는 철저히 분해검사하고, 레드스톰에서 당시 진행하던 다른 3D 타이틀인 도미넌트 스피시즈에 사용하던 코드를 끌어냈다. 이 모든일이 연말연시에 일어났다. 미칠것같은 2달간이었다.

그때부터 우리의 개발노력은 종점을 향해 치닫게 되었다. 98년 2월부터 7월까지 비상모드에 들어섰다. 프로젝트의 마지막 몇 달간 여러종류의 위기가 발생했다. 3월달에는 97년 11월부터 내 위치에서 개발작업하던 Peter McMurry가 건강문제로 물러났기 때문에 내가 리드 엔지니어로 돌아오게 되었다. 코드를 작성하면 작성할수록, 빌드(컴파일 같은거..)는 점점 더 오래걸리고, 마침내는 몇 시간이나 걸려서 엔지니어들을 좌절시켰다.

실행파일의 크기는 우리의 툴들을 방해하기 시작해서, 프로파일링과 바운즈 체킹이 불가능해졌다. 출시일에 맞추기 위해선, 테스트 기간을 대폭 단축해야 했으므로 위험은 더욱 커졌다. 반면, 프로젝트의 마감이 다가올수록 흥분이 느껴지고 있었다.

98년 3월 우리는 조심스럽게 초기 데모를 잡지사에 보여주고 긍정적인 반응에 스릴을 느꼈다. (이 시점에서 우리는 작품에 너무 빠져있어서 외부에서 어떻게 생각할지 알수가 없었다) 진정한 제막식은 98년 애틀란타에서의 E3쇼에서 였다. 개발팀 멤버들은 쇼 플로어에서 데모를 실행시켰고, 우리 대부분에 있어 그것이 출시전 가장 긴장시킨 일이었다. 게임플레이의 마지막 수정내용은 그 3일간 우리가 배운 것에서 대부분 나온것이다.

잘 되어간것들 (What Went Right) ===============================

1. 일관된 비전(Coherent Vision)
   

   제작기간 도중 여러가지 일이 일어났음에도 불구하고, 레인보우 식스의 게임플레이 핵심부분은 절대 변하지 않았다. 우리는 초기에 이미 완성될 게임이 어떤 것일지에 대한 비전을 세워놓았다. 나는 이런 일관성의 중요성을 강조하지 않을수 없다. 개발 싸이클중 정말 힘든 단계에서도 단순하게 원래의 컨셉을 유지하는 것이다.

   이런 일관된 비전덕분에 우리는 적절한 세부기획서(design document)들이 없이도 간신히 위기를 넘길수 있었다. 많은 부분의 기획(design)이 끝내 만들어지지 않았지만 제작팀은 우리가 나갈 방향을 잘 알고 있었기때문에 많은 부분의 세부사항을 우리 스스로 채워넣을수 있었다. 심지어 프로젝트 중반에 대대적인 엔지니어링 재정비가 있었음에도 기존에 작성된 많은 양의 아트(그래픽)와 코드를 다시 사용할수 있었다.

   우리의 비전은 또한 팀의 사기에도 많은 영향을 미쳤다. 우리가 과연 프로젝트를 마칠수 있을까하는 의문은 많이 떠올랐지만, 우리가 일단 해내기만 한다면 그 결과는 대단한 것일거라는데는 의심해본적이 없었다. 프로젝트가 흘러가는 방향에 대해 믿고 있다면 위기도 큰 문제가 되지 않기 마련이다.

2. 효과적인 아트 파이프라인(An Efficent Art Pipeline)
   

   아트 팀은 최종적으로 적절한 시간내에 원하는 레벨들을 제작할수 있는 답안을 찾기까지 4-5번의 제작 파이프라인들을 시도해보았다. 문제는 우리가 게임상에서 모두 다른(unique) 16개의 배경공간을 원했다는 거다 -- 미션과 미션 사이에는 서로 공유할수 있는 텍스처나 지오메트리(모델링)가 거의 없었다. 게다가, 우리는 전용의 레벨제작 툴을 만드는 대신에 모든 것을 3D 스튜디오 맥스에서 작성했다. 그래서 아티스트들은 그들의 창조할수 있는 공간의 종류에 대해 많은 자유를 누릴수 있었지만, 대신에 복도라든가 계단같은 일반적인 부품들을 찍어낼만한 손쉬운 방법이 없었다 -- 모든것을 손수 모델링해야만 했다.

   결국 아트팀은 노력의 낭비를 최소화할수 있는 프로세스를 찾아서 정착했다. 누구든지 모델링을 하기전에, 아티스트는 전체 레벨을 종이에 스케치한 뒤에 그것을 프로듀서와 아트팀장(art lead)에게 승인받기위해 제출해야 한다. 그리고나서 모델러는 작업을 시작하고, 텍스처링에 들어가기 전에 레벨의 지오메트리상태에서 플레이 테스트를 한다. 각각의 아티스트는 책상위에 게임엔진의 미니버전이 돌아가는 두번째 컴퓨터를 갖고 있어서 레벨이 게임속에서 어떻게 돌아가는지 쉽게 실험해볼수 있다.

3. 톰 클랜시의 지명도(Tom Clancy's Visibility)
   

   라이센스를 잘 얻었다고 해서 후진 게임을 좋게 만들순 없지만, 좋은 게임이 등장할때 주목받을수 있도록 만들수는 있다. 98년 봄, 레인보우6의 데모를 가지고 게임 잡지사등과 접촉했을때 그들은 우리를 중요하게 여길 이유가 없었다 -- 우리는 아무 실적도 없고 스타 개발자도 없었으며 과대광고도 없었다.(아주 없었던건 아니지만..)

   우리는 경쟁이 치열한 장르에서 예술의 경지에 다다르기엔 모자란 렌더링엔진을 가진 이상한 게임을 보여주고 있었다. 신, 하프라이프, 다이카타나 같은 대형 기대작들 사이에서, 간판으로 내건 클랜시의 이름은 사람들이 우리 타이틀을 한번 거들떠 보게 만드는 결정적인 요소였다. 다행스럽게도 그 데모의 게임플레이는 출시일까지 좋은 평가 기사들이 여론을 휩쓸도록 만들었다.

4. 피직스 엔진의 재작업(Reworking the Physics Engine)

   98년 2월, 우리는 레인보우6의 피직스 엔진을 완전히 재정비하였다. 이것은 훗날 여러가지의 최신기술을 가능하도록 했다. 우리는 그 전달에 렌더러를 재정비했지만 여전히 프레임레이트는 버벅거렸다. 프로파일러(profiler)를 통해 코드를 돌려보자 우리는 충돌체크--캐릭터가 월드에 충돌했는지, AI의 시야루틴에서 사용하는 시선검사등--에 많은 시간을 뺏기고 있음을 발견했다.

   문제는 피직스 엔진이 충돌검사를 요구받을 때마다, 매우 일반적인 3D 해(solution)를 계산한다는 점이었다. 수류탄의 튕김이나 탄알의 궤적등의 경우를 제외하고는, 3D 충돌체크는 필요없는 남용이었다. 그 다음달까지 내내 우리는 대부분의 충돌검사를 floor plan(레인보우6의 plan phase에서 건물의 평면도를 가지고 작전계획을 짜는 것)을 이용해 2D로 처리하도록 엔진을 재작업했다. 이 충돌검사용 floor plan은 3D 레벨 모델에서 알고리즘에 의해 생성된다.

   이 테크닉은 적절했다. 플레이하기 좋은 수준으로 프레임레이트가 돌아왔을 뿐만 아니라 충돌검사가 더욱 안정적이 되었다. 또한 이 floor plan은 AI팀 멤버들의 길찾기 루틴에서도 이용할수 있었다. 플레이어들은 플래닝과 액션 인터페이스 모두 동일한 floor plan이 일치함을 볼수 있었다. 낮은 프레임레이트를 높이려는 방법을 강구하다가 서너개의 주요하고 어려운 기술적 문제까지 해결할수 있었다. 때때로 코드의 일부를 포기하고 다시 시작하는 것이 옳은 일일때가 있다.

5. 팀의 단결(Team Cohesion)

   레드스톰은 인기스타도 게으름뱅이도 고용하지 않는다. 레인보우6 팀의 모두는 엄청난 압박감 속에서 무척이나 오랜시간 일했지만, 용케(아마도) 인내심과 프로로서의 자세를 잃지 않았다.

잘못 되어간것들 (What Went Wrong) =================================

1. 선행 기획의 부족(Lack of Up-front Design)

   우리는 한번도 제대로 된 디자인 문서(design document, 기획서를 뜻함)를 가져본 적이 없었다. 이로인해 우리는 많은 코드와 아트를 만들었다가 나중에 버려야만 했다. 더 나쁜건 우리가 작성할 것들의 세부 윤곽이 없었기 때문에, 진행상태(혹은 남은일)를 정확히 측정할만한 방법도 없었다는 거다. 우리는 문제가 심각해지고서야 그 사실을 깨달았다. 만일 선행(先行)의 엄격한 디자인이 있었다면 더 순조롭게 진행할수 있었을 거다.

2. 초기의 인원부족(Understaffing ad the Start)

   이 문제는 앞의 문제과도 밀접한 관련이 있다. 우리는 확고한 디자인이 없었기 때문에 정확한 시간 견적도 불가능했다. 레드스톰은 전면적인 인력의 기아(飢餓)에 시달렸으며, 적절한 스케쥴이 없었기 때문에 각자 자기의 무덤을 얼마나 파야하는지 알 수 없는 것 같았다. 새 회사를 출범하기 위해선 채용말고도 해야할 일이 항상 많았으며 우리는 가능한 시작시의 제한된 자본에만 의존하려고 하고 있었다. 그런 환경에서는 프로젝트의 인원부족과 신규채용의 지연이 합리화되기 마련이다.

   게다가 나는 스스로의 능력을 잘못 과대평가했다. 레드스톰의 첫 해에 나는 4가지 업무를 맡고 있었다: 엔지니어링 부사장(VP of Engineering), 레인보우6의 엔지니어 팀장(lead engineer), 레인보우6의 기획자(designer), 프로그래머. 이중 모두가 전임제(full-time) 직책감이다. 이 4가지 모두를 커버하기 위해서 나는 내 시간을 실제로 일을 진행하기 보다는 하나의 고비를 넘기면 다음 고비를 처리하는 식으로 몰아갈수 밖에 없었다.

   그리고 나는 내 자신의 관리자로도 행동했기 때문에 아무도 나의 수행성과(performance)에 대해 감사할 사람이 없었다. 만일 다른 팀장중 한명이 그의 스케쥴 임무를 지키지 않거나 그의 마일스톤(milestone, 데모등의 중간 이정표)을 제대로 못한다면 내가 문책했을 것이다. 그러나 내 자신의 프로젝트에 대해서는, 항상 핑계를 둘러댈수 있었고 이것은 명백한 문제점이었다.

3. 검증되지 않은 기술에의 의존(Reliance on Unproven Technology)

   우리의 렌더링과 네트워킹의 외부 솔루션들은 모두 실패했고 개발후반에 내부적에서 개발한 코드로 대체되었다. 두 경우 모두, 우리는 아직 개발단계인 소프트웨어에 의존하고 있었다. 핵심 기술은 견실했지만, 적절치 못한 디자인문서, 프로그래밍 인터페이스의 변화, 퍼포먼스 요구사항의 오해, 과중한 통합(C++과 자바사이의 - 역자주) 노력 등으로 인해 고통을 받았다. 두개의 패키지 모두 진행중이었기 때문에, 우리는 그들의 한계와 능력에 대한 철저한 평가를 할수 없었다.

   두가지 모두가 완전히 우리의 필요와는 알맞지 않다는 게 명백해졌을 때, 그들을 바꾸기엔 너무 늦어있었다. 돌이켜보자면, 일찌감치 맘을 단단히 먹고 우리 스스로의 기술기반으로 작성했다면 자금도 절약하고 훨씬 매끄럽게 개발과정을 이끌수 있었을 것이다.

4. 핵심 인물의 손실(Loss of Key Personnel)

   개발팀의 보조인력 한명만 잃어도 최종 마스터가 제때 안나올수 있다. 98년 2월 리드 엔지니어(Lead Enginner, 메인 프로그래머를 의미함)이 병에 걸렸을때 우리는 심각한 위기에 처했다.

   정신없는 몇주를 보내며 회사 외부에서 리드을 채용하려 했지만 결국 누군가를 데려와서 98년 7월 출시일까지 시간을 맞춘다는 일은 불가능하다는게 명백해졌다. 팀내에서 승격 또한 불가능했다 -- 모두의 스케쥴이 너무나 빡빡해서 단지 코딩작업을 끝내기 위해 이미 추가시간을 끌어쓰고 있었다; 누구도 리드의 책임을 맡을만한 여유가 없었다.

   마침내 내가 리드자리로 돌아왔다. 그러나 다들 이때는 이런 조정을 위해서 내가 VP의 임무를 포기해야만 한다는 걸 알고 있었다. 경영쪽의 나머지 인원들과 다른 선임 엔지니어들이 구멍을 메꾸려고 노력했고, 피터는 프로젝트에 강력한 방향을 갖고 있었기 때문에 이동은 매끄럽게 이루어졌다. (그의 건강이 나아진후에 피터는 프로젝트의 끝무렵에 복귀해서 레인보우6의 사운드코드의 마감작업을 도와주었다)

5. 부족한 테스트 시간(Insufficient Testing Time)

   우리는 운이 좋았다. 초기의 실수들로 인해 시간을 제때 맞출수 있는 길은 테스트 스케쥴을 대폭 잘라내는 방법뿐이었다. 우리는 최종 마스터를 완성하기 일주일 전에도 아직까지 새로운 버그(다운되는)를 발견하고 있었다; 만일 이들중 하나라도 수정을 위해 주요한 리엔지니어링 요구했다면 우리는 깊은 문제에 빠졌을 것이다.

   마지막에 엔지니어링 팀의 유언장을 쓰다시피한 믿을수 없는 노력으로 게임은 깨끗하게 출시되었다. 실은 이후에도 버그를 해결하기 위해 여러가지의 패치를 내놓았다.

레인보우6의 개발싸이클은 21달동안의 롤러코스터 같았다. 시작단계에서 프로젝트는 숫자도 모자라고 경험도 없는 팀에 비하면 너무나 야심만만했다. 6개월 내에 엔지니어링 팀장을 2번이나 교체할뿐만 아니라 개발후기에는 그래픽, 네트워크, 시뮬레이션 소프트웨어의 재정비를 견뎌야만 했다. 최종 제품은 버그투성이에 플레이 힘든 엉터리가 될뻔 했다. 그런 최악의 것이 되지 않은 이유는 재능있는 많은 사람들이 열심히 일했기 때문이다.

나는 레인보우6가 완벽한 게임이라고는 말하지 않겠지만, 우리가 96년으로 돌아가 원래 생각했던 바로 그 게임(외양이든 게임플레이든)이라고는 말할수 있다. 우리가 레인보우6로부터 얻은 교훈은 이미 레드 스톰의 차기 제품들에 적용되고 있다. 우리의 현재 초점은 확실한 기획을 미리 마치고 끝까지 확실한 테스팅을 하는 것이며 -- 그리고 물론 대단한 게임을 만드는 거다.