POMMS, 플레이어가 게임을 테스트하게 하는 법

작성자: 로버트 호이셴(Robert Hoischen)
작성일: 2013년 1월 17일

거대한 인디 게임 <마인크래프트(Minecraft)>는 보통 게이머가 실제로 생각하는 "베타 버전"에 대한 인식을 바꾸어놓았다. "베타"라는 말은 더 이상 버그가 많고 실망스럽고 심하게 망가진 데다 전혀 재미없는 것을 의미하지 않는다. 지금은 상당히 플레이 가능하고 상당히 세련된, 그러나 불완전할 수 있는 초기의 개발 마일스톤 1 를 의미한다. "그렇다면 누가 실제로 이 마일스톤들의 베타 테스트를 하는가?"라고 물을 것이다. "<마인크래프트>를 베타 테스트" 했기 때문에 베타 테스터의 자격이 있다고 말하며 인디 게임 개발자 포럼에 오는 사람들은 아마 아닐 것이다.

먼저 명확하게 정의를 내려보자. 베타 버전2이란 기능은 완성되었지만 아직 버그가 고쳐지거나 세련화 작업을 거치지 않은, 개발 작업이 진행 중인 버전을 말한다. 게임의 작은 기능 하나일 수도 있고 전체 소프트웨어일 수도 있다. 이런 정의는 보편적인 것은 아니지만, 앞에서 이미 사례를 들었고, 이 글에서 보게 될 내용은 거부할 수 없는 명백한 사실이다. 노치(Notch)의 훌륭한 작품은 이 정의에 따라 매우 잘 다듬어진 중간결과물 이상도 이하도 아닌 상태로 출시되었는데, 스스로 “베타 테스터”라고 선언한 버전의 출시에 앞서 내부에서 알파와 베타 테스트를 한 것 같다.

최근 이런 변화들은 앞으로의 게임 제작에서 베타 테스트의 필요성에 심정적으로 어떤 영향을 끼쳤는가? 이 질문에 대한 답변은 타겟 이용자에 따라 크게 달라지지만, 일반적으로는 자유롭게 이용할 수 있는 일손들이 점점 "이것저것 해보는" 부류로 옮겨가고 있다.

블리자드 엔터테인먼트는 이런 사람들을 완벽하게 이용하는 방법 3 을 개발했지만, 이들은 소규모나 중간 규모의 테스트 팀에 잠재적인 위험 요소가 될 수 있었다. 유닛 시간과 테스터 당 (고급) 작업을 얼마나 해낼 수 있을지를 과대평가한 것은 즉각 실패로 이어졌고, 결국 신뢰를 잃고 궁극적으로는 판매를 저하시키는 결과를 가져오는 지연으로 이어졌다.

이 문제를 아무것도 계획하지 않거나 모든 것을 자신들이 직접 테스트함으로써 해결하는 인디 개발팀이 많은 것 같다. 실행 가능하지만 최선의 해결책과는 거리가 먼 방법이다.

이런 무지는 그리 놀랍지도 않다. 적절한 테스트 기반을 마련하고 테스트에 적절한 사람들을 찾고 끊임없이 변하는 테스트의 목표를 전달하는 데는 손이 많이 간다. 그게 바로 이 글에서 말하려는 POMMS 기반의 베타 테스트가 나온 이유다.

내가 개발한 POMMS 는 프로젝트 지향의 모듈 동기부여 시스템(Project-Oriented Modular Motivational System)의 약자로, 현재 <오토메이션: 자동차 회사 타이쿤(Automation: The Car Company Tycoon Game)>4을 개발하고 있는 소규모 인디 게임 개발 스튜디오 캠섀프트 소프트웨어(Camshaft Software) 5 에서 베타 테스트라고 불리던 혼돈에 구조와 명확성을 부여하기 위한 도구다. 이 시스템은 테스트 과정 자체에 현대 게임 기획의 요소들, 즉 보통 "게임화 (gamification)"6라는 전문 용어와 관련된 개념을 구현한다. 테스트에 대한 POMMS 기반의 접근은 베타 테스트의 어려운 부분들, 즉 미리 계획하는 능력, 테스터 조정, 테스터 동기부여, 테스트의 초점, 테스터의 유연성과 개성 같은 것들을 공격한다.

POMMS 란 무엇이며 어떻게 작동하는가

이 시스템 자체는 금방 설명할 수 있다. 잘 정의된 하위 프로젝트들을 설명하고, 테스터가 하위 프로젝트의 목표를 실현한 각각의 업무(task)에 일정량의 "점수"가 부여된다. 이 점수가 이른바 테스터의 전투력(power level) 7 인데, 이것이 9,000 점 이상이면 하위 프로젝트들이 너무 길거나 점수당 작업량이 너무 적은 것이다.

하위 프로젝트의 내용에 따라 1 점당 대략 15 분 정도의 작업으로, 중요한 하위 프로젝트는 4 주에서 16 주가 걸릴 수 있다. 주어진 하위 프로젝트에서 각각의 테스터는 테스트에 계속 참여하기 위해 일정한 최고 점수에 도달해야 한다. 최고 점수를 획득한 테스터들은 하위 프로젝트가 진행되면 누적되는 별을 받는다. 별을 획득한 테스터에게 어떤 보상이 돌아갈지는 개발자에게 달려 있다. 예를 들어 개발자는 테스터에게 소프트웨어의 크레딧에 이름을 넣는 특권을 줄 수도 있고, 그 밖에도 특별한 포럼 등급을 부여할 수도 있다.

테스터가 최고 점수는 획득했지만 별 순위 안에 들지 못한 경우 최종 점수는 다음 하위 프로젝트로 이월된다. 이것은 다음 하위 프로젝트에서 최고 점수에 도달하는 것이 아니라 별 순위 안에 드는 것을 유리하게 해준다. 그리하여 테스터가 결국 별을 받을 수 있게 되기 때문에, 하위 프로젝트가 진행되는 동안 작업을 꾸준하게 잘한 테스터에게 보상을 주며, 프로젝트가 끝난 후 테스터가 자신이 이름 없는 테스트 기계였다고 느끼지 않게 해준다.

각각의 하위 프로젝트는 소프트웨어의 특정한 측면에 초점을 맞추되, 활동을 너무 축소시키지 않도록 한다. 좋은 사례는 <오토메이션>에서 엔진 디자이너에 V8 엔진을 추가한 것이다. 이 하위 프로젝트는 8 주 안에 2D 와 3D 아트워크를 체크하고, 시나리오의 플레이를 테스트하고 균형을 맞추고, 실제 엔진의 자료 수집하고, 버그 추적 도구의 항목들을 다듬고, 게임의 모든 새로운 조건들을 체크하고, 마지막으로 가장 중요한 오래된 버그를 잘 보고하는 것을 아우른다.

각각의 하위 프로젝트마다 초반에 점수표가 정해진다. 모든 테스터는 이 점수표에서 베타 포럼의 "영웅의 전당" 스레드에 오르는데, 이 기록은 작업이 진행되는 동안 각 테스터가 꾸준히 업데이트한다. 다음은 위에서 언급한 V8 엔진 프로젝트의 점수표 사례다.

테스터 ID: PaLaDiN1337 (4*)
테스터 상태: 활동 중
현재 점수: 17 (+0)
시나리오 테스트: (V0.88) S1, S2, S4, S5, S7, S8, S11
트래커 항목: ID28804129, ID28796925, ID28786633
엔진 정보: 포드 모듈러 4.6L V8 3-밸브
테스트한 엔진: 포드 모듈러 5.4L "트리튼" V8 DOHC
포럼 장점: 교정 보조(2 점)
성과: 버그 트래커 정리(1 점) 3 회

점수표를 단순하게 유지하는 것이 가장 중요하다. 시나리오를 테스트하면 점수를 받는다. 엔진 정보를 조사하면 점수를 받는다. 버그 리포트를 기록하면 점수를 받는다. 이 시스템은 관리와 사용, 이해가 쉬워야 하고, 진행사항이 잘 보여야 한다.

각각의 하위 프로젝트가 끝날 때 영웅의 전당 표는 고정되고, 점수는 모든 테스터의 현재 상태, 파워 레벨, 이월 점수를 기록한 스프레드시트로 옮겨진다. 각각의 하위 프로젝트에 대해 이 모든 것이 타임라인으로 기록된다.

원본 이미지 링크 :
http://gamasutra.com/db_area/images/feature/184703/image2.jpg

모든 활동이 사전에 잘 계획되거나 준비되는 것은 아니고, 개발이 진행되는 동안 갑자기 발생하는 업무가 있을 수도 있다. 이 때문에 퀘스트 보드(Quest Board)가 있다. 퀘스트보드는 하위 프로젝트에 특화된 것으로 영웅의 전당 스레드에 꾸준히 업데이트되는 부분이다. 퀘스트 보드는 필요할 경우 테스트 초점을 빠르게 전환 해주고 테스트 시스템을 역동적으로 만들어준다. 여기에는 테스터들이 완수했을 때 성과와 점수를 얻게 되는 비격식 업무들이 나와 있다. 이 업무는 "이 스프레드시트를 정리하라"나 "이 주제에 대한 정보 몇 가지를 찾아라" 또는 심지어 "괜찮은 테스터를 더 찾아라" 같은 것일 수도 있다.

대체로 테스터들에게는 사생활이 있으므로(가끔은 그런 척이라도 하는데) 테스트를 쉬거나 그만둬야 할 수도 있다. 이것을 수용하기 위해 테스터를 쉬게 해주되, 작업을 시작하지 않거나 개발 진행 알림을 더 이상 받지 않기로 한 테스터는 즉시 제적시키는 수동적인 규칙을 만들었다.

"삼등분 법칙(Rule of Thirds)"은 사진에서만이 아니라 이곳에서도 빛을 발한다. 팀에 새로 들어오거나 비활성 상태에서 시작하거나, 활성 상태에서 실패한 테스터는 하위 프로젝트 진행 초반 1/3 기간 내에 최소점수의 1/3 이상은 달성해야 제적당하지 않을 수 있다. 이 시스템은 관리도 간단하다. 스프레드시트에서 플래그 하나를 바꾸고, 논란이 되는 모든 후보자들의 해당하는 하위 프로젝트 1/3 점수표를 체크한다.

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