Unity

컨셉(Concept)

어떤게임을 만들고자 한다면 가장 먼저 컨셉을 결정한다

게임을 만드는 목표를 제시하며 개발 과정에서

여러 문제가 발생했을 때, 어떻게 결정해야 하는지에 대한

지침역할을 하기도 한다

컨셉을 잡는 과정은 흰 도화지를 앞에 두고 있는것과 같다

새로운 시도를 할 수 있는 기회이기도 한 것

새로운 게임을 만들기 위해서 가장 먼저 해야하는 것은

컨셉을 잡는 것이다

어떠한 게임을 만들지를 결정하는 것.

이 게임을 통해서 무엇을 말하고 싶은지,

플레이어가 무엇을 느끼게 하고 싶은지를 결정하는 것.

경험이 적은 사람들이 잘못 생각하는 것 중 하나는

아이디어와 컨셉이 같다고 생각하는 것이다.

아이디어가 아직 정리되지 않은 영감이라면,

컨셉은 아이디어들을 정리해서 목표를 세운 것까지

진행된 단계라고 할 수 있다.

여러 생각을 늘어놓은 다음 그 중에 중심으로 삼을 것을

정해서 중심을 세운 후 그에 어울리는 다른 아이디어들을

가감해 하나의 게임을 만드는 것이다.

어떻게 해야 할지 모르겠다면, 게임의 일부분을 구체적으로

상상해본다.

다 만들어진 게임은 어떤 플레이가 펼쳐질까.

배경은 어떠하고, 플레이어의 캐릭터는 어떻게 움직이며,

몬스터들은 어떻게 싸우게 될까

만약 게임플레이를 상상할 수 없다면,

아직 여러 아이디어들이 떠다니고 있고,

컨셉을 무엇으로 할지 결정되지 않은 것이다.

비어있는 부분들을 채워서 한 장면을 완성해라

그 후 그 장면의 플레이가 재미있을지를 상상해본다

만약 재미있지 않다면, 다시 새로운 플레이를 만들도록 한다

재미가 있다면, 구체적으로 어떤 부분이 재미있을지를 

설명할 수 있어야 한다.

바로 그것이 컨셉이다.

게임 내의 요소들이 부드럽게 연결되는 것은 필요하다

플레이의 흐름이 끊기지 않고 익숙한 것에 지루해지기 전에

새로운 플레이 요소나 새로운 도전의 목표가 생겨야

게임을 지속적으로 플레이할 수 있다.

플레이 요소가 많다해서 그 게임이 재미있다고 할 수 없다.

플레이의 요소들중에 어떤 것에 핵심 재미 요소를 넣을 것인지를

고민해야 한다

게임 디자인의 목표 - 핵심 재미요소와 플레이의 목표가

항상 같은 것은 아니라는 것

<컨셉문서의 작성>

컨셉이 정리되었다면, 그걸 팀원들에게 설명해야 한다

문서에는 게임의 컨셉이 설명되어있어야 하고,

그리고 어떤 게임인지 간략하게 설명하면 된다

* 게임 컨셉

* 핵심 재미 요소

* 게임의 간략한 설명

게임의 컨셉은 가능한 간략한 문장으로 표현하는 것이 좋다

문장을 간결하게 만들기 위해서 너무 막연한 표현이

들어가도 좋다는 것은 아니다

'박진감 넘치는','다양한','혁신적인'식의 표현은 좋지않음

이것은 게임을 구체적으로 설명해줄 수 없기 때문에

이런 단어를 사용하겠다면 좀 더 자세한 설명이

덧붙여지는게 좋다

가장 좋은 문장은 그 문장을 듣고 어떤게임인지 연상할 수 있는 것

컨셉이 뚜렷하고, 다른게임들과 차별화될수록 그런 문장을 만들기는

좀 더 수월해진다

중요한 것은 핵심과 그렇지 않은 것을 구별해서 설명해야 한다

게임의 핵심 재미는 어떤 플레이가 중심인지 그 플레이를 위해서

무엇을 강조해야하는지를 설명하는 것이다

말로 설명하기 어려운 경우가 많은데, 다소 감각적인 부분을 표현하는 

경우도 있기 때문

논리적인 부분이 핵심이라면 그나마 말로 설명할 수 있으나

(퍼즐게임 같은경우가 게임의 규칙 안에 들어있는 경우가 많다)

문서에 명시를 해주는 것이 좋은 이유는 

목표를 명확하게 할 수 있기 때문

컨셉 문서가 개발팀을 위한 문서라면 게임의 본질적인 설명에

충실한 게 다른 개발팀원들이 이해하기 좋다.

대략적인 프로그램 구조를 생각할 수 있거나 아트 컨셉을

잡을 수 있는 내용이 들어가면. 다른 파트의 개발자들은

자신의 역할에서 어떤 방향을 추구해야 하는지 짐작할 수 있다

컨셉 문서가 투자를 위한 문서라면 개발팀을 위한 것과는 

조금 다른 내용이 필요하다.

외부 자본을 유치하거나, 혹은 사내에서 팀을 정식으로

구성할 수 있는 조건을 만족시키기 위한 발표 자리를 위한

문서라면 개발 외적인 부분에 대해서도 설명이 필요하다

'어떤' 게임인지도 중요하나 얼마나 수익을 낼 가능성이 있느냐도

중요하고, 게임을 설명하는 부분에도 적당한 미사여구가 

들어갈 필요가 있기도 하다

'우리는 다양한 몬스터를 수집할 수 있게 할 것입니다'

라는 내용이 중요할 수도 있다.

'우리는 기존의 M게임보다 다양한 몬스터를 수집할 수 있도록

할 것입니다라고 설명한다면, 이것 역시 새로운 기준으로서의 가치를

갖는 것이다.

많은 수의 몬스터는 그 게임만의 새로운 광고전략이 될 수 있다

<연습>

이미 출시된 게임을 참고해서 컨셉 문서를 작성해본다.

비슷한 게임을 여러 개 놓고, 각각의 게임 컨셉을 정리한 다음,

어떤 컨셉이 어떤게임과 연결되는지를 확인해본다.

만약 내가 정리한 컨셉 하나가 대상이 되는 게임에 모두 적용된다면,

나는 컨셉을 잡지 못하고 있는 것이다.

새로운 컨셉을 구상한다면, 게임의 목표가 무엇인지를 설명하고,

그 목표를 이루기 위해서 어떤 플레이가 진행되는지를 설명해본다.

만약 플레이 과정이 게임의 목표와 자연스럽게 연결된다면

괜찮은 컨셉을 정한 것이다.

가장 좋은 것은 컨셉만 이야기해도 어떤 플레이가 진행될 지

듣는 이들이 구체적으로 상상할 수 있는 것이지만,

좋은 컨셉은 좋은 아이디어만큼이나 잡기 어렵다.

게임의 플레이가 컨셉과 어울리도록 전체적인 모습을

구상하는 연습이 필요하다.

게임 플레이 장면을 구체적으로 설명할 수 있어야 한다.

컨셉을 정하는 것은 어떤 플레이를 만들어야 하는지도

구체화되었다는 것이다.

아이디어가 컨셉이 아니라는 것을 알아야 한다.

<요약>

* 컨셉은 게임 개발의 목표다.

* 개발팀원은 모두 컨셉에 대해서 이해하고 있어야 

같은 목표를 갖고 게임을 만들 수 있다.

* 문서를 보고 게임의 플레이를 연상할 수 있다면 좋은 문서다.

* 좋은 컨셉은 길지 않은 문서로도 내용을 전달한다.

컨셉이 명확하지 않을수록 설명이 많아진다.

* 컨셉 문서에 핵심 플레이에 대한 설명을 추가하면

읽는 이들이 게임을 이해하기가 좋다.

제 2 장  게임개발단계(Game Dev.Process)

게임디자이너들은 게임의 규칙을 디자인하는 사람들이다

게임의 완성형이 어떤것인지 알고 있기 때문에 자연스럽게 개발과정에서

진행을 맡는다

어떤부분이 먼저 구현되어야 한다거나 결과물의 목적이 무엇인지

팀원들과 공유해서 프로젝트의 방향을 정하는 것 등이다

어떤게임을 만들것인가는 팀원이 같이 모여서 의논하지만 세부적인 모습을

결정하는 것은 게임 디자이너이고,게임디자이너의 문서가 팀에 공유되면

본격적으로 개발이 시작된다

팀의 규모가 커서 일정을 관리하는 역할을 맡은 사람이 있다면

경우가 다르지만, 팀이 작다면 자연스럽게 게임 디자니어가 프로젝트의 일정을

관리하는 역할을 맡게된다

게임의 내용을 결정하는 사람과 일의 진행을 정리하는 사람이 같으면

마음에 드는 결과가 나오지 않은경우 계속 결정을 번복할 수 있다는것이다

모든 게임디자이너들은 개발 단계와 일정관리에 대해서 알고 있어야한다

시간낭비를 줄이기 위함과 팀원간의 신뢰를 떨어뜨리지 않기 위해서

게임 개발 순서

게임 컨셉

↓

프로토타입 제작

↓

게임 구조/규모 결정

↓

구현/리소스 제작

↓

데이터 입력

↓

폴리싱

↓

테스트

↓

출시

게임 개발과정에서 게임디자이너의 역할은

어떤 게임을 만들지 정리하고 필요한 재료들이 준비될 수 있도록 

각 파트원에게 필요한 내용을 구체적으로 알려주고

재료들이 준비되면 조립해서 완성된 게임을 만든다.

게임에 필요한 논리적인 구조와 툴, 리소스들이 어떻게 준비되어야 하는지를 결정하고

정리하는 역할을 한다

개발 준비 단계 (Pre-Production)

게임개발은 크게 개발 준비 단계 

구현단계(Production)

후반 작업단계(Post-Production)을 지나 출시한다

프리프로덕션은 어떤게임을 만들지 구상하는 단계이다

이 단계를 거치면서 어떤 게임을 만들지에 대한 답을 찾고,

구현할 수 있는지, 구현할 가치가 있는지를 확인한다

여러가지 아이디어들이 나오고

아이디어들의 현실성을 검토하고 본격적인 개발에 들어가기 전에

큰 그림을 그려보는 단계다.

프로토타입도 이 단계에 들어가는데

아이디어를 구체화하는 방법 중 하나다

이 단계에서는 안정적인 작업보다는 생각을 빠르게

현실화하는 것이 필요하다

문서를 작성할때도 형식을 갖춘 멋진 문서보다는

필요한 내용만 정리하는 정도로 간략하게 만들고,

형식적인 것을 정리하는 것보다는 팀원들과 자주 소통하면서

게임의 방향성에 대해 논의하는 것이 좋다

이 시기에는 팀원들 간의 회의가 많아지게 되는데,

회의를 할 때는 반드시 회의의 목적과 시간을 정해놓고

이야기하는 것이 좋다

게임의 형태가 명확하지 않기 때문에

제한없이 이야기하면 회의의 흐름이 주제를 벗어나거나

정리되지 못하고 산만하게 흘러갈 수 있다

<게임 개발 단계별 할 일>

컨셉 - 아이디어 수집

↓

프로토타이핑 - 플레이의 핵심 요소 정리 및 검토

↓

구조 설계 - 게임의 플레이 흐름 컨텐츠의 순환 구조

↓

마일스톤 #1 - 구현 순서에 따른 개발 단계 설정

↓

... - 특징(feature)에 따른 마일스톤 계획

↓

마일스톤 #N - FGT(Focus Group Test)

↓

알파테스트

↓

클로즈 베타 테스트

↓                  - 폴리싱(Polishing)

                      출시준비

                      서비스 계획

오픈 베타 테스트

↓

출시

이번 마일스톤에 무엇을 할지 계획을 세우고, 구체적인 사양을 결정하고 구현한 다음에

제대로 잘 구현되었는지 확인하고 수정사항이 있으면 수정한 다음 마일스톤으로 넘어간다

마일스톤의 계획은 목표를 세우는 것이다

이 목표는 기능을 중심으로 선정된다

단기간의 목표를 설정하고 공유하는 것이 좋다

(맵에디터제작)<-구현할 기능들을 정함

세부적인 사양을 결정하는 것은 시스템을 어떻게 만들어야 할 지 결정한다는 것

마일스톤이 종료될 때마다 앞서 개발한 내용을 바탕으로

다음에 개발할 기능들의 시스템을 설계한다

<후반 작업 단계, Post-Production>

후반 작업은 마무리 단계다

필요한 기능들은 다 구현되어있고 세부적인 값들의 조율이나

어색한 부분들을 다음어서 완성도를 높이는 기간이다

폴리싱(Polishing)이나 베타테스트(Beta Test)를 모두 후반작업으로 분류했으나

프로젝트의 성격이나 관리방법에 따라서는 구현단계 - 프로덕션(Production)단계로 분류하고

후반 작업은 출시를 위한 마지막 작업들을 이야기하기도 한다

후반 작업은 지속적인 테스트를 통해서 부족한 점을 보완하고

사용감을 증대시키면서 출시 전 게임을 다듬는 과정이다

<단계별 관리>

큰 규모의 게임을 개발하는 과정은 개발준비 단계, 구현단계, 후반 작업 단계만으로

진행되지는 않음 세부적으로 더 나뉘고 구간별로 반복되는 일이 발생한다

규모가 작은 게임의 경우는 프로토타입을 하나만 만들면 가능할 수도 있다

하지만 필요에 따라 프로토타입을 여러 번 만들기도 한다

그러면 크게 두번의 흐름이 겹쳐질 수도 있다

마일스톤 전에 무엇을 준비해두어야 할지 계획을 세우고

필요한 내용을 준비해둬야 한다

게임 디자이너는 개발단계에 대해 어느정도 알아야하는 이유가

자신들이 진행하는 일에 대해서는 어느정도 관리해야 할 필요성이 있기때문이다

프로젝트의 전체적인 일정은 프로젝트 매니저(Project Manager)가 관리하지만

세부적인 항목들, 자신이 맡은 부분에 대한 진행은 게임디자이너가 관리할 수 밖에 없다.혹은 관리하게 된다.

<게임 개발 단계마다 작성되는 문서>

-----Pre-Production-------------------------------------------------------

컨셉 - 컨셉문서(게임개발의 방향 제시)

↓

프로토타이핑 - 프로토타입 사양서(프로토타입 구현을 위한 내용)

↓

구조 설계 - 게임 구조 문서(게임의 전체적인 구성에 대한 정리, 플레이의 흐름에 대한 정리)

↓

------Production----------------------------------------------------------------------------------------

마일스톤 #1 - 마일스톤 단계별 문서(각종 시스템 구현을 위한 문서, 리소스 제작을 위한 문서)

↓

... - (구현 테스트)

↓

마일스톤 #N 

↓

알파 테스트 - 테스트 의뢰 문서(기능 구현에 대한 테스트, 플레이 경험에 대한 테스트)

------Post-Production------------------------------------------------------------------------------

↓

클로즈 베타 테스트

↓

오픈 베타 테스트

↓                      - 서비스 지원 관련 문서

출시

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

하나의 기능을 설계하고, 무엇이 구현되어야 하는지 범위를 결정하고,

계획대로 구현되었으며 차후 문제점은 없는지 검토하는 책임은 일차적으로

게임 디자이너에게 있는 것이다.

팀의 규모가 작다면, 혹은 팀원들이 모두 경험이 적은 이들이라면

학생 프로젝트라면 프로젝트의 진행관리를 게임 디자이너들이 맡게 되는 경우가 많다

무엇을 만들어야 하는지, 어떤 것부터 만들어야 하는지에 대해서 큰 계획을 세우는이가

바로 게임디자이너이기 때문

어느정도는 프로젝트 관리를 하는 법에 대해서 알고 있어야 하고,

어떻게 프로젝트를 진행할 것인지에 대해 각자 나름대로의 시나리오를 갖고 있어야 한다

그래야 다음단계를 위한 준비를 할 수 있고,하나의 단계가 끝났을 때 정리를 하면서

전체적으로 진행되는 상황을 예측할 수 있을 것이다

<연습>

이미 나와있는 게임을 하나 선택하고,

본인이 게임의 개발 일정을 관리하는

프로젝트 매니저(ProjectManager)라고 생각하고 

이 게임을 어떤 순서로 진행하면 좋을지 생각해본다

가장 먼저 프로토타입을 제작할 것이다

프로토타입으로는 어떤 기능을 최우선으로 개발할 것인가?

한꺼번에 확인하고 싶은 기능을 다 확인할 수 있을까?

만약 그렇지 않다면 몇 단계의 확인과정을 거쳐야 할까?

어느 부분까지 확인하면 본격적인 개발을 시작할 수 있을까?

프로토타입 과정이 끝나면 기능을 중심으로 구체적인 계획을 세운다.

한 번에 너무 많은 기능을 구현하는 것은 좋지 않음

한 단계마다 구체적인 목표를 세우고 그에 필요한 기능을 정리해서

한 마일스톤의 분량을 정한다.

마일스톤이 마감되었을 때 기대하는 결과물은 어떤 모습일지 구체적으로 생각한다.

목표는 가능하면 플레이가 되는 모습을 기준으로 정하면 좋으나,

구현되어야 하는 기능이 너무 많다고 생각되면 쪼개도 좋음.

연습할 때에는 가능한 한 작은 분량으로 쪼개 진행하는 것이 좋다.

짧은 기간의 목표를 잡으면 기간 동안 작업해야 하는 것과 

필요한 리소스의 목록을 만든다.

필요한 문서는 무엇이며, 필요한 그래픽 요소는 무엇인가를 적어보는 것이다.

문서는 문서라는 형식이 중요한 것이 아니라

필요한 내용이 정리되는 것을 말한다.

'스테이지 간의 이동이 가능한 플레이'를 구현한다면

구체적으로 있어야 하는 기능이 무엇이며,

스테이지에서 플레이 가능한 범위가 무엇인지를 정리해서 

사양을 결정하는 것이다.

하나의 마일스톤을 단위로 준비되어야 하는 것들, 혹은 미리 결정되어야 하는 것들,

구현되어야 하는 기능들을 정리하면서 게임이 완료될 때까지의 작업 순서를

적어보면 개발 일정을 어떻게 관리해야 할 지 알 수 있을 것이다.

기능 구현 이전에 준비되어야 하는 내용들이 있으면

언제부터 그것을 준비해야 하는지,

그것을 준비하려면 선행으로 무엇이 결정되거나 기능이 구현되어야

했는지도 볼 수 있다.

개발 순서의 흐름을 크게 보면 개발 과정을 상상할 수 있다

중간중간에 테스트를 위한 일정을 잡는 것도 잊지 않고 해야한다.

경험이 많지 않기 때문에 개발과정에 대해서 상상하더라도

구체적인 일정, 특히 기간에 대한 것은 가늠하기 어렵다.

하지만 실제 나와 함께 일하는 팀원의 역량에도 달려 있는것이므로

정확한 기간을 예측하기는 쉽지 않다.

일정관리라고 하면 기간에 대해서 엄격하게 관리해야 할 것처럼

생각하기 쉬우나 더 중요한 것은 일의 순서다.

작업 순서가 명확하고, 앞뒤로 준비되거나 정리되어야 하는 것이

명확하면 효율적으로 시간을 관리할 수 있기 때문에

결과적으로 밀도 있게 개발이 진행될 수 있고,

기간도 줄어들 것이다.

팀원들에게 구체적인 목표를 제시하고 해야 하는 일들을

명확하게 정리하는 것이 중요하다.

예측할 수 없는 것을 목표로 잡을 수는 없다.

일정관리를 하면서 너무 많은 상황에 대해서 대처하려고 하는 것보다는

가능한 변수를 줄이면서 프로젝트를 진행하는 것이 좋다.

계획이 구체적이지 않은상태에서 성급하게 작업에 들어가면

시간에 쫒기게 되고 마음이 급해져서 중요한 것들이

누락될 가능성이 커진다.

전체 계획에 대해서 팀원 간에 공유하면 개발에 대해서

예측할 수 있으므로 혼란이 줄어들 수 있다.

<요약>

* 게임 디자이너라면 개발 일정 관리에 대해 어느정도 알고 있어야 함

* 게임이 구현되는 과정을 임의로 나눈다. 임의로 나눌 때는 각 단계별로 목표를 설정한다

목표는 구체적으로 설정한다. 참여하는 팀원들이 모두 같은 내용을 인지할 수 있어야 한다

* 구현되는 과정을 나눌 때는 기간보다 순서가 중요하다. 만약 능숙한 개발자라면

기간에 대한 것도 쉽게 예측할 수 있지만, 그렇지 않다면 예측할 수 없는 것에 대한 목표를 잡을 수는 없다.

* 각 단계별로 개발이 들어가기 전에 준비되어야 하는 것의 목록을 작성하고, 

개발이 완료된 후 결과물이 있어야 하는것의 목록을 작성한다.

결과물의 목록은 필요한 파일목록이 될 수도 있고, 기능의 목록이 될 수도 있다.

이 목록을 공유하는 것으로도 팀원들은 해당 마일스톤 단계에서

무엇을 작업해야 하는지 알 수 있다.

* 각 단계마다 확인하는 일정을 꼭 잡는다.

단순하게는 리소스확인이 될 수도 있고, 구현된 기능의 테스트일 수도 있다.

여기서 말하는 테스트는 단순히 기능이 동작하는지에 대한 것만은 아니다.

게임의 전체 목표에 부합하는지에 대한 확인일 수도 있다.

테스트를 하면서 팀원들과 게임에 대해서 심도있는 논의를 할 수도 있다.

* 개발 단계는 비록 짧은 기간이라도 분리되어야 한다.

한편에서는 기능 구현을 하고, 한편에서는 테스트를 하면서 개선방안을 고민해선 안된다.

생각이 정리되지 않을 수 있고, 진행과정에서 변수가 너무 많이 발생할 수도 있다.

* 필요한 개발기간에 대한 것은 한 명이 임의로 잡을 수 없다.

실제로 작업해야하는 사람들의 의견을 듣고 그들에게 어느정도의 기간이 필요한지를 물어보라.

* 테스트는 중요하다. 그리고 마무리 단계의 테스트는 오랜시간이

필요하다는 것을 잊지말기를 바란다. 게임에서 기능 구현은 전체 개발 단계의 50%라고 생각하자.

Concept(콘셉트) - 컨셉

Contents(콘텐츠) - 컨텐츠

Targeting,Target(타기팅,타깃) - 타겟팅, 타겟

놀이를 즐기는 것은 인간의 본성 중 하나.

누구나 즐거움을 추구하고자 하고 새로운 유희 거리를 탐구한다

"놀이는 명확하게 한정된 시간과 공간 속에서 행해지며 주어진 

규칙에 따라 질서정연하게 진행된다"

게임디자이너들에게 왜 게임을 만드냐고 물어보면 

재미있으니까라고 대답할 것이다

게임개발자는 크게 세 분야로 나눌 수 있다

게임을 디자인하는 디자이너

->게임을 만드는 사람,게임의 전체적인 모습을 구상하고

플레이어가 어떤 경험을 하게 할것인지 정의하는 사람들

게임 이미지를 만들어내는 아티스트

->그래픽 혹은 사운드 작업을 하는 이들이다.

이미지 작업을 하는 이들을 칭한다

게임을 구현하는 프로그래머

->게임이 동작하도록 만들어준다 자동차로 예를 들면

엔진을 만드는것과 같디 

디지털 게임 개발은 대부분 소프트웨어의 개발이므로

이들은 모두 어느 정도 소프트웨어에 대한 지식을 갖고 있어야 한다 

                    PD

                (Project Director)

Game Artist   Game Designer  Programmer

Game Developer : 게임 개발자 

↑ 간략하게 본 게임 개발팀의 파트 구분

게임을 제외한 다른분야에서는 개발자라 하면 주로 프로그래머나 엔지니어를 말하나

게임업계에서는 게임 개발에 관련된 모든 이들을 개발자라고 한다

프로그래머만이 아닌 아티스트나 게임 디자이너, 테스터를 모두 포함한다.

게임에서 디자이너라고 하면 게임의 규칙을 정하는 이들을 말한다

디자인(Design)이라는 말은 설계도,계획,만들다 등의 의미를 가지고 있는데,

그림을 그리는 것을 말하는게 아니라 무언가를 만들어 내는 것을 의미한다

게임 디자이너는 만들어지는 게임에 대해 이해하지 못하면 게임 개발에 참여할 수 없다

게임의 규칙을 세우고 어떻게 개발해야 할지 고민하는 이들을 게임 디자이너라고 한다

아이디어를 구현하기 위한 세부적인 내용을 모두 진행할 수 있어야 한다

막연한 아이디어는 결과물을 만들 수 없다.

구체적으로 기준을 잡을 필요가 있다 왜 그런 것을 요구하는지에 대한 고민도 알아야 함 

막연한 이야기 속에서 가장 중요한 것을 찾아내거나 결정하고 다른 부분들을 조율해서 세세한 부분까지 완성해야 한다

게임을 개발하면서 가장 중요한 결과물은 게임이다

아티스트에겐 이미지가 남고, 프로그래머에게는 코드가 남지만

게임 디자이너에게 남는 것은 문서가 아니라 게임이다

문서 작성을 얼마나 잘하느냐보다는 게임을 잘 만들 수 있느냐가 게임 디자이너에게 요구되는 능력이다

재미있는 게임을 구상하는 것도 필요하고, 그 게임을 만들기 위해 

게임의 구조를 어떻게 만들어야 하는지를 잘 아는 것도 필요하다

하지만 게임디자이너들은 문서 작업에 꽤 많은 시간을 쓰고 있고,

규모가 큰 팀이라면 그럴 가능성은 더 높아질 것이다

다행히도 요새 게임을 만드는 과정에서 문서의 중요성은 점점 감소하고 있다

형식 또한 작성하는 데에 부담스럽지 않게 점차 간소화되어

필요한 내용만 메모 형식으로 작성하거나 회의록 등으로 대체하기도 한다

개발에 불필요한 시간 낭비를 막고 부담스러운 행정적 절차를 줄이고 싶어 하기 때문이다.

문서작업은 떄로는 아주 비효율적으로 느껴지기도 한다

필요하면 몇 걸음 떨어져 있지 않은 동료 프로그래머나 아티스트에게 가서

이런저런 설명을 하거나 직접 데이터 테이블(Data Table)을 열고 필요로 하는 값을 수정하면 되는데

굳이 번거롭게 문서로 남기는 것은 시간 낭비처럼 느껴지기도 한다.

하지만 문서를 꼭 작성하라고 이야기하는 것은

대부분 사람은 게임을 구상하는 데에 익숙하지 않기 때문에 

만약 게임을 구상하고, 어떻게 개발해야 할지 능숙해서 머릿속에서 

모든 내용을 깔끔하게 정리할 수 있다면 굳이 문서로 정리할 필요는 없다

간략하게 알아볼 수 있을 정도의 메모로 남겨도 충분하다

문서를 작성하면 내 생각을 정리할 수도 있고, 구상 단계에서 미처 생각하지 못했던

구멍 난 부분들을 찾아낼 수도 있다.

모호하거나 사소해서 잊어버리기 쉬운 부분들을 기록하면 차후에 

찾아보고 기억을 되살리는데에도 도움이 된다

개발문서라는 것은 일종의 계획표이자 설계도라고 할 수 있다

문서를 남기는 것은 다른 팀원들과 생각을 공유한다는 의미도 있다

경험이 많지 않다면 문서 작성을 권한다

<정리>

* 문서로 정리하는 것은 그 자체로 많은 훈련이 된다

* 문서를 작성할 때에는 무엇을 위한 문서인지 목적을 명확하게 정하고, 

  무엇을 설명할지를 정리한다

* 문서의 작성은 개발 과정에서 일을 정리하는 의미를 갖기도 한다.

* 문서의 형식은 중요하지 않다. 문서를 읽는 이들이 이해할 수 있느냐가

  중요하다

* 문장은 가능한 한 짧게 쓴다. 긴 문장을 읽고 싶어 하는 이들은 드물다.

* 완전한 문서를 쓰도록 노력해라. 물론, 완전한 문서 따윈 없지만.

* 내용도 중요하지만 형식도 중요하다. 문서의 편집도 고민해본다.

게임이 가지고 있는 성격

참여 상호반응 엔터테인먼트 

게임기획 -> 게임을 설계(Design)하는 작업

(영어권 사회에서 게임기획자를 Game Designer라고 부른다)

게임의 성공요소중 가장 중요한 것

게임의 완성도 

게임의 재미

시스템 기획

콘텐츠들이 동작할 수 있는 기초 구조나 동작원리

콘텐츠 기획

콘텐츠 -> 게임을 할때 유저가 게임내에서 즐기는데 

도움을 주는 것들 중 오감을 통해 알 수 있는 것들

시나리오,각종 설정(컨셉),레벨(맵) 등 게임 내적 구성요소들

재미있거나 매력적이어야 함

캐릭터라는 공통점 (캐릭터 시스템 기반)

오크,엘프(콘텐츠) 

더 추가해서 올리겠다