알라딘MGG와이드바


Game Developer Magazine 20110607 포스트모템 - Rift(리프트) 포스트모템


Data Points
퍼블리셔, 개발사 : [http]Trion Worlds : Lars Buttler(EA 의 Global Online VP 출신) 와 Jon Van Caneghem(NCSOFT 의 Executive Producer 출신) 이 설립한 회사로 그 외에도 아이온, WOW, EverQuest, Pogo.com 출신들이 활약하고 있다.
개발자 : 출시 당시 110 명
개발기간 : 4.5년
예산 : 5천만 달러
출시 : 2011.03. [http]2012.01 까지 1억 달러 이상을 벌었다고 함.

이 글은 Rift 의 두 번째 대규모 업데이트를 개발하는 도중에 쓰여졌다. RIFT 는 MMORPG 이다. "얼마나 대규모로 만들 수 있을까" 와 "같은 장소에 어느 정도 이상 많은 사람이 모이면 재미가 반감될까" 사이에서 균형점을 찾으려고 많이 노력했다. MMO 게임을 출시하면서 알게 된 점 하나는 출시를 한 이후부터 할 일이 더 쏟아진다는 점이다. 그것도 엄청나게 많이 말이다. 유저와 실시간으로 이터레이션을 주고 받을 수 있다는 점과 급하게 처리해야 할 일이 주는 긴장감은 게임을 사랑하는 개발자를 흥분시킨다.

잘된 점

1. Off-The-Shelf Software
내가 읽은 대부분의 포스트모템에서 툴에 언급되었는데 보통 툴이 나중에 제작되었다던가, 충분한 투자를 하지 않았다던가 등등이었다. 공통 라이브러리에 들이는 시간이 적으면 적을수록 게임의 핵심 로직을 개발하는데 더 많은 시간을 들일 수 있을 것이다. 우리가 이렇게 게임 핵심에 집중할 수 있도록 도와준 요인 중의 하나는 상용툴 중에서 괜찮은 것을 필요할 때마다 교체해 가면서 선택해 쓴 점이다.
Gamebyro(거의 모든 커스텀 툴과 렌더링 코드가 교체되었지만) 엔진은 프로젝트의 핵심이자, 레벨팀이 바로 개발을 진행할 수 있게 했다. Scaleform 은 UI 에, Havok 은 물리에, [http]Wwise 은 오디오 개발에, rsyslog 은 로그에, [http]NavPower 은 길찾기에 사용했다. 이런 기반위에서 우리는 툴이 우리 게임 개발에 잘 맞지 않는 부분만 신경쓰고, 게임 디자인 부분과 CS 툴 개발에만 집중할 수 있었다.

2. Hired a small, talented team at the start and built slowly and carefully
개발 초반에 core 개발팀은 개발에 대한 여러가지 정책과 방침을 정했다. 덕분에 나중에 사람을 뽑았을 때 뭘 어떻게 해야할지, 어떤 용어로 얘기해야 할지를 쉽게 알려줄 수 있었다. 새로 만들어진 회사였고 프로젝트도 아직 눈에 보이는게 없었기 때문에 사람을 뽑기가 어려웠지만 알음알음 수소문해서 좋은 개발팀원들을 미리 뽑을 수 있었고, 덕분에 사람 뽑기가 점점 쉬워졌다. 다양한 경험을 가진 훌륭한 개발자들은 큰 도움이 되었다.

3. Elephants don't belong in rooms
우리 개발팀은 품질이 가장 중요하다고 생각했기 때문에 작업결과물에 대해서 비평하는 것에 주저하지 않았다. 이렇다보니 뭐가 제대로 동작하지 않으면 버리는데 주저하지 않는 문화가 만들어졌다. 물론 새로 만드는 게 항상 즐거울 리는 없지만, 제대로 나올 때까지 계속 다시 만들기를 반복했다. 좋은 개발팀 구축, 툴 개발과 함께 이런 개발 문화 덕분에 우리는 굉장히 민첩하게 게임플레이를 변경하거나 추가할 수 있었다.

4. Scope: Control it, or be controlled
판타지 MMORPG 를 새로 만든다면 그 당시에 가장 잘 나가는 MMO 게임들은 어떻게 만들어져 있는지를 비교하게 될 것이다. 만약 차별화를 하겠다면서 모든 분야를 획기적으로 만들려든다면 아마 절대로 게임을 출시하지 못할 것이다. 혁신에는 더 큰 문제가 있다. 새로 만든 획기적인 게임에 기존 MMORPG 게이머들에게 익숙한 요소들이 부족하다면 마치 게임을 잘못 만든 것 처럼 보일 수 있다(즉, 시대를 앞서 나가는 바람에 대중에 어필하지 못할 수 있다). 이런 상황이 올바른 것인지는 모르겠으나 지난 몇 년간 출시된 MMO 들을 보면서 더욱 더 이런 생각에 확신을 갖게 되었다.
이렇기 때문에 우리는 의도적으로 "새로운" 요소와 "익숙한" 요소 사이에서 균형을 잡으려 했다. 그 중에서 우리가 생각한 "독특한" 차별요소 중 하나가 어디서든 열려서 모든 플레이어들이 하던 일을 멈추고 다 같이 침략자들을 공격해야 하는 rift 시스템이다(이런 시스템은 MMO 에서는 굉장한 차별점이다. 혼자 하는 게임에서의 재미요소와, 전체 서버 유저들과 함께 할 때의 재미요소는 천차만별인 경우가 많다.)
Rift 시스템 개발에 1년 반 이상이 걸렸다. 우리는 남은 시간동안 얼마나 구현해 낼 수 있을지를 잘 알고 있었기 때문에 목표 기능을 정해놓고 작업했다. 또한 나중에 알파테스트 때 실제로 유저들이 플레이하는 모습을 보게 되면 시스템을 고쳐야 할 시간이 분명 필요할 것이기 때문에 여유 시간을 충분히 잡아놨다. 이렇게 시간을 확보하기 위해서 다른 기능들 일부를 다음으로 포기해야 했다.

5. Same greek alphabet, brand new flavor
우리는 알파베스트, 베타테스트를 동시에 중첩해서 진행했다. 알파테스트에서는 출시 1년 전부터 24/7 동안 비공개 유저들에게 항상 열려있는 서버를 제공해 라이브서비스를 연습했다. 덕분에 안정성, 통합성과 유저들의 반응에 민접하게 반응하는 법을 배울 수 있었다. 베타테스트에서는 일정 시간동안 다른 서버군을 공개해 외부유저들에게 테스트를 받았다. 이를 통해서 콘텐츠가 "실제로" 어떻게 플레이되는지를 확인할 수 있었다. 이런 베타 테스트 덕분에 우리는 두 가지를 얻을 수 있었다.
먼저 베타테스트를 오픈할 때마다 회사 규모의 "출시" 를 경험해 볼 수 있었다. 덕분에 다른 MMO 회사는 단 한 번만 경험해 보는 "출시"를 여러 번 훈련해 볼 수 있었다. 이미 3개월 동안 8 번이나 베타테스트 출시를 해 보았기 때문에 실제 출시하는 것도 큰 어려움이 없었다.
둘째, 베타테스트 기간 사이에 1-2주 정도 쉬어가는 기간을 가질 수 있었다. 어려운 문제를 못 풀고 있다가 샤워할 때 엄청난 아이디어가 나온다는 얘기는 다들 들어봤을 것이다. 24/7 동안 서비스를 하게 되면 너무 바빠서 이런 쉬어가는 시간을 갖기 어렵다. 이렇게 베타서비스를 쉬어가는 시간동안 품질을 향상시킬 수 있는 번뜩이는 아이디어를 발견하고 구현할 수 있었다.

아쉬웠던 점

1. Same code, two teams, two missions
우리 회사는 백지상태에서 MMO 프레임워크와 퍼블리싱 플랫폼을 구축하고 동시에 여러 게임을 개발하려는, 굉장히 야심찬(혹은 정신나간?) 계획을 갖고 설립되었다. Austin 스튜디오에서는 주로 게임에 쓰일 기술과 플랫폼을 개발하고, Redwood City 스튜디오는 헤드쿼터이자 Rift 개발팀이 있었고, San Diego 스튜디오에는 Syfy 와 End of nations 개발팀이 있었다. 개발이 진행되는 동안 "이건 게임팀 업무인가? 플랫폼 업무인가?" 에 대한 선을 여러 번 다시 그려야 했다. MMORPG 에 필요한 일이 꼭 MMORTS 에 필요한 것은 아니었고, 이런 것은 MMO 액션 게임에도 마찬가지였다. 업무를 정확히 나누기 애매한 부분이 한 두 곳이 아니었다. 공통 라이브러리, DB 레이어, 그래픽 엔진, UI, 패치, 인증 등등 여러 업부가 모든 게임에 똑같이 쓰기도 어렵고 그렇다고 완전 다른 것도 아니었다. 한 스튜디오에서 먼저 개발한 기술을 가져다 쓴다면 시간과 노력을 아낄 수 있겠지만, 게임개발 스튜디오 입장에서는 공통 모듈 개발보다는 어떻게 하면 우리 게임을 더 재미있게 만들 것인가에 좀 더 집중하기 마련이었다. 결국에는 각각의 스튜디오에서는 각자의 게임에 가장 잘 맞는 기술을 개발하기로 했고, 어느 정도 선에서 가장 효율적으로 기술을 다른 스튜디오에 "공유"할 수 있을 것인지 알게 되었다. 우리의 최우선 가이드라인은 "게임이 훌륭하지 않으면 다른 건 아무 소용없다" 가 되었다. 이렇게 가이드라인을 정하고 나니 많은 것들이 제자리를 잡을 수 있었고, 개발자들이 스스로 판단내릴 수 있었다.

2. Identity : are we a platform, a publisher, a developer, or all three?
처음에는 플랫폼 쪽에 더 관심이 많았다. 이미 두 번째 게임(Petroglyph Games 가 개발하는 End of nations)이 개발 중이었기 때문에 게임을 제때 출시하기 위해 마일스톤 별로 품질 검수를 할 수 있는 QA 팀을 구성해야 했다. 하지만 Rift 개발팀에게는 다른 종류의 QA 가 필요했다. Rift 입장에서는 이미 다른 걸 한 참 개발중인 개발팀에게 몇 주 전에 구현한 것 때문에 무슨 문제가 있다라고 늦게 알려주는 것은 큰 도움이 안 될 것이다. 품질을 유지하기 위해서는 QA 가 매일같이 검증하고 문제가 생기면 그날 바로 알려줄 수 있어야 했다. 이를 위해 우리는 두 종류의 QA(매일 검증과 주기적인 검증)가 필요했다. 여기에 드는 비용은 생각보다 많았지만 실보다 득이 많았다.

3. Creating a new IP was harder than we thought.
우리는 처음부터 새로 만들어진 회사였기 때문에 IP 도 새로 개발해야 했다. 문제는 개발팀원들 모두가 판타지에 대한 취향이 조금씩 달랐기 때문에 모두가 같은 컨셉을 바라보게 하는데 오랜 시간이 걸렸다는 점이다. 게다가 개발팀 규모가 급속도로 늘었기 때문에 모든 팀원들에게 우리 게임이 어떻게 진행되고 있는지를 상기시켜 주기란 굉장히 어려웠다. IP 개발은 개발이 한 참 진행될 때까지 시간이 걸렸지만 적어도 출시 이전에는 잘 정리할 수 있었다.

4. Localization : we can to that all at the end, right?
현지화는 굉장한 도전이었다. 비용이나 개발 파이프라인 구축 시간 모두 예상보다 더 크게 들었다. 우리 게임은 영어, 프랑스어, 독일어로 출시되었는데 백만개 이상의 단어와 함께 여러 녹음된 음성과 비디오가 포함되어 있다.
우리의 교훈은 이렇다. "아직 대사 작업이 끝나지 않았다고 해서 현지화를 늦추지 마라." 보통은 다들 이렇게 얘기할 것이다. "대사는 언제든지 바뀔 수 있으니 현지화는 나중에 하자" (우리도 이렇게 얘기했었다.) 하지만 미리 현지화 개발 파이프라인을 잡아놓으면 나중에 큰 비용을 아낄 수 있다. 또한 현지화에 필요한 인원 뽑기도 어려우니 미리 잘 구해놔라.

5. Dynamic content - Presentation is everything.
우리 게임의 핵심 목표는 다른 MMO 에서는 경험하지 못했던 멋진 일(예를 들어 전세계가 침략당하는)이 벌어지는 세상을 만드는 것이었다. 이를 위해 먼저 어셋과 게임플레이 데이터를 실시간으로 변경하고 대규모 몬스터 습격을 구현하기 위한 프레임워크를 준비해야 했다. 이런 문제들을 해결하고 나니 동적 콘텐츠를 어떻게 플레이어들에게 전달하고 보여줄 것인가에 대한 문제가 남았다. 초반에는 어떤 것이 정적/동적 콘텐트인지 (실시간으로 설명해줌으도 불구하고) 헷갈려했기 때문에 이를 분명히 드러내고 유저들이 쉽게 구별할 수 있도록 많이 노력했다. 덕분에 유저들이 즐겁게 즐길 수 있었다.

핑백

덧글

댓글 입력 영역


Yes24위대한게임의탄생3

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