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

제 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%라고 생각하자.