-
Pre Production
at 2008-01-03 17:27:12 0 comment
아래의 정의는 내가 겪어 본 것과
현재 작업하는 것의 내용을 토대로 정립한 것이다.
회사와 사람에 따라서 생각이 다를 수 있기 때문에
다음의 정의가 진리라고는 하지 않겠다.
그러나 내 경험 상으로는 이게 가장 이상적이라는 의견이다.
Pre Production은 어떤 게임을 만들 것인가를 정의하는 단계라고 할 수 있다.
프러덕션 팀은
개괄적인 마일스톤 위주의 일정을 만들고
이를 실천하기 위한 각 프로세스를 확립하고
개발팀에게 필요한 정보를 공급한다.
이 과정의 끝에는 확정된 일정이 나와야 한다.
게임 디자이너 팀은 게임 디자인 문서(GDD)를 만든다.
Pre Production의 일정이 끝날 때에는
80% 수준의 완성도를 지닌 디자인 문서가 완성되어야 한다.
여기서 80%의 의미는 기능에 대한 설명이
80% 완료되었다는 뜻이 아니라 모든 것을 완성했다는 뜻이다.
즉 실제로는 100%이다.
그러나 실제로 100% 완성된 기획서는 이 세상에 존재할 수 없다.
왜냐하면 실제 개발 도중 많은 이유로 디자인이 바뀌기 때문이다.
즉 나머지 20%는 추후 변경을 위한 여유라고 생각하면 된다.
프로그래머 팀은 게임 디자인 문서에 의거하여
사용될 기술에 대해서 리서치해서
어떤 방식으로 구현할 지를 결정하고,
테크니컬 디자인 문서 (TDD)를 만든다.
프로토 타입 제작을 한다.
아트 팀은 아트 각 필요 내용의 컨셉 작업에 들어가고
프로토 타입에 들어 갈 내용물들을 제작한다.
이 Pre Production의 끝에는 반드시 몇가지 결과물이 있어야 한다.
1. GDD
Game Design Document의 약자. 기획서를 말한다. 이름이 길다보니 약자로 GDD라고 한다.
이 GDD는 기본적으로 또 몇 가지 단계를 거치지만 이 부분은 나중에 자세히 이야기 하자.
가장 중요한 것은 GDD에 포함된 모든 내용은
반드시 모든 개발자들의 리뷰와 토론에 의한 결과물이어야 한다는 것이다.
즉, GDD를 다 썼다는 의미와는 전혀 다른 산물이라는 것이다.
GDD의 완성은 곧 모든 개발자의 의지가 포함이 된 문서인 것이다.
GDD를 써서 내면 그걸로 끝이 아니라
몇 번의 리뷰와 토론을 통해서
모두가 공감하는 게임을 그린 문서가 진정한 GDD라고 할 것이다.
그러나 과거 개인적인 경험에 의하면
한국의 프로그래머들과 아티스트들은 완성된 기획서를 보고 늘 이런 말을 한다.
"너무 방대해서 잘 모르겠다." 혹은 "설명이 너무 부족해서 잘 모르겠다"
무엇이 이유이건 간에 여기서 가장 중요한 것은
커뮤니케이션의 문제라고 본다.
그래서 내가 가장 관심이 있는 부분이
바로 이 프로세스를 어떻게 정립하느냐의 문제이기도 하다.
요점은 수천장 짜리 완성된 기획서를 보여주고
그것의 리뷰를 한번에 받기는 힘들다는 점.
따라서 그 이전의 어떠한 프로세스를 거쳐
팀원들을 이해시키고 그들의 의견을 적용시키냐 하는 점이다.
이 부분에 대한 프로세스는
이후에 더욱 자세히 다루어 보도록 할 것이다.
2. TDD
완성되어가는 GDD와 같이 완성되어야 하는 문서는 TDD이다.
XP(eXtreme Programming)의 TDD(Test Driven Development) 와는 다른 뜻이다.
TDD는 Techniocal Design Document의 약자이다.
완성되어가는 GDD와 동시에 지속적으로 발전하는 문서이다.
이 문서의 주체는 TD(Technical Director)이다.
이 문서는 GDD의 각 기능을
어떻게 구현할 것인지에 대한 Research의 결과물과
어떻게 구현하는 것이 이상적일 것인가에 대한 결과물의 조합문서이다.
예를 들자면 맵의 구성을 어떻게 할 것인가의 문제를
Zone Loading 방식으로 할 것인가 아니면 Seamless 방식으로
할 것인가를 가지고
각각의 장단점을 분석하고
프로젝트에 어울리는 방식을 선택하고
더불어서 어떤 형식의 Seamless 방식이 사용할 것인가를 정의하는 것이다.
그러나 GDD가 다 완성되고 나서
이 문서를 작성하는 것은 시간의 낭비나 다름이 없다.
가장 이상적인 것은 GDD와 같이 혹은 약간 느리게 진행이 되는 것이 이상적이다.
바로 이 부분을 위해서라도 GDD의 작성 과정에
많은 커뮤니케이션과 세부적인 프로세스가 필요한 것이다.
3. 일정표
프로듀서들이 만들게 되는 일정이다.
먼저 GDD를 바탕으로 게임에 들어갈 기능을 확정한다.
그 기능의 우선 순위를 위주로
마일스톤 단위의 개괄적인 일정을 만든다.
여기서부터 프로그래머들은
각각의 기능 구현에 필요한 시간을 검증하고
프로듀서들에게 피드백을 해 주게 된다.
프로듀서들은
프로그래머들과 아티스트들의 피드백을 바탕으로
다시 마일스톤을 잡는다.
마일스톤이 완료가 되면
세부 일정에 들어 간다.
각각의 기능을 구현하기 위한 기술이 무엇이 필요하고
각각의 기술을 구현하는 시간이 얼마가 걸리고를 바탕으로
아트의 결과물과 조율해서
완벽한 기능의 구현이 언제 완료가 되지를 확정하게 된다.
일정의 구성은 역시 GDD를 바탕으로 한다는 점에서
그리고 각 팀의 피드백을 기본으로 조정한다는 점에서
커뮤니케이션이 중요하다는 것은 기본 중의 기본이다.
일정의 완성보다 중요한 것은
그 일정이 현실적인 것인가에 대한 검증이다.
일정은 프로그래머와 아티스트의 말을 믿을 수 밖에 없지만
그렇다고 100% 다 믿으면 대부분 손해를 본다.
그렇다고 팀을 믿지 말라는 것은 아니다.
당연히 실제 개발은 일정 잡은대로 움직이지 못한다.
누가 아프기도 하고
중간에 다른 일이 들어 올 수도 있고
중간에 개발 과정 중에 사고가 나서
작업을 다시 해야 한다던가의
온갖일이 존재 할 수 있다.
팀의 의견을 신뢰하고
추후에 일정의 연기가 발생할 경우
어떻게 대처 할 것인지에 대해서
미리 준비를 해 놔야 한다는 것이다.
4. Prototype
Pre-Production 단계가 끝나면 플레이가 가능한 프로토 타입이 완성이 되어 있어야 한다.
대부분의 프로토 타입의 정의는
* 게임 기본 기능의 완성
* 게임의 특징 부분의 완성
* 플레이가 가능한 1개 정도의 맵을 말한다.
즉 플레이가 가능하지만 게임의 특징을 담은 게임을 만드는 것을 말한다.
이 부분은 Pre production의 절반 가량의 일정을 차지하게 된다.
따라서 GDD의 완성도 이 프로토 타입을 위주로 진행이 되게 된다.
먼저 가장 기본적인 기능의 GDD를 완성하고
게임의 특징이 되는 부분의 GDD를 완성한다.
그리고 하나의 완성된 맵을 붙이는 것이다.
따라서 GDD를 작성하는 우선 순위가 정해져야 한다.
이 부분은 프로듀서의 재량일 수도 있지만
이 부분 역시 모든 팀원들의 의견이 토의를 통해서
결정이 되는 것을 이상적인 것이라고 생각한다.
이런 식으로 프로토 타입이 완성이 되면
이를 바탕으로 게임 디자인에 대한 더욱 세세한 부분의 열띤 논의가 진행이 된다.
그리고 그 부분은 그대로 다시 GDD에 반영이 된다.
그리고 이 GDD는 Full Production에 사용이 된다.
회사마다 다르지만 Pre Production 기간은 약 6개월에서 1년을 잡는다.
해외 개발사들은 Pre Production에 되도록 많은 시간을 할애하려고 한다.
애초에 방향을 잘 잡고 나감으로 개발 도중의 삽질을 최소화 하려는 노력이다.
애초에 Pre Production의 목적은 삽질을 최소화하기 위헤서 탄생된 것이다.
게임 디자인과 동시에 개발을 시작하는 경우 발생하는 수많은 의견난무와
사공이 많아 배가 산으로 가는 과정을 최소화 해 보겠다는 의지의 표현이다.
이제는 한국의 회사들도 많이 이런 부분을 참고하고 받아 들이려고 하지만
그것도 아직은 돈 많은 일부 회사에 한정된 상황이라고 본다.
그러나 확신하는 것은
게임의 개발 기간을 2년으로 잡았다면
Pre Production 6개월 하나 안하나
그 2년 안에 게임은 개발이 될 것이다.
오히려 Pre production을 안하는 경우,
2년 안에 게임이 안 나올 가능성이 더욱 많다고 본다.
그리고 결과물은 더욱 좋을 것임을 개발자들은 알고 있다.
그러나 대부분 사장님들은 잘 모른다. -_-
이글루스 가든 - 게임 기획자로 성공하기
현재 작업하는 것의 내용을 토대로 정립한 것이다.
회사와 사람에 따라서 생각이 다를 수 있기 때문에
다음의 정의가 진리라고는 하지 않겠다.
그러나 내 경험 상으로는 이게 가장 이상적이라는 의견이다.
Pre Production은 어떤 게임을 만들 것인가를 정의하는 단계라고 할 수 있다.
프러덕션 팀은
개괄적인 마일스톤 위주의 일정을 만들고
이를 실천하기 위한 각 프로세스를 확립하고
개발팀에게 필요한 정보를 공급한다.
이 과정의 끝에는 확정된 일정이 나와야 한다.
게임 디자이너 팀은 게임 디자인 문서(GDD)를 만든다.
Pre Production의 일정이 끝날 때에는
80% 수준의 완성도를 지닌 디자인 문서가 완성되어야 한다.
여기서 80%의 의미는 기능에 대한 설명이
80% 완료되었다는 뜻이 아니라 모든 것을 완성했다는 뜻이다.
즉 실제로는 100%이다.
그러나 실제로 100% 완성된 기획서는 이 세상에 존재할 수 없다.
왜냐하면 실제 개발 도중 많은 이유로 디자인이 바뀌기 때문이다.
즉 나머지 20%는 추후 변경을 위한 여유라고 생각하면 된다.
프로그래머 팀은 게임 디자인 문서에 의거하여
사용될 기술에 대해서 리서치해서
어떤 방식으로 구현할 지를 결정하고,
테크니컬 디자인 문서 (TDD)를 만든다.
프로토 타입 제작을 한다.
아트 팀은 아트 각 필요 내용의 컨셉 작업에 들어가고
프로토 타입에 들어 갈 내용물들을 제작한다.
이 Pre Production의 끝에는 반드시 몇가지 결과물이 있어야 한다.
1. GDD
Game Design Document의 약자. 기획서를 말한다. 이름이 길다보니 약자로 GDD라고 한다.
이 GDD는 기본적으로 또 몇 가지 단계를 거치지만 이 부분은 나중에 자세히 이야기 하자.
가장 중요한 것은 GDD에 포함된 모든 내용은
반드시 모든 개발자들의 리뷰와 토론에 의한 결과물이어야 한다는 것이다.
즉, GDD를 다 썼다는 의미와는 전혀 다른 산물이라는 것이다.
GDD의 완성은 곧 모든 개발자의 의지가 포함이 된 문서인 것이다.
GDD를 써서 내면 그걸로 끝이 아니라
몇 번의 리뷰와 토론을 통해서
모두가 공감하는 게임을 그린 문서가 진정한 GDD라고 할 것이다.
그러나 과거 개인적인 경험에 의하면
한국의 프로그래머들과 아티스트들은 완성된 기획서를 보고 늘 이런 말을 한다.
"너무 방대해서 잘 모르겠다." 혹은 "설명이 너무 부족해서 잘 모르겠다"
무엇이 이유이건 간에 여기서 가장 중요한 것은
커뮤니케이션의 문제라고 본다.
그래서 내가 가장 관심이 있는 부분이
바로 이 프로세스를 어떻게 정립하느냐의 문제이기도 하다.
요점은 수천장 짜리 완성된 기획서를 보여주고
그것의 리뷰를 한번에 받기는 힘들다는 점.
따라서 그 이전의 어떠한 프로세스를 거쳐
팀원들을 이해시키고 그들의 의견을 적용시키냐 하는 점이다.
이 부분에 대한 프로세스는
이후에 더욱 자세히 다루어 보도록 할 것이다.
2. TDD
완성되어가는 GDD와 같이 완성되어야 하는 문서는 TDD이다.
XP(eXtreme Programming)의 TDD(Test Driven Development) 와는 다른 뜻이다.
TDD는 Techniocal Design Document의 약자이다.
완성되어가는 GDD와 동시에 지속적으로 발전하는 문서이다.
이 문서의 주체는 TD(Technical Director)이다.
이 문서는 GDD의 각 기능을
어떻게 구현할 것인지에 대한 Research의 결과물과
어떻게 구현하는 것이 이상적일 것인가에 대한 결과물의 조합문서이다.
예를 들자면 맵의 구성을 어떻게 할 것인가의 문제를
Zone Loading 방식으로 할 것인가 아니면 Seamless 방식으로
할 것인가를 가지고
각각의 장단점을 분석하고
프로젝트에 어울리는 방식을 선택하고
더불어서 어떤 형식의 Seamless 방식이 사용할 것인가를 정의하는 것이다.
그러나 GDD가 다 완성되고 나서
이 문서를 작성하는 것은 시간의 낭비나 다름이 없다.
가장 이상적인 것은 GDD와 같이 혹은 약간 느리게 진행이 되는 것이 이상적이다.
바로 이 부분을 위해서라도 GDD의 작성 과정에
많은 커뮤니케이션과 세부적인 프로세스가 필요한 것이다.
3. 일정표
프로듀서들이 만들게 되는 일정이다.
먼저 GDD를 바탕으로 게임에 들어갈 기능을 확정한다.
그 기능의 우선 순위를 위주로
마일스톤 단위의 개괄적인 일정을 만든다.
여기서부터 프로그래머들은
각각의 기능 구현에 필요한 시간을 검증하고
프로듀서들에게 피드백을 해 주게 된다.
프로듀서들은
프로그래머들과 아티스트들의 피드백을 바탕으로
다시 마일스톤을 잡는다.
마일스톤이 완료가 되면
세부 일정에 들어 간다.
각각의 기능을 구현하기 위한 기술이 무엇이 필요하고
각각의 기술을 구현하는 시간이 얼마가 걸리고를 바탕으로
아트의 결과물과 조율해서
완벽한 기능의 구현이 언제 완료가 되지를 확정하게 된다.
일정의 구성은 역시 GDD를 바탕으로 한다는 점에서
그리고 각 팀의 피드백을 기본으로 조정한다는 점에서
커뮤니케이션이 중요하다는 것은 기본 중의 기본이다.
일정의 완성보다 중요한 것은
그 일정이 현실적인 것인가에 대한 검증이다.
일정은 프로그래머와 아티스트의 말을 믿을 수 밖에 없지만
그렇다고 100% 다 믿으면 대부분 손해를 본다.
그렇다고 팀을 믿지 말라는 것은 아니다.
당연히 실제 개발은 일정 잡은대로 움직이지 못한다.
누가 아프기도 하고
중간에 다른 일이 들어 올 수도 있고
중간에 개발 과정 중에 사고가 나서
작업을 다시 해야 한다던가의
온갖일이 존재 할 수 있다.
팀의 의견을 신뢰하고
추후에 일정의 연기가 발생할 경우
어떻게 대처 할 것인지에 대해서
미리 준비를 해 놔야 한다는 것이다.
4. Prototype
Pre-Production 단계가 끝나면 플레이가 가능한 프로토 타입이 완성이 되어 있어야 한다.
대부분의 프로토 타입의 정의는
* 게임 기본 기능의 완성
* 게임의 특징 부분의 완성
* 플레이가 가능한 1개 정도의 맵을 말한다.
즉 플레이가 가능하지만 게임의 특징을 담은 게임을 만드는 것을 말한다.
이 부분은 Pre production의 절반 가량의 일정을 차지하게 된다.
따라서 GDD의 완성도 이 프로토 타입을 위주로 진행이 되게 된다.
먼저 가장 기본적인 기능의 GDD를 완성하고
게임의 특징이 되는 부분의 GDD를 완성한다.
그리고 하나의 완성된 맵을 붙이는 것이다.
따라서 GDD를 작성하는 우선 순위가 정해져야 한다.
이 부분은 프로듀서의 재량일 수도 있지만
이 부분 역시 모든 팀원들의 의견이 토의를 통해서
결정이 되는 것을 이상적인 것이라고 생각한다.
이런 식으로 프로토 타입이 완성이 되면
이를 바탕으로 게임 디자인에 대한 더욱 세세한 부분의 열띤 논의가 진행이 된다.
그리고 그 부분은 그대로 다시 GDD에 반영이 된다.
그리고 이 GDD는 Full Production에 사용이 된다.
회사마다 다르지만 Pre Production 기간은 약 6개월에서 1년을 잡는다.
해외 개발사들은 Pre Production에 되도록 많은 시간을 할애하려고 한다.
애초에 방향을 잘 잡고 나감으로 개발 도중의 삽질을 최소화 하려는 노력이다.
애초에 Pre Production의 목적은 삽질을 최소화하기 위헤서 탄생된 것이다.
게임 디자인과 동시에 개발을 시작하는 경우 발생하는 수많은 의견난무와
사공이 많아 배가 산으로 가는 과정을 최소화 해 보겠다는 의지의 표현이다.
이제는 한국의 회사들도 많이 이런 부분을 참고하고 받아 들이려고 하지만
그것도 아직은 돈 많은 일부 회사에 한정된 상황이라고 본다.
그러나 확신하는 것은
게임의 개발 기간을 2년으로 잡았다면
Pre Production 6개월 하나 안하나
그 2년 안에 게임은 개발이 될 것이다.
오히려 Pre production을 안하는 경우,
2년 안에 게임이 안 나올 가능성이 더욱 많다고 본다.
그리고 결과물은 더욱 좋을 것임을 개발자들은 알고 있다.
그러나 대부분 사장님들은 잘 모른다. -_-
이글루스 가든 - 게임 기획자로 성공하기
할일: 게임 제작 프로세스 정리하기
회원님이 남기신 덧글 하나가 가든에 꽃을 피웁니다.





