게임 제안서의 지침

게임 제안서는 게임 개발 프로젝트를 위해 재정과 자원을 확보하는데에 쓰이는 공식적인 프로젝트 제안입니다.

게임 제안을 올바르게 하기 위해서는 시간과 돈이 필요하기 때문에 게임 컨셉에 대해서만 집중하는 게 좋습니다.

제안서는 게임 컨셉을 더 상세히 말한 것입니다. 제안서를 작성하는 것은 특히 마케팅 부서와 같은 다른 부서들에게서 피드백을 받거나 정보를 얻는 과정이 포함할 수도 있습니다. 마케팅 부서가 컨셉에 대한 시장 조사와 분석을 해야할 수도 있습니다. 만약 게임이 라이센스를 필요로 한다면 금융 부서나 법무 부서에서 라이센스를 확보에 관한 가능성과 비용을 조사할 필요가 있을 수 있습니다.

보통 시니어 프로그래머나 테크니컬 디렉터 같은 프로그래밍 스태프가 컨셉의 기술적인 평가를 수행하는게 좋습니다. 그들은 컨셉의 기술적인 가능성과 연구가 필요할 지도 모르는 프로그래밍 영역에 대해 견해를 밝힐 것입니다. 그들은 위험성과 프로젝트의 주요 업무들을 가늠하고 해결책과 대안을 제시할 것입니다. 그들은 필요한 연구와 개발 기간, 자원에 대해 대략적인 추정을 내놓을 것입니다.

게임 제안서는 게임 컨셉의 개정된 형태를 포함해야 합니다. 컨셉 문서에 대한 기술, 마케팅, 그리고 금융 피드백이 컨셉을 축소하도록 당신을 압박할 것입니다. 또한 특징들을 수정하거나 덧붙이는 방안을 제시할 수도 있습니다.

컨셉이 처음으로 주요한 비판과 협력적인 과정의 대상이 되었기 때문에 이런 변화들은 어느 누구도 놀라게 하지 않을 것입니다. 피드백과 분석이 게임 제안서에 적용되거나 컨셉에 변화를 발생시키기 전에 그 복사본을 부서의 디렉터(또는 게임 제안서를 요청한 누구든)에게 전달하는 것은 좋은 생각입니다. 이 과정은 특정한 사람들 또는 부서가 컨셉을 검토했다는 확인서면을 받는 것뿐 만이 아니라 디렉터가 모든 제안된 변경점에 대해서 거부, 수정 또는 승인하게끔 대비시킵니다.

게임 제안서는 다음의 특징들을 포함합니다:

- (상기의) 개정된 게임 컨셉
- 시장 분석
- 기술 분석
- 법률 분석 (해당 경우에)
- 예상 비용과 이익
- 그림

- 시장 분석: 당신의 회사가 여력이 있을 것이라고 추정하는 마케팅 부서나, 또는 시장 분석 전문 회사에서 이 정보를 취합하는 게 좋습니다. 당신 스스로 이 정보를 취합하고자 한다면 순수하게 산술적인 추정을 하려는 행위는 피하십시오. 인터넷에서 자료를 검색하거나 시장 성과의 지표로써 같은 장르에 존재하는 기존의 히트작을 활용하십시오.

- 목표 시장: 목표 시장은 이미 게임 컨셉에서 언급된 장르와 플랫폼에서 정의됩니다. 당신은 시장을 대변하는 특정 작품들을 언급함으로써 이에 대해 단서를 달 수 있습니다. 이 작품들 중 가장 성공적인 것은 시장의 가능성과 크기를 내비칩니다. 또한 대표적인 연령층과 성별, 그리고 다른 핵심적인 특징들을 언급하십시오. 만약 게임이 라이센스 재산이나 후속작을 포함한다면 기존의 시장을 설명하십시오.

- 선두주자: 시장의 선두주자들을 열거하십시오. 주목할 만한 데이터 디스크 숫자와 성공적인 후속작들의 판매 숫자를 쓰십시오. 출시 날짜를 포함시키십시오. Q1 1998이나 1998 봄이라 해도 상관없습니다. 이 조사는 더 오래 전으로 거슬러 올라갈 수 있기 때문에 데이터를 연대순으로 나타내십시오.
제안된 게임의 플랫폼과 다를 경우 그 플랫폼들을 열거하십시오. 그러나 플랫폼에 따라 시장이 달라지기 때문에 목표 플랫폼에 동일한 장르의 작품을 표시해야 합니다. 그 작품이 다른 것들만큼 성과가 좋지 않더라도 말입니다. 그러한 데이터는 플랫폼에 따른 특정 장르의 게임들의 경직성을 나타내기도 합니다. 예를 들면, 턴제 전략 게임은 PC 플랫폼에서만 훌륭한 판매량을 기록하지만 소니 플레이스테이션에서는 끔찍한 판매량을 기록합니다. 이 선두주자들의 열거는, 당신이 턴제 전략 게임을 할 경우에 이러한 차이를 드러낼 것입니다.

- 특징 비교: 선두주자들의 판매 강점을 분석하십시오. 그것을 컨셉 문서에 설명되어 있는 핵심 특징들과 비교하고 대조하십시오. 세부 사항을 표시하십시오. 예를 들면:
전술적인 전투: Command & Conquer, Dark Reign, and Myth에서는 유닛에게 특정 대상을 공격하고 명령하거나 특정 장소로 이동 또는 이점을 위해 배회하라고 명령합니다. 대부분의 유닛들은 플레이할수록 더욱 분명해지는, 고유한 강점과 약점을 가지고 있어서 당신이 우월한 전술을 고안하도록 독려합니다. Tanktics는 우월한 전술을 쓸 수 있도록 점유, 들이받기, 치고 빠지기 같은 보다 다양한 명령을 가지고 있습니다. 지형과 이동, 또한 사정거리 보너스, 입사각, 그리고 후방과 측면의 약점 때문에 유닛의 위치와 대상 선택이 더욱 중요해졌습니다. 강점과 약점을 차별화하고 전술을 장려하기 위해 모든 유닛들이 서로 구별되는 무기와 방어구, 속도를 가지고 있습니다. 당신은 시간이 지남에 따라 전술을 배울 뿐만 아니라 이런 전술들로 임의의 명령들의 스크립트를 짤 수 있습니다.


기술 분석: 기술 분석은 특히 테크니컬 디렉터나 리드 프로그래머 같은 경험 많은 프로그래머들이 작성한 뒤에 제안서로 편집해내는 게 좋습니다.
제안서를 검토하는 사람은 자신이 결정을 내리는데에 이 기술 분석을 활용할 것입니다. 정직하십시오. 그것은 마침내 당신의 고민을 줄일 것입니다. 종합적으로 이 분석은 검토하는 사람이 게임이 성공할 확률에 대해 긍정적으로 생각할 수 있도록 해줄 것입니다.

- 실험적인 특징: 디자인에서 시도된 적이 없거나 검증되지 않은 기술, 방법, 관점, 또는 고유한 아이디어 같은 실험적인 특징들을 정의하십시오. 개발팀에게는 처음이더라도 다른 기존의 게임에서 검증된 특징들은 포함시키지 마십시오. 예를 들어, 팀이 3D 엔진을 개발한 적이 없다면 실험 항목으로 열거하지 마십시오. 그렇게 하기보다 기술 분석 섹션에서 한 가지 또는 다른 카테고리를 만들어 거기에 나열하십시오. 반면에 개발팀이 4각면(Quads)의 이론적인 체계를 사용하는 3D엔진을 개발하려고 한다면, 이것은 실험 항목으로 분류해야 합니다. 물론 당신이 이 글을 읽을 때면 4각면은 흔한 것일 겁니다.
실험적인 특징들이 평가 단계로 오기 전까지 걸리는 시간 추정치를 포함시키십시오. 완성 단계까지 걸리는 시간도 마찬가지로 포함시키십시오. 실험적인 영역은 일반적으로 스케쥴의 기간이 더 필요하기 때문에, 실험적인 특징을 많이 열거할수록 스케쥴의 기간은 더 길어질 것입니다. 어떤 회사들은 18개월에서 24개월이 걸리는 프로젝트를 피하지만, 대부분은 이런 실험적인 것들을 우위를 점하는 작품을 창조한다는 가치 있는 투자로 봅니다. 따라서 그렇다고 말하되, 그들이 거기서 어떤 것을 얻어낼 수 있는지 말하는 걸 잊지 마십시오. 실험적인 요소가 잘 진행될 거라고 그들을 안심시키십시오.

- 주요 개발 업무: 한 문단 또는 몇 가지 중요 항목 이내로 주요 업무들을 명시하십시오. 기술적인 지식이 없는 사람도 이해할 수 있게끔 언어를 사용하십시오. 주요하다는 것은 매월에 걸친 개발을 의미합니다. 업무를 완수하는데에 필요한 모든 자원을 갖고 있다고 가정하여 기간 추정치를 제시하십시오. 또한 필요한 자원도 제시할 수 있습니다. 예를 들면:

"인공지능 스크립트 파서(Script Parser): 2명의 프로그래머가 3~4개월 작업. 파서는 AI 스크립트를 읽고 실시간으로 실행되는 저수준 논리와 명령어로 취합됩니다."


- 위험성: 모든 기술적인 위험들을 열거하십시오. 기술적인 위험성을 발견할 수 없다면 그렇게 적어도 좋습니다. 위험성은 연구나 개발에 있어서 만약 실패할 경우에 주 단위나 월 단위 수준으로 주요한 지연을 발생시킬 수 있는 측면입니다. 경쟁자들이 그 기술을 검증했다고 하더라도 당신의 회사가 개발해본 적이 없거나 경험이 거의 없는 기술들은 열거하십시오. 만약 당신의 팀이 실시간 전략 게임을 개발한 적이 없다면 실시간 전략 게임을 열거하고, 3D를 처음 시도한다면 3D 렌더링을 열거하십시오. 이전에 언급한 주요한 개발 업무 중에서 당신이 위험을 느끼는 것들을 모두 열거하십시오. 써본 적이 없는 모든 상용제품들(3D 엔진, 편집기, 코드 라이브러리와 API, 드라이버, 그외 등등)은 특정한 요구사항을 충족시키지 못할 수도 있으므로 위험성으로 열거해야 합니다. 외부 계약으로 이루어지는 개발들은 항상 큰 위험이 있으므로 그것 또한 열거해야 좋습니다. 위험성을 평가할 때는 기술을 고치거나 대체하여 발생하는 스케쥴의 변화도 표시하는 게 좋습니다. 몇 주나 몇 달 정도 출시가 지연되는 시간을 표시하십시오. 특정 자원에 대한 시간의 영향을 열거하십시오. 그것을 고치는데에 필요한 모든 새로운 자원(사람, 소프트웨어, 하드웨어, 기타 등등)을 열거하십시오. 이 섹션은 부정적으로 비춰질 수 있습니다. 하지만 특히 이런 위험성들을 자체적으로 평가할 수 있을 경우엔 문서의 검토자에게는 게임 제작이 통제 하에 있다는 인상을 주어 안도감을 줍니다. 추가로 당신이 "제가 경고하지 않았다고 말씀하시진 않겠지요?"라고 말할 수 있는 여지를 줍니다.

- 대안 (만약에 있다면): 대안은 이런 실험적인 것들이나 위험 요소가 있는 특징들과 주요한 개발 업무들을 대체할 수 있는 제안입니다. 대안을 제시하여 검토자에게 옵션을 제공하고 선택하도록 합니다. 돈과 시간을 더 들이면 더 더 나은 결과물이 나온다거나 반대로 돈과 시간이 덜 들지만 결과물이 좀 더 목표한 바와 다를 수 있는, 그러한 모든 것을 열거하십시오. 무엇을 적든 간에 장점과 단점을 언급하십시오.

- 자원 추정: 자원 추정치를 열거하십시오. 피고용자, 계약자, 소프트웨어, 하드웨어, 기타 등등. 회사 바깥의 집단에게는 일반적이고 표준적인 명칭을 사용하십시오. 예를 들면, 문서를 읽을 수도 있는 퍼블리셔나 투자자들 말입니다. 몇 주 또는 수개월에 이르는 추정 작업 기간을 열거하십시오. 그후에 따르는 실지적인 비용(달러)들은 무시하십시오.

- 스케쥴 추정: 스케쥴은 개발 주기의 종합적인 기간입니다. 개발 주기는 최대한 이른 시기의 시작 기간에서부터 알파, 베타 그리고 골드 마스터에 이르는 마일스톤 추정치를 따릅니다.