포스트모텀: Vivid Games' Real Boxing [3/4]
January 21, 2013 | By Tomasz Strzelczyk, Grzegorz Brol, Krystian Komisarek
[ 이전 게시물 ]
잘못한 것들
1. Training Mode (트레이닝 모드)
모든 게임들은 버그 없이 게임을 출시하기 위해서 노력하고 있습니다. 특히 App Store 에서는 사소한 버그조차 나쁜 리뷰 그리고 저조한 별 평가로 이어지기 때문에, 매우 중요합니다. 저희는 테스트를 시작한 지 5 분 만에, 1403 개의 오류를 보고 받았으며, 그러한 버그들은 자잘한 버그 뿐만 아니라, 193 개의 치명적인 버그를 포함하고 있었습니다. 그로 인하여 팀은 거의 쉬지 않고 일을 해야만 했습니다. 특히 Jacek Szarejko 와 시니어 테스터는 병원의 의사들처럼 46 시간동안 한번도 쉬지 않고 일을 하는 등의 악명 높은 기록을 세웠습니다.(그들은 3.13 GB 의 게임 플레이 비디오와 사진을 저장하였다고 합니다.)
이 모든 것에도 불구하고 게임의 첫 번째 버전은 2가지 치명적인 오류를 가지고 있었습니다. 이것은 플레이어가 예정보다 빠르게 마지막까지 도달한다면 안 좋은 평가로 이어질 수 있다는 것을 의미했습니다. 그 에러는 마지막 테스트 이후 나온 버전에서 느닷없이 나타났습니다. 저희는 다행히 첫 번째 업데이트를 통해서 이러한 문제를 해결할 수 있었지만, 이미 많은 플레이어들이 이 에러를 겪을 수 밖에 없었으며, 별점 리뷰에 안 좋은 영향을 미칠 수 밖에 없었습니다.
개발 초기, 저희는 이러한 오류를 철저히 대비했었습니다. 일주일에 한번 저희는 파일을 조절하고 코드를 검토했습니다. 버그와 고칠 점을 문서로 보고하고, 담당자들에게 할당해주었습니다. 저희의 목표는 코드가 진행됨에 따라 발생할 수 있는 문제를 미연에 차단하는 것이었습니다. 이 장치의 장점은 전체 프로젝트를 개개인이 통찰력 있게 바라볼 수 있다는 점이었습니다.
저희는 또한 개발자들을 위해서, 새로운 프로그래머가 빠르게 투입될 수 있도록, 설정 도구(환경 설정, 프로젝트 기본 설정), 기술 문서(구현하는 기술적인 결과물) 또는 Unreal script 의 좋은 예시 (코드 도움말) 등등, 몇 가지 추가적인 문서를 제작하였습니다. 물론 이러한 문제를 준비하는 데 많은 시간을 투자하여야 했습니다. 저희의 리드 프로그래머 Krystian Komisarek 는 코드 리뷰를 통해서 "doc writer." 라는 별명을 얻기도 했습니다.
그러나, 돌이켜보면, 저희의 시스템은 리뷰의 네이밍 작업이나, 리뷰를 통해 얻은 보고서들을 분류하는 작업에서 여전히 불안정하다는 결점을 가지고 있으며, 그로 인하여 많은 노력 끝에 얻은 리뷰들을 사용하는 데 어려움을 가지고 있습니다.
2. iPod Touch (4세대)
게임을 출시 하기 일주일 전, iPod Touch 4세대 와 iPhone 4 를 지원하는 데 문제가 있었으나, 저희는 그것을 해결한 줄 알고 있었습니다. 하지만 출시 후, 저희의 노력에도 불구하고 여전히 문제가 존재한다는 것을 알 수 있었습니다. 저희는 즉시 App Store 에 메시지를 추가하고, 이미 구입한 유저들에게 사과했습니다. 그 오류는 업데이트를 통해서 해결하였으며, 이미 게임을 결제한 플레이어들에게 게임 머니로 보상을 해주었습니다.
저희는 FlySpray 가 가지고 있는 태그를 추가하는 기능을 활용하여 에러를 다루었습니다. 이것은 특정 에러를 찾는 데 효율적이며, 우선 순위를 정하거나 진행 정도를 파악하기 용의 했습니다. 또한 저희는 다양한 버그를 빠르게 고치기 위하여, 첨부 파일(프린트 스크린, 비디오) 을 추가하기도 하였습니다.
하나의 에러가 다른 에러에 영향을 미칠 수 있었기 때문에, 테스터들도 일사분란하게 작업을 진행했습니다. 덧붙여 말하자면, 저희는 모든 에러에 누가 어떻게 찾아냈으며, 버전이 어떤 것인지, 그리고 어떤 기기에서 발생되었는 지에 대한 코멘트를 추가하도록 하였습니다. 그리고 이러한 것들을 담당자에게 빠르게 전달하였습니다. 하지만 불행하게도 이러한 시스템은 앞서 말한 2가지 큰 실수를 막아주지 못했습니다. 저희는 이러한 실패를 교훈 삼아, 항상 프로세스를 개선하며 배워나가고 있습니다.
3. 문서
게임 개발 전에 준비하는 시간이 매우 짧았기 때문에, 저희는 게임의 주요 기능에 대하여 충분히 의견을 나눌 수 없었습니다. 주요한 게임 기획 문서와 기타 추가 서류 (예: SFX 와 음악 리스트, 음성 문서, 게임 경제 문서) 는 프로젝트가 진행되는 도중에 완성되었습니다. 프로젝트를 모니터링 하기 위하여, 문서를 매주 업데이트 하는 일은 최선의 방법이었습니다. 문서가 업데이트 되면, 우리는 팀에게 변경 사항을 짧게 정리하여 전달하였으며, 중요한 변경 사항이 있을 경우 이메일을 통해서 전달하였습니다.
하지만 시간이 경과될수록 정보의 전달이 미흡해지기 시작했습니다. 우리는 정보를 전달하는 가장 효율적인 방법은, 해당 주제와 관련된 사람들과 회의를 하는 방법이라는 것을 깨달았습니다. 때때로, 각 팀의 방에서 일어난 자연스러운 토론은 중요한 이슈를 해결하거나 부가적인 업무를 줄여주는 역활을 해주었습니다.
다음 게시물에서 계속...
'게임 관련 번역 > Gamesutra' 카테고리의 다른 글
| [번역] PC 는 죽지 않았다. 그리고 모바일은 최악이다. (0) | 2013.01.25 |
|---|---|
| [번역] 포스트모텀: Vivid Games' Real Boxing [4/4] (0) | 2013.01.25 |
| [번역] 포스트모텀: Vivid Games' Real Boxing [2/4] (0) | 2013.01.24 |
| [번역] 리그오브레전드에서 플레이어가 명예롭게 행동하도록 변경시키는데 사용한 방법 (0) | 2013.01.24 |
| [번역] 포스트모텀: Vivid Games' Real Boxing [1/4] (2) | 2013.01.23 |
