태그 보관물: prototyping

게임 프로토타이핑 회고

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

초기의 목표

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

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

델파이의 신탁

델포이의 무녀

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

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

오염된 제물

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

신중해지는 발걸음

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

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

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

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

결언

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

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

스타크래프트 2 지도 편집기로 프로토타입 만들기

게임 프로토타입은 무엇보다 빠르게 만들고 빠르게 평가하고, 빠르게 의사결정을 내리는 과정이 중요하다. 프로토타입에 많은 공을 들이기 시작하면 팀 구성원은 쉽사리 지치거나, 혹은 공들여 만들 프로토타입에 미련을 가져 의사결정에 영향을 미치기 마련이다.

이전 프로토타입에서 사용되었던 프로토타입 개발 툴은 전형적인 ‘연필, 종이, 주사위’였다면 이번 실시간 전략시뮬레이션 프로토타입에는 블리자드 엔터테인먼트(Blizzard Entertainment)의 실시간 전략 시뮬레이션 게임인 스타크래프트 2(Starcraft 2)의 지도 편집기(Galaxy Editor)를 이용해 보았다. 스타크래프트 2의 지도 편집기(이하 ‘지도 편집기’)는 다양하고 세부적인 설정 변경 등을 통하여 실시간 전략 시뮬레이션 뿐만 아니라 사용자의 능력 여하에 따라서 다양한 형태의 게임을 생성하고 만들어볼 수 있는 기능을 갖추고 있다. 또한 제작된 게임을 별도의 추가 작업(UI, 그래픽, 사운드, 그리고 여타 잡다한 기본 기능들)이 필요 없이 스타크래프트 2 내에서 바로 확인이 가능하다는 점 때문에스티크래프트 2 지도 편집기가 효과적인 프로토타이핑 툴로써 적합하다는 결론을 내리기 충분했다. 새로운 프로토타입은 자연스럽게 지도 편집기를 이용하여 제작하는 것으로 결정이 되었다.

… 그리고 그것은 고난의 시작이었는데.

지도 편집기를 사용하면서 가장 먼저 맞닥뜨리게 되는 문제는 다양한 기능과 강력한 성능에 걸맞게 초심자에게는 사용방법이 ‘변화된 상황에 적응하지 못하고 이성을 잃어버릴’ 만큼 복잡하고 난해한 툴의 사용법을 친절하게 설명해 주는 사람이 아무도 없다는 것이었다. 심지어 제작사인 블리자드 엔터테인먼트에서조차 ‘공식적으로 편집기를 지원하지 않으며 고객 지원팀 역시 편집기와 관련한 모든 문제에 도움을 주지 않는다’라고 도움말에 명시하고 있다. 즉, 쓰고 싶으면 알아서 배우고 아니면 도태되라는 적자생존 형 서비스. (…) 다행히 도움말 말미에 ‘스타크래프트 2 편집기 위키’로 링크가 되어 있다. 이 페이지는 ‘공식 스타크래프트 2 편집기 토론장’으로 가는 링크가 걸려있다. 지식에 목마른 나는 두근거리는 마음으로 링크를 눌러보았으나…

페이지 없음.
... 아무것도 없. 잖. 어.

… 홈페이지 관리를 제대로 안하는 곳(이곳 같은)에서 자주 보이는 전형적인 잘못된 링크 오류. 해당 페이지는 홈페이지 메뉴의 ‘토론장’ 버튼을 통해서 접근이 가능하다. 하지만 이런 초보적인 실수를 게임 개발의 신인 블리자드가 저지르다니… 뭐 그들도 인간이니까. 하면서 관대한 마음으로 토론장의 글 목록을 본다. 하지만 지도 편집기에 대한 강좌나 문답 보다는 사용자 지정 게임 시스템과 인기도 시스템에 대한 항의 글이 더 많은 상황. 그래도 공지 글 중에 ‘지도 제작 안내서’라는 글이 보인다. ‘그래 이 곳에는 다양한 정보들과 초보 모드 제작자를 위한 팁 들이 존재할꺼야’ 라는 마음으로 링크를 클릭하는데…

지도 제작 안내서
... 이게 다야?

지도 편집기의 지형 제작 방법은 간편하고 직관적인 GUI로 인하여 적어도 당신이 ‘심시티(Sim City)’를 즐겨본 게임 플레이어라면 딱히 설명이 필요없을 정도로 잘 만들어졌다. 응, 그러니까 나는 그게 필요한게 아니라…

편집기 항목 목록
하지만 이것은 빙산의 일각

각 항목의 내용이 뭔지 알아야 지도 편집기를 쓰던가 말던가… 공식 홈페이지에는 각 수치의 동작 관계, 각 객체의 상호 연동, 트리거의 실행 체계 등 완전 커스터마이징(Customizing)을 위해 필요한 자료는 하나도 없다. 아니, 그러니까 나는 막 영웅이 나와서 전장을 휩쓸고 돌아다니고, 불도 지르고, 액션도 하고, 유닛들이 대전격투도 되는 그런걸 만들고 싶다니깐?(뻥) 하지만, 이정도 자료 제공 수준이면 이젠 모드 제작자의 근성을 테스트 하는 단계.

Editor
프로그래머들이 왜 남의 소스 보기 싫어하는지 알 것 같기도

공식 지원이고 뭐고 다 때려치우고 구글링을 해보는게 낫겠다는 심정으로 구글링을 해 보지만 한국어 페이지는 대부분 마딱찮은 내용들에 심지어 패치 이전의 강좌가 업데이트 되지 않은 상태로 존재하는 것도 있는 상황. 결국 ‘게임 개발자의 감’으로 일일이 항목 하나 하나 뜯어가면서 지도 편집기의 기능을 익히고, 캠페인과 공식 모드의 내용을 뜯어서 확인하며, 필요한 내용은 해외의 유튜브(You Tube) 강좌(이 강좌 덕분에 외국 애들은 게임 에디터 강좌도 동영상으로 만드는구나 하는 깨닳음의 계기가 되었다)를 봐 가면서 하나 둘 프로토타이핑에 들어가야 될 기능을 완성해 나갔다. 불행 중 다행이라면 게임의 사이즈가 그렇게 크지 않아서 생각보다 많은 삽질은 다행이 비껴나갔다는 것.

Prototype P1
'드디어, 올 것이 왔군'

본 프로토타이핑은 지도 편집기에 대한 숙련도 레벨을 올리기 위하여 레벨 노가다 작업이 2일이 소요 되었고, 프로토타입 이전 테스트 맵 제작에 1일, 정식 프로토타입 버전 1 제작에 2일이 소요 되었다. 숙련도 쪼랩으로 만들었기 때문에 기본적인 게임 시스템 확인만 얼추 가능한 상태이며, 심지어는 승패 판정 처리도 되지 않는 상황 하에서 릴리즈 되었다. 아마 이 지도 편집기 사용이 능숙한 사용자가 제작을 한다면 더 빠르고 안정적인 프로토타입 제작이 가능 할 것이라 판단이 되지만… 글쎄, 지금과 같은 상황에서는 일단 지도 편집기에 능숙한 사용자가 되는것 자체가 벌써 험난한 여정의 시작인지라… 만약 이 글을 보고 지도 편집기를 게임 프로토타이핑 툴로 사용 할 사람들이 있다면, 판단은 사용할 사람들의 개인에 맡긴다.

 

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 엔진을 사용하였다. 개인적으로는 제작 기간 동안 비주얼 스튜디오에 포함된 프로파일러 사용법을 익혔으며, 엔진의 맥 버전을 지원 하기 위해 맥북 에어를 추가 구매 하였다.