Unity

■ 기획 책 ■

1. 처음부터 실무까지 완성하는 게임기획의 멘토링

출판사 : 북스홀릭

지은이 : 박재석

정가 : 30,000원

- 기획서 작성방법부터 자세히 알차게 나와있다 -

2. 게임기획자와 시스템기획

출판사 : 에이콘

지은이: 심재근

정가: 30,000원

- 시스템 기획법과 게임기획을 어떻게 하는지에 대해 자세히 기술되어 있다 - 

3. 게임 디자이너를 위한 문서 작성 기술

출판사 : 성안당

지은이 : 주진영

정가 : 16,000원

- 게임 기획 문서 작성법에 대한 내용 기술과 예제에 대해 나와있다 - 

기획서 작성 기법

<1.1> 기획자가 배워야 할 툴

1 파워포인트

프레젠테이션용 문서 작성하기위해 사용하는 툴이나

도형이나 그림 등을 쉽게 넣고 꾸밀 수 있다는 장점으로

게임 기획파트에서 기획서 작성 툴로 사용하고 있다

2. 엑셀

수식/수치를 작성하기 위해 사용하는 툴이나

게임 기획 파트에서는 시나리오부터 데이터 테이블까지

다방면에서 활용하고 있다.

3. 메모장

윈도우에 기본 내장된 툴.

특별한 형식도 필요없는 기획서 쓸때 주로 사용.

4. MS워드/아래아 한글

문서작성 시 사용하는 워드 프로세서 소프트웨어로,

최근에는 파워포인트나 엑셀에 밀려 게임 기획 파트에서

잘 사용하지 않고 있다.

MS워드는 주로 회사 내부나 다른 회사에 공문을 보낼 때,

아래아 한글은 국가기관 전달용 문서 작성 시에 사용하는 정도로

역할이 축소되었다.

5. 그래픽 툴

기획서 작성할 때 기획자가 직접 그림을 그려야 하는 경우가

종종 발생한다 게임회사에서 사용하는 그래픽 툴을

어느정도 사용할 수 있어야 한다. 

게임회사에서 기획자가 주로 사용하는 툴이다.

ㅁ 포토샵 

- 다양하고 강력한 기능을 이용해 원하는대로 그림을 그릴 수 있다 - 

ㅁ 비지오 

- 벡터 그래픽을 사용하기 때문에, 그림의 확대 축소가 자유로운 장점이 있다.

ㅁ 스케치업 

-트림블 네비게이션에서 만든 3D 툴로 

사용이 간편하고 성능이 뛰어나며, 입체로 보여줄 필요가 있는 경우에

쉽게 만들어 제시할 수 있는 장점이 있고, 스탠더드 버전은

프리웨어이기때문에 회사에서 사용하는데도 제약이 없다.

<1.2> 기획서 작성 방식

기획서는 잘보이게 만드는 것이 원칙이다.

작성 방식은 파워포인트를 기준으로 한다.

[1] 형식

① 색상 설정

글자의 색상의 가장 무난한 검은색을 사용,

배경에는 흰색을 사용하며, 필요한 경우가 아닌 한

무늬(그라데이션)을 넣지 않도록 한다.

배경에 색상이나 무늬를 넣을 경우에 글자를 읽기

어려운 문제를 방지하기 위해서이다.

게임에 출력되는 부분의 색상 설정을 위해

해당 글자나 UI에 색을 넣는 것은 문제가 되지 않는다.

② 폰트 크기

기획서는 발표용이나 실무용이냐에 따라 폰트 크기를 다르게 정해야 한다.

발표용은 보는 사람이 파악하기 쉽도록 문서는 핵심내용만 간략하게 쓰고

자세한 내용은 발표자가 직접 설명하기 때문에,

핵심내용을 한 눈에 파악할 수 있도록 폰트 크기를 크게 한다.

세부 내용이 들어갈 개발용 문서에 큰 폰트를 쓰게 되면

한 항목에 들어가는 내용이 여러 페이지로 분산되어

내용파악이 어렵고, 분량도 쓸 데 없이 늘어나게 된다.

개발용 문서인 경우 폰트 크기를 정해 사용하도록 한다.

1) 첫 페이지에 제목만 넣을 경우 폰트 크기 제한을 받지 않음.

권장하는 폰트 크기 : 30~50 폰트 사이

2) 기획서의 내용이 한 페이지에 모두 들어가기 때문에 

제목과 본문을 한 페이지에 모두 넣어야 할 경우에는

사용할 폰트의 크기를 소제목과 본문의 폰트 크기와

맞추는 것이 좋음.

권장하는 폰트 크기 : 16~24 폰트 사이

3) 본문의 경우 소제목과 세부 내용에 사용할 폰트 크기를

각각 다르게 정하도록 함.

권장하는 폰트 크기의 차는 1~2 폰트

4) 본문의 소제목에 사용할 폰트 크기는 12~14 폰트 정도로 정한다.

5) 세부 내용에 사용할 폰트 크기는 본문 소제목보다

작은 10~12 폰트 정도 크기로 정함.

6) 소제목과 세부 내용에 사용할 폰트 크기를 다르게 설정할 수 없는 경우

소제목을 진하게 처리해 서로 구분할 수 있게 한다.

7) 폰트 크기를 정하면 모든 페이지에 똑같이 적용함.

텍스트상자를 설치한 후 글자 크기를 고정시켜 사용하도록 한다.

③ 폰트 종류

글자 폰트는 시인성이 좋은 것을 사용해야 함.

기획서에는 곧고 간결해서 시인성이 좋은 돋움이나 굴림, 고딕체가 주로 사용됨.

글을 쓸 때 주로 사용하는 명조체나 바탕체는 기획성용으로는 시인성이

떨어지므로 사용하지 않는 것이 좋음.

ㅁ권장폰트

돋움 굴림 맑은 고딕

ㅁ비권장 폰트

명조 바탕

④ 여백 

페이지 전체를 모두 쓸 경우에는 시인성을 떨어뜨린다.

글을 쓰기 위해 텍스트 상자를 배치할 때는 

페이지 상하좌우 모두 약간의 여백을 두고 배치하도록 한다.

⑤ 줄 간격

기획서 작성 시에는 줄의 간격을 띄워 시인성을 높이는 것이 좋다.

권장 줄 간격 수치는 파워포인트 기준으로 1.3~1.5 사이이다.

⑥ 위치와 형태 고정

첫 페이지에 텍스트 박스나 표 등을 배치할 위치를 정했다면

나머지 페이지에서도 동일한 위치에 배치되게 한다.

텍스트 박스와 표가 같은 것이 계속 사용된다면 

형태도 똑같이 고정한다.

텍스트 박스와 표의 내용이나 쓰임새가 다른 경우에는 

형태를 고정할 필요는 없다.

⑦ 표 형태 설정

표를 사용하는 이유 : 각 항목별로 내용을 구분해

쉽게 파악할 수 있도록 만들기 위해서

1) 표제목은 [가운데 맞춤]으로 정해 셀 중앙에 오게 한다

2) 표제목은 본문과 구분할 수 있도록 글자를 굵게 처리한다.

필요할 경우에는 셀에 특정 색을 선택해 채우는 것도 좋다.

3) 본문에 들어갈 내용이 문장이 아니라 단어 또는

단어에 가까운 형태라면 표제목과 마찬가지로

[가운데 맞춤]으로 정해 셀 중앙에 오게 한다.

4) 본문에 들어갈 내용이 문장인 경우에는 [양쪽 맞춤]으로 정한다.

5) 셀 간격은 본문에 들어갈 내용에 맞춰 조절한다.

단어 또는 단어에 가까운 형태로 들어갈 경우에는

입력될 수 있는 최대 글자 수를 토대로 간격을 정한다.

설명이 들어갈 경우에는 글이 길어질 수 있으므로

가능한 한 셀 간격을 넓게 만든다.

[2] 작성방법

① 기획 의도

기획서 작성 시 가장 먼저 하는 일은 

기획서를 쓰는 이유, 목적, 의도를 명확히 쓰는 것이다.

기획의도를 쓰는 이유는 두 가지 이유이다.

1. 기획할 내용의 일관성을 유지하기 위해서.

기획서의 양이 방대해지면 처음 기획할 떄의 의도와 다른내용으로

진행되는 경우가 발생하는데, 기획의도를 명확히 설정하면

이것을 기준으로 작성하므로 이 문제를 해결할 수 있다.

2. 이 기획이 왜 필요한지 다른 개발자들에게 이해시키기 위해서.

기획의도가 기획서에 없다면 개발자는 기획자의 의도를

자기 관점에서 파악한 후 개발할 수 밖에 없고, 이럴 경우

기획자가 처음에 의도했던 것과 최종완성본이 크게 달라지는

문제가 발생한다. 기획의도를 쓴다면 이 문제를 방지할 수 있다.

기획의도를 쓸 때는 유저가 이것을 어떻게 활용하도록 할 것인가를

기준으로 작성하도록 한다.

② 내용 정리

기획 의도가 설정되었다면 

해당 기획서에 어떤 내용이 들어가야하는지 파악한 후 

간략하게 나열한다.

필요한 것을 단순히 쓰는 단계이므로 생각나는대로 쓰도록 한다.

여기에 쓴 것을 토대로 기획서의 세부내용을 완성하는 것이므로

빠진 내용이 없도록 구성해야 한다.

내용 정리 시는 텍스트 파일 등을 이용해 요점 위주로

간단하게 쓰는 것이 좋다.

③ 항목 설정

기획서에 들어갈 내용이 정리되었다면, 항목을 만들도록 한다

항목 설정 시에는 우선 나열된 것 중에 서로 같거나

연관된 내용끼리 묶도록 한다.

④ 본문 작성

기획서에 들어갈 항목과 들어갈 내용이 모두 설정되었다면

세부 설정을 하도록 한다.

기획서는 게임을 설계하는 문서이므로,

내용 역시 설계도를 만드는 것처럼 체계적으로 작성할 필요가 있다.

여기서부터는 기획서용 툴을 사용해 작성해야 한다.

기획서의 본문을 쓰는 방법

(1) 제목과 본문의 구분

기획서의 내용이 많아 페이지가 여러 장 이상인 경우에는

제목과 본문이 들어가는 페이지를 서로 분리한다.

제목은 가장 첫 페이지에 쓰며, 다음과 같은 정보를 같이 적을수 있도록 한다.

＊ 작성일자: 문서를 완성해서 납품한 날짜와 수정한 날짜를 적는다.

＊ 작성자: 작성한 사람의 신상명세를 적는다. 보통 개발팀 이름/파트/직급/이름 형태로 쓴다.

문서의 내용이 적어 한 페이지에 모두 들어갈 경우에는 

이 설정을 따르지 않아도 된다.

이때는 제목과 본문 폰트를 [폰트 크기] 항목에서

정한 크기로 정해 작성한다.

목차를 넣을 경우에는 제목과 본문 사이에 새 페이지를 마련해 넣도록 한다.

(2) 소제목의 활용

본문을 쓸 경우에는 각 항목에 맞춰 소제목을 단 후 해당 내용을 작성하도록 한다.

소제목을 만들 때는 해당 내용을 파악할 수 있는 이름을 붙이도록 하며,

소제목과 내용의 폰트 크기를 다르게 하거나 소제목을 굵은 글씨로 만들어

서로 구분할 수 있게 만든다.

(3) 내용 배분

내용이 서로 다른 항목인 경우에는 각 항목별로 페이지를 나눠 작성한다.

각 항목의 하부내용은 같은 페이지에 작성하되,

하부내용이 한 페이지 안에 모두 들어가지 못할 경우에는

다음페이지로 넘겨 작성하도록 한다.

두 항목 이상의 내용이 한 페이지에 모두 들어갈 수 있는 경우에는 

한 페이지에 넣도록 한다.

(4) 조건 설정

기획서는 해당 기획을 할 떄 발생할 수 있는 모든 경우의 수에 대한

진행 방법과 결과 처리 방법을 설정하는 문서다.

해당 항목을 설정할 경우에는 어떤 조건이 있는지 파악한 후 

각각에 대해 상세한 결과를 설정해야 한다.

(5) 문장 정리

기획서에 어울리는 형태로 작성해야한다.

a. 단락 나누기

   기획자가 생각한 것을 글로 설명할 때는 소설처럼 긴 문장을 만들어서는 안되며,

   반드시 내용별로 단락을 나눠 정리해야 한다.

   문장이 하나로 연결되어 있으면 어떤 내용인지 파악하기 어렵다.

   단락을 나누고 번호를 붙여 내용을 쉽게 구분할 수 있도록 작성한다.

   단, 스토리 설정처럼 길게 써야하는 경우라면 단락을 나누고

   번호를 붙여 구분하는 방법을 사용하기 힘들다.

   이 경우에는 문장의 첫머리를 한 칸 띄우고, 글의 길이와 내용에 따라

   줄을 바꾸거나 빈 줄을 사이에 두어 문장을 분리하는 방법을 사용해 작성한다.

   단락을 나누지 않고 모든 문장을 이어 쓰고 있을경우는 읽기 어려우므로 정리해야 한다.

b. 간략한 설명

   기획서를 쓸 때 설명이 장황하면 내용을 파악하기 힘들다.

   이런 부분을 없애고 필요한 논지만 써야 한다.

   중복되거나 필요한 부분이 많으면 내용도 파악하기 힘들다.

   필요한 부분만 넣도록 한다.

c. 객관화

   수치화가 힘든 주관적인 표현 대신 정확한 수치를 적용할 수 있도록

   객관화된 표현을 넣어야 한다.

   ※ 같은 종류의 상급 몬스터는 일반 몬스터보다 스테이터스가 조금 더 높게 설정한다.   

   [조금 더 높게] 같은 표현은 기준이 애매하므로 게임에 적용할 수 없다.

   게임에 적용하기 위해서는 객관화된 수치를 써야 한다.

   ■ 상급 몬스터 스테이터스 = 일반 몬스터 스테이터스 * 1.2

d. 쉬운 표현

   기획서는 수월한 게임개발을 위해 작성하는 것이므로

   어려운 단어나 문장을 넣어서는 안되며, 보는 사람이 내용을 파악하고

   바로 활용할 수 있도록 쉽게 작성해야 한다.

e. 문법과 맞춤법

   기획서는 공식문서이기때문에 정확한 표현이 중요하다.

   문법과 맞춤법에 맞춰 기획서를 작성해야 한다.

   ※ 회복 아이템이 회복할 수 있는 체력이 정해져 있다.

  기획서를 쓸 때 종종 나오는 문장의 대표적인 예이다.

  이 문장처럼 쓰면 회복 아이템을 사용해 회복한다는 것이 아니라

  회복 아이템이 회복한다는 뜻이 된다.

  기획자가 어떤 의미로 쓴 것인지는 짐작할 수 있으나 

  원칙적으로는 잘못된 문장이다. 원래 의도대로 쓰도록 수정한다.

  ■ 회복 아이템으로 회복시킬 수 있는 체력 수치가 정해져 있다.

f. 콜론(:) 사용

  콜론을 사용할 때에는 어느 부분을 띄울 것인지를 정한 후 

  모든 문서에 똑같이 적용한다.

  ※ 등급 설정: 해당 길드원의 길드내 지위를 선택한다.

     등급 설정 : 해당 길드원의 길드내 지위를 선택한다.

 첫째 줄은 머리말 다음에 콜론을 붙이고 있고 둘째 줄은 띄우고 있다.

 어느 쪽을 선택해도 상관없으나 한쪽을 선택했다면 

 모든 머리말에 똑같이 적용해야 한다.

g. 머리말과 내용 분리

   콜론을 기준으로 앞에는 머리말, 뒤에는 내용이 들어가야 한다.

   ※ 썰매를 타며 점프하는 게임 : 썰매 게임

   내용에 해당하는 부분이 머리말처럼 사용되고 있다.

   머리말은 내용을 압축한 것, 또는 간략화한 것이 되어야한다.

  ■ 썰매 게임 : 썰매를 타며 점프하는 게임

h. 메시지와 설명 분리

   게임에 출력되는 메시지를 설명할 경우에는 

   설명과 메시지를 분리해 쓰도록 한다.

   ※ 거래가 중지되면 "거래가 중지되었습니다." 라는 메시지가 출력되도록 한다.

  설명과 메시지가 한 문장에 들어 있어 보기가 불편하다.

  서로 분리하도록 한다.

   ■ 거래가 중지되면 다음의 메시지가 출력되도록 한다.

      메시지 : [거래가 중지되었습니다.]

  설정할 메시지가 많을 경우에는 표로 정리하는 것이 좋다.

  (대주제: 상점시스템 메시지 -> 메시지 종류 | 설정)

i. 단어 나열

  아이템 이름과 같이 여러 개의 단어를 나열해야 하는 경우에는

  서로 구분하기 쉽도록 설명과 아이템을 서로 분리한 후 , 

  [탭]키를 이용하거나 슬러시 기호, 표 등을 사용해 단어를 구분할 수 있도록 한다.

  ※ 짧은 칼, 가죽셔츠, 가죽바지, 나무방패, 가죽장갑, 가죽신발 아이템은

    신규 접속시에 기본 제공하는 아이템이다.

  ■ 다음 아이템은 신규 접속 시에 기본 제공되는 것이다.

      짧은 칼    가죽셔츠    가죽바지 

      나무방패  가죽장갑   가죽신발

   이렇게 바꾸면 파악하기 쉬워진다.

(6) 도형 활용

UI 설정처럼 그림으로 형태를 구현할 필요할 경우에는

파워포인트 등의 툴에서 직접 지원하는 도형을 활용한다.

UI 설정을 그래픽 툴로 만든 후, 기획서에 붙이는 경우가 있는데,

이렇게 만들경우에 수정이 힘든 문제가 있다.

파워포인트에서 지원하는 도형을 사용할 경우에는 수정이 간편하다.

(7) 그림 사용

기획서를 쓸 때는 글로만 설명하지 말고 그림을 이용해

같이 설명하도록 한다.

글로 설명할 경우에는 이해도를 100% 까지 올리기 힘든 반면,

그림을 같이 넣는 경우에는 이해도를 대폭 올릴 수 있기 때문이다.

그림을 넣을 때는 다음 내용에 맞게 넣도록 한다.

1) 그림을 넣을 때는 본문과 겹치지 않도록 위치와 크기를 조절해야 한다.

2) 큰 그림이 여러 장인 경우에는 축소해서 한 페이지에 모두 넣지 말고

  페이지를 추가한 후 나눠 넣도록 한다.

3) 그림 옆이나 아래에 이해를 도울 수 있는 설명과 해당 그림의 출처를 알려주는

  링크주소를 같이 곁들이도록 한다.

4) 그림의 비율은 원본과 동일하게 들어가도록 한다.

표 크기에 맞추다보면 비율이 왜곡된 형태로 그림이 들어가 있다.

그림을 표 안에 넣을 경우에는 왜곡된 결과물이 나올 수 있으므로

표 안에 넣는 것보다 빈 공간에 두는 것이 좋고,

표 안에 넣어야 할 필요가 있다면 

원본과 같은 비율로 들어가도록 설정해야 한다.

(8) 표 활용

구분이 명확할 필요가 있는 내용인 경우에는

차례대로 나열하는 것보다 표로 정리하는 쪽이 파악하기 쉽다.

대신, 설정할 내용에 따라서는 표를 사용하는 것이 그다지 좋지 않은 경우도 있다.

셀 크기가 들어갈 내용에 비해 비정상적으로 크게 된 이유는

셀 크기를 많이 차지하는 설명 항목을 표에 같이 넣고 크기를 맞추었기 때문이다.

표에 들어갈 내용의 길이가 달라 표 형태를 정하기 힘든경우에는

항목과 내용에 따라 적절한 방법을 선택해 적용하는 것이 좋다.

(9) 하이퍼링크 활용

기획서의 양이 방대할 경우에는 원하는 부분을 보기 위해

한참 찾아야하는 문제가 발생한다.

이 문제를 방지하기 위해서는 작성자 또는 읽는 사람이

쉽게 찾을 수 있게 주요 항목에 하이퍼링크를 사용하도록 한다.

하이퍼링크는 목차와 개별 항목을 서로 연결하는 경우에 큰 효과가 있다.

[3] 주의점

기획서는 출력해서 보는 경우가 있기 때문에

컴퓨터로만 볼 수 있는 애니메이션/동영상/사운드를 기획서에 넣은 것은

되도록 피해야 한다. 꼭 필요한 경우에는 링크주소를 넣는 것이 좋다.

[4] 역기획서 작성

이미 출시/서비스되고 있는 게임을 

토대로 기획서를 작성한 것을 역기획서라고 한다.

이미 만들어진 게임을 재구축하는 것이기 때문에, 새로운 기획서를 만드는 것보다

작성이 쉬운 장점이 있어 종종 사용된다.

역기획서를 작성할 때는 다음의 사항에 대해 내용을 파악하거나 작성해야 한다.

○ 역기획서로 작성한 시스템을 해당 게임에 적용한 이유/목적/동기를 파악하고

    설명할 수 있어야 한다.

○ 추가로 넣을 설정 사항 및 넣은 이류를 설명해야 한다.

    또한 개발사에서 왜 그 설정을 넣지 않았을까 하는 부분에 대한

    답변도 제시해야 한다.

마무리

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

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

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

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

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

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

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

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

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

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

필요할 수도 있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<정리>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

레벨 디자인(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나 오브젝트 등등의 지형에 

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

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

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

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

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

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

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

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

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

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

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

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

얻을 수 있게 해야 한다.

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

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

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

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

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

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

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

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

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

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

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

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

<정리>

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

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

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

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

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

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

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

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

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

시스템 디자인(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년에 나온 슈퍼 마리오 브라더스같은

게임을 예로 들어본다.

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

[스페이스 인베이더]

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

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

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

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

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

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

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

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

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

맞을때마다 파괴된다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<정리>

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

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

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

* 숫자에 익숙해져라.

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

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

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

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

게임 구조 설계(Game Structure)

<게임의 구조>

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

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

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

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

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

<플레이의 흐름>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<문서작성과 연습>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이해하기 더 좋은 법이다.

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

설명도 쉽고 이해도 쉽다.

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

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

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

번거로울 것이다.

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

설명하는 것이 좋다.

<정리>

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

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

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

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

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

 어느정도 예측이 끝난다.

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

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

게임 아트(Game Art)

<이미지가 없는 게임>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

요즘의 게임 못지 않았다.

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

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

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

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

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

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

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

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

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

<게임 디자인과 그래픽>

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

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

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

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

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

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

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

챙겨야 하는 부분이 있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<설정과 기능의 표현>

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

1.기능 2. 분위기 

이 두 가지 방향이 있다.

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

1. 기능적 접근 

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

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

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

2. 설정적 접근

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

바로 게임의 컨셉이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

□ 게임 진행용 캐릭터

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

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

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

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

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

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

처음은 컨셉을 잡는 단계

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

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

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

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

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

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

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

<문서 작성 요령>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<연습>

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

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

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

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

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

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

□ 키가 크다

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

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

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

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

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

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

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

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

맞추지 않도록 해야한다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<정리>

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

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

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

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

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

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

* 작업 목록을 만들어라.

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

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

고민하는 과정 중 하나다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

생각을 정리하는 것이다.

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

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

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

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

<무엇을 만들까>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<어떻게 만들까>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<연습>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

플레이의 흐름을 적는다.

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

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

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

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

<정리>

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

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

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

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

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

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

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

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

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

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