Anoa의 모든 글

프로그래머를 위한 프로토타입 용 그래픽 리소스 얻기

(주: 글의 내용은 개인적인 의견임을 알아 둡시다)

프로토타이핑

프로토타이핑은 게임의 재미를 검증하고, 나아가서는 구현된 결과물을 수정하여 아이디어를 확장하게 해준다. 좋은 프로토타입을 만드는 데 가장 중요한 부분은 플레이 가능한 게임을 빠르게 구현하는 것이다. 프로토타입을 통하여 게임 디자인 기획서의 목적과 한계를 확인한 후 본 게임을 깔끔하게 다시 만드는 것이 보통이다.

게임의 최종 목적이 귀여운 캐릭터와 아기자기한 그래픽을 통한 승부가 아니라면, 선과 원 그리고 사각형만 가지고도 게임이 재미있어야 한다. 기본 시스템과 동작이 재미있고 여기에그래픽이 추가 된다면 금상첨화가 될 테니까. 하지만 세상은 그리 호락호락 하지 않다. 그래픽이 붙지 않은 상태의 자연 상태의 게임은 목적과는 전혀 다른 게임이 되어버린다. 텍스트만을 이용해서는 복잡한 게임은 만들 수 도 없을 뿐만 아니라, 만들었다고 해도 마치 선사시대 게이머들이나 좋아 할 만 한 넷 핵류 게임처럼 보이게 된다. 이 복잡해 보이는 물건을 ‘절대로 아무도 읽지 않을 설명서’를 줄창 써서 프로토타입 테스터들에게 보내면 이런 메일을 받게 된다.

  • “어떻게 하는지 모르겠어요.”
  • “내가 해야 할 일이 무엇인가요?”
  • “동그란 원과 사각형 혹은 저기 보이는 파란 사각형 중 어느게 저인가요?”
  • “왜 제가 빨간 사각형을 피해야 합니까?”

내가 틀렸다. 지난 8개월 간의 경험과 무지막지한 피드백들을 통해 프로토타입에는 최소한의 그래픽이 필요하다는 결과를 도출 할 수 밖에 없었다.

요즘 이런거 테스터들도 잘 안한...

 

적절한 그래픽 리소스

그럼 프로토타입에는 어느 정도의 그래픽 리소스가 필요할까? 개인적으로는 나름 이하와 같은 가이드 라인을 만들었다.

원칙 1) 에니메이션은 작업에 포함시키지 않는다

프로토타입에 쓰이는 리소스는 실제 버전에서는 무조건 버리게 된다. 애니메이션 같이 품이 많이 들고 낭비인 지점에 신경쓰지 말자. 물론 별도의 동작(공격 등)을 해야한다면 공격 시에 사용할 그림 한장 정도면 된다.

원칙 2) 타입이나 종류 등은 구분이 되어야 한다.

리소스를 아낀다고 다른 종류의 유닛을 하나의 이미지로 처리하지 않는다. 최소한 색이라도 바꿔서 쓰도록 하자. 게임 디자인 상 들어가야 할 필수 요소들은 빼 먹지 않고 그래픽 리소스를 채워 넣는다. 여기서도 꾸미기 요소(이펙트, 배경 등)는 제외한다.

너구리 게임을 예로 들자면 먹어야 할 아이템, 장애물, 사다리 등 게임의 요소로서 영향을 끼치는 것에 대한 구분 용도로 꼭 그래픽 리소스를 넣어야 한다.

그래픽 리소스 +1을 획득하였습니다

그럼 그래픽 리소스는 어떻게 얻어낼까? 본인 스스로 아트 디자인이나 그래픽 리소스 제작 스킬이 있다면 직접 그려도 된다(하지만 나는 당신이 아트 디자인에 관련한 소양이 없기 때문에 프로그래머 혹은 기획자가 되었다는 걸 알고 있다). 또는 주변의 그래픽 디자이너에게 밥을 한끼 사주고 시키거나, 무력으로 그림 잘 그리는 동생을 진압하여 노예처럼 쓰는 방법도 있다(실제 90년대의 국내 아마추어 게임계에서 많이 쓰였던 착취 방식이기도 하다). 하지만 프로토타이핑을 하며 필요한 사소한 리소스 들이 계속 추가 될때 마다, 시도때도 없이 남에게 구두로 리소스를 요청하기는 쉽지않다.

대다수의 훌륭한 어른들은 아무것도 하지 않고 이루려고 한다(혹은 아주 약간의 노력으로 무언가를 이루려고 하기도…). 여기서는 그러한 방법들을 아래서 소개하고자 한다.

우선 프로그래머의 친구 Google에서 Game Sprite로 검색 할 경우 다음의 결과가 나온다.

짜잔!

위와 같이 많은 리소스 들이 존재한다. 이것을 가져다 쓰도록 하자. 검색 결과 상위에 랭크되어 있는 다음의 사이트들에서도 많은 구작 게임들의 스프라이트를 얻을 수 있다.

과거(네오지오Neogeo를 기점으로 이전) 콘솔 게임기들은 하드웨어의 제약으로 인해 비디오 램과 그것을 찍는 방식이 지정되어 있었다. 현재와 같은 일반적인 3D가속 방식을 사용하지 않기 때문에 특정 비디오 램에 이미지를 넣고, 해당 이미지를 특정 레이어로 지정을 하면 찍어주는 그런 블라블라한 방식인 것으로 알고 있는데… 더 이상 자세한 설명은 생략한다(필요 할 경우 직접 검색을 해 보시라). 중요한 것은 레이어 방식 인데, 해당 레이어를 통해서 우선순위가 지정되기 때문에, 비슷한 유형의 특정 스프라이트들은 같은 레이어에 몰아서 넣게 된다(2D 대전 액션의 경우 배경→ 배경 사람 → 뒷 이펙트 → 케릭터 → 앞 이펙트 식). 요즘의 게임 에뮬레이터들은 특정 레이어를 켜거나 끌 수 있는 기능을 제공하고 있는데, 해당 기능을 사용하여 특정 이미지만 깔끔하게 볼 수 있다.

이러한 에뮬레이터의 상태 기능이나 연속 스크린샷 기능, 메크로 기능 등을 적절히 이용하면 원하는 동작이 나오도록 할 수 있을 것이고 그 결과물을 사용하자(물론 바퀴를 다시 발명하는 과오를 범하지 않기 위해 위의 사이트들 에서 누군가 미리 작업해 놓은 것이 있는지 확인하는 것은 필수).

또한 각종 게임 관련 사이트에서 아이템 류의 아이콘 이미지 등을 추출 할 수 있다. 게임 관련 사이트 들에서 공략 등을 이유로 스킬 아이콘이나 아이템 아이콘 등을 표기해 주는 경우가 많은데 이 데이터들을 차용하는 것도 한 방법이다. 브라우저에서 표기되는 모든 이미지 데이터는 하드에 임시로 저장된다. 임시 폴더를 직접 확인하거나 구글 크롬 이용자의 경우 개발자 도구를 사용하면 쉽게 이미지를 얻어올 수 있다.

아무리 찾아도 내 게임은 워낙 독특해서 적절한 이미지를 찾기 어렵다면 직접 그리는 방법이있다. 가마수트라에 게시되어 있는 개발자를 위한 2D 게임 아트란 글을 참조 한다.

마지막으로 주의사항 한 가지. 직접 제작한 것이 아닌 ‘따온’ 데이터는 정식 게임에 포함되지않도록 해야 한다. 여기 나온 팁들은 어디까지나 내부 용도의 테스트에만 사용되어야 하며, 용도를 벗어나게 될 경우 저작권 송사에 휘말릴 수 있다. 개인적으로, 몇 년 전 서비스했던 온라인 게임의 최초 개발 시 테스트용으로 집어넣은 상용 게임의 사운드 파일이 있었는데, 게임의 분위기와 잘 어울린다 생각하고 신경을 못쓰고 있다가 그대로 클로즈 베타 릴리즈를 한 적 이 있었다(물론 파악한 뒤에 바로 삭제하였다). 한 가지 팁을 주자면, 개발용 리소스를 디렉토리를 별도로 두고(root/dev/ 식으로) 실제 사용될 그래픽 리소스가 올라올 때는 실제 사용될 디렉토리에 넣는 식으로 하나씩 옮기면 실수를 하지 않을 것이다.

프로젝트 R P4 개발 후기

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

R 프로젝트의 시작

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

단순 기능 나열의 참극 - Z 프로젝트

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) 시리즈를 만들 수는 없다는 엄연한 현실에 대한 냉정한 판단이었습니다.

이걸 만든다... 고?! - Total War Series

R 프로젝트의 반성

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

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

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

S Project 개발 로그(P1)

Pied Pipers에서 진행된 두번째 프로토타입은 일반적인 플랫포머(Platformer) 타입의 시스템에 레이싱 요소를 가미한 게임을 개발하는 것이 목표였다. 때문에 속도감을 어떻게 주는가? 가 관건이 된다. 예컨대, 소닉과 마리오 그리고 열혈 운동회의 합작 같은 분위기?

맵은 텍스트 스크립트로 제작

최초 기획서 검토 후,  프로토타입의 스펙은 기본 이동, 기본 액션(점프, 슬라이딩), 고정 장애물 2종을 개발 하기로 결정 하였다. 소요 시간은 약 1주 2일 정도. 멥 에디터 등을 별도로 만들기엔 시간이 빠듯한 고로 JSON 형식을 사용한 스크립트 파일에 직접 작성 하기로 하고, 실 게임 프로그램에 맵 뷰(Map View) 모드를 만들기로 하였다(이후 개발이 진행되면서 이 맵 뷰 모드에서 충돌 관련 코드를 작성하거나 테스트하는데 여러가지 도움이 되었다). 기본적으로 프로그램은 프로그램 종료 할 필요 없이 ‘스크립트 다시 읽기 기능’을 지원 하였기 때문에 작업자는 텍스트 에디터에서 스크립트를 수정한 결과를 바로 프로그램에서 확인 할 수 있다.

개인적으로 학창시절 플랫포머를 몇 번 만들어 본적이 있었고, 하이텔 공모전(아마 그 존재를 아는 사람도 별로 없을것이다)에도 당시 제작한 프로젝트를 발표를 해 보았기 때문에 이번 프로젝트에 대해서는 자신이 있었다. 처음에는 Y 값이 뒤집힌(3D와 같은) 좌표계로 제작 할 생각이었다. 일반적인 데카르트 좌표계의 형식을 쓸 경우, 멥의 최 상단 위로 뛰어 오른다면 사용하는 값이 음수가 되어야 하고, 게다가 멥에디터가 없어 무언가 좌표값을 넣을때도 Y 값을 일일이 확인하여 넣는 것이 싫었기 때문. 하지만, 실제 스크린 좌표와 다르기 때문에 변환을 일일이 해야 했고, 손이 가는 부분이 많아 2일 만에 포기. 평생 알던 좌표계를 하루아침에 다르게 생각하기는 쉽지 않은 일인가 싶었다.

이후, 화면의 확대 축소를 지원하기 위해 카메라 시스템을 추가 하였고 모든 오브젝트는 랜더링 시 좌표를 변환해서 찍도록 하였다. 액터(Actor)를 따라다니는 모드와 고정 모드를 제작 하였고, SF 드라마인 베틀스타 갤럭티카(Battlestar Galactica)의 우주 전투 신에서 보여주는 핸드헬드 카메라 스타일의 카메라 움직임을 보여주고 싶었지만, 1일 작업 후 바로 포기(역시 프로토타이핑의 생명은 빠른 포기다).

대신, 카메라 사용 시 랜더 타겟을 쓰면 화면 분할이 바로 될 것이기 때문에 나중에 이를 추가한다면 좋을 것 같다. 과거 작업했던 2d 프로젝트에서는 바로 찍는 것이 아니라 렌더링 해야할 대상을 리스트 업해두고 한꺼번에 그리는 방식을 채택 했던 적이 있는데, 그것과 함께 좌표를 바로바로 변환하는 것이 아니라 아에 ortho모드 옵션을 손대서 그대로 찍는 방식은 어떨까 하는 생각이다.

게임에서 기대하는 움직임은 실제 물리와 다르다-게임에서의 물리는 마리오로도 충분! © Nintendo

과거에 게임을 제작하던 때와는 환경이 다르기 때문에 기본적인 물리 시스템을 우선 작성하기 시작했다. 처음에는 모든 물리 법칙을 게임 내에 구현하기 위하여 중력, 가속도, 탄성, 마찰 등등… 순서대로 하나씩 넣어가며 작업을 하면 할 수록 원하는 움직임과는 달라 보였고, 때문에 또 쿨하게 2일만에 포기(역시 프로토타이핑의 미덕은 빠른 포기다).  x 와 y의 동작 방식을 별도로 하고, 충돌 방향 및 대상에 따라 어떤때는 값을 깎고 어떤때는 튕겨내고 하는 식의 케이스 바이 케이스(Case by case)로 제작하였다.

버그가 가장 빈번하게 나온 곳은 역시 충돌 처리 부분이었다. 일반적인 3D 공간 에서 충돌 처리를 미리 만들어 둔다는 생각으로 실 계산식을 사용하여 선끼리 충돌하면 충돌점을 구해서 빼주고 하는 작업을 진행 하였는데 이때 멥 뷰어에서 직접 시작점 끝점을 이동 시킬수 있도록 작성한 후 개발하였다.

테스트 할 방법을 준비하고 개발한다. 충분히 테스트 되지 않은 기능은 프로젝트 내내 발목을 잡는다.

개발 전 아무리 기획서 검토를 철저히 하여도, 막상 만들다 보면 다른 부분이 존재 하곤 한다. 결국 다시 기획팀과 논의를 하고, 액션은 점프만, 장애물은 1종만 작성 하기로 결정. 하지만 너무 개발 편의적으로 모든 기능을 처낸것이 문제가 되어 우리가 만들고자 하는 게임의 특성을 적용한 프로토타입이 나오질 못했고, 결국 이후 개발 기간을 추가로 들여 AI 기능을 넣기로 결정하였다.

AI 처리를 하기 위해 기존에 있던 엑터 오브젝트에 캐릭터를 조정하는 컨트롤러를 붙일 수 있게 코드를 수정 하였고, 플레이어용 컨트롤러(입력을 직접 받는)와 AI 컨트롤러 중 필요한 것을 붙이면 되는 방식으로 변경 하였다.

현재 캐릭터는 계속 달리기, 점프, 이중 점프, 부스터의 4가지 액션을 선택할 수 있는데 부스터는 맵에서 별도로 호출하도록 하는 방식이라 AI 처리에서 제외하고 작업을 진행하였다. 땅위에 서있을 때만 AI 를 계산 하였고, 이중 점프를 할 것인가? 에 대한 유무도 미리 결정하도록 하였다. 이중 점프는 가장 높은 지점에서 점프와 내려오기 직전의 위치에서 점프 2종류로 나누었다. 처음에는 앞으로 몇 초간의 지형 정보를 분석해서 처리할 수 있을꺼란 생각이 있었는데, 속도의 증감이 있기 때문에 정확히 어느 위치에 갈 수 있을지에 대한 예측이 힘들기 때문에 구현에 실패하였다.

물론 실제와 동일한 속도 식을 짜면 되겠지만, 추후 코드가 변경 될 경우 양측 다 수정을 해야하는 문제가 있기때문에 코드를 수정하여 시뮬레이션 더미를 만들고 실제로 3개 종류의 점프에 대한 시뮬레이팅을 하였다. 실 개발 버전에서는 시뮬레이션을 하는 횟수를 줄이고, 화면 밖에 있는 캐릭터들은 임의 처리하는 등의 방법을 사용할 예정이다.

AI가 도착할 위치를 표시한다. 가장 좋은 디버깅은 결과를 눈으로 확인하게 하는 것이다.

본 프로토타입은 최초 2주를 예상했던 개발 기간보다 좀 더 지난 2주 4일이 소요 되었다. 배경 및 빌딩 이미지는 디자이너 K가 작업해 주었고, 개발용 샘플 케릭터의 이미지들은 구글링을 통한 임시 작업, 그리고 이펙트 이미지들은 본인이 스스로 제작하였다. AI의 과도한 시뮬레이션으로 인한 최적화 문제가 있고, 특정 상황에 AI가 벽을 넘지 못하고 걸려있는 문제가 최종 P1 릴리즈 버전에서 발견되었다.

주석과 공백을 제외한 순수 프로토타입의 코드는 4794라인, 외부 프로그래머와 프로토 타이핑 및 엔진 개발을 병행하며 약 1.5달 간 작업했던 Moderato 엔진을 사용하였다. 개인적으로는 제작 기간 동안 비주얼 스튜디오에 포함된 프로파일러 사용법을 익혔으며, 엔진의 맥 버전을 지원 하기 위해 맥북 에어를 추가 구매 하였다.