게임기획서 쓰는 방법, 핵심 규칙과 검증 기준부터

실제 개발 문서에서 읽는 기획의 깊이

Condor의 1994년 《Diablo》 제안서는 게임 설계와 마케팅, 개발 계획을 함께 다룬다. Game Design에는 던전 탐험과 성장, 마을에서의 정비를 연결한 반복 구조가 있고, Gameplay에는 메뉴에서 캐릭터를 만든 뒤 이동과 상호작용으로 이어지는 플레이 장면이 적혀 있다. Development와 일정표는 그 경험을 만들 인력과 작업 순서를 설명한다. David Brevik이 공개한 8쪽 원본의 구성이다.

LucasArts의 1996년 《Grim Fandango》 퍼즐 문서는 또 다른 설계 단위를 보여준다. Year One의 인물 목록 뒤에는 퍼즐 의존 관계도와 공간 연결도가 이어지고, 개별 퍼즐에는 상황과 해결 과정이 붙는다. 같은 장면을 이야기, 진행 조건, 이동 경로로 나눠 읽을 수 있다.

이 글은 두 공개 원본과 Ubisoft의 설계 과제, Frictional Games의 설계 원칙, Riot Games의 프로토타입 설명, Warren Spector의 제작 회고를 바탕으로 기획서의 역할을 살핀다. 뒤에 나오는 상태·데이터 표와 30초 리듬 연습은 편집부가 작성한 응용 예제다.

문서의 목적에 따라 상세 수준을 나눈다

기획서의 독자와 다음 결정을 먼저 정하면 필요한 정보가 드러난다. 투자를 검토하는 사람에게는 대상 이용자와 경험의 차이, 제작 범위가 필요하다. 기능을 만드는 팀에는 입력과 상태, 데이터와 예외 처리가 필요하다. 테스트 담당자에게는 재현 조건과 기대 결과가 필요하다.

Ubisoft의 공개 Rainbow Six Siege 오퍼레이터 설계 과제는 목표 정의, 피치, 프로토타입 계획을 단계로 나눈다. 대상 이용자와 해결할 과제에서 출발해 역할·장비·플레이 경험을 설명하고, 이후 목표를 검증할 실행 계획으로 이어 간다. 공개 멘토십 과제에서 제시한 구성이다.

이를 소규모 프로젝트에 적용하면 개요 문서, 기능별 상세, 콘텐츠 표, 검증 기록으로 나눌 수 있다. 개요에는 우선순위를, 상세에는 동작을, 표에는 반복 제작할 데이터를 둔다. 아래 구분은 자료를 바탕으로 정리한 편집부의 작성 체계다.

설계 원칙은 기능을 선택하는 기준이다

Frictional Games는 《SOMA》의 다섯 설계 원칙을 공개하면서 행동·세계·이야기를 연결하는 기준을 설명했다. 잠긴 문을 여는 퍼즐에도 인물이 그 문을 열어야 하는 단기적인 이유와 이야기상의 보상이 연결된다. 팀은 각 장면이 목표한 경험을 만드는지 이 기준으로 검토한다.

리듬게임에 적용한 작성 예는 “짧은 예고를 듣고 다음 박자를 예상한다”, “입력 결과를 다음 시도에 활용한다”, “같은 조작으로 패턴의 차이를 익힌다”다. 원칙마다 화면에서 관찰할 행동과 기능 선택의 이유를 붙이면 기획 판단에 사용할 수 있다.

예를 들어 패턴 기억을 중심에 두는 구간은 시범과 응답의 구분, 기억해야 할 길이, 반복 횟수가 핵심 변수다. 현재 날아오는 대상에 반응하는 구간은 예고 시간과 방향 인지가 중심이다. 같은 버튼을 쓰더라도 이 차이를 문서에 적으면 난이도와 연출의 우선순위가 명확해진다.

플레이 시나리오를 규칙과 연결한다

《Diablo》 원본의 Gameplay는 캐릭터 생성, 마을 이동, 상호작용, 던전 진입으로 이어지는 장면을 설명한다. 클릭 대상과 거리의 관계에 따라 이동과 상호작용이 이어지는 방식도 적혀 있다. 당시 턴제 구상의 제안서에 담긴 설계다.

기획서에서 이런 서술은 팀이 같은 플레이를 상상하는 출발점이다. 이어서 각 문장을 규칙으로 풀면 구현할 사건과 상태가 나온다. “공이 목표선에 오면 누른다”는 시나리오에는 등장 시점, 목표 시점, 허용 입력, 판정 범위와 결과 표시가 연결된다.

장면 하나에는 진입 조건, 플레이어가 받는 정보, 가능한 행동, 시스템의 반응, 다음 장면으로 넘어가는 조건을 함께 적는다. 피드백에는 화면과 소리의 종류뿐 아니라 어느 사건을 알려 주는지도 명시한다. 성공 직후의 번쩍임은 입력을 접수했는지, 목표를 맞혔는지에 따라 전달하는 정보가 달라진다.

퍼즐과 스테이지를 선행 조건으로 설계한다

《Grim Fandango》의 Year One 퍼즐 도표는 순서대로 이어지는 과제와 동시에 진행할 수 있는 과제를 선으로 구분한다. 다음 쪽의 Location Layout은 장소 사이의 이동을 따로 보여준다. PDF 3~4쪽을 함께 읽으면 진행상의 선행 조건과 공간상의 접근 경로를 대조할 수 있다.

이 구분은 리듬게임의 해금과 학습 순서에도 적용할 수 있다. 한 박 입력을 익힌 뒤 좌우 전환을 소개하고, 두 기술을 익힌 다음 복합 패턴을 여는 구조다. 필요한 선행 기술과 진입 조건을 각각 적으면 학습 단계와 메뉴의 잠금 표시를 같은 기준으로 맞출 수 있다.

진행 그래프의 간선에는 완료 조건을, 공간도에는 이동 가능한 경로를 적는다. 재도전·중단·다시 방문할 때 유지할 상태도 함께 정한다. 아래 도표는 병렬 학습 뒤 두 조건이 합쳐지는 과정을 설명하는 편집부 예제다.

상세 규칙은 상태·입력·결과로 적는다

기능 상세의 기본 단위는 현재 상태에서 어떤 사건이 발생하면 무엇이 바뀌는가다. 상태 전이표에는 현재 상태, 사건과 조건, 갱신할 값, 표시할 피드백, 다음 상태를 둔다. 이런 형식은 같은 사건을 프로그래머와 기획자, 테스트 담당자가 함께 대조할 때 유용하다.

한 박 연습의 판 상태는 준비, 진행, 일시정지, 결과로 나눈다. 노트 상태는 대기, 성공, 놓침으로 관리한다. 판이 진행 중이고 노트가 대기 중일 때에만 입력을 판정한다. 성공 또는 놓침으로 확정된 노트는 그 상태를 유지한다.

입력의 우선순위도 명시한다. 여러 노트의 판정 창이 겹치는 설계라면 같은 레인에서 시간 차가 가장 작은 대기 노트를 고르는 식으로 대상 선택 규칙을 정한다. 한 번의 물리 입력이 처리할 대상 수와, 키를 누르고 있을 때 반복 이벤트를 취급하는 방법까지 같은 항목에서 다룬다.

입력 중복 방지는 사건 단위로 설명할 수 있다. 키보드는 keydown의 최초 눌림을 사용하고 repeat를 건너뛴다. 터치는 pointerdown을 기본 입력으로 정하고 같은 동작에서 뒤따르는 click은 UI용으로 분리한다. 이 글의 연습 예제는 한 입력으로 한 노트만 처리한다.

30초 연습의 시각과 판정 경계를 계산한다

가상의 “한 박 연습”은 120 BPM에서 한 버튼으로 박자를 익히는 30초 실행본이다. 한 박은 60÷120=0.5초이며, 30초는 60박에 해당한다. 첫 4박인 0초 이상 2초 미만을 준비에 사용하고, 입력 목표 56개를 2.0초부터 29.5초까지 0.5초 간격으로 둔다. 목표 인덱스 k가 0~55일 때 t(k)=2.0+0.5k초다.

입력 시각과 목표 시각은 같은 음악 시간축에서 비교한다. 보정값 c를 입력 시각에서 빼는 규약을 택하면 오차 e=t입력−c−t목표다. 양수 c는 기록된 입력을 그만큼 앞당겨 해석한다. 시험용 판정은 |e|≤0.100초로 두고 양끝을 포함한다. 실제 채택할 값은 대상 기기의 입력·오디오 조건과 플레이테스트를 통해 정한다.

이 예제의 음악 위치는 오디오 시작 기준에서 지난 시간을 초 단위로 읽는다. 장치의 출력 지연과 이용자의 입력 경향은 보정 시험에서 따로 살핀다. 화면의 프레임 번호와 음원의 목표 시각은 각자의 단위로 기록하고, 판정에 사용할 공통 시간축과 변환 규약을 문서에 남긴다.

준비 중 입력은 점수 집계에서 제외한다. 진행 중에는 아직 대기 중인 노트의 성공 창을 검사하고, 창 바깥의 입력은 대상 상태를 유지한다. 목표 뒤 0.100초를 초과하면 대기 노트를 놓침으로 확정한다. 준비 상태의 입력 제외 규칙이 우선하므로 첫 목표의 유효 입력은 진행 시작인 2.0초부터 2.1초까지다. 2.0초에는 진행 전환을 먼저 처리한 뒤 입력을 검사한다. 나머지 목표는 전후 0.100초의 창을 사용한다. 마지막 노트의 늦은 경계는 29.6초이며 결과 화면은 음악 위치 30.0초에 연다.

창이 숨겨지면 음악과 판정 시간을 함께 멈춘다. 복귀 버튼을 누르면 같은 음악 위치에서 재개하며 남은 노트를 이어 간다. 초기 음원 준비, 재개, 오디오 컨텍스트 상태는 실행 환경에서 시험할 항목으로 기록한다.

데이터 표에는 단위와 불변 조건을 둔다

NC가 공개한 게임 디자인 직무 설명은 플레이 요구사항을 규칙과 시스템 흐름으로 정리한 뒤 데이터를 설계하는 과정을 다룬다. 시스템 디자인에는 규칙을 운용하는 구조와 데이터가, 콘텐츠 디자인에는 개별 콘텐츠의 세부값과 균형 조정이 포함된다. 국내 제작사가 설명하는 업무의 연결이다.

콘텐츠 표는 디자이너가 반복 제작할 값을 담는다. 채보라면 chart_id, chart_version, note_id, 목표 시각, 입력 레인, 노트 종류를 기본 열로 정할 수 있다. BPM이 바뀌는 곡에는 tempo segment와 박 위치를 시간으로 바꾸는 규약을 함께 둔다.

한 박 연습은 고정 템포이므로 note_id 0~55와 target_seconds=2.0+0.5×note_id를 사용한다. 표시를 위한 출발 시각은 목표 시각에서 예고 시간을 빼서 계산한다. 예고 시간을 1초에서 1.5초로 바꾸면 화면에 나타나는 시점이 달라지고, 맞혀야 할 목표 시각은 유지된다. 두 수치를 분리하면 가독성과 판정 난이도를 각각 조정하기 쉽다.

가져오기 검사에는 ID의 고유성, 목표 시각 정렬, 지원하는 레인 값, 음원 범위, 판정 창의 겹침을 넣는다. 동시 노트를 허용한다면 같은 목표 시각과 서로 다른 레인의 조합을 허용 목록에 둔다. 표를 읽는 프로그램과 편집 도구가 같은 조건을 사용하도록 버전을 함께 관리한다.

난이도에는 박당 입력 수, 연속 입력의 길이, 좌우 전환, 시범을 기억할 시간, 휴식 구간을 구분해 적는다. 한 번에 바꾼 변수와 관찰 결과를 기록하면 다음 채보를 조정할 근거가 쌓인다.

제작 범위는 콘텐츠와 의존 작업으로 계산한다

《Diablo》 제안서의 Development는 인력 구성과 그래픽·음향·프로그래밍 작업을 설명하고, 마지막 일정표는 작업의 겹침과 순서를 보여준다. 플레이 구상 뒤에 제작 계획을 붙인 구조다.

우리 작성 예에서는 캐릭터 1종, 배경 1종, 노트 1종, 입력 효과와 결과 화면을 첫 실행본의 범위로 둔다. 그림 작업량은 대상 수, 방향, 동작, 변형을 나눠 산정한다. 예를 들어 2방향과 3동작, 2외형을 각각 별도로 그리면 조합은 12개다. 좌우 반전과 공통 동작 재사용이 가능한 부분은 제작 항목에 따로 표시한다.

스테이지 추가에는 채보 작성 외에도 음원 구간 정리, 배경 배치, 난이도 검토, 입력 시험이 따른다. 작업 표에 선행 조건과 담당, 산출물, 검수 항목을 붙이면 단계별 완료를 판단할 수 있다. 음원과 시간축을 읽는 기능이 준비돼야 채보와 판정의 싱크를 시험할 수 있다는 관계가 한 예다.

프로토타입은 설계 질문에 답하도록 만든다

Riot Games는 프로토타입 단계의 산출물로 대상 이용자의 정의, 핵심 변화를 보여주는 플레이 경험, 팀의 이해와 플레이테스트 근거를 제시했다. 최소한의 장르 구조를 먼저 만들고 새 요소를 대조하는 game scaffold도 설명한다. 기능을 구현하는 순서와 확인할 질문이 함께 제시된다.

리듬 연습에 적용할 질문은 “예고 시간을 늘렸을 때 첫 목표를 알아차리고 입력하는 과정이 어떻게 달라지는가”처럼 적을 수 있다. 같은 목표 배열과 판정 폭을 유지한 채 예고 시간을 바꾸고 첫 입력까지의 시간, 준비 중 입력, 놓친 노트의 위치를 기록한다. 두 조건을 여러 사람이 경험하면 제시 순서와 반복 학습도 함께 기록한다.

기능 검증과 경험 검증은 기록을 나누면 읽기 쉽다. 경계 입력을 자동으로 넣는 시험은 판정 규칙을 확인한다. 대상 이용자가 도움 없이 무엇을 보고 언제 눌렀는지 관찰하는 시험은 안내와 학습 흐름을 살핀다. 참가자의 말과 실제 행동, 편집자의 해석은 각각의 칸에 남긴다.

성공률은 성공 노트 수를 판정 대상 노트 수로 나눈 값이다. 한 참가자의 첫 성공률에는 그 사람의 기기와 경험, 안내 조건이 함께 작용한다. 참가자별 결과와 시험 회차를 보존하고 수정 후 다시 관찰하면 기능과 경험을 연결한 판단 기록을 만들 수 있다.

실행 결과를 기획 변경으로 돌려준다

Warren Spector는 《Deus Ex》 제작 회고에서 초기 목표를 기준으로 시스템을 검토하고 proto-mission을 통해 설계를 조정한 과정을 설명했다. 회고에는 플레이 가능한 임무를 검토한 뒤 기획 문서를 500쪽에서 270쪽으로 정리한 사례도 등장한다. 실행에서 확인한 내용을 다음 제작 범위에 반영한 기록이다.

기획서에는 규칙 ID와 개정일, 결정 상태, 담당, 시험 근거를 둔다. 확정 규칙은 구현의 기준이며 시험값은 비교할 조건이다. 검토 중인 항목은 결정 방법과 필요한 자료를 연결한다. 변경 기록에는 바뀐 값과 이유, 영향을 받는 표·화면·저장·검사 항목을 함께 적는다.

예고 시간 변경은 화면 등장 시점과 튜토리얼 설명, 테스트 항목으로 이어진다. 판정 폭 변경은 판정 로직과 결과 비교 조건으로 이어진다. 같은 뜻의 값을 여러 파일에서 수동 관리한다면 어느 파일이 기준인지 문서에 정한다. 기획서·데이터·실행본에서 동일한 버전을 찾을 수 있도록 유지하는 과정이다.

한 기능의 근거부터 검증까지 추적한다

한 박 연습의 목표를 G01, 입력 규칙을 R01, 판정 규칙을 R02, 검증 사례를 T01처럼 연결하면 작업 결과를 구체적으로 확인할 수 있다. 예를 들어 G01은 “일정한 간격을 예측해 입력한다”, R02는 “대기 노트 한 개를 목표 전후 100ms 안에서 한 번 판정한다”, T01은 “경계인 100ms와 그 바깥인 101ms를 넣어 결과를 비교한다”로 적는다. 모든 수치는 편집부의 학습용 시험값이다.

기능 검토에서는 목적, 정상 흐름, 예외 흐름, 데이터 정의, 화면·소리, 콘텐츠 수량, 검증 사례와 변경 이력을 함께 읽는다. 다른 팀원이 이 문서만으로 같은 예제를 구현하고 결과를 대조할 수 있는지가 작성의 실용적인 기준이다. 아래 양식에는 이 흐름을 반영한 빈 항목과 완성 예시를 담았다.