글쓴이 주 -이 글은 포스트모템이라기 보다는 프로젝트의 진행시 있었던 일의 기록에 가깝습니다. 글쓰는 재주가 없기에 동굴 벽에 그려져 있는 원시인의 벽화를 보듯이 한 번씩 “이 사람은 왜 이런 부분을 썼는가?” 를 고민하면서 읽어 주셨으면 좋겠습니다.

R 프로젝트의 시작

이 프로젝트를 하기 전에 먼저 언급해야 할 프로젝트가 있습니다. Z 프로젝트가 그것으로(링크 참조) 2011년 3월 28일 야심차게 시작한 그 프로젝트는, 점차 규모가 커지는 모든 죽음의 행진 프로젝트가 그러하듯, 그동안 전혀 수행하지 않은 방식으로 개발 되었습니다. 바인딩 언어로 파이썬을 사용하였고, UI가 많이 필요 할 것이란 예상에 따라 별도의 UI 라이브러리를 만들어서 사용하였으며, 케비넷이라는 데이터 구조를 바탕으로 만들었습니다. 위의 도구들은 문서의 하단에서 다시 한번 언급하겠습니다. 사실 좋은 프로젝트는 빨리 결과를 확인 할 수 있는 프로젝트가 좋은 프로젝트인데, 단계적 개발 및 도구 적용이 아닌 전면 개발 및 도구 적용이라는 개발 포퓰리즘이 일어낸 참극 이였습니다.

Z 프로젝트로 인하여 길어지는 프로그램 담당의 방황 속에, 기획 담당은 마인크래프트 유저와 같이 일을 스스로 만들어 하기 시작합니다. 그 중 하나가 이 R 프로젝트입니다. 이미 Z 프로젝트로 충분히 정신 없었던 프로그램 담당의 도움을 받을 수 없었기 때문에 기획 담당은 스타 크래프트 2 지도 편집기를 사용하여 프로토타입을 제작하게 됩니다(링크 참조).

‘포기하면 편해’ 라는 말도 있지만 언제나 인생은 포기하는게 쉽지만은 않습니다. Z 프로젝트라는 아이에게 영양분과 산소를 계속 공급해주고, 좌절하고, 오열하는 나날 끝에, 결국 2011년 6월 10일. 3개월 가량 끌어온 작업을 포기하게 됩니다. 사실 개인적으로 게임의 재미라는 것 그리고 그 재미를 만드는 방법에 대해서 고민을 많이 하던 시기였습니다. 본인 스스로 게임 개발이란걸 십년 넘게 하다 보니 자만심이 생긴 것도 같았고, 너무 말도 안되는 실수를 계속하게 되니 자괴감도 들었습니다.

Z 프로젝트를 정리(처분)하고 성급히 무언가 할 프로젝트가 필요 했고, 그렇게 선정된 프로젝트가 R 프로젝트입니다. 사실 애초에 기획 담당이 스타크래프트2의 지도 편집기를 통해 제작한 프로토타입은 해당 게임의 전술모드였고, 그 전술모드의 상위에서 전체를 지휘하는 전략모드가 필요하다는 판단 하에 프로젝트의 규모를 확장해 버렸습니다. 네. 소위 말하는 지도 모드가 필요 했고 저는 지도 페티쉬(!)가 있습니다. 그래서 전략모드의 프로토타이핑을 강력히 외쳤던 것입니다!

 R 프로젝트의 유산상속

다나카 요시키의 은하영웅전설에서는 로이엔탈이 반란을 한 후, 최후의 전투에서 퇴각할 때. 비록 패배하고 퇴각하지만 엄격한 군율에 의해 질서 정연하였다. 라고 합니다. 프로젝트의 종료 시에도 마찬가지로 기본적인 룰과 코드의 작성 룰이 있다면 항상 다음 프로젝트를 위해 사용 가능한 도구, 그리고 경험이 남게 됩니다. Z 프로젝트의 경우에도 이후의 프로젝트를 위해 사용가능한 몇 가지가 준비 되었습니다.

– UI Lib.

게임 내 수 많은 UI를 위해 트리구조의 다중 윈도우 시스템을 가진 윈도우 라이브러리가 구성 되었습니다. 버튼(체크, 라디오 등), 리스트 윈도우, 스크롤 바 윈도우 등 일반적인 윈도우 시스템을 만들 수 있는 시스템 기능을 작성 하였습니다. 해당 윈도우에 이미지나 텍스트 등을 꾸미기 위해 기존의 프로젝트에서 작성한 스토리보드라 이름 붙인, 화면에 출력하는 시스템을 붙일 수 있도록 하였는데, ‘Money가 0보다 작으면 빨간색 많으면 녹색’ 같은 게임에 특화된 기능들을 작성하다 보니 시간지연, 결국 if, goto label 과 같이 흐름을 제어하는 문법 기능이 들어가서 기능이 너무 복잡해지고 스크립트 코드가 길어져서 작성하기 까다롭게 되었습니다. 해당 기능들은 추후 html과 css에서 어떻게 풀어냈는가? 를 보고 반성하였습니다.

– 케비넷 시스템

케비넷 시스템은 모든 객체는 ‘키-값’의 쌍을 여러개를 가지고 있고 해당 객체들 간의 연관 관계로 게임 상의 거의 모든 구조를 구현 할 수 있다는 데에서 착안하여 만든 시스템입니다. 스스로는 세상을 담을 수 있는 구조라 생각 하고 있는데, 기본적인 구성의 아이디어는 noSQL과 비슷합니다. 그 안에서 개별 객체의 관계를 하나의 이름으로 묶는 기능과 값 변경 트리거, 그리고 화면에 표기등을 위해 매 틱(Tick)마다 데이터를 새로 가져올 수 없기에 값의 레퍼런스를 항상 가지고 있을 수 있게 하는 등 몇몇 변칙기술들을 위해 noSQL계열 라이브러리를 쓰지 않고 직접 구성 하였습니다.

스크립트 언어를 임베디드 해서 사용할 경우 항상 귀찮은 부분이 바인딩을 위해 함수를 연결해 주는 부분인데 스크립트와 게임과의 연결통로를 해당 데이터 구조만으로 한정하였기 때문에, 바인딩의 량을 줄여 개발하기 좋게 되었고. 게임의 로직도 파이썬 측에서 모두 짤 수 있게 되었습니다. 그리고 해당 객체의 검색기능을 사용해 어느 위치에서든 모든 데이터에 접근 가능하게 되었고 이런 이유들로 인해 개발의 속도가 올라가게 되었습니다.

R 프로젝트의 포인트

프로젝트를 시작하면서 UI를 간결하게 만들어야 겠다고, 우선 생각 했습니다. 이전 Z 프로젝트에서 UI의 양이 소규모 인력으로 감당하기 무시무시 했고, 양이 많음 에도 불구하고 실제로 사용하기에는 너무 불편한 상황이였기 때문에 모든 유아이는 일단 하단의 카드 시스템에 모으고 그 카드 시스템을 제대로 구현하는데 목표를 삼았습니다. 아직 프로토 타입이기 때문에 개발 개발 도중 기능이 변경 됨에 따라 개발 중 UI가 많이 뒤바뀐다는 점도 간결함을 유지 한 이유이기도 합니다.

게임 개발 이란게 처음 상상 할 때는 재미가 있지만, 작업이 길어지고 후반으로 갈수록 지칠 때가 있습니다. 그럴 땐 ‘이 기능이 들어간다고 딱히 게임이 재미있어 지는 것도 아니’라는 생각도 들고 그렇지요. 그럴때 화면에 사각형과 글씨만 가득 차 있는 화면(빠른 프로토타입이라는 미명 하에 벌어지는 미적 요소의 계획 살해)을 보고 있으면 ‘난 누군가? 또 여긴 어딘가?’ 같은 생각이 들게 됩니다. 그래서 게임을 게임 답게 만들기 위해 사소한 것 하나라도 ‘뿅-뿅-‘ 하고 나타나고, 기존 비슷한 컨셉의 게임에서 이미지를 잘라 붙이고 하는 식으로 기본적인 게임의 분위기를 유지 하기 위해 노력했습니다. 재미있는 게임은 선과 사각형만 있어도 재미 있을 수 있다 라고 생각하지만 그렇게 재미있는 게임은 아직 만들 때가 아닐 수 있다는 생각을 하기도 했습니다.

예측 불가능한 곳에서 게임의 재미가 나오는 경우가 있는데, 그것이 게임의 모든 재미라고 믿는 사람들이 있습니다. 게임의 모든 곳은 랜덤(Random)으로 돌아가야 한다고 말이지요. 하지만 그 사람들이 간과한 것은 예측 가능한 곳에서 예측 가능하지 않았기 때문에, 다양한 반응에 재미를 느낀 것 이라는 점입니다. 기본적으로 게임은 어떠한 동작을 하면 그 동작에 대한 예측된 결과를 보여 주어야 합니다. 그렇지 않으면 사용자는 “나는 이 게임을 잘 모르겠어” 라는 반응을 보냅니다.

R 프로젝트의 욕심

2011년 7월 1일 여름 휴가를 가기 전, 기본적인 장수 운용 시스템과 전쟁 만 가능한 시스템을 구현 했습니다. AI들은 저돌적으로 공격을 들어 오도록 작성 되었고, 게임은 30분 정도의 플레이 타임을 갖게 되었습니다. 그리고 휴가 동안 좀 더 복잡한 전략 모드에 대한 갈구가 생겼습니다. 외교 시스템을 넣고 AI에 성격을 부여 하고 싶었습니다.  AI의 모든 판단은 욕구 수치를 두고 제한선을 조정하는 방법으로서 제어 할 수 있다고 생각 하였지만 판단 미스 였습니다. 장수를 계속 뽑았다 잘랐다 한다 거나 외교적으로 여러가지 바보짓을 보여 주었고, 해당 외교 상태를 풀기 위해 일종의 외교 설정 장치인 플래그(Flag)라는 기능을 수정 하면 할 수록 AI는 점차 바보가 되어갔던 것입니다.

사실 이때부터 반 쯤은 현재 만든 전략모드에 기존의 전술 프로토타입을 합쳐 하나의 게임으로 만든다는 가정을 이미 어느정도 포기한 상태였습니다.  주객전도 라고 할 수 도 있겠지만 어쨌든 주인이 바뀌었다면 새로운 주인을 따라야 하니까. 그리고 게임의 규모가 지나치게 커졌던 것은 심한 부담이었습니다. 백분의 일도 안되는 인원으로 토탈워(Total War) 시리즈를 만들 수는 없다는 엄연한 현실에 대한 냉정한 판단이었습니다.

R 프로젝트의 반성

외교 시스템을 작업하면서 Z 프로젝트의 악몽이 떠오르기 시작했습니다. 충분히 방어 적으로 짜지 못한 코드는 한 곳을 수정하면 다른 곳이 에러나는 버그의 악순환이 시작되는 분위기였고, AI는 위에서 이야기 한 대로 해당 상황 자체에서는 맞지만 전체적인 맥락에서는 맞지 않는 바보의 냄새를 풍기기 시작했습니다. 그리고 외교 및 AI의 조율 작업이 장기화 되면서 프로젝트 자체도 점차 미궁속에 빠지는 분위기가 감돌기 시작했습니다. 때문에 일단 정리를 해야겠다는 마음이 들었고 운명의 2011년 8월 29일에 릴리즈 감행. 내부의 게임 평가단에게 평가용 프로토타입을 배포하였습니다.

닫혀진 테스트 이고, 테스터들이 우리의 상황(개발 환경이나 게임 성향)을 충분히 알고 있기 때문에 별도의 튜토리얼 등은 크게 필요 없을 꺼라 생각했었습니다. 테스터들이 게임을 많이 겪어본 사람들이기도 하거니와 설마 프로토타입에서 출시 수준의 완성도를 바라겠어? 하는 마음도 없지 않았습니다. 하지만 조사 결과, 테스터들은 외교를 사용하지 못했고, 한 턴을 그냥 넘기면 병력이 채워지는 기본 시스템 조차 몰랐다는 이야길 들었을 때, 그제서야 다시 한번 생각이 들었습니다. “내부 테스터도 유져다.” 다음 번에는 튜토리얼과 비슷한 수준으로 프로토타입을 구성하던가 아니면 프로토타입 단계에서 UX의 완성도를 최대한 끌어올려야 된다는 생각을 가지게 되었습니다.

게임 자체는 조금 더 사용자에게 친절해야 할 필요가 있었습니다. 특히 외교 시스템에 있어서 테스터에게 비난을 받았던 ‘외교 시스템의 난해함’은 직관적이지 못한 UI에서발생한 대표적인 문제였습니다. 일례로 ‘동맹요청 -> 상대의 거부로 인해 사이 나빠짐 ->  이후 외교에서 어떤 버튼을 눌러도 동작하지 않는다(동작이 플레이어에게 보이지 않는다)’. 의 순환에 의해서 외교 자체를 기피하게 만들어 버렸습니다. 이는 예측 할 수 있는 도구(동작에 대한 결과 통보, UI 등)를 주지 못한 것이 잘못이라 여겨집니다.