성공을 위한 실패 : 게임플레이를 간단한 플레이어 메트릭스로 전환하기
크리스 프루엣(Chris Pruett) 가마수트라 등록일(2010. 12. 16)
http://www.gamasutra.com/view/feature/6155/hot_failure_tuning_gameplay_with_.php
[이 글은 2010 년 9 월 Game Developer magazine 에서 발췌한 것으로, 구글 게임 개발 지지자 Chris Pruett 이 안드로이드 게임, Replica Island 에 어떻게 빠르고 값싼 메트릭스를 구현했는가를 설명하고 있다.]
다른 사람이 당신의 게임을 지켜 보는 것 만큼 좋은 것은 없다. 개발 과정 중에, 당신은 매일 게임을 하고, 아마도 무의식적으로 특정한 플레이 스타일을 개발했을 것이다. 그러나 게임에 대한 경험이 많지 않은 사람들에게 당신의 게임을 플레이 하도록 하면, 당신의 디자인이 어떤 방식을 이해되는지를 알아볼 기회를 가지게 된다.
충돌이 발생하고, 애니메이션이 끊어지고, 튜노리얼 메시지가 혼란스러워지며 간헐적으로 발생하는 버그는 초보자가 게임을 플레이 할 때 더 증폭적으로 나타난다. 얼마나 많은 버그를 고치고, 얼마나 많이 게임을 수정하더라도, 당신의 플레이 스타일과 친근한 콘텐츠 유사성은 다른 이용자가 즉각적으로 마주치게 될 문제의 편견을 피할 수 없게 한다.
때문에 플레이 테스팅은 좋은 게임을 만들기 위한 필수적인 부분이다. 플레이 테스팅의 궁극의 결과를 가지기 위해서, 당신은 게임 플레이 메트릭스를 모으는 나의 경험을 통해서 데이터를 모아 보려고 할 것이다.
단순하게 시작하기
Game Boy Advance games 로 이야기를 시작하고자 한다. 그때, 플레이 테스팅에 대한 우리의 생각은 매우 직선적이었다 : 우리는 지역의 어린이를 초청하여 그들에게 GBA 를 준 다음, 얼마동안 플레이를 하게 하고 영상을 촬영했다. 그리고 나서 촬영 영상을 리뷰하였다. 이 절차는 즉각적이고 극적인 버그를 찾을 수 있게 해 주었다.
개발 팀이 당연하다고 여겼던 영역이 테스터에게는 무한한 좌절을 안겨주는 원천이 되는 경우가 많았다. 타겟 오디언스가 특정 영역에서 지속적으로 실패하게 될 경우, 이것은 뭔가 고쳐져야 한다는 명확한 메시지를 전달한다. 이 생생한 테스트와 만들고 있는 게임에 대한 반복적인 플레이를 통해서 게임은 향상될 수 있다.
요즘, 나는 안드로이드 휴대폰 게임을 개발하고 있다. 나의 첫 번째 안드로이드 게임인 Replica Island 는 스크롤 게임인데, 10 년전 내가 만들었던 GBA 게임과 크게 다르지 않다. 그러나 일부 변한 것도 있다 : 나는 더 이상 게임 스튜디오에서 일하지 않는다 ; 나는 Replica Island 를 혼자 만들었는데, 한 명의 아티스트의 도움을 받았을 뿐, 대부분 여유 시간에 작업을 진행했다.
나는 또한 더 이상 어린 플레이 테스터를 동원하지 않는다. 만약 내가 예전에 그렇게 했다하더라도, 이제 나의 타겟 오디언스는 조금 더 나이 들어 있는 층이다. 그리고 누군가가 플레이하고 있는 동안 핸드폰의 결과물을 기록한다는 것은 쉬운 일이 아니다. 핸드폰을 게임을 이용하고 있는 사람을 어깨 너머로 관찰하는 것은 너무 이상하기도 하고, 테스트 플레이에 영향을 미칠 수도 있기 때문에 테스트 자체가 어렵다.
인디 핸드폰 게임 개발자들은 어떻게 하고 있을까? Replica Island 의 완전성에 대하여, 나는 이 게임이 재미있다는 것을 증명할 어떤 방법도 없다는 것을 깨달았다. 게임은 거의 다른 사람의 도움 없이 만들어졌고, 내가 이 게임에 대한 자신감을 가지기 위해서는 출시하기 전에 더 많은 사람들의 견해가 필요했다.
내가 노력한 첫 번째 일은 이용자 조사였다. 나는 이메일을 보내 게임을 하고, 결과를 알려달라고 하였다. 심지어 게임에 대한 몇 가지 질문을 형성하여 피드백 포럼을 구성하였다.
이 접근법은 꽤 실패적이었다. 많은 사람들이 게임을 다운로드 하였지만, 1% 미만의 사람들만 나의 5 문제 설문을 채워주었다. 그러나 이것 조차도 충분한 정보를 제공해 주지 않았다. “게임이 너무 어렵다”는 것이 플레이어 콘트롤의 문제인지, 레벨 디자인의 문제인지, 퍼즐 디자인의 문제인지, 아니면 튜토리얼 레벨의 문제인지를 판별해 내는 것은 너무 어려웠다.
메트릭스에 대하여 생각하기
이러한 실패 후에, 나는 Naughty Dog 이 개발한 오리지널 Crash Bandicoot 의 플레이어 메트릭스 시스템에 대한 기억이 났다. 이 시스템은 메모리 카드에 플레이에 대한 통계를 작성할 수 있게 해 주며, 플레이어의 실패 수와 플레이 기간 등을 기록하여 플레이어의 게임 경험이 극한에 이르는 지점을 찾을 수 있게 해 주었다.
이 문제의 지점은 수정되었고, 데이터는 다시 게임의 역동적인 난이도 조정을 조율하는데 활용되었다. Naughty Dog 은 게임 종료 화면은 어떤 비용을 들이더라도 피해야만 한다는 생각을 가지고 이 시스템을 개발하였고, 이 생각은 정말 흥미로운 원칙 중의 하나이다. 이들의 최종 목표는 플레이어가 게임에 갇혀서 계속해서 플레이를 할 수 없는 “선반 상태”가 일어나지 않도록 하는 것이었다.
나는 이것이 꽤 좋은 아이디어라고 생각했다. 그러나 나는 이것을 어떻게 휴대폰에 적용할 수 있을지 확신하지 못했다. 나는 예산을 많이 들인 게임의 메트릭스 리코딩 상태가 어떠한지를 알아보았고, 많은 회사들이 플레이어의 액션에 대한 통계를 기록하고 있다는 것을 알았다. 몇몇 사람들은 나에게 그들이 많은 정보를 수집하고 있으며, 특정한 디자인 변경을 제시할 결과를 데이터로부터 분석하는데 어려움을 겪고 있다고 말해주었다.
반면에, 일부 스튜디오는 레벨에 따라서 플레이어의 경로를 재창조할 수 있는 도구를 가지고 있었고, 이용자가 선호하는 무기에 대한 통계를 가지고 있었다. 어떤 적인 특히 강한지, 지도의 어느 부분이 특히 눈에 들어 오는지 등에 대한 선호체계도 알고 있었다. 플레이어 메트릭스의 콜렉션은 다양한 게임에 적용될 수 있을 듯 보였지만, 그들이 모은 데이터를 처리하는 도구를 만드는데 유의미한 시간을 보낸 스튜디오만을 위한 것이었다.
(이런 종류의 시스템이 극단으로 치닫는 예로써, Georg Zoeller 가 언급했던 BioWare 의 the crazy system 를 찾아 보라.) 데이터를 수집하는 것은 쉬운 부분이지만 디자이너가 활용할 수 있는 방식으로 렌더링 하는 것은 훨씬 어려움이 틀림없다.
낙담시키는 듯이 들리겠지만, 나의 목표는 나의 도구를 가능한한 단순하게 유지시키는 것이었다. 그러나 나는 어쨌든 메트릭스 레코딩을 실행하기로 결심했고, 몇 가지의 핵심 메트릭스를 가지고 시작하였다. 나의 안드로이드 핸드폰은 메모리 카드를 가지고 있지 않았지만, 지속적인 인터넷 접속이 가능하였다. 내 생각에, 내가 중요한 이벤트에 로그할 수 있고, 그것을 서버에 보낸다면, 이런 방식을 플레이어의 결과를 가질 수 있을 것 같았다. 나의 목표는 시스템을 가능한 한 단순하게 유지하면서 가능한 한 플레이어를 이해할 수 있는 방법을 찾는 것이었다.
기본 시스템
내가 작성한 로깅 시스템은 세 부분이다 : 플레이어 이벤트를 모으는 게임 런 타임 쓰레드와 이 정보를 서버에 보내는 부분, 서버 ; 그리고 서버에 기록된 데이터를 분석하는 툴.
“서버”는 두번째 구성 요소에서 중요한 단어이다. 내 서버는 PHP script 여서, 보내진 HTTP Get query 를 인증하고, MySQL 데이터 베이스에 결과를 작성했다. Query 자체는 완전히 단순하다 : 이벤트 이름, 레벨 이름, xy 좌표, 버전 코드, 세션 아이디 와 시간 스탬프. 이러한 필드는 데이터베이스에 글자 그대로 기록된다. 데이터의 실질적인 프로세싱은 스페셜 대시보드 페이지가 로드될 때, 요청에 의해서만 가동되는 PHP 에서 이루어진다.
나는 두 가지의 이벤트로 시작했다 : 플레이어 죽음과 레벨 완료. 플레이어가 죽거나 레벨을 완료할 때 마다, 게임은 서버에 이벤트에 대하여 리포트 한다. 이 데이터로부터, 나는 꽤세부적인 게임 흐름에 대한 오버뷰를 구성할 수 있었다. 나는 어떤 레벨이 어느 정도의 시간을 요하는지를 알 수 있었고, 어느 부분에서 플레이어가 가장 많이 어려움을 겪는지, 어디에서 가장 쉽게 해결하는 지 등을 알 수 있었다.
독특한 플레이어 수로 나누어서, 나는 특정 지점에서 플레이어가 죽는 퍼센트를 알 수 있었고, 각 플레이어의 평균 죽음의 수를 알아냈다.
이벤트의 공간 위치를 봄으로써, 적과의 싸움에서 이기지 못해 죽음을 맞이하는지, 뜻밖의 상황에서 죽음을 맞이하는지를 구별할 수 있었다. 이 단순한 메트릭스 시스템은 꽤 세부적인것을 증명해 주었다.
밝은 붉은색으로 실패를 강조하기
기본적인 시스템을 만들어 운영한 다음, 나는 테스트에게 업데이트를 거친 버전으로 플레이를 하게 하였다. 그리고 습득한 데이터를 보았다. 매우 빠르게 패턴이 나타났다. 최소한 하지점에서 거의 플레이어가 전부 다 죽는 레벨이 있었으며, 또 다른 지점에서는 몇 시간 동안 빠져 나오지 못하기도 하였다 (5 분 정도 걸리는 레벨은 좋은 디자인은 아니다). 숫자를 보는 것만으로도, 나는 어떤 레벨이 가장 작업을 필요로 하는 지에 대한 명확한 그림을 그릴 수 있었다.
그러나 문제가 있는 레벨을 구별하는 것만으로는 충분하지 않았다. 때로 나는 특정한 레벨이 왜 문제인지를 구별할 수 없었다.
그래서 나는 한 단계 더 들어갔다. 같은 데이터를 활용하여, 나는 탑 레벨에서 죽음 위치를 알아낼 수 있는 도구를 만들었고, 그 결과 나는 이용자가 어디서 죽어가고 있는지를 정확하게 볼 수 있었다(그리고 그들이 어디서 활발히 살아 움직이는지를 볼 수 있었다). 한명의 플레이어가 죽을 때마다 레벨에 작은 점을 그리게 되는데, 플레이어의 수가 많아지면, 죽음의 위치가 많은 지도를 렌더링하여 레벨 수준을 바꾸었다.
※ 자세한 내용은 첨부(PDF)화일을 참고하시기 바랍니다.
|