포스트모템: 아발란치 스튜디오의 <레니게이드 옵스>

작성자: 악셀 린드버그(Axel Lindberg)
작성일: 2012년 6월 8일

모든 일은 아발란치 스튜디오(Avalanche Studios)가 <저스트 코스 2(Just Cause 2)>의 베타 버전을 테스트하는 중에 시작되었다. QA 부서로부터 버그 신고가 계속 쏟아져 들어오고 있었다. 번쩍이는 아이디어나 기막힌 기능을 생각해 낼 시간이 결코 아니었다. 사실, 게임 개발 단계에서 “베타”의 목적은 열정적이고 창조적인 마법사들을 잘 훈련 받은 버그 수리 군인들로 바꿔놓는 것이다.

베타 단계에서 하는 일은 게임을 더 낫게 만들겠다는 꿈을 키우는 대신 게임에 만들지 못한 부분을 그만 받아들이는 것이다. 베타는 모든 게임 개발자들이 겪어야 하는 필수적인 전투인 셈이다. 베타 단계를 거치지 않은 게임은 이상하게 돌아가고, 작동을 멈추고, 대개는 플레이 할 수 없게 될 것이기 때문이다.

이 전투 중에, 나는 유독 성가신 버그를 고치고 있다가 갑자기 회의에 불려가게 되었다... “여러분, 새 프로젝트를 시작하면 어떨까요? 세가(Sega)가 우리 엔진을 사용하고 오리지널 IP 가 있는 XBLA/PSN/STEAM 게임의 컨셉 피치를 들어보고 싶어해요. 어떻게 생각해요?”

우리의 대답은 “세상에나! 신나게 일해봅시다!”쯤 되었다. 짜릿한 순간이었다.

왜 레니게이드 옵스 Renegade Ops 인가?

게임 컨셉을 정하기 전에 우리가 제일 먼저 한 일은 현재 엑스박스 라이브 아케이드(Xbox Live Arcade)와 플레이스테이션 네트워크(PlayStation Network)에 어떤 게임들이 출시되어 있는지를 살펴 보는 것이었다.

이 때는 체어엔터테인먼트(Chair Entertainment)에서 <섀도우 콤플렉스(Shadow Complex)>라는 게임을 출시한 무렵이었다. 우리는 그 게임을 무척 좋아했다. NES 와 SNES 콘솔용으로 나왔던 닌텐도(Nintendo)의 고전 게임 <메트로이드(Metroid)>를 에픽(Epic)의 언리얼 엔진(Unreal Engine)을 사용해서 개조했는데, 현대적인 느낌을 굉장히 잘 입혔다.

새로운 IP 를 사용했고, 많은 메카닉(mechanic)이 오늘날의 게이머들의 기대에 부응하도록 업데이트되고 심화되었으나, 80 년대 <메트로이드>의 인기에 기여했던 핵심 철학과 컨셉은 완전히 보존되어 있었다. 그 게임이 불러일으킨 향수가 우리를 열광케 했다.

우리가 만들 게임도 같은 아이디어 선 상에 있었으면 했다. 게임 황금 시대의 컨셉에 현대적 감각을 덧입혀 2011 년으로 끌어 오는 것이다.

어떤 게임에서 영감을 받을 수 있을지에 대해 많이 토론했다. 대규모 예산을 들인 게임들에 비하면 규모가 매우 작을 것이었으므로, 아발란치 스튜디오의 강점과 경험에 부합하는 게임에서 영감을 끌어와야 했다. 액션이 매우 뛰어나고, 파괴감이 크며, 탈 것들이 혼재하고, 장난스러운 마초적 태도가 깃들어 있어야 했다.

머지 않아 주로 영감을 얻을 소스들을 골라낼 수 있었다. <Jackal(NEX 1988)>, <Desert Strike(Genesis/Mega Drive 1992)>, 오래 전 토요일 아침에 보곤 했던 만화 <지아이 조(GI Joe)>가 조건을 완벽하게 만족시켰다. 이로서 프레임워크가 명확하게 정해졌고, 팀 내에서 아주 초기단계부터 비전을 통일하는데 도움이 되었다.

포스트모템

프로젝트가 시작되기 전에 세웠던 목표들은 상당히 명확했다. 달성하기에는 어려운 점이 있었을지언정 말이다.

  ● 대규모 예산이 들어간 게임처럼 보이고, 들리고, 느껴져야 하지만 용량은 작아야 한다.
  ● 아발란치 엔진 Avalanche Engine)에 온라인 기술을 위한 토대(멀티플레이어)를 마련해야 한다.
  ● 메타크리틱(Metacritic) 리뷰 점수가 85%를 넘어야 한다.

Renegade Ops 리뷰들을 읽어보면, 우리가 첫 번째 목표는 달성한 것 같다는. Tom Chick 은 1UP 의 게임 리뷰에서 다음과 같이 썼다 “…<레니게이드 옵스>는 <저스트 코스 2>에서의 화려한 액션 영화같은 느낌을 잘 살렸다. 그러나 탑뷰 방식의 트윈스틱 슈팅 게임(twin stick shooter)의 한계에 갇혀 있다.”

두 번째 목표 또한 달성했다. 현재 아발란치 엔진(에 멀티플레이어가 존재한다. 그로 인해서 우리가 이후 프로젝트에서 무엇을 할 수 있게 되었는지에 대해서 정말 말하고 싶지만, 내가 지금 그 정보를 공유하면 앞으로 어떤 정보도 공유할 수 없게 될 것이기 때문에 슬프지만 말할 수 없다.

세 번째 목표와 관련해서 <레니게이드 옵스>는 메타크리틱에서 81 점을 받았다. 나는 그 점수에 만족하고, 객관적으로 볼 때 합당한 점수라고 생각한다. 그러나 우리의 목표가 85 점이었기 때문에 목표를 달성하지 못한 것은 맞다.

이렇게 얼핏 보기에는 괜찮아 보인다. 이제 <레니게이드 옵스> 개발 과정이 어땠는지 좀 더 깊이 파고 들어가보자. 무엇이 잘 되었는가? 무엇이 잘 안 됐는가? 중간 결과물과 베타 버전을 만들어내면서 우리의 생활은 어땠는가? 계속 읽어주기 바란다.

잘된 점

프로젝트는 관련 프로세스와 개개인 모두에게 발전의 기회이다. 이 개발 후기는 그 기회를 다른 사람들과 공유하고자 작성되었다. 이 섹션이 그 목적에 맞게 흥미롭거나 유용한 정보를 제공하기를 바란다. 우리의 접근법에서 성공적이었다고 생각하는 측면에 대해서 먼저 이야기하는 것으로 시작하겠다.

1. 빌드 중심의 개발

<레니게이드 옵스>의 가장 중요한 목표는 재미있는 게임이어야 한다는 것이었다. 이 점이 우리에게 최우선 순위가 되었고, 우리는 팀 내에서 “재미”에 대해 많은 의견을 나눴다. 우리는 “재미(fun)”가 자연스럽게 모든 결정의 주요 요소가 되는 접근법을 찾고 싶었다. 이를 위한 가장 믿을만한 방법은 개발하는 동안 개발자들이 직접 게임을 아주 많이 플레이 해보고 “재미”를 감소시키는 요인들에 대해서 솔직하게 토론하는 것이다.

우리는 내부적으로 이러한 접근법을 “핵심 메카닉에 집중한 빌드 중심의 개발”이라고 불렀다. 이는 무엇보다 게임이 항상 플레이 가능한 상태로 유지돼야 함을 의미한다. 게임 플레이가 불가능하도록 만드는 충돌이나 비슷한 문제점들이 생기면 우리 팀은 즉시 하던 일을 모두 멈추고 그것을 고쳤다.

또 우리는 개발중인 게임의 최신 버전이 우리가 다음에 할 작업을 결정하는 요소가 되도록 했다. 보통 개발 목표를 기록한 서류에 주로 근거해 작업하는 것과는 다른 방식이었다. 게임을 플레이 해보고 나서 이렇게 말하는 식이었다: “좋아. 지금 운전감이나 슈팅감은 아주 좋아! 근데 슈팅용 지프에 질렸어. 더 크고, 재미있는 적이 필요해. 전투를 더 신나고 다채롭게 만들 수 있는지 보자고.”

그리고 나서 우리는 가능한 적의 유형 리스트가 들어있는 고수준(high-level) 설계문서를 확인했다. “탱크! 크고 무서운 걸로! 좋았어! 다음 주엔 이 탱크를 만들기 시작하자고!”

내 말을 오해하지는 마시라. 우리도 프로젝트에 대한 전체적인 기획이 있었다. 그 기획서에는 단계적으로 달성해야 할 목표들과 퍼블리셔에 대한 우리의 의무도 구체적으로 담겨 있었다. 다만 Sega 가 뭐라하지 않을 범위 내에서 우리의 본능을 따를 수 있는 여유가 최대한 많이 주어지는 방식으로 기획을 짜기는 했다 (Sega 덕분이다!). 예를 들어, 중간 목표를 이런 식으로 세웠다. “적 유형을 두 개 개발하여 적용한다.” 그러나, 우리가 고수준 설계 문서에 열거된 유형 가운데 어느 것을 선택할 것인지는 구체적으로 밝히지 않았다.

2. 최소한의 문서화

그러면 왜 이렇게 야단법석인가? 음, 게임 개발은 “재미있는”, “직관적인”, “집중하게 하는” 같은 애매한 단어들을 특징으로 하는 상품을 개발하는 일이 모두 그러하듯, 매우 복잡하고 약간 혼란스러운 과정이다. 문서화에 너무 의존할 때의 문제점은 게임 개발이 본래 엄청나게 반복적인 일이라는 점이다. 지면상에, 또는 이론상으로 설계가 아무리 잘되어 있다 할지라도 실제 게임에서 그대로 구현하기 위해서는 트라이얼 앤 에러(trial and error) 방식으로 다듬어 가는 과정이 필요하다. 게다가 게임 플레이 시스템 상의 사소한 변화 하나가 잠재적으로 (그리고 종종) 게임 전반에 큰 영향을 미친다.

이런 것들이 멋드러진 문서를 작성하는데 시간을 쏟아 부을 생각을 사라지게 하는 주요 요인들이다. 이러한 문서에 담긴 내용들은 대개 아이디어를 게임에 적용해 테스트하는 순간 낡은 정보가 되어버리기 때문이다. 그래서 실제로 게임을 만드는 시간보다 서류를 다시 작성하고 업데이트 하는데 더 많은 시간을 보낼 수도 있다.

우리는 문서화에 시간과 에너지를 가능한 적게 썼다. 대신에 대내외적으로 말로 커뮤니케이션하고 지식을 퍼트려 나갔다. 게임에 대한 고수준의 아이디어와 그 아이디어를 어떤 식으로 구현할 것인지만 문서화 되어 있으면, 우리는 기록을 멈추고 게임 개발에 집중했다.

내부적으로, 우리는 팀 내에 개방적이고, 자유롭고, 자발적인 커뮤니케이션을 통해 협동이 이루어지는 문화를 만들어 내려고 했다. 누군가가 어떤 내용을 이해하지 못했을 경우, 우리는 서버에서 업데이트가 되어 있을 수도 있고 되어 있지 않을 수도 있는 서류를 확인하기 보다는, 시간을 내서 그와 얼굴을 마주하고 이야기하는 것을 선호했다 (서류가 업데이트 되어 있다면, 그건 누군가가 매일 서류를 업데이트 하는데 많은 시간을 쓰고 있다는 것을 의미하기 때문에, 내가 보기에는 업데이트가 되어 있든, 되어있지 않든 손실이었다.)

외부적으로, 우리는 Sega 와 매우 건강하고, 개방적인 관계를 맺을 수 있었다. 일주일에 여러 번 퍼블리셔와 정기 회의를 했는데, 어떤 종류의 토론이든 가능한 자리였다. 더 긴급한 사안이 생길 때에는 이메일을 주고 받는 것보다 전화로 이야기하는 것을 선호했다.

이에 더해, 중간 결과물들을 기록할 때에는 시청각 녹음장치를 사용해서 해당 아이디어나 결정에 이르기까지 팀에서 겪었던 과정을 녹음했다. 실제 문서에는 감당할 수 있을 수준만큼만 세부사항을 포함시키고, 아주 세부적인 사항들은 말로 녹음했다. 녹음된 것은 항상 참고할 수 있었고 다른 이해 당사자들과 공유할 수도 있었다.

※ 자세한 내용은 첨부(PDF)화일을 참고하시기 바랍니다.