카발 (비밀결사): Valve의 Half-Life 기획 과정

 

 

=================================

=================================

=================================

 

 

출처: http://parkpd.egloos.com/3730476

카발 (비밀결사): Valve의 Half-Life 기획 과정 #

By Ken Birdwell 
Gamasutra
December 10, 1999

 

Half-Life 가 평판과 수익 모두에서 어마어마하게 성공한건 사실이지만(50개가 넘는 ‘올해의 게임’ 상을 수상하고 전세계적으로 백만 장 이상 팔렸다), 이 게임이 처음부터 성공작은 아니었다는 것을 알고 있는 사람들은 드물다. 사실, 이 게임을 만들려는 Valve의 첫 시도는 폐기처분해야 했다. 좋게 봐줘야 그저그런 수준이었고, 수많은 게임들을 고질적으로 괴롭히는 전형적인 문제에 시달려야 했다. 이 글은 우리의 초기 실패작 버전의 Half-Life 를 획기적인 성공작으로 바꾼 팀웍 - 즉, ‘카발Cabal 과정’에 대한 것이다.

 

좋은 의도로 시작하긴 했다

 

초 반 출시 예정은 게임이 실제로 나오기 1년 전인 1997년 11월이었다. 이 일정에 맞추면 Valve가 사실상 예쁜 Quake TC (Total Conversion : 완전 변환 - 완전히 새로운 시각적 구성과 레벨 만들기)를 개발할 수 있었던 것이었다. 1997년 9월이 되어 원래 스케줄의 끝에 다다르자, 많은 작업이 완료되었지만 한 가지 중대한 문제점이 남아 있었다. 게임이 하나도 재미가 없었다.

 

일부 몬스터가 멋지긴 했다. 하지만 플레이어들이 기획자가 기획한 방식대로 싸우지 않으면 녀석들은 너무나 멍청하게 행동했다. 멋진 레벨도 있었지만 전체적으로 조화를 이루지 못했다. 멋진 기술도 일부 보유하고 있었지만, 대개의 경우 게임 내에서 한 두 군데서만 실현되었다. 따라서 처음부터 끝까지 일관적으로 게임을 플레이할 수 없었고, 심각한 기술적 문제들이 산재해 있었다. 따로 놓고 보면 멋진 부분들이 꽤 있었지만, 게임 전체로 놓고 보면 제대로 돌아가고 있지 않았다.

 

가장 쉬운 해결책은 몇 달 더 작업해서 가장 치명적인 문제들을 적당히 숨긴채로 출시하는 것이었다. 이것은 퍼블리셔들의 변덕에 의해 생사가 결정되는 회사에서 일반적으로 택하는 해결방안이다. 예측 가능한 결과가 나오기 때문이다. 하지만 Valve는 제법 독립적이었고, 우리 중 누구도 한 두 달 더 작업한다고 해서 의미있는 차이가 보일 것이라 생각하지 않았다. 그래서 무척이나 고통스러운 결정을 내려야 했다. 게임의 모든 단계를 처음부터 다시 작업하기로 한 것이다.

 

스크립트 연출순서는 플레이어들에게 게임플레이의 힌트를 주면서도 끔찍한 공포를 선사하도록 기획되었다.

 

다 행히 이 게임에는 우리가 좋아하는 요소도 있었다. 우리는 소규모 그룹을 조직해서 이 게임 어디인가에 존재하는 모든 웃긴 아이디어,  모든 쿨한 재주, 모든 흥미거리들을 찾아내어 단 하나의 프로토타입 레벨에 집어넣어 보도록 하였다. 이 레벨이 재미있어지자, 그들은 점점 더 재미있는 변수들을 추가했다. 재미없는 아이디어는 그냥 잘라버렸다. 소프트웨어 기능이 필요해지면 계속 단순화시켜서 며칠 안에 작성할 수 있는 수준으로 변경했다. 이들이 한 달 가량 이 작은 한 개의 레벨을 작업하는 동안 우리 나머지 사람들은 사실상 거의 놀고 있었다. 그들이 작업을 끝마치자 우리는 그것을 플레이해보았다. 엄청 좋았다. 마치 ‘다이하드’와 ‘이블데드’를 합쳐놓은 듯 했다. 이 게임은 계시였다. 우리의 대표 게임이 될 것이었다. 거대하고 무시무시하고 엄청난 작업량을 요구하겠지만, 일단 경험해보고 나니 이 게임 이하 수준으로는 만족할 수 없었다. 단지 우리가 할 일은 이만큼 재미있는 레벨을 한 100개 정도 더 만들면 되는 것이었다. 별 거 아니었다.

 

자, 어린 시절에 대한 이야기를 해보시죠

 

‘카 발’이 나오기 전의 두 번째 단계는 프로토타입 레벨의 어느 요소들이 재미있는지를 분석하는 것이었다. 처음 제시한 이론은 ‘경험밀도론’이었다. 즉, 한 플레이어가 맵 안에서 일정 시간과 장소 내에서 얼마나 많은 ‘짓’을 벌이는지에 대한 이론이었다. 우리의 목표는 몬스터, 특수효과, 플롯 기점, 액션 연출 등의 다음 자극이 일어나기까지 플레이어가 너무 오래 기다리지 않도록 만드는 것이었다. 물론, 이 모든 자극을 플레이어에게 한 번에 다 안겨줄 수야 없으므로(끝없는 자극의 시리즈는 따분할 뿐이다), 모든 컨텐츠는 시간이 아닌 거리에 의해 배치되었으며, 어떤 활동도 플레이어의 영향력 너머에서 발생하지 않았다. 만일 플레이어들이 더 많은 액션을 원한다면, 단지 앞으로 몇 초 동안 걸어나가면 되는 것이었다.

 

플레이어와 플레이어의 적들 모두에게 위험한, 천장에 매달린 몬스터에 대한 컨셉아트

 

두 번째 이론은 ‘플레이어 인정론’이었다. 즉, 플레이어들이 행동을 취할 때마다 게임 세계가 그 행동을 인정해야 한다는 뜻이다. 예를 들어서, 플레이어들이 총을 쐈다면, 소리보다 더 영구적인 방법으로 그 행동을 세계가 인정해줘야 한다. 자신이 총을 쐈다는 시각적인 증거가 남아야 하는 것이다. 우리는 벽에 구멍을 뚫고 싶었지만, 기술적인 문제라던가 게임 진행적인 측면 때문에 그럴 수는 없었다. 그 대신에 우리는 ‘흔적’ - 총알 자국과 폭발 표시를 모든 표면에 남겼고, 이는 플레이어의 행동에 대한 영구적인 기록이 되는 셈이다. 또한, ‘밀려날 법한’ 물체를 플레이어가 밀면, 물체가 플레이어를 무시하지 않고 밀려나야 한다. 플레이어들이 쇠지레를 들고 ‘깨질 법한’ 물체를 후려갈기면, 그 물체는 깨져야 했다. 다른 캐릭터들이 있는 방에 들어가면, 그 캐릭터들도 플레이어를 인정해야 했다. 이름을 부르지 않는다면 쳐다보기라도 해야 하는 것이다. 우리 이론의 기본은 ‘세계가 플레이어를 무시하면, 플레이어는 세계에 대해 무관심해진다’였다.

 

마지막 이론은, 실패에 대해 늘 플레이어가 자기 자신을 탓하도록 만들어야 한다는 것이었다. 아무런 경고도 없이 게임이 플레이어를 죽여버리면, 플레이어들은 게임을 탓하고 싫어하게 된다. 하지만 게임이 위험에 대해 힌트를 주고 해결방법을 보여준 후에도 플레이어들이 죽어버렸다면, 플레이어들은 그것이 ‘자기 탓’이라고 생각하게 된다. 자신들이 게임의 기대에 부응하지 못했으므로 더욱 열심히 노력하게 된다. 그리고 성공했을 때 게임이 스크립트 연출, 특수 효과 같은 작은 보상을 해준다면, 스스로에 대해서, 그리고 게임 자체에 대해서 긍정적인 느낌을 가질 것이다.

 

카발(비밀결사)

 

프로젝트의 첫 11개월 동안 우리는 우리 앞에 나타나서 모든 것을 하나로 묶어줄 공식적인 ‘게임 기획자’ 라 불리는 사람을 찾고 있었다.  수많은 이력서를 읽어보고 가능성이 있어 보이는 여러 지원자를 인터뷰했지만, 우리가 진지하게 필요하다고 생각했던 신과도 같은 ‘게임  기획자’가 될 만큼의 특성을 가진 사람은 찾을 수 없었다. 결국 우리는 이러한 이상적인 인물은 존재하지 않는다고 결론짓었다. 그대신 회사의 여러 부서의 장점을 모아 우리 스스로의 이상에 맞는 하나의 집단을 구성해 그들을 ‘카발Cabal’이라고 부르기로 했다.

 

이 집단의 목적은 모든 레벨, 주요 몬스터 인터랙션, 특수효과, 플롯 도구, 디자인 기준 등을 세부적으로 담은 하나의 문서를 만드는 일이었다. 카발은 각 몬스터, 무기, NPC가 언제 어떻게 등장해야 하는지, 어떤 기술을 플레이어가 가져야 하는지, 우리가 그 기술을 플레이어에게 어떻게 알려줄 것인지를 고안해야 했다. 무척 위압적인 작업처럼 보이지만, 우리는 이 일을 해냈다. 우리는 카발 과정이 매우 성공적이었으며, Half-Life 의 주요 성공요인 중 하나라고 생각한다.

 

카발 회의는 주로 게임의 한 분야에 대한 준공식적인 브레인스토밍 모임이었다. 각 회의 때마다 한 사람이 디자인의 기록과 작성을 하게 되어 있었고, 또 한 사람이 레이아웃과 기타 세부사항을 설명하는 그림을 그리게 되어 있었다. 카발 회의는 일반적으로 며칠 동안 특정 분야에 대한 고차원적인 개념들과 재미있을 법한 이벤트를 조합하는 모임이었다.

 

기획팀은 다양한 시각적 은유법을 통해 매우 독특하고 효율적인 적들을 만들었다.

 

어 느 정도의 아이디어가 제시되었다면, 그것을 굵직한 스토리라인과 연대기로 재구성하였다. 이런 작업이 다 이루어진 후에는 기하학적  지형의 러프 스케치를 만들고, 여기에 각 주요 이벤트가 어디서 발생할 지를 표시하였다. 처음부터도 마음에 드는 구역들이 있었지만, 다른 구역은 ‘야외’나 ‘큰 몬스터가 있는 곳’ 정도로 오랫동안 방치되었다. 몇몇 구역은 게임 내에서의 특정 위치가 없는 것들이었다. 이러한 디자인들은 수 주 동안 허공에 떠 있다가 폐기되거나, 아니면 다른 두 구역 사이의 연결점으로 쓸모가 있는지를 검토했다. 다른 구역은 특정한 기술을 강조하기 위해 창조되거나, 단지 카발 이전의 실험에서 얻은 쿨한 모형을 집어 넣기 위해 만들어졌다. 신기하게도, 이러한 인위적인 요소들의 조화를 시도할 때가 최고의 작품이 나오는 경우가 많았다. 나중에는 연관성이 없는 몇 개의 요소들을 각 구역에 배치하고 그것들을 같이 엮을 합리적인 방법을 고안해 내는 버릇마저 생겼다. 회의를 끝내고보면 처음 나왔던 아이디어가 현재의 결과물만하지 못하고, 우리가 만든 구조가 초기 아이디어를 폐기할 때 더 잘 돌아가는 경우가 많았다.

 

카 발 회의에는 모든 사람이 기여했지만, 모든 사람이 매일 똑같이 헌신할 수는 없었다. 회의는 가혹할 정도로 힘들었고, 집단의 절반 정도 사람들은 멍하게 생각없이 회의를 두세 번 참석하다가, 갑자기 아무도 보지 못한 생각의 방향을 발견하고 갑자기 그 주의 주요 기여자가 되곤 하는 것이 거의 법칙이 되어버렸다. 이유는 모르겠지만, 생각의 입력이 부족해서 회의가 정지되지 않도록 하기 위해 적어도 대여섯 명이 각 회의마다 참석하게 되었다.

 

카발은 매주 4일, 매일 6시간씩 연속 5개월 동안 회의를 했고, 프로젝트의 종료까지도 종종 만나곤 했다. 회의가 6시간씩이었던 이유는 6시간 이후에는 모두가 정신적, 육체적으로 힘들었기 때문이다. 회의에 참여한 사람들은 이 기간 동안 이메일을 읽고 매일 작성하는 기록들을 제외하곤 특별히 다른 일을 할 수도 없었다.

 

최초의 카발 집단은 세 명의 엔지니어, 레벨 디자이너, 작가, 애니메이션 담당으로 구성되었다. 이들은 Valve의 모든 주요 집단과 프로젝트의 여러 모습을 대표하였으며, 가장 제품 출시의 경험(반드시 게임 경험과 일치하진 않지만)이 많은 사람들로 이루어졌다. 카발은 게임의 출시와 연관된 사람들로만 이루어져 있었다. 즉, 기획자들은 포함되지 않았다. 카발의 각 멤버는 그들이 맡은 기획이 설명하는 대로 실제로 작업을 이루어내거나, 적어도 필요할 때 그런 일을 할 수 있는 책임감을 가진 사람들이었다. 

 

각 레벨의 진행경로와 대략적인 모형 및 캐릭터 배치의 정보를 표시해 두는 것이 중요하다.

 

처 음으로 카발이 진행되는 몇 개월 동안은 외부 사람들에게는 다소 불안스러운 기간이었다. 서로의 자존심을 누르고 일을 제대로 처리할 수 있는지, 여러 사람의 손을 거친 게임은 주제가 흐릿해지진 않을지를 알 방법이 없었다. 결과적으로는 우려했던 것의 반대가 일어났다. 혼자 일하는 것에 지친 사람들은 협동적인 과정에 의해 활력을 되찾았고, 이제껏 본 적이 없는 수준의 확고한 디자인을 만들고 있었다.

 

카발의 성공이 드러나자 내부적으로 소형 카발들이 조직되어 다양한 기획문제를 해결하게 되었다. 소형 카발들은 특정 기획 분야의 결정에 직접적으로 연관된 사람들로 구성되었지만, 가능하면 다른 측면의 의견도 얻기 위해 다른 분야 사람도 포함시키곤 했다. 우리는 또한 카발의 멤버쉽을 유연하게 만들어서 매달마다 이전 멤버 중 일부를 빼고 몇 사람씩 멤버를 교체해서 언제나 회사의 여러 부서들 출신들이 있도록 조직했다. 이를 통해 멤버들이 소진하는 것을 막았고, 카발의 결정을 많은 사람들이 경험해 볼 수 있게 해주었다.

 

최종 결과는 200 페이지가 넘는 문서로서, 버튼이 어느 정도 높이에 있어야 하는지부터 각 레벨의 시작 시간이 몇 시 몇 분인지까지의 모든 것을 세부적으로 포함한 결과물이었다. 모든 레벨의 초기 그림, 그리고 각 레벨에서 필요할 수도 있는 모든 기술, 음향, 애니메이션에 대한 작업 아이템 리스트도 있었다.

 

또한 한 사람을 지정해서 문서 전체를 유지하고 전체 스토리라인을 파악하도록 했다. 30시간짜리 영화에 맞먹는 기획이었기에, 함부로 대충 짧은 시간으로는 감당할 수 없을 정도로 방대한 세부사항을 만들게 되었다. 또한 스태프에 전문 작가를 두는 것이 이 과정에서 가장 중요한 부분임을 깨닫게 되었다. 작가는 캐릭터들에게 성격을 부여하고, 극적인 구조를 이해하며, 플롯의 반전, 페이스의 조절, 연속성을 유지할 수 있는 소중한 능력을 가진 사람이다. 

 

돼지 목에 진주 목걸이

 

카발의 두 달째에 접어들자, 우리(돼지들)는 여러 분야에서 개발을 시작할 수 있을 정도의 게임 디자인을 준비하게 되었다. 석 달째가 되자 플레이 테스트를 할 정도를 완성할 수 있었다.

 

플 레이 테스트 세션은 한 명씩의 외부 지원자(퍼블리셔인 Sierra는 다른 게임의 테스트를 위해 등록 카드를 제출한 지역 내 지원자들을 선출했다)가 2시간 동안 게임을 플레이하는 것이었다. 그들의 바로 뒤에서 게임의 그 구역을 담당한 카발의 멤버와 현재 테스트 중인 레벨의 담당 레벨 디자이너가 앉아 있었다. 새로운 AI를 시험하는 경우라면 엔지니어도 함께 참석했다. 

 

게 임을 실행하고 게임이 정지할 경우 리셋하는 것을 빼고는 Valve의 관찰자들은 아무 말도 하지 못하게 했다. 그들은 조용히 앉아 여러 사항을 기록하면서 어떤 힌트나 의견제시도 할 수 없었다. 불쌍한 플레이 테스터가 20분 동안 당신이 만든 레벨에서, 당신은 꽤나 ‘당연하다’고 생각한(그러나 알고 보니 제멋대로이고 답을 얻기가 불가능한) 해답을 찾지 못한 채 갈피를 못 잡고 허둥대는 것을 지켜보는 것은 무척이나 사람을 겸손하게 만든다. 

 

이 생물은 원래 호의적인 캐릭터였으나, 플레이 테스트를 해본 결과 플레이어들은 일단 쏘고 나중에 고민한다는 것을 알게 되었다.

 

 

 

반응형

 

728x90

 

 

 

또 한 이것은 디자인에 대한 논쟁을 종식시키는 방법이기도 했다. 적어도 다음 플레이 테스트 세션이 오기 전까지는 자신이 주장하는 개인적 의견들이 큰 의미가 없다는 점이 자명해진 것이다. 단지 내가 재미있을 것이라 생각한다 해서 재미있는 것은 아니었다. 플레이 테스터들은 그 생각이 얼마나 틀렸는지를 보여주곤 했다. 

 

일반적인 2시간 플레이 테스트 세션은 게임 내에서 수정, 변화, 추가, 삭제할 100 여개의 ‘액션 아이템’으로 환산된다. 처음의 2, 30 번의 플레이 테스트 세션은 회사 전체에게 어떤 요소들이 재미있는지를 감별할 수 있게 해주었다. 프로젝트가 진행하면서 우리는 200 회가 넘는 플레이 테스트를 하였고, 이 중 절반은 중복해서 테스트를 한 플레이어들에 의한 것이었다. 이 세션들을 통해 얻은 피드백은 다시 카발 과정에 입력되어서, 가능성이 없는 디자인을 제거하고 가능성이 있는 디자인을 더욱 발전시키게 되었다.

 

프 로젝트의 중반기에는 일단 주요 요소들이 제대로 배치되어 있었고 게임을 거의 끊김없이 진행할 수 있는 정도였으므로, 이제는 사실상 세밀하게 튜닝을 하는 작업이 남아 있었다. 이를 위해 우리는 게임에 기본적인 도구 하나를 추가해서 자동적으로 플레이어의 위치, 건강, 무기, 시간, 그리고 세이브, 사망, 부상, 퍼즐해결, 몬스터 전투 등의 주요 활동을 기록하였다. 몇 번의 세션을 통해 얻은 결과를 그래프로 만들어서 문제가 있는 구역을 찾아내었다. 문제가 있는 구역이란, 플레이어가 아무런 조우 없이 오랫동안 있는 구역(지루하다), hp 가 너무 오랫동안 높은 구역(너무 쉽다), hp 가 너무 오랫동안 낮은 구역(너무 어렵다) 등이었고, 이를 표시함으로 우리는 플레이어들이 일반적으로 어디쯤에서 죽을지, 어디쯤에 아이템을 배치할 지에 대해 많은 아이디어를 얻을 수 있었다. 

 

플레이어들이 자신들도 피해가야 할 다른 캐릭터들의 실수를 보게 함으로써 효과적으로 퍼즐에 대해 설명하고 긴장감과 재미를 제공할 수 있다. 

 

디 버그를 할 때 도움이 되었던 또 다른 요소는 각각 다른 버전의 엔진 사이에 호환이 되는 세이브 게임 포맷이었다. 게임은 주기적으로 자동 세이브를 하기 때문에, 만일 플레이 테스터의 게임이 정지해도, 그 버그가 일어난 시점에서 그리 멀지 않은 세이브 파일을 보유하고 있었다. 이 파일들은 테스트 당시의 코드 베이스가 지금보다 몇 버전 아래 것이라도 작동할 수 있었으므로, 버그를 재현하고 고치는 작업으로 어려움을 겪는 경우는 거의 없었다. 우리는 이 세이브 게임 포맷을 통해 게임을 망가뜨리지 않고서도 임의대로 데이터를 추가하거나 삭제하고, 코드를 추가하거나 삭제(우리는 기능 포인터도 지원했었다)할 수 있었다. 이 때문에 게임을 출시한 후에도 플레이어들이 땀 흘려 얻은 세이브 게임들을 건드리지 않는 주요 변경 사항을 실행할 수 있었다. 

 

선행을 해도 욕먹는 수가 있다

 

카 발 과정이 실행되기 전까지는 Half-Life 에 신기술을 마구 추가하고 있었다. 그 당시의 생각은 ‘만들면 쓰겠지’였다. 즉, 새로운 기술이 나오면, 무조건 창조적인 기획자들이 그것을 적용시킬 것이라는 생각이었다. ‘빔’ 효과 기술을 예로 들 수 있다. 이것은 기본적으로 말해서, 번개, 레이저, 수상한 에너지 등, 두 점 사이의 구불거리는 빛을 만들 때 쓰는 것이다. 게임 엔진에 이것을 추가하고, 파라메터를 공개하고, 이메일로 쓰는 방법을 설명했다. 그 결과... 아무도 쓰지 않았다. 두 달 후에 단 한 명의 레벨 디자이너가 맵에 빔 효과를 설치했다. 엔지니어 팀은 경악했다.

 

카발 과정 중에 우리는 레벨 디자이너들이 이 기능에 대해 알고 있었지만, 어디에 써야할 지에 대해 감을 잡지 못한다는 것을 알게 되었다. 파라메터는 매우 난해했고, 조합을 잘못하면 엄청나게 추한 효과만 일어나는 것이었다. 적용할 수 있는 적당한 텍스쳐도 없었고, 설치하는 법도 명확하지 못했다. 그 뒤로 기술 그 자체는 단지 작업과 적용, 훈련, 추적검사를 통해 게임에 유용한 기술을 만들어 내는 일의  지극히 일부라는 사실을 깨닫게 되었다. 코드를 작성하는 것 자체는 중요성의 비중이 절반도 안 된다. 

 

안 맞는 사람도 있다

 

솔 직하게 말하자면, 우리가 카발에서 실행한 집단 활동이 처음부터 모든 사람에게 어울리는 것은 아니다. 강한 개성의 소유자, 언어전달  능력이 부족한 사람, 집단 안에서 창조하는 것을 싫어하는 사람 등을 강제로 참여시킬 수는 없다. 우리는 게임 디자인 경험보다는 집단적 디자인 경험이 많은 사람들을 중심으로 집단을 만들었다. 그래도 결과적으로는 거의 모든 사람들이 한 개 이상의 카발에 속해 있었고, 카발 프로세스를 도입하면서 익숙해지고 성공을 거두게 되자 꺼려하는 사람들도 끌어들이는 것이 쉬워졌다. Team Fortress 2 와 같은 현재 프로젝트에서도 카발은 12명 이상으로 이루어져있고, 8명 이하는 드물다. 회의는 더 짧아졌고 아이디어의 분산도 더 빨리 이루어지지만, 처음부터 이렇게 큰 집단을 만들라고 권하고 싶진 않다. 

 

Half-Life 의 거의 모든 요소는 카발에 의해 만들어졌다. 처음에는 좀 과도하다고 생각했으나, 디자인에 관여된 모든 사람들의 장점을 끌어내는데 있어서 중요한 역할을 했다. 모두가 전체로서 디자인에 관여하게 되면, 각 개인이 가지고 있는 ‘조각’들의 집합이 아니라, ‘우리’의 전체 게임 디자인이라고 인식하게 된다.

 

‘우리의 것’이라는 생각은 모든 분야에 확산되었다. 게임의 거의 모든 레벨은 적어도 세 명의 다른 레벨 디자이너들에 의해 편집되었고, 개발 도중 몇몇의 경우에는 모두의 손길이 흔적을 남기기도 했다. 비록 레벨 디자이너들은 모두 우수했으나, 각기 다른 측면들을 선호한다는 사실을 알게 되었다. 스케줄 때문에 때로는 서로 역할을 바꾸어 가면서, 한 명은 지형을, 한 명은 몬스터와 AI를 맡게 되고, 텍스쳐 담당이 와서 텍스쳐를 입히면 다른 한 명이 조명을 완성시키곤 했다. 사람마다 작업의 완료 시기가 달라지게 되는 프로젝트 후반기에는 이런 협조가 매우 중요하였다. 플레이 테스트 세션을 통해 수정사항을 알게 되었다면, 모든 레벨 디자이너들은 특정 담당자를 찾지 않아도 게임을 변경할 수 있었다.

 

전통적인 전투 액션을 도전적인 환경에 배치함으로써 긴장과 서스펜스의 느낌을 강조할 수 있었다.

 

이 아이디어는 또한 코드, 텍스쳐, 모델, 애니메이션, 음향 등에도 확산되었다. 모두 하나의 소스 항목 하에 있었기에, 누구든지 소스를 찾아 필요한 변경작업을 할 수 있었다. 약간의 자제력만 있다면, 이것은 생각보다 그다지 혼란스럽지 않다. 게다가 누가 어떤 변경을 하였는지에 대한 기록을 매일 얻을 수 있는 장점도 있었다. 우리는 이 정보를 다시 플레이 테스트 쪽으로 적용시켜서 변경된 부분만 확인하고, 변경사항들을 모니터링하고 특정 요소들의 안전성과 호환성을 예측하여 프로젝트 자체의 스케줄 관리를 도왔다. 또한 이를 통해 최소한의 충돌로 체계적인 기능을 추가할 수 있었다. 기술적인 문제가 해결되면, 엔지니어는 모든 미술자료를 이용해 새로운 파일(모델, 텍스쳐, 레벨 등)을 작성할 수 있었다. 

 

작업자들이 생산방식을 제어한다

 

집 단 활동을 강조하긴 했지만, Half-Life 의 주요 기능들은 상당수가 개인적인 순발력으로 가능할 수 있었다. 모든 사람들은 게임이 어떠해야할 지에 대해 각자 다른 의견을 갖고 있었거나, 어떤 기능들이 포함되어야 하는지에 대해 의견이 분분했다. 카발 과정을 통해 이런 아이디어들을 들을 수 있었고, 누구나 디자인에 대한 의견을 낼 수 있었으므로, 사람들은 자신의 주장을 최대한 제시했다. 만일 의견을 제시한 사람 이외의 다른 작업자가 필요하다거나, 게임의 다른 분야에도 영향을 주는 의견이 나왔다면, 새로운 카발을 조직해서 다른 주요 분야 사람들에게 그 의견의 가치를 설득해야만 했다. 프로젝트의 초창기에는 모두가 작업량을 과소평가했기에 쉬운 일이었지만, 중반기와 후반기에 이르면서 무리한 의견을 납득시키기 어려워졌다. 또한 효율적인 개발 작업량을 통해 가능한, 플레이어에게 가장 큰 영향을 주는 디자인을 제외한 나머지를 걸러내는데도 기여했다.

 

플레이어를 군인 대 외계인의 전투에 집어넣음으로써 활동적인 환경의 실감을 더했고, Valve가 플레이어에게 최소한의 위협을 주면서도 전투 AI를 선보일 수 있게 해주었다.

 

지 속적인 플레이 테스트와 피드백, 리뷰와 편집을 통해 카발 프로세스는, 아무리 특정 기획자가 감정적으로 애착을 갖는 부분일지라도 수준 이하인 게임 요소들을 제거하는데 있어서도 중요한 역할을 했다. 이는 카발 과정에서 가장 논쟁거리가 되는 부분 중에 하나였지만, 가장 중요한 기능일지도 모른다. 그 자체의 특성 때문에 카발은 다른 권위체제 조직들에서 만연한 개인적인 갈등을 피할 수 있었다. 플레이 테스트라는 다소 객관적인 방식을 통해 모든 문제들을 확인하였고, 해결방식도 전체적인 동의나 동료들을 통해 제시되었기에, 반항할만한 권위주의적 대상이 존재하지 않았다.

 

일일 단위로 따져본다면, 200 페이지짜리 기획문서에 있는 정보는 어느정도 애매할 수 있다. 각 분야마다 1,001개씩 새로 생기는 특수한 세부 문의사항을 답해주지는 못하며, 일상적인 개발 과정에 있어서의 수많은 창조적인 세부사항도 없다. 기획문서란 결국 작업을 진행하기 위한 틀이자 여러 사람들의 작업을 매끄럽게 조합하는 가능성을 높이기 위한 수단이다. 문서화되지 않은 거시적인 아이디어들 - 게임의 분위기에 필수적이지만, 문서화 하기에는 애매한 생각들 - 을 알리는데 기여한 것이 카발 프로세스다. 또한 이를 통해 개인의 장점을 최대화하고 약점을 최소화하며 각 기여자마다 게임에 최대한의 영향력을 가질 수 있는 틀을 제공한다. Half-Life 의 경우, 기본 틀 안에서 10명 이상의 인원의 직접적인 작업이 닿지 않는 분야란 거의 없었다. 

 

고도의 권위체계 조직이 효율적이려면, 작업을 하는 사람들 이외에도 모든 것을 파악하는 한 명의 지도자가 있어야 하며, 그에게 복종할 것을 인정하면서도 디자인을 고안할 실력이 있는 사람들이 필요하다. 대부분의 인기 게임 타이틀의 복잡성을 고려한다면, 이러한 방식은  실용적이지 못하다. 실력이 있다면, 왜 남의 추종자가 되고 싶어하겠는가? 반면에, 조직화되지 않은 집단은 정보와 조정의 부재라는 문제가 있다. 모두가 자기 일만 하고 있다면, 결과물이 하나로 통합될 확률은 0에 가깝다.

 

Valve 는 카발 과정의 결과를 매우 흡족하게 생각한다. 물론, 우리도 과도한 야심, 때로는 비현실적인 기대감 때문에 문제를 겪는다. 하지만 이러한 문제들은 결국 여과되기 마련이며, 카발 과정은 최상의 타협안을 만드는데 매우 유용하다. 초반에 엄청난 실패를 한 것에 비해, 최종적인 게임의 완성도가 기대이상이라는 점에서 한 때 카발 과정을 꺼려하던 사람도 이제는 카발의 강력한 지지자가 되었다. 

 

게임 주인공의 초안이다. 이제는 애정을 갖고 모두 ‘우주 바이커 이반’이라 부른다.

 

성공적인 카발을 위한 조언

 

• 모든 기능 분야(프로그래밍, 아트 등)의 전문가를 하나씩 포함하라. 회의 참석자들 중 아무도 이해 못하는 분야에 대해 서로 논쟁하는 것은 모두의 시간 낭비다. 
• 모 든 것을 기록하라. 브레인스토밍은 회의 도중에는 좋지만, 기록되지 않았다면 며칠 안에 당신의 놀라운 의견은 잊혀진다. 게임의 가장 합리적인 부분들에 대해 최대한 설명하고, 사람들이 해야 할 일에 대해 해답을 주는 문서를 제작하는 것을 목표로 하라. 
• 모 든 아이디어가 다 훌륭한 것은 아니다. 당신의 아이디어도 여기 포함된다. 모두가 ‘멍청하다’고 여기는 당신만의 ‘훌륭한’ 아이디어가 있다면, 더 이상 밀고 나가지 마라. 다른 사람들도 멍청한 의견을 낼 때가 있다. 당신이 억지를 부린다면, 그들도 억지를 부릴 것이고, 서로 교착상태가 될 뿐이다. 어쩌면 훌륭한 의견이 단지 잘못된 분야에 배치된 것일 수도 있다. 나중에 언급하면 된다. 어차피 게임 플레이 시간이 30시간 이상인 게임을 제작하고 있을 것이다. 정말 버리기 싫은 아이디어라면 게임의 어딘가에는 적용될 수 있을 것이다. 어쩌면 다른 사람들이 다음 달에는 받아들일 지도 모르지 않는가. 
• 이미 작동하거나, 아니면 플레이 테스트 기간 이전에 완성할 수 있는 기술적인 요소들에 대해서만 계획을 짜라. 출시하기 직전에야 준비될 수 있는 기술에 의존하지 마라. 물론 쿨한 기술에 대해 꿈꾸는 것은 좋지만, 완성될 지도 모르고, 출시할 수 없는 수준일 수도 있는 요소들을 중심으로 게임을 기획하는 것은 무의미하다. 실현되지 않는다면 최대한 빨리 없애버려라. 
• 모든 1회용 기술적 요소들을 피하라. 엔지니어링이 요구되는 모든 작업은 게임에서 적어도 두 번 이상 사용되어야 한다. 엔지니어들은 정말 느리다. 그들의 작업은 본래 수개월이 걸린다. 그들이 만들어낸 기술이 1회용으로 사용될 것이라면, 그건 제한적인 자원을 낭비한 셈이다. 엔지니어들의 목표는 언제나, 어디서나 사용될 수 있는 도구와 기능의 제작이어야 한다. 그들이 한 달을 소비해 모두가 생산적일 수 있는 도구를 만든다면, 성공적인 일이다. 1주일을 소비해서 게임 플레이의 10초에 영향을 주었다면, 그것은 낭비다.
  
  

켄 은 밸브사의 중견 개발자로 15년간 다양한 분야의 프로젝트를 경험했고, 최근에는 하프라이프의 애니메이션과 인공지능 파트를 담당했다. 이전의 프로젝트는 인공위성 네트워킹, 암호화, 3D 인공 보철 디자인 툴, 3D 지형 재구성, 폐쇄회로 에뮬레이터에 이르기까지 다양하다. 켄은 에버그린 시립 대학에서 순수미술 학위를 따기 위해서 공부하다가 때려치웠으며 지루한 미분 방정식 수업을 듣는것보다 창조적으로 생각하는 것이 훨씬 더 훌륭하다고 생각하고 있다. 여기 이메일로 kenb@valvesoftware.com 켄과 연락할 수 있다.

 

관련 정보 #

gitiss - 커밸(Cabal)을 계획하다
동우리의 블로그 - Cabal Approach
gamedevblog - Notes on Half-Life 2

 

 

=================================

=================================

=================================