게임 프로토타이핑 회고

프로토타이핑의 목적이라고 함은 실제 제품을 제작하기 전 최종 완성품이 어떻게 동작을 할 것인지를 ‘재빠르게’ 확인하는 데 있다. 뭐, 경영학 교과서에서나 나올 고리타분한 이야기를 하고자 하는 것은 아니고, 그간 프로토타이핑을 진행 하면서 부딪쳤던 문제들-특히나 위와 같은 교과서적인 이야기와 실제와의 괴리감에 대한 경험과 소감을 간략하게 정리하고자 한다.

초기의 목표

초기의 우리 팀이 프로토타이핑 기법을 사용하면서 가장 중요하게 생각한 부분은 시간과의 싸움이었다. 인디 게임 제작팀이라는 한계, 다들 밥벌어 먹고 다닐 수 있는 기반이 없는 불안한 생계, 거창하게 이야기해서 나름 목숨을 걸고 하는 일이니 째깍째깍 흘러가는 시간은 목숨만큼 소중하다고 생각했다. 때문에 활동 초기 ‘한달에 프로토타입 네개’ 같은 무지막지한 목표 같은것도 존재했었다. 그래도 그때 당시 저런 목표가 불가능하지만은 않았던 이유는 프로젝트의 규모가 고만고만한 수준이었고, 프로토타이핑의 검증 범위가 무척이나 좁았던 것에 기인했다(전투 시스템 일부, 혹은 심플한 수준의 플랫포머 시스템 검증).

Card Game Prototyping
초기엔 이런것으로 만들기도 했었다

델파이의 신탁

델포이의 무녀

완성된 프로토타입을 검증하기 위해서는 내부 테스트 및 검증을 거쳐야 한다. 하지만, 단 두 명의 비슷한 성향의 제작 당사자들이 예리하고 객관적인 시선으로 자신의 자식을 재단할 수는 없을 것이라는 판단에 의해 팀은 설문 팀을 꾸리기 시작했다. 최소한의 객관성 확보를 하고 싶다는 자위적인 판단도 함께했다. 이를 위하여 게임 개발에 종사하거나 여전히 게임 개발 활동을 하고 있는 지인들을 추려서 신탁(Oracle)을 받았다.

이른바 델파이 기법(소규모 전문가 집단을 대상으로 한 설문조사-고대 그리스의 델포이의 신탁(Oracle of Delphi)에서 그 이름을 따왔다)을 이용한 설문조사를 통하여 프로토타입에 대한 테스트 및 이에 대한 의견 수렴 등을 거치는 작업을 수행하였다.

오염된 제물

신들은 항상 깨끗한 제물을 원한다. 문제는 여기서 부터 시작했다. 내부 개발 팀에서 자체 테스트를 위한 프로토타입은 ‘어마무지하게 많은 편의 사항을 삭제’하고 신속한 개발을 하는 것이 가능하다. 어차피 내부 개발자들은 최종 제품에 대한 이미지를 항상 머릿속에 그리고 있고, 어떠한 방식으로 구현이 될지 속속들이 알고 있으니깐. 문제는 해당 제물을 ‘신들’에게 바치고 신탁을 얻을 때였다. 정제되지 않은-생략된 많은 UI들은 외부 테스터들에게 다양한 형태의 오해를 불러일으켰고 종종 테스트 자체를 불가능하게 만들어버렸다.

신중해지는 발걸음

사실 게임의 UI는 단순히 눈에 보이는 디자인과 꾸미기 문제가 아니라, 사용자가 게임을 조작하고 어떠한 방식으로 조작에 대한 피드백을 주어서 전체 게임 시스템을 파악하게 만드는 것이다. 아무리 개별 시스템의 아이디어가 충분히 멋지고 근사한 것이라고 해도 잘못된 UI 설계로 인하여 사용자가 게임 구조를 파악 못하면 기본적인 게임 플레이조차 원할하게 이뤄지지 않는다. 때문에 프로토타입 단계에서 UI를 충분히 구현하지 않을 경우 해당 프로토타입의 제작 시간을 아끼더라도 결국 잘못된 결과를 도출하게 되는 것이다.

R 프로젝트 프로토타입 외교 UI의 변화-룰은 거의 변화하지 않았지만, 상단 상태 바를 추가 함으로써 외교 시스템을 좀 더 직관적으로 이해할 수 있도록 하였다.

결국 게임 프로토타입을 제작하면서 프로토타입을 위한 ‘생략’은 대폭적으로 줄어들 수 밖에 없고 이는 필연적으로 프로토타입 제작 기간의 증가를 불러올 수 밖에 없다. 핵심적인 시스템의 구현 뿐만 아니라, 사용자가 이를 수월하게 파악하기 위한 UI 작업은 이제 선택이 아닌 필수가 되어 버렸다. 덕분에, 프로토타입이 ‘제작-폐기’ 되는 제작 순환 시스템에서  프로토타입의 제작 기간은 점차 늘어가기만 했다. 1주일에 1회였던 프로토타입 릴리즈 주기는 6개월이 지난 이후 1달에 1회 꼴로 늘어졌다.

신규 프로토타입에 대한 제작 기간이 늘어나는 것은 목숨을 건 인디 게임 제작 팀에게 있어서 그리 유쾌한 일은 아니지만, 신속함을 버린 대신 프로토타입의 검증력과 설문 기법을 통한 의견 수렴의 질은 점차 증가하였다. 무엇보다 무신경하게 지나쳤던 UI 문제로 인하여 게임 다운 피드백을 사용자에게 전해주지 못했던 프로토타입이 게임의 진행-결과에 대해 사용자에게 명확하게 피드백을 전달해 줌으로써 좀 더 게임다워졌다는 점은 가장 큰 수확이었다.

결언

게임 프로토타입 개발에 있어서 중요한 부분은 단순히 게임 내의 룰을 구현하는 것 뿐만 아니라 그 ‘룰을 기반으로 사용자와 어떻게 피드백을 주고받느냐?’이다. 시간의 압박에 쫓겨 기본 요소도 충실히 구현하지 못한 엉성한 프로토타입은 개발 전 테스트에 절대로 도움이 되질 못하며 오히려 그만큼의 시간을 추가로 낭비하는 요소로 작용한다. 게임 프로토타입에서 게임 시스템과 UI는 우선 구현 요소이며, 타협되어서는 안되는 부분이다. 게임 프로토타입 제작 규모를 가늠 할 때 위의 두 요소 중 하나라도 제외가 된다면 이미 해당 프로토타입의 가치는 반쪽이 되어버린다.

결론은, ‘재빠른’ 프로토타입의 제작 보다는 ‘기능을 제대로 보여주는’ 프로토타입의 제작이 중요하다.