포스트모템: <킹덤 오브 아말러: 레코닝>

작성자: 마이크 프리들리(Mike Fridley)
작성일: 2013년 7월 30일

[<킹덤 오브 아말러: 레코닝(Kingdoms of Amalur: Reckoning)>은 빅 휴즈 게임스(Big Huge Games, 이하 BHG)와 모회사인 38 스튜디오(38 Studios)의 유일한 합작품이다. 불안정한 초기 매출과 실수, 불운의 연속으로 인해 게임 출시 3개월 만인 2012년 5월 두 회사 모두 부도로 문을 닫게 됨으로써 의도치 않게 게임 산업에 교훈을 남기게 되었다. 예산의 일부를 로드 아일랜드 주에서 대출받아 충당한<킹덤 오브 아말러: 레코닝>은 외부 자금의 도움으로 제작된 트리플 A급 게임의 아주 독특한 사례이기도 하다.

이 글은 가마수트라의 자매지인 <게임 디벨로퍼 매거진(Game Developer Magazine)> 1 2012년 4월판에 실렸던 포스트모템으로, 전(前) BHG 핵심 프로듀서 마이크 프리들리가 불운한 출시로 이어진 <킹덤 오브 아말러: 레코닝> 제작 과정에서의 잘된 점과 잘못된 점들에 대해 고찰했다.]

5년 전, BHG는 제작하는 게임의 유형을 완전히 바꾸기로 했다. 우리는 실시간 전략 게임 대신 롤플레잉 게임을 만드는 것으로 방침을 바꾸었고, PC용 게임뿐만 아니라 콘솔용 게임도 만들기 시작했다. 이런 변화를 시도한 이유가 몇 가지 있었다. 수익도 이유 중 하나였지만 그 때문만은 아니었다. 우리는 말도 안 되는 일을 하고 싶었다. 우리는 오픈 월드 RPG 대작을 만들고 싶었는데, MMO 게임을 제외하면 우리가 생각해낼 수 있는 가장 미친 프로젝트였다. 하지만 우리 모두가 RPG 게임의 열렬한 팬이었기에 RPG 장르를 잘 해낼 수 있으리라고 생각했다. 그래서 우리는 스튜디오를 RPG 게임 제작 스튜디오로 전환하는 작업에 착수했다.

처음에 우리의 롤플레잉 게임 제작 프로젝트는 "크루서블(Crucible)"이라는 이름이 붙었고 THQ가 퍼블리시 하려고 했었다. 제작 과정은 잘 진행되었고, THQ는 우리의 진행 사항에 아주 만족해 우리 스튜디오를 완전히 사들였다. 그렇게 우리 스튜디오는 THQ의 내부 스튜디오가 되었다. 그 즈음 우리는 게임의 핵심 기능을 변경하면서 프로젝트의 이름도 "어센던트(Ascendant)"로 바꾸었다. 우리는 THQ의 예산이 고갈되기 시작한 바로 직전까지의 짧은 기간 동안 THQ 스튜디오 네트워크의 일부였다. 거대하고 흥미진진하고 RPG 장르에서 증명되지 않은 우리의 스튜디오는 THQ가 매각을 시도한 주대상이었다.

말 그대로 "폐쇄" 타이머가 겨우 며칠을 남긴 상황에서, THQ는 우리 스튜디오를 커트 실링(Curt Schilling)의 38 스튜디오에 매각했다. 이곳에서는 R. A. 살바토레(R. A. Salvatore)가 "세계의 창조자"이다. 살바토레의 뛰어난 재능을 이용하기 위해 우리의 게임의 세계와 일부 특성들을 바꿀 필요가 있다것이 곧 분명해졌다. . 우리는 프로젝트의 이름을 "머큐리(Mercury)"로 바꾸었고, 나중에 게임이 최종 출시될 때에는 <킹덤 오브 아말러: 레코닝>이 되었다.

게임이 출시될 때까지 5년 동안 우리 스튜디오는 두 번 사고 팔렸고 프로젝트의 이름과 핵심 기능들을 세 번 바꾸었다. 길고 이상한 여정이었다는 것은 말할 필요도 없다. 이 글은 개발 초기 2년의 잘못된 시작보다는 <레코닝> 을 개발했던 2년 반의 기간에 한해 적었다.

잘된 점

1. 전투: RPG 게임이라고 해서 전투가 지루할 필요는 없다.
제작 준비 단계를 벗어난 직후, 우리는 우리 게임을 오랫동안 자세히 들여다 보면서, 어떤 점에서 경쟁 업체보다 더 나아질 수 있는지를 찾아보았다. 우리는 오픈 월드 RPG 게임 디자인이 스토리, 캐릭터 레벨업, 탐험, 전투라는 네 가지 기본 요소들로 나누어져 있다는 것을 알게 되었다. 또, 스토리와 레벨업, 탐험의 측면에서 성공적인 게임들을 발견하기는 쉽지만, 이 세 가지 요소들에 대한 플레이어의 기대를 만족시키면서도 전투를 잘 구현해낸 확실한 게임은 아직 없다는 사실을 알게 되었다. 그래서 우리는 전투에 올인하기로 결정하고 인력관리 계획을 바꾸어 전투가 재미있는 오픈 월드 RPG 게임을 만드는 일에 착수했다.

전투에만 집중해서<레코닝>을 만든 것은 아니지만, 전투에 대한 우리의 취향이 반영된 것은 분명하다. 던전 통로의 최소 사이즈에서부터 한 스크린에 한번에 수용할 수 있는 적의 수에 이르기까지, 모든 것이 전투가 멋져야 한다는 가이드라인에 따라 제작되었다.

개발과정에서 잘된 점들 중, 사용성 테스트와 기능적인 팀 배치 두 가지는 멋진 전투에 집중해 개발한 결과로 나타난 것이다.

2. 초기에 그리고 자주 진행된 사용성 테스트

우리는 제작 초기 단계부터 실제 플레이어들의 피드백을 꼭 최우선으로 삼기로 했다. 제작 중인 빌드를 대중에게 공개하고 조사할 수는 없었기 때문에, 차선책으로 개발 과정 초기에 EA의 사용성 연구실을 이용했다. EA의 연구실에서는 일반 대중 가운데서 테스터를 모집해 우리가 개발하고 있던 시스템이나 컨텐츠를 집중적으로 테스트하는 데 이용할 수 있었다. 예를 들어 만약 우리가 게임의 시스템을 제작하는 첫 단계를 통과했다면, 반나절 만에 12명 정도의 플레이어들을 모집해 인터페이스가 조종하기에 용이한지 또는 대장장이 기술이 보상으로 느껴지는지에 대한 피드백을 받을 수 있었다.

EA의 연구실에서 최종 세션의 동영상을 녹화했기 때문에, 우리는 플레이어가 게임의 그 부분에 대해 어떻게 생각하는지도 우리의 팀에게 알려줄 수 있었다. 어떤 일련의 공격이 나쁘게 느껴지거나, 일반적인 플레이어에게 퀘스트가 말이 되지 않는다고 느껴진다면, 그 부분들을 작업하는 팀은 고객의 직접적인 의견에 귀를 기울여야 해당부분을 반영해야 했다. 플레이어가 직접 보낸 피드백은 우리가 전투 시스템을 조절하는데 실제로 도움을 주었고, 결국에는 전체 게임에 도움이 되었다.

3. 기능별 팀: 서로 협력해 성과를 올리다

우리의 개발 철학의 일환으로 우리는 부서를 초월하는(cross-departmental) 팀 형태로 긴밀하게 협업하고 있다. 이렇게 하고 있는 스튜디오들이 많이 있지만, BHG에서는 이 프로젝트를 시작하기 전까지는 기능별 팀 운영을 실제로 추진하지 않았다.

스튜디오의 물리적인 구조 때문에 하나의 사무실에 3명 이상의 인원을 두지 못한 팀도 있고, 변화가 강요되기 전까지는 절대로 바뀌지 않는 구태의연한 생각을 하고 있는 팀도 있었다. 결국 우리는 말 그대로 벽을 허물고 사무실 구석구석에 비교적 큰 기능별 팀들을 배치하기 시작했다. 팀이 배치된 장소를 우리는 "피트(pits)"라고 불렀는데, 예를 들어 전투 피트에는 애니메이터와 디자이너들이 나란히 앉아있는 식이었다.

이렇게 하면, 공격 체인을 작업하는 애니메이터는 게임 내에서 이를 구현하는 작업을 하고 있는 디자이너와 가까운 곳에 앉아 있게 된다. 그래서 서로의 작업을 쉽게 관찰하고 의견이나 비판을 빨리 전달할 수 있었다.

하지만 상호 협력적인 기능별 팀 배치는 피드백 과정의 속도를 높이는 것보다는 상호 협력을 강제하는 쪽에 가깝다. 협력하는 일을 게을리 하거나 자신의 사무실 밖에서 일어나는 일에 대해 잘 알지 못하는 개발자들이 많은데, 직접적으로 함께 일하는 사람들이 항상 곁에 있으면 그들과 유대관계가 형성되기 마련이다. 많은 기능별 팀들이 아주 친밀하게 엮어지고 근무가 끝나면 함께 어울림으로써 실제로 하나의 팀처럼 작동했다. 이것은 작업에 관한 커뮤니케이션이 더 많이 이루어지고 개선되는 결과로 이어졌으며, 실제로 최종 결과물의 품질을 향상시켰다.

4. 스크럼(Scrum) 개발 방법론

<킹덤 오브 아말러: 레코닝>가 제작 준비에 들어가기 전에, 스크럼은 게임 개발 업계에서 탄력을 얻기 시작하고 있었다. 나는 스크럼이 오늘날 게임을 개발하는 데 사용해야 할 유일한 방법이라고 생각하지는 않지만, <킹덤 오브 아말러: 레코닝> 전체 개발 과정에 스크럼을 사용하고 난 후 이 방법론의 확고한 신봉자가 되었다.

이 글에서는 애자일(Agile) 개발 프로세스에 대해 자세히 다루지 않겠지만, BHG에서 스크럼이 성공하게 된 기본 요소는 각 개발자가 자신의 작업을 평가할 수 있다는 점이었다.

과거는 흘러갔다. 프로듀서나 팀장들이 앞으로 3년간 하게 될 모든 일을 모아서 거대한 폭포수 모델로 만들어낸다는 건 터무니없는 소리다. 게임 개발 업계에서는 1년 후에 자기 팀이 무슨 일을 하게 될지도 예측할 수가 없다. 날짜를 박아 주요 마일스톤을 세워놓을 수는 있겠지만, 그 사이를 세세하게 채우는 일은 헛수고다.

컨텐츠 개발에서의 시간 측정 기준에 대해 기본적인 이해가 있었기에, 우리는 옛날식대로 폭포수 모델을 따르는 스케쥴링도 가능했다. 그러나 폭포수 모델은 할당된 시간 안에 정해진 범위의 작업을 완성할 수 있게 팀이 페이스를 유지하게 하는 데에만 사용되었다. 예를 들어 우리는 배경 아티스트 중 한 사람에게 특정 구역의 기초적인 요소들을 3개월 안에 제작하고 다음 구역 제작으로 넘어가야 한다고 말할 수는 있었지만, 그보다 상세한 것에 대해서는 어떤 계획도 세우지 않았다. 그 구역의 모든 나무와 바위, 수풀 등을 따지지 않았다. 한편 그 기초 요소들의 집합에 해당하는 것이 무엇인지나, 그게 얼마나 걸릴지에 대한 실제 계획은 스프린트 계획 회의에서 아티스트가 자신의 업무와 걸릴 시간을 생각해 말하는데 따랐다.

스크럼은 계획을 잘 세울 수 있게 해주었을 뿐 아니라, 전체 팀에게 게임에 대한 훨씬 많은 소유권과 안목을 주었다. 새로운 일이 나오면(게임 개발할 때 항상 일어나는 일이다) 팀은 지금 하고 있는 작업을 완성하지 않으면 그걸 못하게 되리라는 것을 알았다. 그래서 개발 막바지의 거대한 죽음의 행진 대신 전체 개발기간 내내 작은 마감(과 이에 따른 야근)들이 많이 생겼다. 각 팀은 원래 구현하고자 했던 것이 제거되거나 형편없게 완성되는 것을 보느니 차라리 약간의 초과 근무를 하는 쪽을 택했다. 개발이 끝날 무렵에도 여전히 야근이 약간은 있었으므로 스크럼이 완전 특효약은 아니었지만, 도움은 확실히 되었다.

스크럼은 게임 개발에서 오랫동안 결여되어 있던 일상적인 책임을 가능하게 해준다. 개발자는 변화가 생기면 24시간 안에 이를 이해하게 된다. 전통적인 개발 방법들은 이런 작은 시간 손실을 몇 개월 동안 알아차리지 못하기 때문에 개발이 끝날 무렵에 많은 초과근무를 하게 되거나 전체 시스템이나 많은 컨텐츠를 제거해야 한다. 또, 전체 팀이 백로그에 항목을 추가할 수 있게 한 것도 우리에게는 큰 성과였다.

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