알라딘MGG와이드바


Game Developer Magazine 201002 포스트모템 - Borderland(보더랜드) 포스트모템

Borderland

Borderland 개발은 재미있었다. Gearbox 의 사명은 창조, 행복, 성공인데 Borderland 는 이 세 가지 항목을 모두 만족시켰다. 핵심 코어 기능은 2006년 첫 프로토타입에 구현되었다. 우리 스튜디오의 장점을 고려해 슈팅과 RPG 를 결합(Halo meets Diablo)한 장르를 개발하기로 했다. 전투에 대한 기대가 컸기 때문에 먼저 핵심 메커니즘으로 슈팅 부분을 제대로 만드는 것이 중요했다. 개발팀은 Halo PC 포팅 작업을 막 끝낸 참이었는데 여기에 영향을 받아서 Unreal 3 엔진에 Halo 의 데이타주도 개발 방식을 도입해서 고유한 IP 의 게임을 개발하기로 했다. 슈팅 게임에 RPG 의 아이템 루팅과 레벨링 기능을 추가하는 것은 여러 Gearbox 개발자들의 오랜 숙원이었다. 먼저 [http]Brothers in arms 게임을 개발한 뒤 RPG 와 슈팅을 결합할 방법을 찾기 위한 소규모 컨셉팀이 만들어졌다. 컨셉이야 쉽게 이해할 수 있었고, 핵심 기능도 빨리 구현했지만, 원래 악마는 사소한 곳이 숨어있는 법이다. 가장 큰 문제는 우리가 몰랐던 것을 아직까지 우리가 모르고 있었다는 점이다.

Art Style And "The change"

2005년 중반 프로젝트를 시작하면서 아이디어 구체화 작업을 시작했다. 처음에는 전쟁 중인 무리들이 우글거리는 외계 행성에서 명예와 돈을 찾아다니는 현상금 사냥꾼 이야기를 최신 서양식 SF 스토리로 엮어보려고 했다. 특히 아트 스타일에 대해서는 각자 자신만의 의견이 있었기 때문에 아트 레퍼런스 칠판에다가 원하는 스타일을 붙여놓거나 추천을 받도록 했다. 최종적으로는 [http]maschinen krieger 아트 스타일에 영향을 받은 복고 스타일이 우리 게임에 가장 적합하겠다고 결론을 내렸다.
개발팀은 계속해서 게임이 어떤 방향으로 나아가야 할지를 실험헀다. 아트팀은 사실적인 느낌을 추구했지만 그 외의 부분은 점점 창의적이고 비현실적인 컨셉으로 발전되어 갔다. 2008년말이 되어서 사실적인 아트 스타일과 비사실적인 게임 디자인 컨셉(분위기, 유머, 환상적인 캐릭터 스킬 시스템)이 너무 따로 논다는 것을 알게 되었다. 신나게 게임 시스템을 만드는 것까지는 좋았지만 이제는 아트 스타일을 거기에 맞춰야 했다.
이 때 그래픽 노블 스타일의 아트에 대해서도 논의하기 시작했고, 언젠가 게임에 써 먹으면 좋겠다고 생각했다. 마침 Borderland 의 게임플레이와 아트스타일이 따로 놀던 때라 "크리에이티브 독재자"인 [http]Brian Martel 이 Borderland 에 그래픽 노블 스타일을 도입해 보는 건 어떨지 시험해 보기로 했다. 이 결정은 엄청난 변화를 초래했고 내부적으로 "대격변([http]The Change)"이라고 불렸다. (역주 : 대격변(The Change)이 모든 팀원에게 받아들이기 쉬웠던 것은 아니었다. 기존 아트디렉터는 이런 결정에 너무 상처를 입어서 Gearbox 를 떠나 아예 다른 분야로 가 버렸다.)

Data Poins
퍼블리셔 : 2K Games
개발사 : [http]Gearbox Software
개발자 수 : 120
개발기간 : 1500 일
출시일 : 2009.10
Perforce 에 커밋한 횟수 : 120,000
코드 라인 수 : 250만 줄
버그 수정 횟수 : 35,000
소프트웨어 : Perforce, 3ds Max, MS Visual Studio, UnrealEd, 그외 여러 기업 내부 소프트웨어
개발기간 동안 생긴 아이 23 명
플랫폼 : Xbox 360, PlayStation 3, Windows

잘된 점

1. Code stability

프로그래밍팀은 리더쉽이 얼마나 중요한지를 잘 보여줬다. Technical director 인 Steven Jones 와 리드엔지니어 Jimmy Sieben 는 기능이 정의된대로 안정적으로 돌아갈 수 있도록 디자인팀과 잘 협동해서 일하게 해서 전체 팀이 코드를 신뢰할 수 있게 했다. 그리고 모든 팀원들이 코드 작업을 크게 기다리지 않고도 일할 수 있도록 했다.
새로 팀원이 들어왔을 때 가장 먼저 듣게 되는 얘기가 빌드 안정성이다. 우리 빌드는 다운되게 두지 않았다. 안정성을 유지하도록 많이 노력했고, 확 바꾸기 보다는 점진적으로 변경하는 것이 팀의 철학이었다. 또한 엔지니어 리드들은 계속해서 빌드 타임을 줄일 수 있도록 노력했다. 이전에 개발했던 [http]Brothers in arms 에서는 전체빌드에 4시간, 콘텐츠 개발자에게 업데이트 하는데 30분이 걸렸었기 때문에 이번 프로젝트에서는 리드 엔지니어들이 나서서 설정을 고치고 모든 부분이 잘 통합되도록 빌드할 수 있게 만드려고 노력했다. HP 와 손잡고 새로운 빌드 서버를 만들어 효율성을 높혔다. 덕분에 QA 은 매일 저녁 [http]Build Verification Tests 용 빌드버전을 받아서 다음날 아침 테스트와 함께 리포트를 제공할 수 있었다. Epic 과의 코드 머지를 굉장히 효율적으로 진행할 수 있었던 점도 큰 도움이 되었다.

2. Decision making at the edge

조직구조는 구현하는데 가장 최적화된 형태로 변경되었다. "대격변" 이후로 프로듀서는 모든 리드개발자들을 불러모아서 "게임은 정해진 일정에 출시되어야 한다. 그리고 어떤 결정을 내릴 때에는 그 결정을 구현할 사람이 같이 참여해야 한다" 라는 다짐을 받았다.
우리 개발팀에는 사람들이 자기가 현재 상황에 가장 효율적일 수 있는 역할을 맡는 문화가 있다. 예를 들어 이전 프로젝트에서 디렉터를 했던 사람이 다음 프로젝트에서는 UI 같은 개발진행 사항을 리딩할 수도 있다. 스스로를 조직화하는 문화는 Gearbox 스튜디오가 게임을 원하는 품질로 출시할 수 있게 하는 핵심이다. 상황에 맞는 조직 적응력은 다른 게임팀에서는 보기 힘든 문화이고, 우리는 이런 문화를 의도적으로 연습해왔다.
경험에 비추어보면 기능에 대한 결정을 내릴 때 개발에 참여하지 않았거나 소유권(ownership)이 없는 사람에게 개발을 맡기는 것이야말로 기능 구현을 실패하는 가장 확실한 방법이었다. 이런 상태에서의 결과물은 구현하는 사람이 직접 명세를 만들고, 이걸 왜 하는지 이해하는 사람이 만든 것보다 품질이 떨어진다. 얼핏 보기에는 당연해 보이지만, 우리가 이런 진실을 깨닫기까지 시간이 걸렸다. "대격변" 이전까지는 관료적인 구조에서 디자인이나 제품개발에 대한 결정이 내려졌다. 하지만 2009년에 게임을 출시하기로 결정한 뒤로는, 시간을 맞추기 위해서는 각 팀원들에게 결정권을 더 많이 위임하는 수 밖에 없다는 것을 알게 되었다.

3. Skill System

스킬 시스템이야 말로 디자인 결정권한을 위임하기로 한 이후에 가장 품질이 좋아진 경우다. 우리 회사의 시니어 디자인 리드(이자 베타랑 아티스트)가 "대격변" 시기에 새로 팀에 투입되어 스킬 시스템을 최대한 빨리 다시 디자인하는 작업을 맡게 되었다. 2009년 초 [http]Truth 팀(플레이어들이 무엇을 원하는지를 계속해서 알려주는 독립된 팀) 으로부터 플레이어들은 스킬이 어떻게 동작하고 어떤 점이 좋아지는지 이해하기 어렵다고 알려줬다. 플레이어 입장에서는 레벨이 어떤 역할을 하고, 스킬 포인트를 어떻게 써야할지, 스킬은 캐릭터 차별화와 어떻게 연결되어 있는지, 전투에서 스킬을 쓰는게 왜 좋은지가 분명하지 않았던 것이다. 이런 시스템은 특히 슈팅 게임 유저들 같이 전투 도중 스킬을 쓰기 위해 전투를 중단하고 싶지 않는 유저들에게는 접근하기 어려운 콘텐츠였다. 재미있는 스킬 시스템과 이 시스템이 캐릭터 레벨링과 연결되어 있는 부분이 게임 디자인의 핵심이었기 때문에 큰 문제인데다가, 너무 늦게 알게 되었다.
새로 투입된 디자이너에게는 필요한 결정을 내리고 게임플레이 개발자, 디자이너, UI 디자이너 리드에게 자신의 아이디어를 구현하도록 업무를 지시할 수 있는 권한이 주어졌다. 이것은 기존의 명령체계와는 별도로 팀원에게 권한이 주어진 첫 번째 예였다. 이 디자이너는 1주일 간 시스템을 개편했다. 기존 시스템에 익숙하고 데이타 주도 디자이너 툴을 잘 쓸 수 있는 디자이너와 함께 전체 스킬세트 중에서 절반을 새로 만들고 절반을 뜯어 고쳤다. 4명의 캐릭터와, 캐릭터당 22개의 스킬이 있는 게임이다보니 만들고 다듬어야 할 콘셉트 양이 엄청났다.
보통 인간을 뛰어넘는 솜씨에 더불어, UI 와 코드도 1주일안에 새로 원하는 시스템에 맞춰서 멋지게 만들어냈다. 나머지 3주일 동안의 폴리싱 끝에 스킬 시스템이 완성되었다. 이전 3년 동안에는 이런 식으로 개발해 보지 않았거니와 그렇게 하기 불가능했다. 맞는 사람에게 맞는 작업을 필요한 권한과 함께 맡겼더니 이렇게 전혀 다른 결과를 얻을 수 있었다. 스킬 시스템 개발과정을 보고 디자인 결정 권한을 위임하는 것에 대해 자신감을 얻을 수 있었고, 다른 시스템에도 권한을 위임하기 시작했다.

4. Kit Bashing mentality

우리는 아트, 그 중에서도 환경(월드) 아트를 효율적으로 만들기 위해 노력했다. "대격변" 이전에는 한 명의 아트 디렉터가 5 명의 풀타임 작업을 도맡아 했다. 즉, 내부/외부 아트 디렉션을 잡고, 전체 아트 검수에 대한 일정을 잡고, 스타일 가이드라인을 만들고, 기술 스펙과 표준, 팀에게 기준을 보여주기 위한 아트 세트를 만들고, 스카이박스 같은 이펙트 아이템도 만들어야 했다. 이런 작업들은 각자의 생산성을 최대한 끌어올려야 하는 AAA 프로젝트에서 한 사람이 맡기에는 너무 많은 일이었다.
"대격변"동안 유능한 아티스트이기도 한 아트 디렉터는 레벨 디자인과 아트팀 사이에서 새로운 스타일을 만드는 데 도와주는 역할을 하고, 새로 만들어진 Visual Design 팀에 시니어 아티스트로 들어가기로 했다. 이제 원래 한 명의 아트 디렉터가 맡던 작업을 아트 디렉터, 아트팀 리드, 내부 아트 프로듀서, 아웃소싱 아트 프로듀서, 환경 아트(Visual Design 팀) 리드, 아웃소싱 아트 리드로 나눠서 맡게 했다. 사람들에게 각자가 원하는 일을 맡겼더니 최고의 효율을 얻을 수 있었다.
새로 만들어진 Visual Design 팀은 아트출신 레벨디자이너들과 몇몇 시니어 아티스트로 구성되었는데, 새로운 아트 스타일을 기술적으로 정의하고, 이런 미학적인 내용을 팀에 전파하는 역할을 맡았고, [http]kit bashing(역주 : 원래는 프라모델에서 기존 모델들의 부품들을 모아서 새로운 모델을 만들어 내는 방법) 을 해답으로 삼았다. kit bashing 은 Epic 레벨 디자이너들이 사용해 온 기법으로 Unreal 엔진에서 어셋의 방향을 돌리거나 크기를 조절하거나 둘 이상을 조합하는 식으로 어셋을 재사용하는 방식으로 원하는 시각적 결과를 얻는 기법이다.
[http]Fyrestone 이 새로 제안된 아트 스타일을 테스트해 보는 시험장이었다. Fyrestone 은 돌아다닐 정도로 충분히 넓은 장소인데 이곳을 새로운 스타일로 만든 몇 가지 프랍들(파이트, 주름진 깡통, 물탱크, 타이어, 두 개의 갈색 대들보, 몇 종류의 바닥 아트와 다른 자질구레한 것들)만으로 Kit Bashing 해서 만들었다. 그 당시에는 외각선 기법이 없었는데 아웃소싱 아트 리드(Borderland 로 오기 전에는 다른 프로젝트에서 아트 디렉터였던) 가 예전 Quake 모드 만들던 시절에 메시 두 개의 면을 뒤집어서 외각선을 만들던 기법을 기억해 내 만들었다. 즉, 아웃라인 아트 스타일조차도 kit bash 으로 확인해 볼 수 있었다!

사진 설명 : Lucky 의 간판은 kit basing 의 결정판이다. 간판의 네잎클로버는 20 개가 넘는 납작한 통으로 만들었고, Lucky's 라는 단어는 17개의 화살표를 연결해서 만들었다.

5. The new art style.

Fyrestone 테스트가 완료되자마자 CEO 인 [http]Randy Pitchford 는 이 결과물을 가지고 "대격변" 을 설득하러 2K 로 날아갔다. 이렇게 개발 막바지에 확 바꾼다는 것은 대부분 좋지 않은 생각이기 때문에 2K 쪽에서 어떻게 반응할지 아무도 예측하지 못했고 전망은 불안했다. 하지만 Fyrestone 으로 "대격변" 의 결과를 본 모두는 가능성을 확인했고, 특히 새로운 스타일로 만들어진 레벨을 게임에서 돌아다녀 본 대부분의 사람들이 만족해했다. Fyrestone 가 제 역할을 충실히 한 것이다. Randy 와의 회의 끝에 2K 는 우리와 새로운 스타일을 믿어주기로 했고, 덕분에 두 회사 사이에 확고한 협력관계를 구축할 수 있었다.
새로운 아트 스타일과 함께 모든 것이 서로 맞아떨어지기 시작했다. 이제 우리는 게임의 분위기에 맞는 아트가 생긴 것이다. 이제는 플레이어가 하늘 높이 점프를 하거나 적들이 레벨에 따라 다른 데미지를 주거나, 미션 목표가 엉뚱하거나, 미친 난쟁이가 플레이어 앞으로 뛰어오거나, 머리에서 뇌에 튀어나와 땅에 떨어지거나, 재치있는 외발바퀴 로봇이 플레이어를 안내하더라도 아트와 잘 어울렸다. Visual Design 팀은 이를 "교양없는 재치(ill-mannered whimsy)" 라고 칭했고, 프로젝트 디렉터인 [http]Matt Armstrong 은 "우리 게임의 분위기는 Paul Verhoeven 감독의 작품인 스타쉽 트루퍼스와 로보캅처럼 과장된 폭력이 블랙유머를 보여주는 스타일에 영향을 받은 거 같다고 얘기했다. 이제는 월드에서 유머스러워도 괜찮았기 때문에 개발팀은 디자인에 집중할 수 있었다. 개발생산성이 굉장히 좋아졌고, 아트가 디자인에 영향을 주고, 디자인이 아트에 영향을 주는 선순환 관계를 만들 수 있었다.
새로운 스타일은 현실적인 문제에 있어서도 도움이 되었다. 즉, 어셋 개발 과정을 명확하게 명시할 수 있었고, 완료 여부를 아트 디르가 평가할 수 있게 되었다. 좀더 사실적인 스타일이었다면, 어셋이 다 만들어졌는지 애매할 때가 많다. 하지만 (카툰 스타일의) 새로운 스타일에서는 완료 여부가 명확했다. 또한 새로운 스타일에서는 효율성과 품질면에서 반복개발할 수 있는 시간적 여유가 있었다. 이전에 코믹북 아트를 그렸던 경험이 있는 팀원에게 나머지 팀원들의 품질을 검사하고, 나머지 팀원들이 품질을 맞추기 시작하면 새로운 기법에 맞춰 품질 수준을 더 높히는 역할을 맡겼다. 예를 들어, 좀더 효율적이면서 텍스처 품질을 높히는 실험을 하는 중에, 그는 "화사하게 만드는(color up)" 것이 "어둠게(ink down)" 만드는 것보다 우리 스타일에 더 맞다는 것을 보여줬다. 이런 방식은 일반적인 게임아티스트의 방식과는 전혀 다르다. 일반적으로는 아티스트가 노멀맵과 AO 를 만들어 이를 텍스터에서 칼라를 보여주는 가이드로 삼을 것이지만 우리의 아트 스타일에서는 대부분의 어셋이 이미 그래픽 노블 일러스트레이터처럼 디테일하게 그려져 있기 때문에 노멀맵이 필요하지 않았다. 다행인 것은 우리에게는 팀에 이런 기법을 전체 개발에 적용하는 최선의 방법을 이해할 수 있도록 도와줄 수 있는 전문가가 있었다는 점이다.

아쉬웠던 점

1. Memory part 1 : mystery memory.

다른 콘솔게임도 마찬가지지만, 개발 막바지에 되어갈수록 메모리가 어떻게 사용되는지 파악해야 했다. 처음 해야 하는 일은 메모리 사용 방식을 평가해서 어떤 시스템이 얼마만큼의 RAM 을 사용하는지 파악하는 것이다. 어떤 시스템에서 사용하는지 확인되지 않은 메모리를 우리는 "수수께기 메모리"라고 불렀다.
메모리 문제를 진단하고 책임을 부여할 수 있는 확실한 방법이 없을 경우 콘텐츠 개발자(특히 주니어들 같은 경우)는 자신이 개발한 부분과 게임 상태에 분명한 연관관계를 찾기 어렵기 때문에 적극적으로 문제가 없을지 확인하지 않게 된다. 이런 걸 알려면 엔진이 메모리 문제를 피하기 위해 어떻게 돌아가고 있는지에 대한 고급 지식을 알아야 했고, 이런 부분은 개발자들에게 메모리를 신경쓰지 않는 좋은 핑계꺼리가 되었다. 그렇기 때문에 우리는 주니어 개발자들에게도 베테랑 같은 마음가짐으로 개발하도록 당부했다. Unreal 엔진은 여러모도 멋진 개발툴이지만, 메모리 검사만큼은 우리가 직접 툴을 개발해야 했다.
문제인지도 아닌지도 분명하지 않은 것을 고치기란 어렵다. 이래서 어셋 표준을 엄격하게 잡는 것이 중요하다. 또한 할 일이 산더미처럼 쌓여있을 때 하던 일이 문제 없는지 확인하기 위해 잠시 시간을 갖기란 쉽지 않다. 다행인 것은 우리에게는 TA 와 이펙트 아티스트를 거친, 경험많은 아트팀 리드가 있었다는 점이다. 아트 리더는 TA 들과 함께 게임에서의 메모리와 성능 문제를 파악할 수 있도록 해 주었고, 적정 메모리 사용량에 대해서도 토론했고, 아트 어셋 파이프라인 관련자 모두에게 결론을 알려주고 이런 결론이 어떤 의미가 있는지를 이해할 수 있도록 도왔다.
이런 토론 중 하나는 아티스트가 고해상도 소스로 작업하는 것에 대한 부분이었다. 고해상도로 작업하게 되면 주인공이나 보스 어셋을 만들거나 마케팅용 아트를 만들기에는 좋지만, 적절한 LOD 를 잡아주지 않을 경우 성능에 문제가 있을 수 있고, 생산성도 떨어지게 된다. 이런 토론은 팀이 유저들이 최종적으로 경험하게 될 결과물에 집중할 수 있게 해 줬고, 새로운 아트 스타일을 만들기 좋도록 작업 순서를 조정하는데 도움이 되었다.
최적화 문제는 그야말로 TA 의 가이드라인을 기초로 하는 팀 전체의 노력과, 프로그래머들의 발견에 영향을 받았다. 프로젝트가 막바지가 되어 갈 수록 최적화 문제는 출시 여부를 결정짓는 중요한 문제가 되었기 때문에, 테크니컬 디렉터는 자체 메모리 프로파일링 툴을 만들어 파악되지 않은 메모리 사용 출처를 찾는데 요긴하게 쓸 수 있었다. 물론 아직도 메모리 사용 정보에 대해서 제대로 파악하지 못한 부분이 꽤 있다.

2. Memory part 2 : Platform headaches

Xbox 360 같은 경우 unified memory 덕분에 그나마 쉽게 실행가능하게 만들 수 있었다. (역주 : Xbox 360 은 unified memory 을 사용한다. 즉, 512M 메모리를 시스템 메모리와 그래픽 메모리용으로 다같이 쓴다. PS3 같은 경우 256M 메모리는 시스템용으로, 나머지 256M 메모리는 그래픽용으로 나눠쓴다고 한다. [https]출처) Xbox 360 은 PS3 보다 훨씬 빨리 인증받았다. PS3 같은 경우 PS3 메모리에 게임을 올리기 위해 더 많은 노력이 필요했다.
우리 플랫폼 엔니지어는 플랫폼 측면에서 (일부 데이터를 [http]RSX 메모리로 옮기고, 데이터를 좀더 효율적으로 저장하기 위해 코드를 다시 작성하는 등등) 엄청나게 많은 일을 해 내야 했다. 이런 작업과 더불어 게임개발팀도 콘텐츠 측면에서 메모리 사용량을 줄이기 위해 많은 작업을 했다. PS3 작업에는 두 가지 난관이 있었는데 첫번째는 unified memory architecture(역주 : 아마 Xbox 360 의 unified memory architecture 에 반대되는 divided memory architecture 를 잘못 쓴게 아닐까 생각됨) 이고 두 번째는 굉장히 큰 메모리 페이지 크기(64k) 였다. 메모리 페이지가 너무 크면 메모리를 해제해도 전체 페이지가 다 해제되지 전 까지는 메모리가 남아있는 문제가 있다. 이러다보니 (디스크 단편화 같은) 메모리 단편화가 심각해졌다. 게임을 PS3 에서 돌아갈 수 있도록 만들어 테스트까지 마친 후 인증을 요청해도, 게임을 충분히 오래 지속하다보면 단편화가 생겨서 메모리를 더 이상 할당할 수 없는 상태가 된다는 점에서 단편화는 심각한 문제였다. 더해서 물리 엔진같이 미들웨어 중의 일부가 엄청나게 메모리를 잡아먹는다는 것도 알게 되었다.
예를 들어 같은 메시를 사용하는 두 인스턴스는 물리 데이터를 공유하지만, 둘 중 한 인스턴스의 크기가 변경(scale) 되면(예를 들어 Borderland 의 모든 바위가 그런 식이다) 각 인스턴스별로 물리 메모리를 복사하고 있었다. 이 방식은 PS3 에 적합하게 구현된 것이 아니어서 단편화를 심하게 만들고 있었다. 결국에는 물리 메모리 공간에 가상 메모리가 돌아갈 수 있도록 만들어야 했는데, 이 작업을 위해 프로젝트 막바지에 엄청나게 변경을 해야 했다. 다른 흥미로운 문제로 오디오 메모리를 RSX 메모리로 옮긴 문제가 있는데, 이러다보니 가끔 오디오를 출력할 때 버스에 그래픽 데이터와 함께 몰리는 바람에 경쟁(contention) 상태가 생길 때가 있었다.(나는 아직도 어떻게 우리 PS3 리드프로그래머가 이 사실을 알아냈는지 모르겠다.)
이런 코어 레벨에서의 변경을 프로젝트 막바지에 하고 싶은 사람은 없을 것이다. 더 큰 문제는 이런 것들을 변경할 때마다 남아있는 여러 문제들을 해결하기가 더 어려워지고 걸리는 시간도 늘어났다는 점이다.

3. The quest for missions.

"대격변" 이후 레벨 디자인 팀에는 게임에 들어갈 모든 미션을 만들어라는 작업이 떨어졌다. 이것은 보통 일이 아니었다. "대격변" 으로부터 출시일까지 레벨 디자이너들은 무엇을 해야하는지를 알고 있었다. 레벨 디자인 리드와 함께 단결하여 온 힘을 다해 게임을 완전히 새로 만들어야 했다. 디자인팀에게는 2009 년 초에 개발 완료된 고차원(high level) 미션 프레임워크가 마련되어 있었기 때문에 스토리와 미션을 변경해야 하는 작업 앞에서도 그나마 자신감이 있었다.
미션 시스템은 프로젝트 초반에 디자인팀이 만들어놓은 스팩에서 점점 발전해 나가기 시작했다. 프리프로덕션 기간 동안에는 게임이 어떻게 구성되어야 할지를 고민하고, 다양한 방면에서 재미요소를 찾으려 노력했다. 2006~2008 년말까지 매번 데모를 준비해야 했기 때문에 미션을 디자인할 때 6개월 안에 소규모의 코어 개발팀이 개발할 수 있고, 짧은 시간에 즐길 수 있는 미션 개발에만 치우치게 되었다. 하지만 Borderlands 는 좀더 장기적인 관점에서 개발해야 하는 게임이었다.
마지막 네러티브 구조까지 정리해 놓은 뒤에야 개발팀은 큰 그림을 그릴 수 있게 되었다. 전체 그림을 볼 수 있게 되자 어떻게 하면 재미있는 미션을 만들 수 있을지에 대한 새로운 아이디어들이 쏟아지기 시작했는데 이를 구현하기 위해서는 시스템을 확장하기 위해 많은 지원이 필요했다. 그전까지 미션 시스템은 여러 번 수정되어왔지만 이런 식의 미션을 쉽게 만들 수 있도록 제대로 리팩토링된 적이 없었다. 결국은 팀의 한 명이 나서서 미션 시스템에 대해서 열심히 연구해 미션 전문가가 되어, 미션에 대해서 물어볼 일이 있을 때마다 도와주는 역할을 맡았다.
미션 시스템은 우리가 개발한 데이터 주도 인터렉티브 객체 시스템과, Unreal 엔진의 비주얼 스크립트 인터페이스인 Kismet 을 이용해 구현했는데, Kismet 은 레벨 디자이너의 모든 필요에 대해서 확장하기 쉽지 않았다. 특히나 프로젝트 막바지였기 때문에 새로운 기능 개발의 우선 순위는 낮았다.
이런 시스템적인 제한은 디자이너들로 하여금 현재 구현된 시스템 내에서 할 수 있는 최선의 방법을 찾도록 강제함으로서 미션 개발에만 집중하게 할 수 있었다. 아쉬웠던 점은 미션 시스템을 완벽하게 이해하는 사람이 한 명뿐이었기 때문에 그 사람의 업무가 너무 많았고, 미션을 디버깅하기 힘들었다는 점이다.

4. Analysis paralysis and the Truth

초기 핵심개발팀은 굉장히 추상적인 목표와 이상적인 생각으로 프로젝트를 시작했다. 그 당시 개발팀은 문서화와 의사소통에 가장 효율적인 도구가 위키라고 생각했다. 하지만 개발팀 규모가 늘어남에 따라 위키가 잘 안 맞기 시작했다. 디자인은 그 디자인을 문서화한 위키 페이지보다 더 빠르게 발전해 나갔고, 문서를 어느 정도로 업데이트 해야 하는가에 대한 합의가 팀 내에서 불분명했다. 이러다보니 어떤 결정이 왜 내려졌는지, 어떤 얘기들을 검토 중이었는지, 기능이 구현될 때까지 어떤 내용은 더 이상 논의하지 않기로 했는지 등을 기억해 내기가 어려워졌다. 개발 초기에는 전혀 문서화되어 있지 않은 기능을 구현하는 바람에 특정 기능이나 콘텐츠의 정확한 현재 상태를 파악하기도 어려웠다. 특정 기능에 대해 원하는 최종상태는 정확하게 기술되어 있지 않았고, 여기에 더해서 현재 상태가 어떻게 되어 있는지를 잘 모르거나 서로 의견이 다른 경우에는 여러 번 회의를 진행해도 결정되는 것이 하나도 없었다.
유저들이 게임에 들어갈 기능에 대해 어떻게 생각할지, 개발팀이 다음으로 무슨 일을 해야 할지에 대해서도 의견 충돌이 있었다. 프로젝트 디렉터는 이런 문제를 해결하기 위해 이터레이션에 할 일을 정할 때 유저의 관점을 감안할 수 있는 포커스 테스트를 도입하기로 했다. 디렉터는 2K 가 외부 서드파티 테스트 서비스를 통해서 만든 고객 플레이 테스트팀에서 많은 가능성을 보았다. "대격변"을 결정한 이후부터 우리는 타겟 유저를 대상으로 기능에 대해 포커스 테스트에 집중하기로 했다.
Gearbox 의 테크니컬 디렉터가 맡아서 the Truth 팀이 만들어졌다. 이 팀은 고객의 입장에서 아무런 개인적 의견이나 추측없이 데이터로 얘기하도록 했다. Truth 팀은 우리가 내린 결정 중에서 최고의 결정이었고, 앞으로 개발할 모든 프로젝트에서도 Truth 팀을 활용하기로 했다.

5. Waterfall deadlines in an agile world

하이브리드형 게임을 만들기 위해서 유연한 개발방법론이 필요했다. 개발팀은 아이템 드랍과 루팅, 레벨링, 미션 디자인, 스킬 업그레이드, 전투 등 여러 면을 혁신적으로 만들고 싶었기 때문에 독립적인 개발라인이 필요했다. 개발마감은 개발팀을 집중하게 하는데에는 도움이 되지만, Borderland 를 개발할 때에는 개발마감 때가 되면 다음 마일스톤에 대한 개발준비를 해야 했기 때문에 마일스톤 결과에 대해서 고민, 분석할 시간이 충분치 않았다.
프로젝트를 시작한 뒤로 2008년 말까지 개발팀은 내부, 외부 데모를 보여주기 위해서 콘텐츠와 시스템을 반복개발했고, 마일스톤 역시 데모에서 발전된 모습을 보여주는 쪽에 초점이 맞춰졌다. 그러다보니 많은 시스템들이 병렬적으로 의도를 보여주기 위한 정도로만 개발되었고, 제대로 폴리싱 된 것은 거의 없었다. 마치 여러 장의 접시를 돌리는 것 처럼 어떤 시스템을 잠깐 챙겼다가 바로 다른 시스템을 챙기는 식이었다.
전체 핵심 피처를 마무리하고, 그 위에서 게임을 개발하기에는 일정이 유연하지 않았다. 예를 들어 Second Wind(새로운 활력. 마라톤에서 힘이 다 빠진 선수가 갑자기 다시 힘을 얻는 현상) 시스템이 시간별로 나뉘어서 개발된 경우다. Second Wind 는 적을 죽일 경우 넉다운 상태에서 빠져나올 수 있는 기회를 주는 시간베이스 게임 메커니즘이다. 이 시스템을 보여줄 전체 UI, 애니메이션, 아트, 룰, 사운드, 이펙트 세트가 제대로 준비되지 않아 겨우 반만 구현만 해 놓은 추상적인 상태였다. 그러나보니 개발자와 Truth 팀 모두가 Second Wind 를 그다지 탐탁치 않게 여겼다.
Second Wind 는 사망 시스템과 관련되어 있는데, 사망 시스템은 경제와 게임세이브와 연관되어 있기 때문에 이들 시스템을 잘 엮기 위해서는 이들 시스템을 왔다갔다 하면서 반복개발해야 했다. Second Wind 의 개발이 지지부진했기 때문에 그 동안에 캐릭터의 드라마를 만들고, 플레이어의 경험을 재미있게 만들 수 있었다는 점에서는 도움이 되었다. 하지만 Second Wind 시스템 같은 시스템을 처음부터 제대로 마무리하는 식으로 작업했었더라면 동시에 게임에 여러 시스템을 집어넣지는 못했겠지만, 적더라도 제대로 완성된 시스템이 들어간다는 점에서 훨씬 더 효율적이었을 것이다. 또한 개발팀 사기 측면이나, 개발팀과 파트너 사에게 게임의 의도를 전달한다는 점에 있어서도 더 좋았을 것이다.

Crossing the border

모두가 케익을 좋아한다. 하지만 반쯤 만든 케익이란 건 없다. 게다가 전세계적으로 팔릴만한 케익을 전시회에 보여주기 위해 케익을 굽는 도중에 재료를 바꿔서 다시 오븐에 넣는 일을 반복하는 식으로 만들기란 불가능하다. 아마 그런 식으로 케익을 굽다가는 케익이 엉망진창이 될 것이다. Borderlands 를 개발하면서 많은 것이 바뀌었다. 우리는 프로젝트 기간 내내 요리사 역할을 서로 돌아가면서 맡았다. Borderlands 개발은 케익 하나 굽는 것과는 전혀 다르다. 그보다는 일관되면서도 맛있고, 알맞은 모양이 나올 때까지 다양한 실험을 통해서 다층 웨딩케익을 만드는 과정이었다고 볼 수 있다. Borderlands 의 성공비법은 모든 팀원이 게임에 기여할 수 있다고 느낄 수 있게 한 점, 그리고 실제로 다같이 기여한 점에 있다. 그게 사실 전부다. 우리가 개발한 게임이 자랑스럽지만, 이제 막 시작일 뿐이다.

Aaron Thibault 는 Gearbox Software 의 개발부서 vice president 이다.


덧글

댓글 입력 영역


Yes24위대한게임의탄생3

위대한 게임의 탄생 3
예스24 | 애드온2