사후검토: A 프로젝트

프로젝트 소개

A 프로젝트는 아케이드 업소용으로 제작된 터치 디바이스 기반 미니게임 모음 게임이다. 코나미 Konami 의 ‘비시바시 Bishibashi 시리즈’, 엑스포테이토의 ‘컴 온 베이비 Come on Baby’와 비슷한 구조의 아케이드 게임으로 터치 스크린을 이용한 미니 게임들을 새로 디자인 하여 게임 내에 삽입 하였다.

비슷한 게임
프로젝트와 비슷한 포지션의 비시바시(좌) 컴온 베이비(우)

게임을 시작하면 캐릭터 선택 및 기기가 지정해주는 미니 게임을 선택하여 최대 3~4 개의 미니 게임을 연속으로 즐길 수 있다. 매장 내 동일 기기 간 네트워크 연결을 지원하여 점수 경쟁을 통한 ‘경쟁 모드’가 구현되어있다.

프로젝트는 베타 릴리즈 상태로 사내에서 잠정 중단 된 상태이다-현재 해당 프로젝트를 진행했던 인원 전원이 다른 프로젝트에 배속, 퇴사 등으로 인하여 팀이 흩어져 있으며, 사실상 프로젝트가 와해되어있는 상황이다.

  • 프로젝트: A Project
  • 플랫폼: 아케이드 업소용 – 윈도우즈 / PC 플랫폼
  • 기기: 커스텀 PC / 터치 스크린
  • 개발 기간: 2009. 06. ~ 2010. 05. (12 개월)
  • 개발 인력: 약 110 M/M (월 평균 약 9 M/M, 최대 인원 Full Time: 9, Part Time: 3)
  • 상태: 베타 릴리즈 / 프로젝트 잠정 중단1

잘 된 부분

프로젝트 개발 프로세스 정립

프로젝트 초창기에는 개발 프로세스라는 형태가 공식적으로 존재하지는 않았다. 나름 게임 개발 업계에서 십 수년간 몸 담은 사람들이 경영진에 포진하고 있고, 마니아 층을 형성한 게임을 제작하고, 온라인 게임 개발도 한 견실한 업체였음에도 불구하고, 프로젝트 관리는 거의 전무하였으며, 초창기 개발 현장에서 보여지는 주먹구구식 개발 환경이 난립하는 회사 상황에서 팀 내의 개발 프로세스를 확립하는 일은 그리 쉬운 일은 아니었다.

팀 내에 개발 프로세스를 도입 할 때의 팀원들의 저항(그런 것 없이도 우린 잘 해왔다 식의)이 있을 것이라 예상되었기 때문에, 팀 내에서 뜻을 가지고 있는 프로그램 – 게임 디자인 파트에서 먼저 프로젝트에 필요한 의사소통 라인을 만들었다. 회의 및 개별 면담 후, 개발 문서를 제작 이를 SVN을 이용하여 일괄 배포하였고, 지속적으로 수정하고 재배포 함으로써 개발 중 발생하는 커뮤니케이션 문제를 억제할 수 있는 환경을 만들었다. 그리고 개발 중 발생하는 이슈를 이슈 트래커 Issue Tracker 인 맨티스 Mantis 를 이용하여 모든 이슈 사항을 기록하였다.

개발 중 이슈 트래커로 이용한 맨티스

기반 시스템이 완성 된 이후, 프로젝트를 진행하면서 개발 프로세스 관련 문제가 불거질 때 마다, 그래픽 파트, 기획 파트 등의 인력 들을 하나 둘 설득해 가면서, 개발 프로세스를 위한 관련 툴의 사용법을 교육하고, 프로세스에 대한 이해를 팀원 하나 하나에 넓혀가면서, 팀 전체가 하나로 정립된 프로세스에 맞춰 업무를 진행 할 수 있도록 하였다. 약 3~4개월에 걸쳐 이를 천천히 추진함으로써, 새로운 개발 프로세스에 대한 팀 내 저항을 최소화 하였으며, 개발 프로세스 정립으로 인한 장점들을 팀원들 하나 하나가 체득해 나가면서 프로젝트의 진행에 탄력이 붙기 시작했다.

프로세스에 대한 전체적인 관리는 각 개발 파트(게임 디자인, 프로그래밍, 그래픽)의 팀장들이 각 팀원들에 대한 업무 관리를 진행하였다. 이를 뒷받침하기 위한 협업 개발 툴(개발 페이지, SVN,맨티스)에 대하여 별도 관리 담당자를 지정하여 팀원들이 개발 툴을 100% 활용 할 수 있도록 서포트 하였다. 별도로 제작된 개발 페이지에서는 개발 일정, 최신 개발 이슈 현황, 일일 빌드 현황을 개발 팀원 누구라도 손쉽게 확인 할 수 있도록 하였다. 매 주 정기 회의에서는 통계 처리된 업무 진척 상황을 보여줌으로써 객관화 된 프로젝트 진척 상황의 공유가 가능하도록 하였다.

리소스 관리 및 배포

프로젝트 진행 중 발생하는 모든 리소스는 SVN Subversion 을 이용하여 관리/배포 하였다-팀 내 SVN을 도입 하기 이전에는 메일과 공유 폴더를 이용하여 리소스가 관리되고 있었다. SVN에서 프로그램 소스 뿐만 아니라 모든 문서, 그래픽 및 사운드 리소스, 심지어 일일 빌드 결과물까지 통합적으로 관리하여 개발 도중 리소스를 분실하여 시간을 버리는 일이 없도록 하였다-물론 모든 리소스를 SVN에 관리하다 보니 개발 후반부에 SVN이 점차 느려지는 현상이 발생하기도 하였다.

개발 문서의 경우 수정 사항이 발생 할 경우, 해당 수정 사항을 반영한 문서를 바로 커밋하여 팀원들이 항상 최신의 문서에 접근 할 수 있도록 하였다. SVN의 기록 기능과 문서 상에 수정 이력, 그리고 해당 이슈에 기록을 통하여 수정 사항에 대해서 팀원들이 놓치지 않도록 주의를 기울였다.

그래픽 리소스에 대해서도 기존 개인 작업 폴더 – 공유 폴더로 유지 되면서 버전관리 및 리소스 관리가 되지 않았던 부분을 SVN에 통합시키므로써, 리소스 분실, 중복, 과거 내용을 덮어 씌우는 사고 발생이 줄어들었으며, 이는 프로젝트 수행 시간을 절약하는데 많은 역할을 하였다.

SVN을 관리하는 담당자가 배정되어, 팀원들에 대한 SVN 이용법 교육, 사용자 문제 해결, SVN 저장소 관리 등의 업무를 진행하였으며, SVN 이용에 대한 가이드라인을 만들어 공유하고, 해당 가이드라인에 맞게 관리 함으로써, 효율적인 업무 진행을 이끌어내었다.

또한 빌드 자동화 시스템을 도입하여, 전날 작업 된 결과물을 바로 다음 날 확인 할 수 있도록 하였다. 게임 디자인 담당이 매일 아침 빌드 된 게임을 테스트 하면서 일반적인 버그 및 실행 오류 등의 문제를 잡아내고, 이를 즉시 처리했기 때문에 프로젝트 후반까지 자잘한 버그로 인하여 고생하는 경우는 거의 존재하지 않았다. 모든 팀원들은 매일 새로운 빌드를 가지고 30분 ~ 1시간씩 이른바 ‘개밥 먹기’에 동원 되어 게임을 테스트 하고 문제 사항을 수정하는 과정을 거쳤다.

빌드 자동화 프로그램으로 유명한 CC.net을 사용했다
프로토타이핑

미니 게임 제작 시의 기본 제작 프로세스는 제안 – 게임 디자인 검수 – 프로토타이핑 – 사내 테스트 – 실 제작의 형태로 진행되었다. 게임 1종 당 보통 1~3개월의 개발 기간이 소요 되었다. 미니 게임에 대한 프로토타이핑은 ‘재미있는 게임’과 ‘재미없는 게임’을 사전에 걸러내는 필터 역할을 충실하게 하였다. 제안서 상 재미있을 것 같은 게임이 막상 구현 시 재미없다는 사실을 사전에 알 수 있는 방법은 빠른 프로토타이핑 뿐이며, 덕분에 난립하는 제안서 중에서 제대로 된 미니 게임들을 선택하여 게임 내에 포함 시킬 수 있었다.

초기 미니게임 프로토타입 중 하나

잘 되지 못한 부분

일관된 프로젝트 목표 부재

처음 프로젝트가 킥 오프 될 당시 제품 목표는 아케이드 업소를 찾는 라이트 유저-게임 소비 시간이 한정적이고 캐주얼 게임을 즐기는 층을 시장 목표로 잡고 이에 어필 할 수 있는 제품을 만드는 것이었다. 시장 목표의 특성으로 여성과 어린이, 그리고 복잡한 게임에 익숙하지 않고 경쟁보다는 즐거움을 소비하는 것으로 자체 리서치 결과 판단되었고, 이에 대한 팀원들의 이해와 공유가 이뤄진 상태에서 프로젝트는 진행되고 있었다.

파국이 찾아온 것은 게임 개발이 어느 정도 완료된 이후 제품에 대한 포커스 그룹 테스트가 진행된 이후였다. 테스트 결과 주요 항목 평균이 10점 만점에 7~8점을 기록했기 때문에 최종 발매 결정에 별 다른 장애가 없을 것으로 예상되었지만, 갑작스럽게 프로젝트 목표를 라이트 유저 및 헤비 유저(대전 액션 등의 게임을 즐기는 하드 코어 유저) 성향의 소비자들이 사용할 수 있는 게임으로 일방적으로 변경 된 것이다.

이미 제품의 개발이 막바지에 다다른 상황에서 있을 수 없는 일이지만, 결국 무리한 설계 변경과 게임 난이도 변경을 통하여 게임은 애초의 기획과는 다르게 색이 불분명한 게임이 되어버리고 말았다-게임은 지나치게 어려웠지만, 그렇다고 이를 지속적으로 즐기기 위한 도전 욕구를 불러일으키는 것도 아닌 형태가 되었고, 애초 프로젝트 목표였던 라이트 유저에게는 다가가기 힘든, 그리고 헤비 유저들에게는 난이도만 높고 따분한 게임이 되어버린 것이다.

비 상식적인 일정과 몰아 붙이기 식 팀 관리

프로젝트를 시작 할 때 제안서 상에 의하면 개발 예상 기간, 개발 예산, 소요 인력, 예상 매출액 등이 존재했지만, 사실 어느 항목 하나 제대로 된 ‘근거 자료’는 전무했다. 때문에 말도 안되는 개발 일정이 팀원들에게 떨어졌다. 초기 개발 예상 기간은 실제 실무자들의 예측에 비하여 반 이상 짧게 잡혀 있었고, 이에 대한 어필을 하더라도, 개발 기간 연장은 관행인 것 마냥 이 문제를 대수롭지 않게 생각하고 있었다-결국 이런 태도가 경영진의 팀 및 프로젝트에 대한 불신을 부채질 한 원인 중 하나였다.

이런 책이 괜히 있는 것은 아니다 – 맨먼스 미신

제품 개발을 위한 연구/개발 활동이 일정상 불가능 한 상황에서 어처구니 없는 개발 스펙을 요구하는 일도 비일비재 했다. 개발 팀의 역량, 현재 상태, 필요 자원 등에 대한 고려는 일절 무시 한 체, 안되면 말지 식의 제안이 나오는 경우도 허다 했다. 개발 팀은 현실적인 개발 스펙 제시 및 이에 대한 수정 일정을 제시하고 이를 철저하게 지키는 데 역량을 집중했다. 때문에 최소한 ‘본인 입에서 나온 일정’은 지킬 수 있었다.

위기 관리 능력 부재

어떠한 프로젝트든 마찬가지로 위험은 존재하는 법이며, 이 프로젝트에서도 각종 위험 요소들이 존재하고 있었다. 가장 큰 문제는 프로젝트에 대한 경영진의 신뢰 여부였는데, 경영진과 팀간의 커뮤니케이션은 심각한 문제가 있었다. 나중에 확인 된 일이었지만, 경영진이 알고 있는 프로젝트와 개발 팀이 알고 있는 프로젝트는 전혀 다른 종류의 것이었다.

인적자원과 관련한 문제도 존재했다. 프로그램 팀장의 병역특례와 관련하여 훈련소 입소 문제는 프로젝트 시작 전부터 확인 된 문제였고 이를 회피 할 수 있는 상황이었음에도 불구하고, 아무런 조치를 취하지 않은 체 가장 중요한 프로젝트 막바지에 이르러 입소하게 하는 상황을 자초했다-덕분에 프로젝트는 프로그램 팀장의 군사 훈련 기간 동안 진척 없이 표류하기만 했다.

잘못 설정한 프로젝트 진행 기간으로 인하여 제작 필수 인력을 타 팀에 빼앗기는 상황이 발생하기도 했다. 무리한 일정을 기반으로 다른 팀과 인력 교류를 약속했다가, 역시 프로젝트 막바지에 해당 인력이 팀을 옮기는 상황이 발생하였는데도, 이에 대한 대체 인력 충원 등의 대책은 나오지 않았고 프로젝트는 그냥 속행 되었다.


결과

프로젝트는 정상적으로 진행되지 않았고, 사실상 실패(게임 업계에서 ‘잠정 중단’은 ‘영구 폐기’와 유의어)하였다. 팀 내/외에서 많은 문제점들이 있었기 때문에 당연한 결과였을지 모르지만, 덕분에 프로젝트 관리와 리더십에 대한 반면교사가 될 수 있었다고 생각한다. 프로젝트의 목표 설정, 관리, 리더십에 관하여 성찰을 하는 데 더 없는 기회가 되었다는 것은 이 성공하지 못한 프로젝트가 가진 가장 큰 성공이 아닐까.


  1. 한참 시간이 흐른 뒤 전해 들은 바로는 게임은 해외 시장에서 정식 발매 및 유통이 되었었다고 한다.(2019. 05. 08. 추가)

사후검토: GRBT Game Rating Board Tycoon

GRBT Game Rating Board Tycoon 는 약 1년 전 다니던 회사를 관두기 직전부터 익히기 시작한 플래시 기반 스크립트 언어인 액션 스크립트를 독학하면서 간단하게 만들어 볼 게임이 없을까하며 만들기 시작한 게임이다. 제목에서 나타내고 있듯 한국의 게임물 등급 분류 기관인 게임물 등급 위원회(이하 게등위)를 소재로 하고 있으며 다분히 해당 단체를 풍자하기 위한 의도를 가진 시리어스 게임 Serious Game 으로 기획되었다.

게임은 대단히 단순한 구조로, 제한시간 내에 ‘심의를 받지 않고’ 서비스 되고 있는 해외 각국의 게임들을 차단하는 것을 기본 목표로 한다. 세계 지도 상에 나타나는 아이콘은 전 세계에서 발매되는 미심의 게임을 의미하며, 이 아이콘들을 클릭하면 바로 차단 처리가 되면서 아이콘이 사라지며 하단의 차단율이 올라간다.

게임 클리어 목표는 80% 이상 차단이지만, 사실상 일반적인 ‘인간’의 경우에는 클리어가 불가능 하도록 세팅하려 했다-이는 2008년 당시 게등위에서 ‘국내에 유통되는 모든 게임’을 심의 대상으로 삼았음에도 불구하고 플래시 게임의 경우 고작 0.35% 정도의 심의율을 보였다는 국정감사 결과를 보고 비꼰 것이다. 2년이 지난 지금도 여전히 게등위의 심의 등급물 처리 능력은 미진한 가운데 다양한 플랫폼과 오픈마켓의 활성화 등으로 인한 급변하는 산업에 대한 적절한 대책이 없이 규제 일변도의 심의 정책을 고수한다는 논란은 계속 되고 있다…


가벼운 마음-사실상 액션 스크립트의 연습을 생각하고 만든 게임이기 때문에 게임 자체의 구현에 신경을 쓰기로 하고 세부적인 부분에 대한 것들은 전부 제외 하였다. 그럼에도 불구하고 제작 기간에 1년의 공백이 생긴 것 역시 가벼운 마음으로 시작된 원인이 컸다. 코딩이나 프로그램 구현에 대해서 전문적으로 공부를 시작한 적은 없었기 때문에 최근 소스를 수정하기 위해 다시 코드를 보았을 때 너저분한 구조에 치를 떨었 수 밖에 없었던 것도 사실이다. 게임 편의를 위한 몇몇 기능들-예를 들어 게임 재시작 같은 기능은 프로그램을 처음부터 다시 짜야 된다는 부담 때문에 결국 포기하고 말았다. 회사를 두어번 옮기면서 삶에 여유가 없었다는 핑계를 델 수도 있지만, 치명적인 게으름은 역시 핑계가 되지 못하는 것 같다.

리소스 등은 저작권이 허락하는 범위 내의 이미지나 사운드 효과음 등을 이용하여 제작하였다. 최대한 저열한 가운데 게임을 만들어보자는 생각으로 단순하게 만든 게임이기 때문에 게임의 외형에 대한 부담은 없지만, 게임의 내용이 사용자에게 잘 전달이 될지에 대한 것은 의문인 점은 걱정일 수 밖에 없다.

1년이나 지난 이후에 게임을 다시 정리하기 위해 꺼내들었지만, 다행(?)이라면 지금까지도 별 달리 상황이 변한 것은 없었기 때문에 게임의 시의성이 상하지 않았다는 것이다. 오픈마켓 게임물에 대한 자율 심의에 대한 내용이 담긴 게임법 개정안이 올해 초 발의 되었지만, 갖가지 국내외 정치적인 문제로 인하여 국회 내에서 표류되어버렸던 것이다. 덕분에 GRBT가 가지고 있는 의미는 아직도 유효하며, 한참이 지난 지금에서야 정리를 해서 릴리즈를 해도 괜찮은 이유라고 생각한다.

추가1(2019. 05. 08.)

게임의 SWF 파일을 공개 할 예정이다. 게임물 등급분류를 완료한 후, 준비가 되는 대로 공개하도록 하겠다.

추가2(2019. 06. 04.)

게임물 등급분류가 완료 되었다. 게임을 체험해 보고 싶다면 이 링크를 눌러 게임물을 다운로드 받으면 된다. 게임 실행 방법은 다음과 같다.

  • 구글 드라이브 폴더의 GrbtProject.swf 를 다운로드 받는다.
  • 플래시 플레이가 가능한 프로그램(인터넷 브라우저, 카카오 팟플레이어 등)에서 파일을 로드하면 바로 게임이 시작된다.
  • 별도의 게임 종료, 재시작은 없다. 플레이어 프로그램을 종료하거나, 파일을 다시 불러오면 된다.

사후 검토: Sissy Fight 3000 – 제 2회 게임 디자인 워크샵

프로젝트 소개

Sissy Fight 3000은 게임 디자인 방법론인 MDA 프레임워크와 관련한 실습용 프로젝트이다. 기본적인 게임 시스템은 카드를 이용한 대전 형태의 게임으로, 각 플레이어는 목표 카드Target Card와, 행동 카드Action Card, 그리고 자존심(일종의 HP Health Point)을 가지고 시작을 하게 되며, 각 턴이 시작 될 때 마다 자신이 선택할 행동(공격, 협동 공격, 방어)에 대한 카드와, 그 행동의 대상이 되는 목표 카드를 제시함으로써 결과를 가늠하는 형태로 진행된다. 최종적으로는 자신의 자존심을 지키고 상대방의 자존심을 0으로 만들어 승리를 쟁취하는 형태의 게임이다. 여기에 한가지 제약 조건이 붙는데 게임 내의 모든 커뮤니케이션은 완전 공개를 원칙으로 한다-즉, 상대에 대한 연합 작전이나 뒷담화도 공개적으로 해야 한다는 규칙이 붙는다.

여학생들의 자존심 싸움이라는 기본 스토리 컨셉을 가지고 있지만, 사실 시커먼 남자들이 게임을 해 보면 여학생들의 생기 발랄함(…) 따위는 전혀 찾아 볼 수 없는데다가, 공개적으로 열려있는 커뮤니케이션 때문에 중상 모략과 각종 간계가 판을 치게 된다. 흡사 플레이어 전부가 조조나 사마의, 제갈공명이라도 된 듯, 서로를 기만하거나, 협력하고 또는 배신하는 형국이 매 턴마다 치열하게 펼쳐지기 때문에 스토리 컨셉과 게임 내용이 대체 맞긴 한건가…? 하는 의심이 들 정도이다. 하지만, 처음 보는 사람들끼리라도, 가벼운 마음으로 진행하기에는 적당한 형태의 게임이기 때문에, 기본 설정 그대로라도 게임은 충분히 재미있고, 즐거운 형태가 될 수 있었다.

프로젝트 팀

2009년 4월 23일 늦은 저녁시간에 열린 제 2회 게임 디자인 워크샵에 참석한 분들의 면면은 프로그래머, 게임 기획, 그래픽 등등 여러 분야의 실무진 분들이 모여있었다. 지인들과 함께 온 분들도 몇몇 있었지만, 대부분은 아마 지금 이 글을 쓰고 있는 본인 처럼 서로를 처음 대면하는 자리였으리라 생각되어진다. 참여자들은 총 4개의 팀으로 랜덤으로 구성되었고, 우리 팀은 나를 포함 총 5명의 인원이 같이 자리에 하게 되었다.

첫번째 연습 게임이 끝나고, 각자 게임에 대한 룰에 대한 파악이 어느정도 끝났을 때 즈음, MDA 프레임워크에 대한 설명과 함께, 각 팀에게는 가상의 ‘퍼블리셔’의 사업부에서 온 메일 한통이 하나씩 전해 지기 시작했다. 이른바 사업부의 꼬장질(…)이 시작된 것이었는데, 각 팀은 자신의 퍼블리셔의 비위를 맞춰주기 위해 메일에 제시 된 불만 사항을 접수하고 해결해줘야 하는 과제가 주어졌다. 여러가지 과제들-게임의 한 라운드를 1분 이내로 마칠 수 있도록 해 달라던가, 혹은 게임의 커스터마이징이 손쉽게 될 수 있도록 해 달라라는 등-가운데 우리 팀에게는 ‘게임의 대상 연령인 8세 ~ 13세의 포커스 테스트에서 룰이 지나치게 어렵고 권모술수가 난무하는 게임이라 아이들이 거부감을 느낀다(그러니 좀 어떻게 좀 해 봐 달라, 그리고 우리 딸 애가 애완동물을 너무 좋아하는데… 그냥 그렇다고)’란 과제가 주어졌다. 그리고 주어진 시간은 약 1시간 이내! ‘젠장, 우리가 개발한 것도 아닌데…’라고 투덜거릴 여유도 없이, 팀원들은 바쁘게 논의에 들어가야 했다.

진행

‘ 우리가 개발 한 것도 아닌데’였기 때문에 당연히 초반에는 방향을 잃고 해맬 수 밖에 없었다. 처음 게임을 즐겨보고 난 이후에 감상에 대해서 논의가 오가는 도중, 룰의 복잡함에 대한 문제제기가 발생했고, 어린 아이들 대상에서는 복잡한 생각 보다는 게임이 단순하고 순간 순간에 집중 할 수 있도록 해야 할 필요가 있다는 의견이 나왔다. 나는 ‘공개된 커뮤니케이션 규칙’으로 인하여 어린 아이들이 친구를 속이고 남에게 해를 주는 행동에 대해 부담을 느낄 수 있다고 생각했기 때문에 비공개 커뮤니케이션 혹은 커뮤니케이션 규칙을 없애는 쪽으로 하는 편이 좋다는 의견을 냈고, 이는 바로 받아들여졌다. 이외에도 동시 턴 방식을 순차 턴 방식으로 변환, 상대와 전략에 대한 랜덤 선택 등의 아이디어가 나왔고 첫번째 테스트를 실시 하였다.– 1차 테스트 룰

  • 목표 카드와 행동 카드를 섞어서 테이블 가운데 둔다
  • 순차 턴 방식으로 목표 카드와 행동 카드를 한 장씩 뽑아 카드 결과에 따라서 해당하는 플레이어의 자존심을 깎는다
  • 공식 커뮤니케이션은 존재하지 않는다

이내 몇 턴이 돌지 않았지만, 직감적으로 다들 ‘이건 아닌데…’라는 분위기가 팽배했다. 무엇보다 랜덤에 많은 것을 의존한 나머지 머리 싸움에 대한 재미가 심하게 없어져버렸다. 결국 1안은 곧장 폐기되어버렸다. 게임은 다시 순차 턴에서 동시 턴으로 바뀌었고, 카드를 이용하여 행동과 타겟을 선택한다는 것도 다시 살아났다. 게임 플레이 보다는 게임 자체의 UI 쪽에 문제가 있다고 생각한 팀원들은 기본 시스템을 되도록 그대로 가되 복잡함을 야기하는 요소들을 삭제하는 것으로 다시 결정을 내렸다. 이를 통하여 ‘목표 카드’가 아에 통째로 사라져버렸고, 데미지 계산을 치명적으로 느리게 하는 ‘협동 공격 카드’를 제거해 버렸다. 대신 목표는 공격하려는 대상을 행동 카드를 제시하면서 상대에게 직접 제시 하는 방식으로 바뀌었다. 그리고 ‘방어 카드’는 성공 시 완전 방어가 되지만, 1회 사용 이후 버려지는 형태로 바뀌었다.– 2차 테스트 룰

  • 목표 카드 제거: 공격 상대를 직접 가리킨다
  • 협동 공격 카드 제거
  • 방어 카드: 1회만 사용 가능

이번에는 게임은 스피디하고 단순하게 진행되었지만, 방어 카드가 너무 쉽게 버려지는 문제가 발생했다. 무엇보다 게임 전체 통틀어서 방어 카드를 1회만 사용 할 수 있는 것은 방어 전략을 선택하는 것을 최후까지 미루게 만들어 다이나믹한 전략 구성이라는 본래의 게임의 장점이 무색하게 되어버렸었다. 때문에 이에 대한 보강이 필요하다는 판단이 팀원들 사이에 공감을 얻게 되었고, 방어 카드와 사라진 협동 공격에 대한 룰이 변경되게 되었다.– 3차 테스트 룰

  • 방어 카드는 방어 성공 시 계속 사용. 단, 방어 실패(자신에게 공격이 들어오지 않았는데 방어 카드를 낸 경우)때는 방어 카드를 버리게 된다
  • 협동 공격 룰 추가: 별도의 협동 공격 카드를 넣지 않고, 한 사람에게 공격 카드가 2장 이상 들어 올 경우 협동 공격으로 간주. 데미지는 카드 수 * 2로 친다

이제 각 턴 마다 선택 할 수 있는 전략의 폭은 원작에 비하여 그리 줄어들지도 않은 상태에서 전반적인 UI는 단순해진 게임이 되었다. 소기의 목적을 달성했다고 생각한 팀원들은 프로젝트 릴리즈 5분전, 마지막 요구사항(?)인 ‘그리고 우리 딸 애가 애완동물을 너무 좋아하는데… 그냥 그렇다고’를 해결하기 위한 아이디어를 짜내기 시작했다. 팀원들 중 한 분은 자신이 선택하는 동물 캐릭터에 따라서 체력이나 공격력에 차별화를 두자는 의견을 내놨는데, 나는 이 의견에 대해서는 다음과 같은 이유로 반대를 했다. 첫번째로는 프로젝트 마감 시간이 5분 이내로 남았으며, 두번째로는 게임의 밸런스를 조정해야 될 필요가 있는데 5분이란 시간 동안 이를 해결할 방법은 없다. 마지막으로 (이에 대해서는 이야기 하지 않았지만) 기능을 넣는 아이디어 자체는 좋지만, 그 기능이 게임 플레이에 결정적인 순기능을 할 것이라는 판단이 서질 않는 상태에서 잘못 집어넣으면 게임 시스템만 다시 복잡해 질 우려가 있다는 이유였다. 다른 팀원 분께서도 ‘테스트로 검증되지 않은 시스템을 마지막에 넣는건 위험하다’라고 하셔서 결국 해당 시스템은 마지막에 철회되었다. 단, 게임의 전체적인 아트 컨셉 부분을 동물들을 보호하는 목자(또는 신)와 휘하의 동물들로 결정하였다. 최종적인 모양새에 있어서 아래와 같은 결과물이 도출되었다.– 최종 변경 사항

  • 각 플레이어는 두 장의 행동 카드(공격, 방어)와, 10개의 동물 칩(자존심을 동물 형태로 변경하였다)을 가진다
  • 10개의 동물 칩을 모두 소진하면 게임에서 지게 된다
  • 두 장의 행동 카드 중 공격은 사냥꾼 이미지로, 방어 카드는 목자 이미지로 카드 디자인 컨셉으로 디자인 한다
  • 게임 시작 시 각 턴은 ‘하나, 둘, 빵!’ 하는 구호와 함께, 자신의 행동 카드를 제시 하는 형태로 진행한다
  • 방어 카드는 자신 앞에 제출, 공격 카드는 공격하는 대상 앞으로 가리키면서 제출한다
  • 한 사람 앞에 두 장 이상의 공격 카드가 제시 되는 경우, 이는 ‘협동 공격’으로 간주되며, 제시된 카드 수 * 2 만큼의 데미지를 얻게 된다
  • 방어 성공 시 모든 공격은 무효 처리 된다. 단, 방어 실패(방어 카드를 냈을 때 자신에게 오는 방어 카드가 없을 경우)인 경우 자신의 방어 카드는 버려지게 된다

프로젝트 종료

그리고, 프로젝트 종료를 알리는 외침이 들려왔고, 각 팀의 프로젝트는 일단 종료되었다. 잠깐 동안의 휴식 시간 이후 각 팀에서 각자의 과제에 따라서 진행된 프로젝트 결과물을 다른 팀과 공유하는 시간을 가지게 되었는데, 다들 목표에 충실하게 변경하느라 노력한 흔적이 엿보였다.

우리팀의 프로젝트에 대해 자기 평가를 하자면, 어린 연령의 사용자 층에 집중한 결과 그에 걸맞는 결과물을 냈다고 생각한다. 무언가를 덧붙이는 것 보다 잘라는데 집중을 한 덕분에, 원작의 복잡한 UI는 상당히 개선되었으며, 룰 역시 직관적으로 파악하기 쉬워졌다는 것 역시 좋았다고 본다. 다만, 원작에 있었던 각 플레이어간의 치밀한 심리전은 완벽하게 제거 될 수 밖에 없었는데, 이는 게임을 소비하는 소비층에 따라서 평가가 극단적으로 갈릴 듯 보였다. 그래도 퍼블리셔가 의뢰했던 연령층에는 잘 먹히지 않을까 싶다.

게임 제작 방법론에서 프로토타입Prototype의 중요성은 익히 들어서 알고 있지만, 실제로 경험 할 수 있는 경우는 그다지 많지 않다. 우선적으로 프로토타입을 만드는데 공을 들이는 환경이 그리 많지 않다는 문제점과 더불어, 이런 방법론에 대해서 알고 있는 사람들, 그리고 그 중에서 이를 실천 할 수 있는 위치에 있는 사람들은 정말 극단적으로 소수이기 때문이다. 나 역시도 머리로 막연히 알고 있었던 부분을 실제로 체험해 보면서 일종의 쇼크를 받는 느낌이었는데, 특히 처음 보는 팀 구성원들과 고작 1시간 이내에(그것도몇장의 종이와 몇자루의 펜을 이용해서) 결과물을 만들어냈다는 것 자체가 MDA 프레임워크의 효과를 보여주는 가장 극단적인 부분이 아니었을까?-3년을 같이 일하는 동료와도 제대로 된 게임을 만들어 보지 못한 사람이라면 이것이 무엇을 의미하는지 알 수 있을것이다.

물론 MDA 프레임워크 뿐만 아니라 많은 요소들이 재미있는 게임을 만드는데 중요한 역할을 한다는 것은 자명한 일이지만, 무엇이든 처음 접하고 계속적으로 발전해 나가는 것이 가장 중요하다. 지금 내가 바라는 일은 이 경험을 지금 일하고 있는 회사의 구성원들과 공유하고 좀 더 발전적으로 나갈 계기를 만들었으면 한다. 그리고… 나도 내년에는 GDC를 가고 싶다. (…되도록이면 회사 돈으로 ;;)