프로토타입

<프로토타입(Prototype)의 목적>

본격적인 구현에 들어가기 전에 무엇을 어떻게 만들어야 하는지를

고민하는 과정 중 하나다.

머릿속에서 생각했던 것을 구체화하고 플레이가 가능하도록

구현해서 상상했던 게임 플레이의 느낌, 조작성 등을 가시화하는 과정이다.

동작하는 게임을 보고, 생각한 부분의 약점이나 강점을 파악하고, 

구현을 위한 구체적인 데이터들을 얻을 수 있다.

프로토타입을 만드는 것은 동작하는 게임을 볼 수 있다는 것으로도 큰 의미가 있다.

프로젝트에 대해서 현실적인 검토를 할 수 있다는 것도 있다.

플레이가 가능하도록 만드는 것이므로 내가 생각했던대로 플레이가 진행될 것인지 확인해볼 수 있다.

게임의 목적은 승리, 혹은 성취일지 몰라도 게임의 가치는 바로 '즐거움'이다.

<프로토타입에 대한 오해>

프로토타입을 만드는 이유 중 하나가 재미를 확인하는 것이다.

프로토타입만 플레이해봐도 게임이 재미있을 것이라 생각하지만 그것은 오해이고,

빠른 시간내에 만든 프로토타입이 짧게는 몇 주, 길게는 몇 달 동안 다듬고 다듬어서

밸런싱을 맞춘 게임처럼 재미있다면 폴리싱이라고 부르는 다듬는 과정이 필요하지도 않을 것이다.

내가 생각한 게임이 내 머릿속에 있을 때와는 다르게 아주 재미가 없다는 것도 깨우칠수 있게 해주는데

처음의 구상은 과감하게 버리는 것이다.

프로토타입은 빠른 시간에 만들어서 움직이는 것을 보는 

일종의 시험작(Test-Bed)이다.

굳이 그래픽이 멋질 필요 없고, 기능을 빨리 구현해야 하는 상황에서 멋진 그래픽을 위해

시간을 들이는 것은 비효율적이다. 그래서 필요한 그래픽 리소스는 최소한으로 한다.

구현을 위해서 필요한 데이터들을 더미 데이터(Dummy Data)라고 부르는데,

더미 데이터용 아트 소스들은 극단적으로는 기본 도형들, 큐브, 원기둥 등을 사용하기도 한다.

아티스트는 프로토타입을 만드는 기간에 아트컨셉에 대해 논의하기도 한다.

게임에 대해서 말로 설명을 듣는 것보다 움직이는 것을 보면 게임에 대한 이해가 높아지므로

아트 컨셉을 어떻게 잡으면 좋을지, 시각적으로 어떤 부분에 중점을 둬야 할지에 대해서 

생각을 정리하는 것이다.

아트 컨셉에 대한 논의가 이루어졌고,  필요한 내용에 대해 미리 준비되었다면,

준비한 아트 리소스를 적용해보고 게임 플레이와 시작적 느낌이 얼마나 잘 어울리는지 확인할 수 있다.

기능이 중요하다고 해도 시각적 분위기 역시 기능 못지않게 중요하다.

그래픽이 중요하지 않은 게임이라고 해도 그래픽이 있으면 좀 더 게임의 분위기를 알 수 있다.

<무엇을 만들까>

왜 프로토타입을 만들어야하는지 명확한 목적을 먼저 정해야 한다.

여러명이 작업을 하기 위해서는 항상 객관적인 언어를 준비해야 한다

예) 재미있는지 확인할거에요(x)<-너무 막연하다. 좀 더 구체적인 대답이 필요하다.

예) 내 생각엔 재미없는 것 같다.->그냥 아닌 것 같아(x) -> 이 게임의 재미는 무엇으로 확인하는가?

예) 벼랑 위에서 점프를 할 때 어떤 걸 느꼈어?

예) 뛰어내릴 때 실패할 수도 있다는 생각이 들 수 있을까?

예) 힌트를 찾는 과정에서 흥미를 지속시킬 수 있을까?

->막연한 느낌에 대해서 설명하더라도 좀 더 구체적인 상황과 기대하는 바를 정리하면

좀 더 명확한 목표와 조건에 대해서 이야기할 수 있다.

어떤 부분에서 재미를 찾을 것이고, 어떤 재미를 찾아야 하는지에 대해서 세부적으로

고민하고 그에 대한 내용을 팀원들과 공유해야 한다.

그 핵심 재미가 게임의 목표를 좀 더 명확하게 해줄 것이고,

구체적인 부분을 정리해보면 스스로도 구체적인 목적에 집중할 수 있다.

재미라는 말은 추상적이고 아주 개인적이다. 

프로젝트를 진행하기 위해서는 추상적인 것을 구체적인 것으로 바꾸고,

주관적인 기준을 객관적인 기준으로 바꿔야 한다.

그렇게 해야 게임을 개발하는 팀원들이 같은 목표를 갖고 갈 수 있기 때문이다.

재미있는 것이라는 말은 좀 더 구체적이고 가시적인 무언가로 정리되어야 한다.

프로토타입은 게임 전체를 구현하는 것이 아니라 핵심적인 부분만 구현한다.

전투느낌을 보고 싶다면 전투부분만 구현하면 된다.

전투가 진행되기 위해서는 전투가 이루어지는 지형, 전투에 필요한 캐릭터 혹은 몬스터가

필요할 것이고 장비, 스킬들이 필요할 수도 있다.

게임 플레이는 어떻게 이루어질까, 지형을 이동하다가 몬스터와 조우하게 되는 플레이를 

상상한다면 몬스터가 스폰(spawn->몬스터를 생성시키는 것)되는 것도 필요하다.

한 번에 몬스터 하나와 싸우게 된다면 전투가 끝나기 전에는 몬스터가

스폰되지않아야 하지만, 한 번에 여러 몬스터와 싸우게 하고 싶다면

몬스터가 여러 마리 스폰되어야 한다.

얼마나 스폰되게 할 것인가, 한 번에 얼마나 많은 수의 몬스터와 싸우게 할 것인지에 따라

몬스터 스폰 양을 조절해야 한다.

이 전투를 왜 구현했을까, 무엇을 확인하고 싶어서 전투를 구현했을까?

이 전투의 목적이 무엇일까? 여기에서 가장 중요한 왜가 등장한다.

왜 전투 프로토타입을 만드는가?

<어떻게 만들까>

프로토타입은 본격적인 구현의 단계가 아니라 가능성을 확인해보는 단계다.

굳이 완성된 게임의 일부처럼 만들어야 할 필요는 없다.

프로토타입을 위한 이미지는 아주 특별한 필요할 필요는 없다.

멋진이미지들이 필요하지 않다는 의미이고, 

단지 게임 플레이를 위한 기능적인 요구만 충족되면 된다.

플레이하는 데 필요한 게임 요소들이 들어가기만 하면 될 수도 있다.

이미지 없이 구현하는 것이 아니라 작업 시간을 요구할 정도의

본격적인 아트 작업이 필요한 것은 아니라는 것이다.

횡스크롤로 진행되면서 몬스터와 전투를 하는 내용을 구현해볼 때,

캐릭터와 몬스터의 생김새가 반드시 이 게임의 컨셉과 어울릴 필요는 없다.

프로토타입에서는 회색의 바탕에 인간형 캐릭터가 동물형 몬스터와 전투를 진행해도,

보고자 하는 것을 보는 데에는 아무런 문제가 없다는 것이다.

주로 더미(Dummy) 그래픽 소스를 많이 사용한다.

그래픽 작업을 위해서 시간을 들이는 것보다 빨리 만드는 것이 더 바람직하다.

다른 프로젝트에서 진행했던 이미지 소스를 사용하거나 필요로 하는

기본 구조만 있는 이미지를 활용한다.

프로토타입을 만드는 데 형식은 중요하지 않다. 무엇을 만들어서

확인할지에 대한 목적이 분명하면 좀 더 손쉽고 빠른 방법을 찾아 낼수도 있다.

<프로토타입을 위한 문서 작성>

문서에는 크게 두가지 내용이 있어야 한다.

1. 프로토타입의 의도를 설명하는 것.

2. 어떤 것을 구현해야 하는지 설명하는 것.

왜 이것을 만드느냐에 대한 것이 의도이다.

구현되어야 하는 것의 핵심은 무엇이며, 무엇을 확인하고자 하는지를 설명해서

같은 팀원들끼리 같은 목표 의식을 공유하도록 하는 것이다.

기능에 대한 설명만 나열하는 것보다 우리의 지향점을 알려주면

보다 좋은 의견을 받을 수 있다.

구현할 내용을 설명하는 것은 사양서와 같다.

게임이 어떻게 동작해야 하는지 설명한다. 

작은 규모의 게임이므로 나름의 플레이 시나리오가 있어야 한다.

플레이 시나리오를 만들고 그 단계마다 필요한 내용을 정리하면

전체적인 모습을 설명할 수 있다.

플레이 시나리오를 기준으로 설명하면 듣는이들도 쉽게 이해할 수 있다.

플레이어가 어디서부터 어디까지 진행하도록 만들 것인가,

맵 하나를 플레이할까, 난이도가 서로 다른 스테이지 3개를 플레이하게 할까,

10분동안 전투를 하게 할까, 플레이를 시작해서 종료할때까지 흐름은 어떻게 진행될까,

시작하면 캐릭터는 아무것도 없는 평면을 뛰어다닐까? 아니면 원하는 스테이지를 선택해서 들어갈까?

맵 하나만 만들면 되는지, 그 전에 맵을 선택하는 화면이 있어야 하는지, 맵에서 그저 사냥만 하면 되는지,

종료 조건을 만들어서 결과를 봐야 하는지 등등

플레이어가 게임을 실행해서 종료할 때까지 어떤 플레이를 하게 될지 순서를 정리한다.

플레이 흐름에 대해서 자세하게 정리를 하면 만들어야 할 것들이 눈에 보인다.

U.I는 어느정도까지 만들어야 하고, 배경은 얼마나 만들어야 하며,

오브젝트는 어떤 기능으로 몇 종류나 필요한지 등등. 

그러면 이제 구체적으로 만들어야 하는 기능과 작업해야 하는 목록을 만들 수 있다.

어떤 것을 요청해야 할지도, 프로토타입을 개발하는데 이정표가 되는 내용을 문서로 정리할 수 있을것이다.

□ 게임의 전체적인 내용이 아니라 핵심적인 부분만 잘라서 구현한다.

□ 생각한 게임에서 가장 재미있다고 생각하는 부분이 무엇인가.

□ 생각한 게임에서 가장 확인해보고 싶은 부분이 무엇인가.

시작과 끝이 있어야 한다. 게임 실행부터 종료까지 진행 과정을 설명한다.

어떻게 보여야 하는지에 대해서 중점적으로 설명한다.

아직 시스템이 체계적이거나 안정적일 필요는 없다.

프로토타입에서도 디자인 데이터가 필요한 경우가 있다.

어떤 값을 변경해야 하는지를 명시한다.

핵심이 무엇인지를 명시한다. 내 자신도 문서를 정리하면서 생각을 정리할 수 있고,

팀원들도 어디에 집중해야 하는지를 알 수 있다.

프로토타입은 게임의 일부분이지 전체가 아니다.

관련 내용을 정리할 때도 게임 전체를 정리할 필요는 없으나,

마음속에는 게임 전체의 모습을 그릴 수 있어야 하며,

결과에 따라 어떻게 전체적인 모습을 그려나갈지 항상 염두에 둬야 한다.

<연습>

만들고자 하는 게임이 뭐가 재미있을지 목록을 만든다

가능하면 한 문장으로 끝내는 것이 좋다.

하나의 문장에는 하나의 내용만 있도록 목록을 만든다.

목록의 문장이 너무 길어진다면 왜 짧게 정리할 수 없는지 냉정하게 판단해야 한다.

핵심이 없으면 말이 길어지는 법이다.

목록 중에서 '이 플레이의 느낌을 구현하지 못하면, 게임을 만드는 의미가 없다'라고

생각되는 사항들을 분류한다.

'반드시 살려야 하는 부분'과 '좋은 것'을 분류한다.

필수적인 목록은 가능한 한 적은 게 좋으므로 기준을 엄격히 적용한다.

'왜 이 부분이 반드시 구현되어야 하는 것'인지 설명할 수 있어야 한다.

프로토타입을 만드는 내용은 '반드시 살려야 하는 부분'만 확인하면 된다.

다른 부분들은 방향성이 확실하게 결정되고 본격적인 개발 단계에서 구현한다.

필수적인 항목의 목록이 정리되었다면, 그 다음은 우선순위를 정리한다.

가장 먼저 확인되어야 하는 것과 다른 항목이 먼저 구현되어야 확인할 수 있는 것이 있다.

여러가지 기준을 고려해서 우선순위를 정리한다.

가장 먼저 구현되어야 하는 내용을 바탕으로 무엇을 확인하기 위한 작업인지,

구현된 모습을 보고 기대한 만큼의 결과가 나오지 않는다면 그에 대한 대비책은 무엇인지도 정리되어야 한다.

프로토타입은 정해진대로 걸어가면 되는 길이 아니라,

이 다리가 괜찮은지 두들겨보는 단계이다.

실제 플레이가 되는 것을 만들어야 하므로 어떤 플레이가 이루어질지 구체적으로 상상해본다.

상상하기 어렵다면, 가상의 플레이 시나리오를 적어보는 것도 좋다.

내 자신이 플레이어라고 생각하고 플레이 리뷰를 쓴다는 기분으로 가상의 시나리오를 적다 보면

구체적인 플레이의 흐름을 상상할 수 있다.

이 내용을 다른 이들에게 설명할 수 있어야 한다.

구체적으로 상상한 플레이 내용을 구현하기 위해서 무엇이 필요한지 내용을 정리한다.

플레이 흐름에 따라 정리하고, 게임을 실행해서 플레이가 종료될 때까지

플레이의 흐름을 적는다.

시작과 끝을 정하고 진행 과정에서 보고 싶은 내용을 정리해서 팀원들과 공유한다.

필요한 데이터들을 목록화하고 가장 효율적으로 결과를 볼 수 있는 방법을 논의해서 결정한다.

규모가 있는 게임이라면 한 번에 많은 부분 구현보다는 핵심적인 부분부터 구현하고

결과를 본 후, 다음 단계로 기능 추가를 하면서 진행한다.

<정리>

* 처음으로 만들어지는, 플레이가 가능한 버전이다.

* 생각을 구현함으로써 어떤 게임을 만들 것인지 명확하게 공유한다

* 게임이 성립하기 위한 기본적인 사항들을 검증한다.

* 프로토타입을 왜 만드는지 목적을 구체적으로 정하고 팀원들과 공유한다.

    - 그렇게 해야 차후에 혼란이 적다.

* 프로토타입은 동작하는 것만을 보기 위함이 아니다.

* 프로토타입은 여러 번 만들 수 있다.

    - 검토해봐야 하는 것이 많다면 여러 번에 걸쳐서 만들어 보는 것이 더 효과적일 수 있다.

* 본격적인 개발이 아니라 무엇을 만들지를 검토하는 과정이다.

  빨리 만들어서 플레이 결과를 보고, 안정적인 것은  본격적인 개발에 들어갈 때 고민해도 된다.