'게임 기획서/문서 작성'에 해당되는 글 9건

  1. 2019.04.29 마무리
  2. 2019.04.29 레벨 디자인
  3. 2019.04.29 시스템 디자인
  4. 2019.04.29 게임 구조 설계
  5. 2019.04.29 게임 아트
  6. 2019.04.29 프로토타입
  7. 2019.04.23 컨셉(Concept)
  8. 2019.04.22 제 2 장 게임개발단계(Game Dev.Process)

마무리

게임 기획서/문서 작성 2019. 4. 29. 09:48

마무리


게임 개발 과정에서 문서  작성의 필요성은

팀이 어떻게 일을 하느냐에 따라 아주 중요하게 취급되기도 하고,

하찮은 취급을 받기도 한다.


팀의 규모가 크고, 한 부분을 구현하는데 여러 사람의 의견을 

모아야 한다면 문서 정리의 중요성은 커진다.


문서는 개발에 필요한 내용을 정리해놓는 것뿐만 아니라

진행 과정에서 발생하거나 예측되는 문제점들을 어떻게

해결할 것인지 등에 대해 정리한 일종의 매뉴얼 역할을 하게 된다.


무언가 새로운 생각이 났을때 빠르게 구현해 볼 수 없는 환경이라면

문서 작업을 통해 생각의 오류가 없는지 신중하게 고민하는 과정이

필요할 수도 있다.


생각을 바로 구현해 볼 수 있는 환경이라거나 멤버간의 소통이 빠르다면

시간을 들여 문서를 정리하는 것보다 직접 구현해서

동작을 살펴보는 것이 더 좋다.

이런 환경에서의 문서 정리는 가급적 간단하게 진행된다.


많은 경험자들은 문서를 팀원들이 모두 꼼꼼하게 읽지 않는다는 것을 알고 있고,

문서에 쓸 문장을 고민하는 것보다 게임 플레이를 한 번이라도 더 해보는게 낫다고 생각한다.


가장 좋은 경험은 게임을 만들어 보는 것이나 경험이 없는 이들이

아이디어가 떠오른다 해서 그것을 곧바로 구현하기는 어렵다.


게임은 꽤 복잡한 구성요소를 가지고 있으며 전체적인 모습을 정리하는 것은

나름 훈련이 필요하고, 무언가를 만들기 위해서는

생각을 정리하는 과정도 필요하다.


문서를 정리하는 것은 자신의 생각을 정리하면서 게임의 형태를 

완성시켜 볼 수 있는 좋은 연습 과정이 될 수 있다.


읽을 때 작성자의 의도를 파악하고 제대로 이해할 수 있는 문서가 좋은 문서이다.

좋은 문서에는 약간의 형식도 필요하다.


<정리>

* 문장은 가능한 한 짧게 마무리 짓는다.

문장을 정중하게 마무리할 필요는 없다.가능한 한 짧게 문장을 정리해서

읽는 이들이 한눈에 내용을 파악하게 하는 것이 좋다.


'캐릭터는 점프를 할 수 있습니다.'(x)

'캐릭터는 점프를 할 수 있다.'(O)

이 경우 위의 문장보다는 아래의 문장이 선호된다.



* 하나의 문장에는 하나의 내용만 담는다.

긴 문장보다 짧은 문장이 읽을 때 더 빨리 이해할 수 있다.

비슷하거나 연결된 내용이라도 하나의 문장으로 연결해서 쓰면

문장이 길어지게 되고, 한눈에 내용을 이해하기 어려워진다.

차후에 문서의 내용 일부를 수정하게 될 때,

구체적으로 어떤 부분이 수정되었는지 알기 어렵다.

'캐릭터는 위로 점프를 할 수 있고, 두 번 연속으로 점프하면

이단 점프를 할 수 있지만, 떨어지는 지형에서는 점프를 할 수 없다.'


'캐릭터는 위로 점프할 수 있다. 

두 번 연속으로 점프하면 이단점프를 한다.

떨어지는 지형에서는 점프를 할 수 없다.'


내용을 연결해서 긴 문장으로 쓰는 것보다 짧은 문장으로

분리해서 쓰는 것이 읽는 이들이 이해하기에 더 좋다.




* 문서가 양이 많아진다면 문서를 나눠서 작성한다.


긴 문서를 읽고 싶어하는 이들은 없다.

하나의 게임을 만들기 위해서는 생각보다 많은 내용의 정리가 필요하다.

게임도 복잡해져서 어떠한 게임도 하나의 문서로 깔끔하게 정리하기 어렵다.

하나의 문서에는 핵심이 하나만 있는 것이 좋다.

구현 담당자가 다르다면 당연히 문서가 분리되어 있는 것이 

작업하기에 더 편리할 것이다.



* 핵심 내용은 가급적 앞에 쓴다.


문서를 읽는 이들이 문서의 모든 내용을 꼼꼼하게 읽기를 기대하지는 않을 것이다.

개발자들은 필요한 내용만 빠르게 살펴보고 싶어한다.

중요한 내용은 가급적 문서의 앞에 써서 읽는 이들이 놓치지 않도록 한다.

앞부분은 소중한 공간이다. 무의미한 내용이나 형식적인 사항들로 

읽는 이들의 집중력을 허비하게 할 필요는 없다.


주로 문서의 앞부분에 기술되는 내용은 구현의 지향점들로

이 시스템들이 무엇을 위해서 만들어지는지,

이 컨텐츠가 어떤 목적을 갖고 있는지 등이다.



* 그림과 도표를 적극 활용한다.


좋은 이미지는 때로 긴 문장으로도 이해시키기 어려운 것을 쉽게 설명하기도 한다.

글자보다는 그림이 더 빨리 이해되는 경우가 많다.


잘 정리된 이미지는 효과적인 의미 전달 도구이며 상황을 이해시키기 위해서

어떻게 도표나 이미지를 정리하는 것이 좋을지 고민하는 것도 자신의 생각을

정리하고 다듬는 데 도움이 된다.




문서가 모든 것을 설명할 수는 없다.

너무 자세하게 정리된 문서는 때로는 읽기에 부담스러울 수도 있고,

오히려 이해하는데 어려움을 줄 수도 있다.

실제로 모든 내용을 적는 것도 불가능하다.

문서는 여러가지 도구 중 하나일 뿐이다.


중요한 내용 위주로 문서에 담고, 문서를 전달하기 전에

문서의 내용을 설명하는 미팅을 하고 세부 내용을 설명하기를 권한다.


그 과정에서 내가 놓친 부분이 있다면 차후에 문서에 추가하면 된다.

오랫동안 같이 일을 해온 동료라면 문서에서 세부적인 내용을

설명하지 않더라도 서로 이해할 수 있을 것이다 문서는 필요한 만큼만 쓰면 된다.


좋은 아이디어가 있다고 하더라고 그것을 설계해서 완성된 게임으로

만들기 위해서는 많은 연습이 필요하다.


프로그래밍이나 게임 엔진에 대해서 공부하는 것도 좋다.

게임을 무엇으로 만들 것이냐에 대한 공부가 될 것이다.


도구를 잘 다루는 것도 필요하지만 게임, 그 자체가 목적인 연습도 필요하다.

단편적으로 떠오르는 생각이거나 기존 게임의 한 장면을 보고

전체적인 흐름을 설계해서 게임 하나를 완성해보는 과정을 여러 번 연습하면서

어떤 요소들이 플레이에 도움이 될지, 완성도를 높이기 위해서는 어떤 장치가 필요한지를

고민하면서 전체 모습을 구성해보는 훈련을 할 필요가 있다.


유행의 흐름이 있고 예전의 게임들을 참고한다고 해도


자신이 만들 게임의 형태와 완성도를 본인이 고민하지 않으면 

좋은게임을 만들기 어려울 것이다.



'게임 기획서 > 문서 작성' 카테고리의 다른 글

레벨 디자인  (0) 2019.04.29
시스템 디자인  (0) 2019.04.29
게임 구조 설계  (0) 2019.04.29
게임 아트  (0) 2019.04.29
프로토타입  (0) 2019.04.29
:

레벨 디자인

게임 기획서/문서 작성 2019. 4. 29. 09:46

레벨 디자인(Level Design)

게임 플레이가 이루어지는 공간을 디자인하는 것을 말한다.

공간 안에서 어떤 플레이를 하게 하고, 어떤 경험을 줄 것인가 등

게임의 여러 요소들을 하나로 통합하는 것에 대한 고민이다.


<공간에 대한 계획>


전통적인 의미의 게임들, 흔히 테이블 게임(Table Top Game)이라

부르는 게임들은 레벨 디자인이라는 개념이 필요없었다.

그 게임들은 정해진 규칙이 있었고 플레이어들은 규칙에 따라 행동하면서

승부를 겨루는 방식이었다.

상황에서 할 수 있는 행동들이 규칙으로 정의되어 있어서

게이머(Gamer)들은 자신의 행동을 결정하고 각 게이머들의 행동이 

서로에게 영향을 미치면서 게임이 진행되었다.

이런 게임들은 게임 디자이너들이 플레이의 흐름을 제어할 수 없었다.


체스 게임을 예로 들어 설명하면 각각의 체스 말은 어떻게 움직일 수 있는지

이동 규칙이 정해져 있다.

각각의 체스말을 어떻게 움직일 것인지는 게이머의 선택이다.

체스 말들은 규칙을 벗어나서 움직일 수는 없다.

게이머는 언제 어떤말을 움직이게 할 것인지, 

말을 어느방향으로 움직일 것인지를 결정한다.


참여한 이들의 순간순간의 결정들로 인해서 

게임의 긴장감이 바뀌지만 이건 게이머들이 만드는 상황이고,

게임 디자이너가 만드는 상황은 아니다.

게임이 진행되면서 만들어지는 모든 상황은 게이머들이 만들어내고

게임 디자이너는 의도하는 상황이 나올 수 있게 게임 규칙을 만들었다.

이런 게임은 게임 디자이너가 플레이의 흐름을 제어하는데 한계가 있다.


게임 디자이너는 재료를 제공하고 게이머들이 재료를 어떻게 갖고 노는지 결정한다.


초창기의 비디오 게임은 테이블 게임과 크게 다르지 않았다.

게임의 규칙은 단순했고, 날아오는 공을 받아치거나 떨어지는 물체를 받는 등의

단순한 반응 행동에 관련된 것이 많았고, 게임 플레이를 위한 공간에 대한 고민은

크게 필요하지 않았다.


하지만 게임 내에서 표현할 수 있는 것이 많아지면서 게임 디자이너가

플레이 흐름을 구체적으로 디자인할 수 있게 되었다.

플레이어의 캐릭터가 이동하면서 장소마다 특정 상황을 다르게 만들수 있는데,

어느 구간은 빠르게 지나가야 하고, 어느 구간은 느리게 진행하는 등의 

적절한 조작을 요구하는 게임 배경을 만들 수 있다.

이렇게 만들 경우 두 공간에 대한 플레이는 다른 흐름으로 진행된다.

게임 디자이너는 게임 플레이를 좀 더 구체적으로 디자인할 수 있게 되었다.


<레벨 디자인이란 무엇인가>


작게는 맵을 디자인하는 것이고,

크게는 플레이의 흐름을 잡는 것이 레벨 디자인이다.

플레이의 흐름을 잡는다는 것은 플레이 진행 과정을 만드는 것이다.

시작하는 부분에서는 게임 플레이에 대한 방법을 알려주고,

중반에서는 플레이의 흐름이 끊기지 않으면서 지루하지 않게

컨텐츠들을 배치하고, 중간중간에 적당한 허들을 넣어서

플레이어에게 난관을 주지만 난관을 넘어설 수 있는 

충분한 장치들을 배치해서 난관을 극복했을 때

성취감을 얻게 한다.


언제 느슨하게 진행하고, 언제 조여서 긴장감을 갖게 할지 등의

의도가 고려되어 게임 요소들이 배치된다.

작게는 하나의 구간, 스테이지, 던전, 사냥터 등이 될 수 있고

크게는 플레이의 시작부터 끝까지 일관성 있게 만들기도 한다.


게임이 너무 쉽다면 플레이어들은 지루함을 느낄 것이다.

반대로 어려운 구간이 너무 길게 지속된다면 이 역시 지루함을 느낀다.

게임에 몰입하려면 적절한 강도의 자극이 지속적으로 주어져야 하지만

규칙적으로 주어진다면 다음 번의 강도는 이전보다 더 약해지기 마련이다.


약간은 예측을 벗어난 흐름이어야 플레이어의 몰입도가 올라간다.

그래서 어려운 게임이라도 단순하게 계속 어려운 상황을 만들진 않는다.


전투를 할 수 있는 조건을 얻기 위한 과정이 어렵고 조건을 모두 갖춘 상태에서는

전투는 그렇게 어렵지 않게 진행될 것이다.


전투 상태인 몬스터(Monster)를 만드려는 것은 플레이어를 괴롭히게 하는

목적이 아니라 승리했을 때 성취감을 주려는 것이다.

자신이 처한 상황을 살피고 이용할 수 있는 모든 자원을 이용해서

상대를 이겼을때 사람들은 희열을 느끼고 본인에게 만족감을 느낀다

이것은 게임의 즐거움 중 하나다.


어려운 전투를 끝내고 멋진 장비를 얻었다면, 한동안은 그 장비를 들고

나의 강함을 즐길 수 있는 시간이 필요하다. 

장비를 얻고 다음 사냥터로 갔더니 계속 어려운 전투가 기다리고 있으면,

게임을 즐긴다기보다는 계속 시험을 보는 느낌으로 다가올 수도 있다.


게임 플레이는 완급 조절이 중요하다.

적장한 가격으로 적당한 난이도를 주고 허들을 넘었을 때

스스로에 대한 만족감을 충분히 즐길 수 있게 한다.

잘 디자인된 레벨은 이런 플레이를 만들어낸다.


<플레이를 위한 배경>


하나의 구간의 플레이에 대해서 디자인한다는 것은 각각 다른 색실을 엮어서

하나의 매듭을 만드는 것과 같다.


하나의 플레이를 만들기 위해서는 플레이에 엮어 넣을 수 있는 재료가 

무엇이 있는지 모두 알아야 한다.

컨텐츠를 구성하는 모든 시스템에 대해서 이해하고 있어야 한다는 뜻이다.

다뤄야 하는 재료를 모두 알아야 어떻게 가공할지 판단할 수 있다.


하나의 구간에 대해서 레벨 디자인을 하려면 해당 구간의 플레이 목적을 알아야 한다.

목적을 위해서 필요한 플레이를 구상하고, 플레이를 만들기 위한 컨텐츠들을 연결해서

언제 어떤 플레이를 하게 할 것인지 정리한다.


디자인한 플레이를 할 수 있도록 플레이를 위한 공간을 설계하고 구상했던 컨텐츠들을 얹는다.

배경을 만든다는 것은 그 위에서 무슨 플레이를 하게 할 것인지 설계한다는 것이다.


레벨 디자인 하면 많은 사람들이 지형 디자인, 배경 디자인을 연상하지만

레벨에는 높이, 층의 의미가 있다. 

하지만 수준이라는 의미도 있다.

플레이의 수준을 어떻게 플레이하게 할 것인지 고민하고

필요성을 충족시키기 위한 지형을 만드는 일은 눈에 띄는 일 중에

가장 먼저 하는 일이다.


Level

--------------------------------------------------------------------

 명사


1.AMOUNT I (특정한 시간적 상황에 존재하는 양의) 정도[수준]

2.STANDARD I (가치' 질 등의} 수준[단계]

3.RANK IN SCALE I (크기' 중요도의) 수준[규모]

4.POINT OF VIEW I 관점,입장

5.HEIGHT I (지면 또는 무엇의 이전 위치와 관련지은) 높이

6.FLOOR/LAYER I (건물'땅의) 층

---------------------------------------------------------------------


지형을 만드는 것은 그저 배경을 만든다는 의미가 아니다.

이 모든 내용을 포함해서 어떤 플레이가 이루어지게 할 지

여러가지 세부사항이 고려된 바탕을 만드는 것이다.

게임의 모든 요소들을 조화롭게 분배해서 하나의 흐름을 만들어

플레이어들이 게임에 몰입하도록 한다.


<사냥터 만들기>


RPG게임에서 특정 구간을 디자인하기 위해서 어떤 과정을 거치게 될까.

성장의 중간과정에서 스킬을 새로 가르쳐주는 플레이 구간 - 사냥터를 디자인하려고 한다.


□ 스킬은 어떻게 가르쳐 줄 것인가, 배우기 전의 과정이 필요할까?

□ 스킬을 배운 후 스킬 사용이 익숙해지게 하기 위한 구간이 필요하다.

    - 이 구간은 스킬 사용 시 실수하더라도 치명적이지 않도록 어렵지않게 만든다.

    - 익숙하지 않는 스킬을 사용하는 데 위험부담이 크다면 사용을 꺼리게 될 것이다.

    - 이 구간은 진행에 따라 점차적으로 위험도가 증가하게 만든다.

□ 새로 배운 스킬을 꼭 사용해야 성공할 수 있는 지점, 혹은 몬스터를 만든다.


배우게 될 스킬의 특성을 이해하고 해당 스킬이 필요한 전투의 특징을 알아야

전투 대상이 되는 몬스터를 디자인할 수 있다.

그 전에 게임에서 전투가 어떻게 이루어지는지 알고 있어야 한다.


플레이 진행 과정에서 들어가야 할 사건을 만들고 사건을 해결하기 위한

조건이 필요하면 조건을 충족시킬 수 있는 구간을 만든다.

스킬을 습득한 후 얼마나 오랫동안 훈련을 시킬 것인지 고려하고

훈련을 위한 공간의 넓이를 정하고 흐름에 따른 난이도의 기준을 설정한다.


기능적인 부분이 정리되었다면 그 다음은 감성적인 부분이다.

사냥터에 어떤 설정을 넣고, 설정에 맞는 분위기는 어떻게 조성할지 고려해야 한다.

플레이의 세부적인 동선을 유도하기 위해서 퀘스트를 이용하기도 한다.

사냥터의 설정은 무엇이며 어떤 이야기들이 있을지 정리하고 

그 분위기를 표현하기 위한 장치들을 만든다.


구상한 계획을 위한 지형 계획을 세운다.


□ 플레이에 대한 구체적인 계획

□ 지형 제작

    - 지형의 구조 결정

    - 지형의 분위기와 표현되어야 하는 설정 등을 결정


□ 컨텐츠 제작

    - 몬스터 디자인

    - 퀘스트 디자인


□ 플레이 구현

    - 비전투 캐릭터/몬스터,오브젝트 등을 배치


구간별로 어떤 사냥을 시킬 것인지 결정하고 

구간과 구간 사이에 어떤 완충 장치를 넣을지 결정한다.

사냥의 특성과 난이도 등등 디자인 의도를 고려해서 지형을 만든다.


<연습>


기본 시스템이 전혀 없는 상태에서 레벨 디자인을 하겠다는 것은

게임 전체를 다 만들어야 한다는 의미이므로 

기존의 게임 중 하나를 선택해서 그 게임의 레벨을 하나 만들어 보는게 좋다.

게임을 하나 선정하고 그 게임의 시스템과 컨텐츠를 우선 이해해야 한다.


게임 속 특정구간의 사냥터 하나를 선택하고 그와 대치되는 사냥터를 만들 것이다.

게임에 있는 사냥터와 같은 목적, 같은 특성으로 만들어도 되고,

플레이해봤더니 아쉬운 점이 있었다면 기존 사냥터와 병렬적으로

배치할 수 있는 사냥터를 만들어도 좋다. 사냥터의 목적을 정한다.


사냥터의 목적이 정해지면 목적을 이루기 위한 방법으로 무엇을 할 수 있는지

목록을 만들어본다. 그럼 사용할 수 있는 도구가 준비된다.


동선을 정하고 동선의 부분마다 무엇을 플레이하게 할 것인지 계획을 세운다.

어떤 컨텐츠를 어떤 간격으로 플레이하게 할지, 난이도는 어느 정도로 할지를 정한다.

이것이 해당 지점의 플레이 목적이다.


사냥터의 목적이 '새로운 장비를 맞추기 위해서 돈을 벌어야 하는 곳'일지라도

사냥터의 특정 지점의 목적은 '3인 파티 플레이가 어렵지 않게 플레이할 수 있는 곳'이 될 수도 있다.

각 지점의 목적들이 서로 연결되어 플레이의 흐름을 만들 수 있어야 한다.


동선을 고려해서 지형구조를 계획한다.

동선의 부분에 어떤 플레이가 필요한지가 정리되어 있으므로 플레이에 필요한 공간도 정리할 수 있다.

때로는 넓은 공간이 필요할 수도 있고, 고저차가 심한 지형이 필요할 수도 있다.

다양한 목적에 맞춰서 지형의 구조를 만든다.


지형의 구조가 나왔다면 사냥터의 기본 설계도가 나온 것이다.

구역마다 의도한 전투에 맞는 몬스터의 데이터를 만들고 

몬스터를 어떻게 배치할지 계획을 세운다.

몬스터뿐만 아니라 비전투NPC나 오브젝트 등등의 지형에 

배치되어야 하는 모든 것들의 배치 계획을 세워야 한다.


사냥터의 배경 설정을 만든다.

게임의 세계관에 어울리는 배경을 만들고 배경에 어울리는 

시각적 분위기를 만든다 여기에도 기능적인 요소가 있다.

그래픽은 감성적으로 게임을 몰입하게 만들지만, 

플레이에 필요한 정보를 제공하기도 한다.


퀘스트의 가이드를 하기 위해서

'푸른 나무 아래의 제단에 올려놔 주세요'라고 한다면

'푸른 나무'는 정보의 기능을 하게 된다.

배경에 푸른 나무가 여럿이라면 플레이어는

목적지를 찾기 어려울테니 푸른 나무를 하나만 만들거나,

다른 특징을 만들어서 플레이어가 게임 진행에 필요한 충분한 정보를

얻을 수 있게 해야 한다.


배경을 위해 꾸며져야 하는 요소들, 전달한 정보를 정리해서

아티스트에게 보여줄 문서를 만든다.

필요한 내용에 대한 이유도 설명되어야 한다.


문서를 작성할 때 설명이 길어지면 문서가 장황해질 우려가 있긴 하지만

가능하면 읽는 이들이 쉽게 이해하도록 문서 모양에

신경쓰면서 내용을 정리한다.


레벨 디자인의 작업 과정은 계획을 세우고, 무엇을 만들어야 할지 정리해서

작업자들과 공유하고 작성해야 하는 데이터들을 만들어서

플레이 테스트를 진행하는 길고 세심한 과정이다.

각각의 과정에 무엇이 정리되어야 다음으로 진행할 수 있을지 생각해본다.


레벨 디자인은 게임의 시스템도 이해하고 있어야 하고, 

플레이의 감성도 읽을 수 있어야 한다.


<정리>

* 플레이의 전체적인 흐름을 디자인하는 것이 레벨 디자인이다.


* 완급 조절을 통해 플레이의 흐름을 만든다. 규칙적으로 어려워지는 것이 아니다.


* 레벨 디자인을 하기 위해서는 게임을 구성하는

 모든 컨텐츠와 시스템에 대해 이해하고 있어야 한다.


* 플레이 동선을 계획하고 동선에 따라 컨텐츠들을 배열한다.


* 긴장감을 줄 구간과 느긋하게 진행할 구간의 흐름을 구별한다.


* 흐름을 구성하기 위한 중심 요소가 있어야 한다.


* 플레이의 흐름을 고려하여 지형을 만든다.


* 계획된 지형에 게임 요소들 - 몬스터, 퀘스트 등등을 어떻게 배치할 지 계획을 세운다.

'게임 기획서 > 문서 작성' 카테고리의 다른 글

마무리  (0) 2019.04.29
시스템 디자인  (0) 2019.04.29
게임 구조 설계  (0) 2019.04.29
게임 아트  (0) 2019.04.29
프로토타입  (0) 2019.04.29
:

시스템 디자인

게임 기획서/문서 작성 2019. 4. 29. 09:43

시스템 디자인(System Design)


<게임규칙을 위한 규칙>

게임을 플레이하기 위해서는 규칙이 필요하다.

게임 디자이너는 게임의 규칙을 정해서 게임이 어떻게 진행될 것이냐를 정의한다.

예) 테이블 보드 게임

유닛,카드,보드판등을 어떻게 이용해야 할지를 정의한게 게임 규칙.

규칙이 정리되었다고 게임이 완성되지는 않는다.

어떤 구성의 유닛이 필요하고, 맵에는 뭐가 그려져 있어야 하며,

카드에 적혀야 할 정보가 무엇인지 정리하고 인쇄하면

드디어 게임이 하나 완성된다.


디지털 게임을 만들기 위해서는 추가적인 과정이 하나 더 필요한데,

게임 규칙을 어떻게 작동하게 할 것인가의 문제다.

게임 플레이를 위한 규칙과 게임을 구현하기 위한 규칙이 필요하다.


플레이어가 보고 인지하는 것 외에 플레이어에게 보이지 않는 다른 규칙들이 있다.

바로 '게임 시스템'이다.


[용사가 빨간 물약을 먹고 체력은 128만큼 회복했다.]

->체력이 128만큼 회복되었다는 것은 빨간 물약이 갖고 있는 값일까,

용사의 레벨에 따라 계산된 값일까?


<시스템 디자인의 과정>


시스템은 게임 내부의 데이터들이 어떤 법칙으로 돌아가게 할 것이냐를 정의하는 것이다.

게임 규칙과는 조금 다른 개념이면서 비슷한 개념이다.

시스템은 게임 규칙이 어떻게 진행되게 할 지에 대한 규칙이라 할 수 있다.


예) +(더하기)는 

더하기를 기준으로 좌/우의 값을 더하고,

좌/우의 값은 문자열은 안되고 숫자열만 가능하며,

좌측부터 순서대로 계산한다.

->더하기에 대한 기본 규칙.

게임을 위한 규칙을 조금 덧붙여보면 아래와 같다.


예) 한 스테이지(stage->시작과 끝이 있는 짧은 구간을 말함. (한)판, 혹은 레벨, 챕터 등으로 말하기도 한다)

에서 덧셈 문제가 n개 나오고, 시간 안에 문제를 모두 맞혀야 한다.

문제를 모두 맞히면, 해당 스테이지는 성공, 모두 맞히지 못하면 실패한다.

정해진 시간보다 빨리 맞히면, 추가 점수를 받을 수 있다.


여기까지는 플레이어도 쉽게 알 수 있는 규칙이다.

게임을 만들기 위해서는 다른 규칙들이 필요하다.

문제는 어떻게 낼 것인지,

'정해진 시간'은 어떻게 정의할 것인지에 대한 규칙이 있어야 한다.


예) 한 스테이지에서 문제는 5~15개까지 나온다(1~10:5문제, 11~20:10문제,21~30:15문제)

뒤로 갈수록 문제의 수가 많아진다.

문제의 수에 따라 스테이지의 제한 시간이 정해진다.


한 스테이지를 반복 플레이를 할 때, 같은 문제가 나오면 재미없을 것 같으니,

5문제라면 10개 혹은 15개를 내고, 그 안에서 랜덤으로 5문제가 나오도록 하는 게

좋을 것 같다. 문제는 출제되어야 하는 문제의 3배의 문제를 준다.


예) 문제는 미리 내놓는다.

한 스테이지에 필요한 문제는 제출수 * 3 (3배의 문제를 준비해놓는다)

한 문제당 주어지는 시간은 10초로 한다.

문제는 한 자릿수만 등장한다.

스테이지는 모두 30개를 만든다.


문제를 제출하려면 문제를 위한 데이터 테이블(DataTable)을 만들어야 한다.


<시스템과 데이터>


게임을 위한 규칙에는 두가지 성격의 규칙이 있다.

1. 게임 진행과정에서 변하지 않는 규칙

-> 덧셈의 규칙 같은 것들

무엇을 어떻게 처리할지를 정의하는 것이 시스템이다.

시스템을 만들기 위해서는 여러 상황에서 판정하는

규칙들을 명확하게 정의해야 한다.


퀘스트의 액션으로, 플레이어 캐릭터는 다음과 같은 행동을 할 수 있다.

[장작을 들고 이동할 수 있다]


개념에 대한 설명은 이렇게 쓸 수 있으나 이것을 시스템으로 만들기 위해서는

좀 더 긴 설명이 필요하다.


필드에 장작이 배치된다 - 장작은 [ObjectData]로 정의하고, 배치는[ObjectSpawnData]에서 위치를 지정한다.

플레이어 캐릭터가 장작 가까이 가면, 장작을 들 수 있는 조작 키가 활성화된다.

장작 가까이 - 장작을 중심으로 3m 이내로 접근하면 조작 키가 활성화된다.

조작 키를 선택해서 장작을 들면, 플레이어 캐릭터는 장작을 들고 있는 동작의 애니메이션을 한다.

장작을 들고 있을 때에는 일반 이동의 1/3 속도로 이동할 수 있다.

장작을 들고 있는 중에 공격을 받으면, 장작을 떨어뜨리고 전투 상태가 된다.

떨어진 장작은 사라진다 - 전투가 끝나고 다시 처음의 위치로 가서 장작을 들어야 한다.


막연한 개념들을 정확하게 표현해서 기준을 정해야 한다.

가까이 간다는 것이 아니라 2m라고 거리를 명시하고, 그 상황에서 일어날 수 있는 모든사건,

상황들에 대해서 어떻게 반응할 것인지를 정해야 한다.

일차적으로 개념을 정리했다면, 그 개념을 어떻게 판단하고 적용할 것인지를 정리하는 것이다.


이런 변하지 않는 규칙이 있다면, 가변적인 재료들도 있다.

가까이 - 3m 이내로 접근하면 조작 키가 활성화된다고 생각해본다.

장작과 같은 것이 여러 종류가 필요하다면 큰 틀을 만드는게 좋다.

가까이 가면 - 3m 이내로 접근하면 조작 키가 활성화되고, 조작 키를 

선택하면 정해진 액션을 취하는 것이 큰 틀이고 공통적인 규칙이라고 할 수 있다.


이런 규칙 안에서 장작에 가까이 가면 장작을 들고 이동해서

모닥불을 피울 수 있고, 우물 가까이 가면 물을 뜰 수 있거나,

석상 가까이 가면 석상을 밀어버릴 수 있다.

이런 것을 오브젝트라고 정의하고 세부적인 내용을

오브젝트 데이터(Object Data)로 입력하는게 좋다.


오브젝트 데이터에는 장작, 우물, 석상 등이 있을 수 있다.

장작은 장작을 들고 이동하고, 장작은 놓으면 사라지고,

물은 놓으면 물을 마실 수 있고, 석상은 놓으면 

원거리 공격을 할 수 있다.

큰 규칙을 만들어놓고 세부적인 내용을

데이터로 입력할 수 있도록 하면 쉽게 새로운 것을 추가하거나

기존의 내용을 수정할 수 있다.

주로 디자이너들이 사용하는 데이터라고 해서 

디자인 데이터(Design Data)라고 부르기도 한다.

모든 시스템이 그러지는 않지만 많은 시스템들이 필요한 데이터들이 있다.


전투시스템은 캐릭터의 능력치와 몬스터의 능력치를 비교해서

누가 이길지를 결정한다.

능력치를 기반으로 상대에게 얼만큼의 데미지를 줄 것인지를 전투 공식으로 만든다.

전투 공식은 가변적이지 않고 누구와 전투를 하든 항상 같은 방법으로 판정한다.

하지만 캐릭터의 능력치와 몬스터의 능력치는 상대에 따라 다르다.

몬스터는 해골병사와 고블린 전사가 서로 다른 능력치를 갖고 있다.

또는 같은 해골 종류일 수도 있고, 능력치가 다른 몬스터가 여러 종류일 수도 있다.

몬스터들은 데이터로 각 몬스터들의 스탯을 정의한다.

몬스터 데이터를 전투 공식에 대입해서 캐릭터가 이길지, 몬스터가 이길지를 판단한다.


캐릭터 시스템은 몬스터와는 조금 다르다.

몬스터는 데이터들이 고정되어 있지만 캐릭터의 기본 능력치는 정해져 있어도

성장하면서 조금씩 변할 수 있어서 ' 기본 ' 캐릭터의 능력치가 필요한 것이 아니라

'현재' 캐릭터의 능력치가 필요하다.


시스템의 논리적인 구조를 만들고, 프로그래밍으로 시스템을 구현하면

필요한 데이터를 입력해서 게임을 플레이할 수 있게 만든다.

여기에서 시스템의 구조를 만들고 데이터를 입력하는 것은 디자이너의 역할이며,

게임의 최종 모습은 디자이너의 손에서 결정된다.


[게임 개발 순서]

시스템 디자인 -> 시스템 구현(Programming)->데이터 입력->게임 플레이


<연습>


아주 간단한 게임을 하나 선택한다.

1978년에 나온 스페이스 인베이더나, 1985년에 나온 슈퍼 마리오 브라더스같은

게임을 예로 들어본다.


선택한 게임의 구성요소들을 적는다

[스페이스 인베이더]

- 플레이어가 조작하는 우주선이 있다

- 이 우주선은 횡으로만 이동 가능하다

- 공격해서 제거해야 하는 외계인들이 있다

- 외계인들은 처음에 등장할 때, 행과 열을 맞춰서 시작하며,

한 칸씩 옆으로 이동하면서 아래로 내려온다

- 간헐적으로 비행선이 제일 위에 지나간다

- 비행선은 언제 공격당하느냐에 따라 점수가 다르다

- 우주선과 외계인 사이에는 장애물이 있다

- 장애물은 외계인의 공격도, 우주선의 공격도 모두 맞으며

맞을때마다 파괴된다


게임의 구성요소들과 그것들이 무엇을 해야하는지를 정리하고

이걸 어떻게 만들어야 할지를 정리한다.

우주선의 시작 위치를 어떻게 지정하고, 외계인들의 배열은 어떻게 지정하고

플레이 영역은 어떻게 제한할 수 있을지를 고민한다.


'우주선이 왼편 모서리에 나타나서 오른편으로 갔으면 좋겠어.'라고 말하면

프로그래머가 게임을 완성해주는 것이 아니다.

우주선의 시작위치를 데이터로 입력할 수 있게 만들어주면 다양한 데이터를 넣어보고

최적의 위치를 찾아서 결정하는 것은 게임 디자이너의 몫이다.

어떤 데이터를 입력해야 하고 입력한 데이터가 어떻게 동작해야하는지 생각해본다.


예시로 든 게임들이 너무 간단하다면 좀 더 복잡한 게임으로 할 수도 있다.

게임의 구성요소들을 모두 나열해서 각 요소들의 시스템적 정의를 내린다.

각 시스템들의 동작원리를 설명하고 필요한 데이터를 목록화한다.

어떤 시스템들은 같은 데이터를 사용할 것이다.

어떤 시스템에서 해당 데이터를 입력하게 할 것인지를 정리한다.

열쇠로 열리는 문을 만든다면, 열쇠는 자신이 어떤 문을 열 수 있는지 알고 있어야 할 것이고,

문은 어떤 열쇠가 자신에게 맞는지 알아야 할 것이다.

열쇠가 문의 정보를 갖고 있고, 문이 열쇠의 정보를 갖고 있다면 이것은 서로 중복된다.

이 경우는 문이나 열쇠 둘 중 하나만 정보를 갖게 한다.

시스템에 대한 설명은 가능한 객관적이고 명확한 언어로 표현한다.



<정리>

* 시스템은 게임의 동작 원리를 규정하는 것이다.


* 시스템을 만들 때에는 기준이 명확해야 한다.


* 만들 게임의 모습을 구체적으로 상상해서 논리적인 기준을 잡는다.


* 숫자에 익숙해져라.


* 디자이너가 원하는 값을 쉽게 적용할 수 있도록 데이터 테이블을 만든다.


* 비슷한 성격을 가진 데이터끼리 묶어서 데이터 구조를 만든다.


* 하나의 데이터는 한곳에서 입력하도록 한다.


* 시스템들 간의 연계성도 고려한다.


'게임 기획서 > 문서 작성' 카테고리의 다른 글

마무리  (0) 2019.04.29
레벨 디자인  (0) 2019.04.29
게임 구조 설계  (0) 2019.04.29
게임 아트  (0) 2019.04.29
프로토타입  (0) 2019.04.29
:

게임 구조 설계

게임 기획서/문서 작성 2019. 4. 29. 09:42

게임 구조 설계(Game Structure)


<게임의 구조>

게임을 개발할 때 , 제일 먼저 만드는 것은 프로토타입이다.

프로토타입은 게임 플레이 중에서 가장 핵심의 플레이 부분을 구현하는데,

이것만으로 게임의 전체적인 모습을 가늠하는 것은 쉽지 않다.


프로토타입은 게임의 핵심이지만, 게임의 전체적인 모습을 그리기 위해서는

다른 사소한 것들도 필요하다.


<플레이의 흐름>


게임의 구조를 잡는다는 것은 게임을 실행하고 종료할 때까지의

큰 플레이의 흐름에 대한 구상과도 같다.


이것은 단순히 UI(UserInterface)를 말하는 것이 아니라 게임 플레이의 흐름이나

게임 내 구성요소들(Contents)의 흐름이다.

시작과 종료라는 것이 게임을 실행하고 종료시키는 것을 말하는 것이 아니다.

이 흐름을 잡으면 각각의 요소들이 어떻게 연관되어 있는지 정리할 수 있고,

그렇게 하다보면 게임의 전체적인 모습과 규모를 알 수 있다.


시작은 프로토타입부터다. 

요소를 중심으로 플레이의 흐름을 정리하는 것은

엔딩이 없는 온라인 게임에서 주로 사용하는데,

결말이 없다보니 게임 플레이는 순환 구조를 가져야만 한다.

그래야 플레이어들이 끊어짐 없이 지속적인 플레이를 할 수 있기 때문이다.

굳이 새로운 경험이 없어도 요소들의 흐름이 부드럽게 순환된다면

지속적으로 게임을 즐길 수 있다.


게임의 전체 구조를 정리하고 나면 게임 규모(volume)가 결정된다.

구성요소들이 얼마나 많으며, 그 요소들이 어떻게 연결되어 있고,

세부적으로 무엇을, 얼마나 만들어야 할까 하는 것들 말이다.

게임의 크기가 가늠되고, 프로덕션 단계에 들어갈 때, 작업 일정과

대략적 업무 부담을 예측해볼 수 있다.


온라인 게임이라면 지속적으로 플레이를 할 수 있어야 하기때문에

엄밀히 말해 게임의 종료, 엔딩이 없다.

대신 그 안에서 컨텐츠들의 흐름이 정리되어야 한다.


<문서작성과 연습>


문서를 작성할 때 읽는 이가 이해하기 쉽게 작성해야 한다.

플레이 흐름을 이해시키려면 좀 더 신중한 설명이 필요하다.

한 부분이 아니라 게임 전체를 설명하거나, 혹은 영화/드라마 등을

전체적으로 다른 이들에게 설명해보면 내가 전체적인 모습을 잘 설명하는지,

너무 부분에만 신경쓰는지를 알 수 있다.


게임에 대한 정보가 거의 없는 사람들에게는 U.I의 흐름에 따라

설명하면 이해하는 게 도움이 된다.

우리가 알아야 하는 것은 게임이 어떻게

플레이어들에게 보일까 하는 것이다.


플레이어에게 어떻게 보일지를 설명하면 만드는 게임이 

어떻게 플레이어들에게 보일지를 알 수 있게 해준다.

각 부분마다 화면을 중심으로 필요한 내용들을

정리하고, 그 다음 단계로 필요한 내용들을 정리한다.


게임의 구성요소들이 연결되는 것에 대한 것도 설명이 필요하다.

하나의 플레이가 어떻게 다른 플레이로 연결되는지,

전투를 하다가 채집이나 제작을 언제 어떻게 하게 되는지,

게임 내의 플레이 혹은 게임 내의 자원/재화들이 어떻게 흘러가고

어떤 유기적인 관계를 갖는지를 설명하면 큰 틀에서 개념을 이해하기에 좋다.


많이 이용하는 것이 순서도(FlowChart)나 개념도(Mindmap)이다.

문자만으로 설명하는 것보다 서로의 연결 관계를 그린 도표가 

이해하기 더 좋은 법이다.

큰 개념을 잡으면 그 다음의 세부적인 규칙들은

설명도 쉽고 이해도 쉽다.


하나에 너무 많은 내용을 담으려고 하지 말아라.

플레이의 큰 흐름을 쉽게 이해시키기 위함이지 모든 경우의 조건을

설명하려고 하면 도표는 복잡해지기 때문에 그 도표를 읽고 이해하기

번거로울 것이다.

나타내야 하는 것이 많으면 세부적으로 단계를 조절해가면서

설명하는 것이 좋다.




<정리>

* 핵심 플레이 부분을 정리한 후, 게임 전체의 구조를 정리한다.


*게임의 시작과 종료 사이의 과정에 플레이어가 어떤 행동을 할지를 순서대로 정리한다.


* 게임 내에 많은 구성요소들이 있다면 이것들은 어떻게 서로 연결되는지를 그려본다.

    - 이것이 게임의 플레이 흐름이고, 게임 내 자원의 흐름이다.


* 게임의 구조에 대해서 정리하면 게임의 규모에 대해서도 

 어느정도 예측이 끝난다.

    - 게임을 개발하기 위해서 얼마의 자원이 필요한지를 알 수 있다.

    - 이를 바탕으로 일정 등을 예측할 수 있다.



'게임 기획서 > 문서 작성' 카테고리의 다른 글

레벨 디자인  (0) 2019.04.29
시스템 디자인  (0) 2019.04.29
게임 아트  (0) 2019.04.29
프로토타입  (0) 2019.04.29
컨셉(Concept)  (0) 2019.04.23
:

게임 아트

게임 기획서/문서 작성 2019. 4. 29. 09:39

게임 아트(Game Art)

<이미지가 없는 게임>


머드게임(MudGame->Multi User Dungeon)

최초의 머드게임은 로이 트럽쇼(Roy Trubshaw)와 리차드 바틀(Richar Bartle)이 개발해서

1978년에 서비스를 시작했다.


플레이어들이 미지의 던전을 탐험하는 것이 이 게임의 주요 플레이 내용이었다.

모든 머드게임이 던전 안에서만 돌아다니는 것은 아니나,

새로운 장소를 탐험하고, 몬스터와 싸우고, 마법을 사용하면서 비밀의 보물을 찾아다니는 것은

많은 게이머들에게 매력을 불러일으켰다.

한국에서는 1993년경부터 플레이를 할 수 있었으며 전화선을 통해 게임을 플레이했다.


머드게임의 흥미로운 점은 게임이 모두 글자로 이루어져 있다는 것.

캐릭터의 위치나 처한 상황을 모두 글자로 설명해서 소설을 읽는 느낌도 있었다.

지형을 설명하고, 전투가 시작됨을 알리고, 아이템을 얻은 것도 모두 글자로 설명했다.

캐릭터를 이동시키는 등의 게임조작도 명령어를 글자로 입력해서 게임을 진행했다.


이미지가 없는 게임이다보니 플레이어의 상상력이 필요했지만, 

텍스트로만 등장하는 몬스터와 조우해서 숫자로만 진행되는 전투의 긴장감은

요즘의 게임 못지 않았다.


던전을 탐험하는 게임인데, 내가 어떤 길을 지나왔는지

개인적으로 던전 구조를 그려놓지 않으면 같은 곳을 빙글빙글 돌기도 일쑤였다.

그 다음에는 조금 더 친절한 게임이 나왔다.


화면은 문자로 가득하나, 문자의 배열을 이용해서 지형구조를 보여준것이다.

1980년에 나온 게임 로그(Rogue)는 화면에 아스키 부호로

던전의 구조를 그려서 플레이어가 어느 위치에 있는지, 어느지점에 

몬스터가 나오거나 아이템이 있는지를 설명했다.

구조를 이미지로 보여주는 것만으로도 플레이는 쾌적해졌고,

게임에 대한 몰입감도 더 좋아졌다.


<게임 디자인과 그래픽>


게임의 그래픽은 게임을 표현하는 아주 중요한 요소 중 하나이며,

게임에 좀 더 몰입하게 해주는 장치가 된다.

때로 플레이어들은 어떤 게임 플레이를 할 수 있느냐보다

어떤 그래픽을 갖고 있느냐를 기준으로 게임을 선택하기도 한다.


게임 디자이너와 아티스트의 의사소통이 중요해졌다.

게임의 아트를 전반적으로 책임지고 진행하는 아트 디렉터(ArtDirector)가 있다 해도

게임 디자이너가 아티스트들이 어떻게 이미지 컨셉을 잡고 진행해야 하는지

챙겨야 하는 부분이 있다.


게임 속의 이미지들은 예쁜 그림들이 아니라, 게임 세계와 플레이 상황 등을 

플레이에게 전달하는 역할도 한다. 

게임의 요소들이 어떻게 시각적으로 보여져야할지 신중하게 고민하고 결정해야 한다.

게임 디자이너들은 아티스트와 긴밀하게 이야기를 나눠서 최선의 결과물을 낼 수 있어야 한다.


게임을 만드는 것은 플레이어의 경험을 디자인하는 것이며,

게임 디자이너는 자신이 만든 게임 안에서

플레이어가 어떤 감정을 가지고 플레이하게 할 것인지를 고민한다.

시각적 자료는 경험을 좀 더 구체적으로 만들면서 게임에 더 몰입하게 만든다.


<구체적이고 명확한 설명>


아티스트들이 많이 토로하는 고충들이 있는데,

너무 모호한 표현으로 요구사항을 전달하거나, 개인의 취향을 강요하는 것들이다.

예) 섹시하고 귀여운, 그로테스트하면서 웅장한<-구체적이지 않은 표현들


모호한 표현들의 문제점은 정말 중요한 정보전달이 되지 않고 진행과정에서

개인적 취향으로 논쟁을 벌이게 될 수 있다는 것.

답을 찾을 수 없는 논쟁은 서로에게 소모적이다.


아티스트에게 필요한 이미지 작업을 요청할 때, 무엇이 필요한 내용이고,

어느 범위 안에서 아티스트가 자신의 생각을 표현할 수 있는지를 알려줘야 한다.

아티스트가 게임 디자이너의 마음을 읽을 수 없다.

아티스트가 게임 디자이너의 취향을 맞춰줄 필요도 없다.


같이 작업하기 전에 게임 디자이너의 역할과 아티스트의 역할에 대해서 잘 생각해보고

경계의 문제점들을 어떻게 해결할지 논의하고 개발과정에서 서로의 업무 영역을

불쾌하게 넘나들지 않도록 주의해야 한다.


경험이 적은 사람들에게 게임 내에서 필요한 캐릭터가 있어서 아티스트에게

내용 전달을 위한 문서를 작성하라고 하면 캐릭터들의 외형에 대해서

꼼꼼하게 문서를 갖고 오는 경우가 많은데, 

자료를 뒤져서 가장 적합하다고 생각하는 이미지를 찾는 것은 당연하나

왜 그것을 찾았는지에 대한 설명은 부족하고 이미지의 결과에 대한 설명만 적는다.

그 것은 무의미하고, 아티스트들에게 모작을 시킬 것이 아니라면 

시각적으로 새로운 컨셉을 잡고, 아티스트가 상상해서 작업할 수 있도록

작업 범위와 목적에 대해서 설명하는게 중요하다.


<설정과 기능의 표현>


게임 속 필요한 캐릭터에서 무엇이 표현되어야 하는지 필수적인 내용은

1.기능 2. 분위기 

이 두 가지 방향이 있다.


게임의 이미지에 대해서 고민해야 하는 방향은 두가지가 있다.

1. 기능적 접근 

무엇이 필요한지를 파악하고, 그에 대한 내용을 정리하는 것.

크게 어떤 요소들이 있는지 정리하고 각 요소들의 세부적인 기능을 정리하면 된다.

게임의 내용이 구체적으로 정리가 되면 목록화할 수 있다.


2. 설정적 접근

게임의 분위기를 잡는 것이다.

이 게임은 웅장한 분위기? 아니면 귀엽고 아기자기한 것? 무섭고 공포스러운 것?

말 그대로의 느낌을 표현하는 것이다.

시각적 분위기에 대한 것이지만, 게임 디자이너가 원하는 내용에 대해서 

명확하게 전달할 필요가 있다.


'게임의 분위기는 좀 어둡고 괴기스러운 분위기였으면 좋겠어. 

캐릭터가 작게 들어갈 거라서 머리가 크고 동글동글한 귀여운 형태면 좋을 것 같아.'


게임의 그래픽은 생각하는대로 나오는 것이 아니고, 게임 아티스트도

팀의 동료이며 같이 게임을 만들어가는 개발자다.

그래서 왜 이런 이미지가 나와야 하는지 설명이 필요하다.

모든 디자인은 의도가 있는법이다.


'배경의 장치들을 보고 맵의 함정을 피하면서 앞으로 진행해야 하는 게임이야.

배경을 봐야 하기 때문에 캐릭터가 너무 크면 안되니까 화면 비율상

캐릭터가 작게 보이게 될 것이므로 캐릭터의 움직임이 잘 보일수 있는 비율이어야 해.

그리고 어려운 게임을 생각하고 있어서, 캐릭터가 함정을 피하지 못하면

귀엽게 폴짝폴짝 뛰어가다가 목이 잘리는거지.'


게임과 어울리는 분위기를 잡으려면 플레이를 이해하고,

그에 어울리는 그래픽 분위기를 잡아야 한다.

테마를 맞춰서 게임의 그래픽에서 시각적으로 표현하고,

게임 디자인에서 구조적으로 표현한다.


배관공이 스패너를 들고다녀야만 하는 이유를 만들어서

플레이와 연계시키는 것이다.


게임의 이미지는 게임의 분위기를 반영한다.

게임의 이미지를 위해서는 어떤 게임인지를 설명해야 한다.

만약 게임이 유쾌하고 가벼운 플레이를 추구한다면

게임의 이미지 또한 밝고 유쾌한게 어울릴 것이다.


게임이 심각하고 진중한 이야기를 다루고 있다면

게임의 이미지 또한 그런 이야기를 반영할 것이다.


게임에 대한 설명과 게임을 통해 무엇을 표현하고 싶은지를 설명한다.

바로 게임의 컨셉이다.


게임의 컨셉은 이것이 어떤 게임이라는 것을 설명하는 가장 좋은 방법이다.

여기에서 말하는 게임의 컨셉은 게임이 어떤 게임인지에 대해서 설명하고,

게임이 추구하는 방향, 개발의 목표 등에 대해서 공유해야 한다는 것이다.


일반적인 경우에는 게임의 컨셉 문서를 공유하지만, 가끔은 그래픽을 위한

별도의 문서를 작성하기도 한다. 


게임의 컨셉과 함께 게임의 시각적 요구사항에 대해서 

잘 설명해줄 수 있는게 있는데, 바로 '게임의 스토리'다.

게임의 컨셉 문서를 작성할때, 스토리를 설명하는 게임이 아님에도 불구하고

배경 설정을 넣거나 시놉시스 등을 적어주는 경우가 있다.

바로 게임의 테마를 어떻게 잡는게 좋을지에 대한 설명이다.


스토리가 진행된다거나 스토리를 전달하고자 하는 게임이 아니더라도

배경 설정이 있으면 플레이어가 게임에 몰입하기 위해서

어떤 내용을 전달해야 하는지를 알 수 있다.

게임을 플레이하는데 몰입하기 위해서는 게임 내의 세계에 대한

이해가 있으면 도움이 된다.


<현실적인 가이드의 제공>


게임의 분위기에 대해서 어느정도 가이드라인이 나오면 아티스트와 논의한다.

게임에 대해서 설명하고, 그래픽에서 표현되어야 하는 사항들을 정리해서 논의하면

게임을 시각화시키는데 좀 더 구체적인 이야기를 할 수 있다.

기준이 있으므로 그에 맞는 이미지들을 만들어 낼 수 있다.

논의를 하면서 분위기가 변경될 수도 있다.


필요한 작업 내용을 설명할 때에는 구체적으로 목록을 작성해서 전달하면

받는 사람이 이해하기에 훨씬 쉽다.

□ 게임 진행용 캐릭터

□ 게임 플레이용 모션 5개 필요(달리기,걷기,뛰기,점프,사망)

□ 캐릭터 선택 화면에서 전체 모습

□ 대화창에서 보일 캐릭터 아이콘


이렇게 구체적으로 정리해서 전달하면 캐릭터를 디자인하더라도

어떤 부분을 더 신경 써서 이미지 작업을 해야할지 이해하기 쉽다.


그래픽 작업은 두 단계로 진행된다.

처음은 컨셉을 잡는 단계

다음에는 실질적으로 게임에 필요한 리소스를 만드는 단계

리소스를 만들 때에는 결과물의 목록을 전달한다.


작업 목록이므로 컨셉을 잡을때보다 더 구체적이고

자세한 설명으로 전달되어야한다.

컨셉을 잡는 단계에서도 예상하고 있는 작업 범위를 공유하면

컨셉을 잡을때 더 효과적인 모습을 고민할 수 있다.


서로의 진행 상황을 공유하고 요구하는 바를 논의하면서 정리하면 된다.


<문서 작성 요령>


시스템에서 필요한 그래픽 목록을 작성하고

이것이 어디에 사용되며 어떤 내용을 담고 있어야하는지 설명한다.

-> 작업 분량을 쉽게 파악하게 하기 위해 목록으로 만든다.


컨셉문서는 개발 초기 단계에서 어떻게 분위기를 잡을지 논의하는 단계이므로

작업목록을 만드는것 보다 좀 더 광범위하고 막연하다.


게임에 대해서 설명하고 게임 플레이의 방향성, 방향성으로 인해 요구되는 그래픽의 분위기

또는 게임 내에서 진행되는 스토리를 위한 배경 설정 등을 설명한다.


아티스트가 시각적 기준을 모두 결정한다고 해도 어떤 분위기를 원하는지 구체적으로 설명해야 한다.

문서에는 글로 된 설명 외에도 참고할만한 이미지를 자료로 첨부한다.

참고할 자료를 문서에 첨부할 때에는 이 이미지를 왜 참고용으로 선택했는지에 대한 설명을 적어야 한다.


'배경이 늪지대여서 약간은 몽환적인 분위기가 났으면 좋겠는데, 이 것처럼 저채도의 

부드러운 색감이면 좋겠다' 


' 숲의 아이들이라는 설정이 있으니까 옷차림 등에 대해서도 숲과 어울리는 색감을 써 달라.'


'녹색이 이 캐릭터의 가문의 색이므로 녹색의 신발을 신겨달라.'


원하는 바나 필요한 내용을 구체적으로 설명해주는 것이 좋다. 

이미지를 설명하는 것이 아니라 원하는 구성요소를 설명한다.


아티스트가 좋은 이미지를 만들 수 있도록 충분한 재료를 주면서

그들의 새로운 해석 또한 존중해줘야 한다.


<연습>


만들고자 하는 게임에 어울릴 캐릭터 이미지를 찾는다.

인터넷이나 화보집 등을 활용해서 기대하는 캐릭터와 가장 비슷한 이미지를 찾는다.

찾은 이미지를 보고 주요한 특징을 적는다.

내가 만들고자 하는 캐릭터의 외형에 필요한 주요한 특징이다.


외형적인 묘사를 위해서 아티스트와 논의할 것이므로 

외형적 표현을 중심으로 목록을 정리한다.


□ 키가 크다

□ 녹색의 두건과 옷을 입고 있다

□ 한쪽 어깨에만 견갑을 대고 있다

□ 허리 버클의 장식은 태양의 모양이다.


적은 목록들이 왜 게임에 어울린다고 생각하는지 이유를 적는다.

반드시 그렇게 되어야하는 것인지 반대 의견도 적어본다.

반대 의견이 타당하다면 그 이유는 중요하지 않은 것이다.

참고자료를 찾는 과정에서 마음에 드는 이미지가 있을 때

그 이미지에 현혹되어 내 생각을 참고하는 이미지에 

맞추지 않도록 해야한다.


□ 숲에서 활동하는 조직이므로 녹색의 옷을 입는다 

-> 숲에 어울리는 의상이면 되는것이 아닌가?

□ 활을 쓰는 레인저들이므로 활을 당기는 팔은 견갑을 두르지 않는다

-> 방어구로 어떤 무기를 사용하는지를 표현하고 싶다.

□ 태양신을 섬기는 사제들이므로 태양신의 상징이 필요하다

-> 꼭 허리 버클이어야 하는가, 태양신의 상징을 지니고 있기만 하면 되는가?


목록을 만들어보면 좀 더 객관적으로 판단할 수 있다.

나의 주관적인 취향의 반영인지 게임에 정말 필요하다고 생각되어 

이미지에 해당부분이 반영되어야 하는지.


□ 설정상 이 캐릭터가 속한 그룹은 녹색의 의상을 입는다.

그리고 이 게임에서 설정의 표현은 중요하다

□ 이 캐릭터의 장비는 활이다.


주관적인 판단이더라도 들어가면 게임과 잘 어울릴 것 같은 부분들도 있으나

그 부분은 따로 정리해서 전달해야 한다.


분명히 의미있는 내용이지만 게임 내에서 보여주기 어려운부분이거나 

게임의 리소스 제작에는 어울리지 않지만 아트 컨셉에는 필요한 내용일 수도 있다

그런 부분들은 분리해서 정리한다.


□ 설정상 이 캐릭터가 속한 그룹은 녹색의 의상을 입는다

-> 게임 내에서 이 설정은 그다지 중요하지 않다.-> 해당 내용은 반드시 필요한 내용이 아니다.

□ 허리 버클의 장식은 태양의 모양이다.

->하지만 게임 내 캐릭터는 3등신이라서 허리 버클은 보이지 않는다

-> 이 내용은 참고자료로 제시할 수 있으나 게임 리소스를 위한 아트 작업에

반영해야 하는지 아닌지에 대한 기준을 알려준다.


정리한 내용을 주변의 아티스트들에게 보여주고 어떤 컨셉을 잡을 수 있는지 물어본다.

아티스트가 그것을 보고 내가 참고용으로 찾았던 이미지와 거의 흡사한 이미지를 잡았다면

정리한 내용은 아티스트의 의견이 적게 반영되었을 가능성이 높고,

머릿속에 갖고 있는 이미지를 강요했을 수도 있다.

필요한 요소를 이용해서 아티스트가 자신의 능력을 충분히 발휘할 수 있도록 설명했는지

모방을 위한 내용을 설명했는지를 생각해보자.


컨셉이 결정되었다면, 실제로 게임 내에서 필요한 리소스는 어떤 것인지 목록으로 정리한다.


점프를 하면서 횡스크롤로 이동하는 게임이라면 

캐릭터의 정지, 이동-걷기. 이동-달리기, 점프 등등의 모션이 필요할 것이다.

UI에 보여질 캐릭터 아이콘이 필요할 수도 있고

캐릭터를 선택하기 위한 이미지가 필요할 수도 있다.

이런 식으로 게임 내에서 필요한 목록을 작성해본다.

아티스트가 무슨 작업을 해야 하는지 고민하지 않고

그 목록만 보고 작업할 수 있다면 괜찮게 만든 것이다.




<정리>

*  원하는 분위기를 위해서 참고자료를 준비한다.


* 실제로 필요한 내용인지, 개인의 취향인지를 구별해야 한다.

    - 그들의 본분을 존중하라.


    - 반드시 필요한 것, 되면 좋은 것, 절대 되면 안되는 것을 분리해서 설명해라.


* 필요한 것을 설명할 때에는 이유도 설명해라.


* 아티스트가 일의 범위를 알 수 있는 가이드를 제공해라.


* 작업 목록을 만들어라.

'게임 기획서 > 문서 작성' 카테고리의 다른 글

시스템 디자인  (0) 2019.04.29
게임 구조 설계  (0) 2019.04.29
프로토타입  (0) 2019.04.29
컨셉(Concept)  (0) 2019.04.23
제 2 장 게임개발단계(Game Dev.Process)  (0) 2019.04.22
:

프로토타입

게임 기획서/문서 작성 2019. 4. 29. 09:31

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

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

고민하는 과정 중 하나다.


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

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

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

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


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

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

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

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


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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

생각을 정리하는 것이다.


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

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

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

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


<무엇을 만들까>


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


<어떻게 만들까>


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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


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


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

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


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

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


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

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


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

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

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

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


<연습>


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

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


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

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

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


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

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


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

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

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


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

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


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

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

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


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

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


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

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


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

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


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

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

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


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

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

플레이의 흐름을 적는다.


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

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


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

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



<정리>

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


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


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


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

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


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


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

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


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

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

'게임 기획서 > 문서 작성' 카테고리의 다른 글

게임 구조 설계  (0) 2019.04.29
게임 아트  (0) 2019.04.29
컨셉(Concept)  (0) 2019.04.23
제 2 장 게임개발단계(Game Dev.Process)  (0) 2019.04.22
1장. 게임디자인  (0) 2019.04.18
:

컨셉(Concept)

게임 기획서/문서 작성 2019. 4. 23. 09:06

컨셉(Concept)


어떤게임을 만들고자 한다면 가장 먼저 컨셉을 결정한다

게임을 만드는 목표를 제시하며 개발 과정에서

여러 문제가 발생했을 때, 어떻게 결정해야 하는지에 대한

지침역할을 하기도 한다


컨셉을 잡는 과정은 흰 도화지를 앞에 두고 있는것과 같다

새로운 시도를 할 수 있는 기회이기도 한 것


새로운 게임을 만들기 위해서 가장 먼저 해야하는 것은

컨셉을 잡는 것이다

어떠한 게임을 만들지를 결정하는 것.


이 게임을 통해서 무엇을 말하고 싶은지,

플레이어가 무엇을 느끼게 하고 싶은지를 결정하는 것.


경험이 적은 사람들이 잘못 생각하는 것 중 하나는

아이디어와 컨셉이 같다고 생각하는 것이다.


아이디어가 아직 정리되지 않은 영감이라면,

컨셉은 아이디어들을 정리해서 목표를 세운 것까지

진행된 단계라고 할 수 있다.


여러 생각을 늘어놓은 다음 그 중에 중심으로 삼을 것을

정해서 중심을 세운 후 그에 어울리는 다른 아이디어들을

가감해 하나의 게임을 만드는 것이다.


어떻게 해야 할지 모르겠다면, 게임의 일부분을 구체적으로

상상해본다.

다 만들어진 게임은 어떤 플레이가 펼쳐질까.

배경은 어떠하고, 플레이어의 캐릭터는 어떻게 움직이며,

몬스터들은 어떻게 싸우게 될까


만약 게임플레이를 상상할 수 없다면,

아직 여러 아이디어들이 떠다니고 있고,

컨셉을 무엇으로 할지 결정되지 않은 것이다.


비어있는 부분들을 채워서 한 장면을 완성해라

그 후 그 장면의 플레이가 재미있을지를 상상해본다

만약 재미있지 않다면, 다시 새로운 플레이를 만들도록 한다

재미가 있다면, 구체적으로 어떤 부분이 재미있을지를 

설명할 수 있어야 한다.

바로 그것이 컨셉이다.


게임 내의 요소들이 부드럽게 연결되는 것은 필요하다

플레이의 흐름이 끊기지 않고 익숙한 것에 지루해지기 전에

새로운 플레이 요소나 새로운 도전의 목표가 생겨야

게임을 지속적으로 플레이할 수 있다.


플레이 요소가 많다해서 그 게임이 재미있다고 할 수 없다.

플레이의 요소들중에 어떤 것에 핵심 재미 요소를 넣을 것인지를

고민해야 한다


게임 디자인의 목표 - 핵심 재미요소와 플레이의 목표가

항상 같은 것은 아니라는 것


<컨셉문서의 작성>


컨셉이 정리되었다면, 그걸 팀원들에게 설명해야 한다

문서에는 게임의 컨셉이 설명되어있어야 하고,

그리고 어떤 게임인지 간략하게 설명하면 된다


* 게임 컨셉


* 핵심 재미 요소


* 게임의 간략한 설명


게임의 컨셉은 가능한 간략한 문장으로 표현하는 것이 좋다

문장을 간결하게 만들기 위해서 너무 막연한 표현이

들어가도 좋다는 것은 아니다

'박진감 넘치는','다양한','혁신적인'식의 표현은 좋지않음

이것은 게임을 구체적으로 설명해줄 수 없기 때문에

이런 단어를 사용하겠다면 좀 더 자세한 설명이

덧붙여지는게 좋다


가장 좋은 문장은 그 문장을 듣고 어떤게임인지 연상할 수 있는 것

컨셉이 뚜렷하고, 다른게임들과 차별화될수록 그런 문장을 만들기는

좀 더 수월해진다

중요한 것은 핵심과 그렇지 않은 것을 구별해서 설명해야 한다


게임의 핵심 재미는 어떤 플레이가 중심인지 그 플레이를 위해서

무엇을 강조해야하는지를 설명하는 것이다

말로 설명하기 어려운 경우가 많은데, 다소 감각적인 부분을 표현하는 

경우도 있기 때문

논리적인 부분이 핵심이라면 그나마 말로 설명할 수 있으나

(퍼즐게임 같은경우가 게임의 규칙 안에 들어있는 경우가 많다)

문서에 명시를 해주는 것이 좋은 이유는 

목표를 명확하게 할 수 있기 때문


컨셉 문서가 개발팀을 위한 문서라면 게임의 본질적인 설명에

충실한 게 다른 개발팀원들이 이해하기 좋다.


대략적인 프로그램 구조를 생각할 수 있거나 아트 컨셉을

잡을 수 있는 내용이 들어가면. 다른 파트의 개발자들은

자신의 역할에서 어떤 방향을 추구해야 하는지 짐작할 수 있다


컨셉 문서가 투자를 위한 문서라면 개발팀을 위한 것과는 

조금 다른 내용이 필요하다.


외부 자본을 유치하거나, 혹은 사내에서 팀을 정식으로

구성할 수 있는 조건을 만족시키기 위한 발표 자리를 위한

문서라면 개발 외적인 부분에 대해서도 설명이 필요하다


'어떤' 게임인지도 중요하나 얼마나 수익을 낼 가능성이 있느냐도

중요하고, 게임을 설명하는 부분에도 적당한 미사여구가 

들어갈 필요가 있기도 하다


'우리는 다양한 몬스터를 수집할 수 있게 할 것입니다'

라는 내용이 중요할 수도 있다.


'우리는 기존의 M게임보다 다양한 몬스터를 수집할 수 있도록

할 것입니다라고 설명한다면, 이것 역시 새로운 기준으로서의 가치를

갖는 것이다.

많은 수의 몬스터는 그 게임만의 새로운 광고전략이 될 수 있다


<연습>


이미 출시된 게임을 참고해서 컨셉 문서를 작성해본다.

비슷한 게임을 여러 개 놓고, 각각의 게임 컨셉을 정리한 다음,

어떤 컨셉이 어떤게임과 연결되는지를 확인해본다.


만약 내가 정리한 컨셉 하나가 대상이 되는 게임에 모두 적용된다면,

나는 컨셉을 잡지 못하고 있는 것이다.


새로운 컨셉을 구상한다면, 게임의 목표가 무엇인지를 설명하고,

그 목표를 이루기 위해서 어떤 플레이가 진행되는지를 설명해본다.


만약 플레이 과정이 게임의 목표와 자연스럽게 연결된다면

괜찮은 컨셉을 정한 것이다.


가장 좋은 것은 컨셉만 이야기해도 어떤 플레이가 진행될 지

듣는 이들이 구체적으로 상상할 수 있는 것이지만,

좋은 컨셉은 좋은 아이디어만큼이나 잡기 어렵다.


게임의 플레이가 컨셉과 어울리도록 전체적인 모습을

구상하는 연습이 필요하다.

게임 플레이 장면을 구체적으로 설명할 수 있어야 한다.

컨셉을 정하는 것은 어떤 플레이를 만들어야 하는지도

구체화되었다는 것이다.

아이디어가 컨셉이 아니라는 것을 알아야 한다.


<요약>


* 컨셉은 게임 개발의 목표다.


* 개발팀원은 모두 컨셉에 대해서 이해하고 있어야 

같은 목표를 갖고 게임을 만들 수 있다.


* 문서를 보고 게임의 플레이를 연상할 수 있다면 좋은 문서다.


* 좋은 컨셉은 길지 않은 문서로도 내용을 전달한다.

컨셉이 명확하지 않을수록 설명이 많아진다.


* 컨셉 문서에 핵심 플레이에 대한 설명을 추가하면

읽는 이들이 게임을 이해하기가 좋다.







'게임 기획서 > 문서 작성' 카테고리의 다른 글

게임 구조 설계  (0) 2019.04.29
게임 아트  (0) 2019.04.29
프로토타입  (0) 2019.04.29
제 2 장 게임개발단계(Game Dev.Process)  (0) 2019.04.22
1장. 게임디자인  (0) 2019.04.18
:

제 2 장 게임개발단계(Game Dev.Process)

게임 기획서/문서 작성 2019. 4. 22. 09:11

제 2 장  게임개발단계(Game Dev.Process)


게임디자이너들은 게임의 규칙을 디자인하는 사람들이다

게임의 완성형이 어떤것인지 알고 있기 때문에 자연스럽게 개발과정에서

진행을 맡는다

어떤부분이 먼저 구현되어야 한다거나 결과물의 목적이 무엇인지

팀원들과 공유해서 프로젝트의 방향을 정하는 것 등이다


어떤게임을 만들것인가는 팀원이 같이 모여서 의논하지만 세부적인 모습을

결정하는 것은 게임 디자이너이고,게임디자이너의 문서가 팀에 공유되면

본격적으로 개발이 시작된다


팀의 규모가 커서 일정을 관리하는 역할을 맡은 사람이 있다면

경우가 다르지만, 팀이 작다면 자연스럽게 게임 디자니어가 프로젝트의 일정을

관리하는 역할을 맡게된다


게임의 내용을 결정하는 사람과 일의 진행을 정리하는 사람이 같으면

마음에 드는 결과가 나오지 않은경우 계속 결정을 번복할 수 있다는것이다


모든 게임디자이너들은 개발 단계와 일정관리에 대해서 알고 있어야한다

시간낭비를 줄이기 위함과 팀원간의 신뢰를 떨어뜨리지 않기 위해서


게임 개발 순서


게임 컨셉



프로토타입 제작



게임 구조/규모 결정



구현/리소스 제작



데이터 입력



폴리싱



테스트



출시



게임 개발과정에서 게임디자이너의 역할은

어떤 게임을 만들지 정리하고 필요한 재료들이 준비될 수 있도록 

각 파트원에게 필요한 내용을 구체적으로 알려주고

재료들이 준비되면 조립해서 완성된 게임을 만든다.


게임에 필요한 논리적인 구조와 툴, 리소스들이 어떻게 준비되어야 하는지를 결정하고

정리하는 역할을 한다



개발 준비 단계 (Pre-Production)


게임개발은 크게 개발 준비 단계 

구현단계(Production)

후반 작업단계(Post-Production)을 지나 출시한다


프리프로덕션은 어떤게임을 만들지 구상하는 단계이다

이 단계를 거치면서 어떤 게임을 만들지에 대한 답을 찾고,

구현할 수 있는지, 구현할 가치가 있는지를 확인한다

여러가지 아이디어들이 나오고

아이디어들의 현실성을 검토하고 본격적인 개발에 들어가기 전에

큰 그림을 그려보는 단계다.

프로토타입도 이 단계에 들어가는데

아이디어를 구체화하는 방법 중 하나다

이 단계에서는 안정적인 작업보다는 생각을 빠르게

현실화하는 것이 필요하다


문서를 작성할때도 형식을 갖춘 멋진 문서보다는

필요한 내용만 정리하는 정도로 간략하게 만들고,

형식적인 것을 정리하는 것보다는 팀원들과 자주 소통하면서

게임의 방향성에 대해 논의하는 것이 좋다


이 시기에는 팀원들 간의 회의가 많아지게 되는데,

회의를 할 때는 반드시 회의의 목적과 시간을 정해놓고

이야기하는 것이 좋다


게임의 형태가 명확하지 않기 때문에

제한없이 이야기하면 회의의 흐름이 주제를 벗어나거나

정리되지 못하고 산만하게 흘러갈 수 있다



<게임 개발 단계별 할 일>


컨셉 - 아이디어 수집



프로토타이핑 - 플레이의 핵심 요소 정리 및 검토



구조 설계 - 게임의 플레이 흐름 컨텐츠의 순환 구조



마일스톤 #1 - 구현 순서에 따른 개발 단계 설정



... - 특징(feature)에 따른 마일스톤 계획



마일스톤 #N - FGT(Focus Group Test)



알파테스트



클로즈 베타 테스트


↓                  - 폴리싱(Polishing)

                      출시준비

                      서비스 계획


오픈 베타 테스트



출시


플레이에 관해서 괜찮은 아이디어가 나오면 프로토타입을 만든다
프로토타입을 만들면서 완성된 게임의 모습을 계속 상상하고
세부적인 부분까지 어떻게 만들지 다양한 각도로 구성해봐야 한다
개발 준비 단계가 모두 끝나야 진정으로 개발 일정을 산정할 수 있다
이 단계가 끝나면 구체적으로 무엇을 어떻게 만들어야 할지가 결정되기 때문

프로토타입으로 가능성을 검토하고, 어떻게 해야할 지에 대한
구현방법을 확인하고, 그를 바탕으로 전체적인 게임의 규모와
필요한 기능들에대한 정리가 되었을 것이다


구현단계. Production

처음에 계획한 결과물을 보는것이 중요하다
구현하는 것에 집중하는 것이 효율적이다
만약, 너무 문제가 많이 발생해서 계속 진행하는 것이 의미없다고
판단되면 즉시 중단하고 다시 계획을 세워서 진행해야 한다

전체적인 게임의 윤곽이 결정되었다 해도,그 모든 내용을 한번에 구현할 수는 없다

그래서 무엇을 먼저 구현할 것인가를 기준으로 시간을 분배하는데,
그것을 보통'마일스톤'이라 부른다
마일스톤은 말 그대로 이정표다.
게임을 개발하는 중간에 필요한 지점을 체크하는 지점이다
목표를 정하고, 이전에 구현된 결과를 보면서 
다음 이정표를 세우는 것이다.


<마일스톤 한 주기의 진행>



마일스톤           계획(Design)
                      
                      사양 결정(Dev.Spec.)
한 주기의           
                      구현(Programming/Artwork)

                      검토(Test) ↑
                       
                      ↓
                      다음 마일스톤 진행            (테스트 과정에서 문제가 발생하면 다시 계획을 세워야 할 수도 있다)
진행 


이번 마일스톤에 무엇을 할지 계획을 세우고, 구체적인 사양을 결정하고 구현한 다음에

제대로 잘 구현되었는지 확인하고 수정사항이 있으면 수정한 다음 마일스톤으로 넘어간다

마일스톤의 계획은 목표를 세우는 것이다


이 목표는 기능을 중심으로 선정된다

단기간의 목표를 설정하고 공유하는 것이 좋다

(맵에디터제작)<-구현할 기능들을 정함


세부적인 사양을 결정하는 것은 시스템을 어떻게 만들어야 할 지 결정한다는 것

마일스톤이 종료될 때마다 앞서 개발한 내용을 바탕으로

다음에 개발할 기능들의 시스템을 설계한다


<후반 작업 단계, Post-Production>


후반 작업은 마무리 단계다

필요한 기능들은 다 구현되어있고 세부적인 값들의 조율이나

어색한 부분들을 다음어서 완성도를 높이는 기간이다


폴리싱(Polishing)이나 베타테스트(Beta Test)를 모두 후반작업으로 분류했으나

프로젝트의 성격이나 관리방법에 따라서는 구현단계 - 프로덕션(Production)단계로 분류하고

후반 작업은 출시를 위한 마지막 작업들을 이야기하기도 한다

후반 작업은 지속적인 테스트를 통해서 부족한 점을 보완하고

사용감을 증대시키면서 출시 전 게임을 다듬는 과정이다


<단계별 관리>


큰 규모의 게임을 개발하는 과정은 개발준비 단계, 구현단계, 후반 작업 단계만으로

진행되지는 않음 세부적으로 더 나뉘고 구간별로 반복되는 일이 발생한다


규모가 작은 게임의 경우는 프로토타입을 하나만 만들면 가능할 수도 있다

하지만 필요에 따라 프로토타입을 여러 번 만들기도 한다

그러면 크게 두번의 흐름이 겹쳐질 수도 있다


마일스톤 전에 무엇을 준비해두어야 할지 계획을 세우고

필요한 내용을 준비해둬야 한다

게임 디자이너는 개발단계에 대해 어느정도 알아야하는 이유가

자신들이 진행하는 일에 대해서는 어느정도 관리해야 할 필요성이 있기때문이다

프로젝트의 전체적인 일정은 프로젝트 매니저(Project Manager)가 관리하지만

세부적인 항목들, 자신이 맡은 부분에 대한 진행은 게임디자이너가 관리할 수 밖에 없다.혹은 관리하게 된다.

<게임 개발 단계마다 작성되는 문서>

-----Pre-Production-------------------------------------------------------

컨셉 - 컨셉문서(게임개발의 방향 제시)

프로토타이핑 - 프로토타입 사양서(프로토타입 구현을 위한 내용)

구조 설계 - 게임 구조 문서(게임의 전체적인 구성에 대한 정리, 플레이의 흐름에 대한 정리)

------Production----------------------------------------------------------------------------------------

마일스톤 #1 - 마일스톤 단계별 문서(각종 시스템 구현을 위한 문서, 리소스 제작을 위한 문서)

... - (구현 테스트)

마일스톤 #N 

알파 테스트 - 테스트 의뢰 문서(기능 구현에 대한 테스트, 플레이 경험에 대한 테스트)

------Post-Production------------------------------------------------------------------------------

클로즈 베타 테스트

오픈 베타 테스트

↓                      - 서비스 지원 관련 문서

출시

--------------------------------------------------------------------------------------------------------


하나의 기능을 설계하고, 무엇이 구현되어야 하는지 범위를 결정하고,

계획대로 구현되었으며 차후 문제점은 없는지 검토하는 책임은 일차적으로

게임 디자이너에게 있는 것이다.

팀의 규모가 작다면, 혹은 팀원들이 모두 경험이 적은 이들이라면

학생 프로젝트라면 프로젝트의 진행관리를 게임 디자이너들이 맡게 되는 경우가 많다

무엇을 만들어야 하는지, 어떤 것부터 만들어야 하는지에 대해서 큰 계획을 세우는이가

바로 게임디자이너이기 때문

어느정도는 프로젝트 관리를 하는 법에 대해서 알고 있어야 하고,

어떻게 프로젝트를 진행할 것인지에 대해 각자 나름대로의 시나리오를 갖고 있어야 한다

그래야 다음단계를 위한 준비를 할 수 있고,하나의 단계가 끝났을 때 정리를 하면서

전체적으로 진행되는 상황을 예측할 수 있을 것이다


<연습>


이미 나와있는 게임을 하나 선택하고,

본인이 게임의 개발 일정을 관리하는

프로젝트 매니저(ProjectManager)라고 생각하고 

이 게임을 어떤 순서로 진행하면 좋을지 생각해본다


가장 먼저 프로토타입을 제작할 것이다

프로토타입으로는 어떤 기능을 최우선으로 개발할 것인가?

한꺼번에 확인하고 싶은 기능을 다 확인할 수 있을까?

만약 그렇지 않다면 몇 단계의 확인과정을 거쳐야 할까?

어느 부분까지 확인하면 본격적인 개발을 시작할 수 있을까?


프로토타입 과정이 끝나면 기능을 중심으로 구체적인 계획을 세운다.

한 번에 너무 많은 기능을 구현하는 것은 좋지 않음

한 단계마다 구체적인 목표를 세우고 그에 필요한 기능을 정리해서

한 마일스톤의 분량을 정한다.

마일스톤이 마감되었을 때 기대하는 결과물은 어떤 모습일지 구체적으로 생각한다.

목표는 가능하면 플레이가 되는 모습을 기준으로 정하면 좋으나,

구현되어야 하는 기능이 너무 많다고 생각되면 쪼개도 좋음.


연습할 때에는 가능한 한 작은 분량으로 쪼개 진행하는 것이 좋다.


짧은 기간의 목표를 잡으면 기간 동안 작업해야 하는 것과 

필요한 리소스의 목록을 만든다.


필요한 문서는 무엇이며, 필요한 그래픽 요소는 무엇인가를 적어보는 것이다.


문서는 문서라는 형식이 중요한 것이 아니라

필요한 내용이 정리되는 것을 말한다.


'스테이지 간의 이동이 가능한 플레이'를 구현한다면

구체적으로 있어야 하는 기능이 무엇이며,

스테이지에서 플레이 가능한 범위가 무엇인지를 정리해서 

사양을 결정하는 것이다.


하나의 마일스톤을 단위로 준비되어야 하는 것들, 혹은 미리 결정되어야 하는 것들,

구현되어야 하는 기능들을 정리하면서 게임이 완료될 때까지의 작업 순서를

적어보면 개발 일정을 어떻게 관리해야 할 지 알 수 있을 것이다.


기능 구현 이전에 준비되어야 하는 내용들이 있으면

언제부터 그것을 준비해야 하는지,

그것을 준비하려면 선행으로 무엇이 결정되거나 기능이 구현되어야

했는지도 볼 수 있다.


개발 순서의 흐름을 크게 보면 개발 과정을 상상할 수 있다

중간중간에 테스트를 위한 일정을 잡는 것도 잊지 않고 해야한다.


경험이 많지 않기 때문에 개발과정에 대해서 상상하더라도

구체적인 일정, 특히 기간에 대한 것은 가늠하기 어렵다.


하지만 실제 나와 함께 일하는 팀원의 역량에도 달려 있는것이므로

정확한 기간을 예측하기는 쉽지 않다.


일정관리라고 하면 기간에 대해서 엄격하게 관리해야 할 것처럼

생각하기 쉬우나 더 중요한 것은 일의 순서다.


작업 순서가 명확하고, 앞뒤로 준비되거나 정리되어야 하는 것이

명확하면 효율적으로 시간을 관리할 수 있기 때문에

결과적으로 밀도 있게 개발이 진행될 수 있고,

기간도 줄어들 것이다.


팀원들에게 구체적인 목표를 제시하고 해야 하는 일들을

명확하게 정리하는 것이 중요하다.

예측할 수 없는 것을 목표로 잡을 수는 없다.


일정관리를 하면서 너무 많은 상황에 대해서 대처하려고 하는 것보다는

가능한 변수를 줄이면서 프로젝트를 진행하는 것이 좋다.


계획이 구체적이지 않은상태에서 성급하게 작업에 들어가면

시간에 쫒기게 되고 마음이 급해져서 중요한 것들이

누락될 가능성이 커진다.

전체 계획에 대해서 팀원 간에 공유하면 개발에 대해서

예측할 수 있으므로 혼란이 줄어들 수 있다.



<요약>


* 게임 디자이너라면 개발 일정 관리에 대해 어느정도 알고 있어야 함


* 게임이 구현되는 과정을 임의로 나눈다. 임의로 나눌 때는 각 단계별로 목표를 설정한다

목표는 구체적으로 설정한다. 참여하는 팀원들이 모두 같은 내용을 인지할 수 있어야 한다


* 구현되는 과정을 나눌 때는 기간보다 순서가 중요하다. 만약 능숙한 개발자라면

기간에 대한 것도 쉽게 예측할 수 있지만, 그렇지 않다면 예측할 수 없는 것에 대한 목표를 잡을 수는 없다.


* 각 단계별로 개발이 들어가기 전에 준비되어야 하는 것의 목록을 작성하고, 

개발이 완료된 후 결과물이 있어야 하는것의 목록을 작성한다.

결과물의 목록은 필요한 파일목록이 될 수도 있고, 기능의 목록이 될 수도 있다.

이 목록을 공유하는 것으로도 팀원들은 해당 마일스톤 단계에서

무엇을 작업해야 하는지 알 수 있다.


* 각 단계마다 확인하는 일정을 꼭 잡는다.

단순하게는 리소스확인이 될 수도 있고, 구현된 기능의 테스트일 수도 있다.

여기서 말하는 테스트는 단순히 기능이 동작하는지에 대한 것만은 아니다.

게임의 전체 목표에 부합하는지에 대한 확인일 수도 있다.

테스트를 하면서 팀원들과 게임에 대해서 심도있는 논의를 할 수도 있다.


* 개발 단계는 비록 짧은 기간이라도 분리되어야 한다.

한편에서는 기능 구현을 하고, 한편에서는 테스트를 하면서 개선방안을 고민해선 안된다.

생각이 정리되지 않을 수 있고, 진행과정에서 변수가 너무 많이 발생할 수도 있다.


* 필요한 개발기간에 대한 것은 한 명이 임의로 잡을 수 없다.

실제로 작업해야하는 사람들의 의견을 듣고 그들에게 어느정도의 기간이 필요한지를 물어보라.


* 테스트는 중요하다. 그리고 마무리 단계의 테스트는 오랜시간이

필요하다는 것을 잊지말기를 바란다. 게임에서 기능 구현은 전체 개발 단계의 50%라고 생각하자.



'게임 기획서 > 문서 작성' 카테고리의 다른 글

게임 구조 설계  (0) 2019.04.29
게임 아트  (0) 2019.04.29
프로토타입  (0) 2019.04.29
컨셉(Concept)  (0) 2019.04.23
1장. 게임디자인  (0) 2019.04.18
: