다음 빌드에 필요한 문서 작성하기
게임 디자인 문서는 무엇을 만들고 무엇을 제외하며 프로토타입의 작동 여부를 어떻게 판단할지 설명해야 합니다. AI의 도움을 받는 개발에서는 구체적인 규칙, 컨트롤, 범위의 경계, 승인 검사가 특히 유용합니다. 긴 이야기 개요만으로는 아이템을 두 번 집계할 수 있는지, 다시 시작할 때 무엇을 초기화해야 하는지 결정할 수 없습니다.
이 가이드는 작은 로봇 배달 게임 Rain Route를 하나의 교육용 예시로 계속 사용합니다. GDD, 프롬프트, 수정, 테스트가 모두 같은 제안 게임을 가리킵니다. 실제로 생성된 프로젝트나 보고된 사용자 경험은 아닙니다. 이 작업 과정은 제안된 빌드가 이미 존재한다고 주장하지 않고도 결정을 구현과 연결하는 방법을 보여 줍니다.
완성된 미니 GDD 복사하기
Rain Route, 디자인 버전 0.1.
기획 요약: 위에서 내려다보는 로봇이 비 내리는 도시의 한 구역에서 추억이 담긴 소포를 배달한다.
플레이어와 플랫폼: 데스크톱 브라우저에서 키보드로 혼자 플레이한다. 첫 플레이 약 5분은 측정 결과가 아니라 디자인 목표다.
약속과 핵심 요소: 차분한 이동, 알아보기 쉬운 목적지, 작은 경로 선택. 추가 시스템보다 명확한 피드백을 우선한다.
핵심 흐름: 배달소에서 소포 하나를 받아 번호가 맞는 현관까지 걸어가 전달하고 다음 소포를 받으러 돌아온다. 세 번 배달하면 승리한다.
컨트롤과 카메라: 고정된 탑다운 카메라. WASD 또는 방향키로 이동한다. 표시된 상호작용 영역 안에서 E로 소포를 받거나 배달한다. 승리 후 R로 다시 시작한다. 화면에 설명을 표시한다.
규칙: 소포는 하나만 들 수 있다. 배달은 1번, 2번, 3번 문 순서로 한다. 잘못된 문에서 E를 누르면 메시지가 표시되지만 소포는 사라지지 않는다. 정확히 배달할 때마다 카운터가 한 번 증가한다. E를 반복해서 눌러도 이미 끝난 배달을 다시 집계하지 않는다.
맵과 도전: 한 구역, 배달소 하나, 문 세 개, 물웅덩이 횡단로와 마른 우회로가 있다. 물웅덩이 안에서는 이동 속도가 평소의 절반이다. 체력 손실, 적, 시간 초과 실패는 없다.
피드백: 현재 목적지, 들고 있는 소포, 완료한 배달 수를 표시한다. 서로 다른 문 번호와 눈에 보이는 배달 확인을 사용한다. 빗소리 분위기는 조용하게 유지하고 음소거를 제공한다.
기술 범위: 브라우저 프로토타입 하나. 계정, 클라우드 저장, 네트워크, 구매, 추가 맵, 잠금 해제 시스템은 없다. 새로고침하면 새 플레이를 시작한다. 게임 흐름이 검사를 통과할 때까지 단순한 오리지널 도형을 사용한다.
승리와 초기화: 세 번째 배달 후 승리 패널을 표시한다. R은 로봇, 소포, 목적지, 배달 카운터, 승리 패널을 초기 상태로 되돌린다.
검토 질문: 처음 플레이하는 사람이 화면에 보이는 설명만으로 첫 배달을 완료할 수 있는가?
1단계: GDD를 하나의 빌드 요청으로 바꾸기
문서는 입력으로 사용하고 구현의 증거로 삼지 마세요. 제출하기 전에 범위, 컨트롤, 승리 조건 사이에 모순이 있는지 확인합니다. ‘새로고침하면 새 플레이를 시작한다’는 배달 상태의 영구 보존을 약속할 수 없다는 뜻이고, ‘소포 하나’는 숨겨진 인벤토리 대기열을 허용하지 않는다는 뜻입니다. 구현 시 추측하게 두지 말고 GDD에서 결정하세요. 적절한 첫 프롬프트는 다음과 같습니다.
디자인 버전 0.1을 바탕으로 Rain Route를 만들어 주세요. 먼저 맵, 이동, 배달소 수령, 1번 문 배달만 구현합니다. 나머지 문은 보이되 비활성 상태로 둡니다. 현재 목적지와 소포를 들고 있는 상태를 표시합니다. 단순한 오리지널 도형을 사용하세요. 날씨 효과, 잠금 해제, 실패 타이머, 추가 메커니즘은 넣지 마세요. 변경한 구성 요소와 수령, 잘못된 문에서의 상호작용, 올바른 배달, E 반복 입력을 테스트하는 방법을 설명해 주세요.
첫 요청은 이 배달 부분으로 제한하세요. 목적지 수를 늘리기 전에 완전한 상호작용 하나를 살펴볼 수 있는 결과가 필요합니다. 문서화된 컨트롤로 경로를 완료할 수 없다면 맵을 확장하는 대신 그 부분을 수정하세요.
2단계: 같은 게임에서 요구사항을 테스트에 연결하기
중요한 규칙에 짧은 식별자를 붙이고 프롬프트, 메모, 테스트 기록에서 계속 사용하세요.
| 요구사항 | Rain Route에서의 행동 | 예상 결과 |
|---|---|---|
| R1: 소포 최대 하나 | 배달소에서 E를 두 번 누른다 | 소포 하나만 계속 들고 있다 |
| R2: 올바른 목적지만 허용 | 소포 1을 들고 2번 문을 방문한다 | 메시지가 나타나고 소포는 남는다 |
| R3: 배달은 한 번만 집계 | 1번 문에서 배달한 뒤 E를 반복해서 누른다 | 카운터가 1로 유지된다 |
| R4: 순서대로 진행 | 배달 세 번을 모두 완료한다 | 목적지가 1 → 2 → 3으로 진행하고 승리가 한 번 표시된다 |
| R5: 물웅덩이 감속 | 표시된 같은 경로를 물 안과 밖에서 이동하며 시간을 잰다 | 물웅덩이 속도가 지정한 절반에 맞는다 |
| R6: 완전 초기화 | 승리 후 R을 누른다 | 초기 위치, 빈손, 배달 0회, 승리 패널 없음 |
실제 관찰 결과는 빌드 버전과 환경을 함께 별도의 실행 기록에 남기세요. 행동을 수행한 뒤에만 통과, 실패, 차단 등의 상태를 추가합니다. 첫 부분이 R2에서 실패하면 배달 세 번을 요청하기 전에 해당 상호작용을 수정하세요. 다른 사람도 실패를 재현할 수 있도록 입력 순서를 정확히 남깁니다.
3단계: 게임 흐름을 확장한 뒤 분위기 추가하기
첫 배달이 통과하면 2번과 3번 문 및 승리·초기화 상태를 요청합니다. R1부터 R4까지와 R6을 다시 실행하세요. 그다음 물웅덩이 감속을 요청하고 수령 로직은 바꾸지 않은 채 R5를 확인합니다.
이 규칙이 통과한 뒤에만 비 시각 효과와 조용한 환경음을 추가해야 합니다. 비가 번호나 상호작용 표시를 가리지 않는지, 음소거가 작동하는지 확인하세요. 날씨 효과로 맵을 읽기 어려워진다면 문서에 명시한 플레이어 경험을 희생하며 분위기를 받아들이지 말고 효과를 줄입니다.
4단계: 증거로 결정이 바뀌면 GDD 업데이트하기
미래의 플레이 테스트에서 플레이어가 현재 목적지를 놓친다고 가정해 보세요. 여기서는 가상의 관찰이지 실제 결과가 아닙니다. 범위를 좁힌 수정으로 문 순서와 배달 규칙을 유지하면서 목적지 표시를 더 눈에 띄게 요청할 수 있습니다. 새로운 플레이어에게 첫 배달에 관한 같은 질문을 다시 테스트하세요.
이 결정을 버전 0.2로 기록하고 변경 이유를 밝히며 영향을 받은 요구사항과 빌드에 연결합니다. 오래된 테스트 결과를 새 규칙의 증거로 착각하지 않도록 이전 결정도 볼 수 있게 보관하세요. 수정된 요구사항에는 이전 검사 중 무엇을 다시 실행해야 하는지 명시해야 합니다.
생성된 변경이 이전 요구사항을 깨뜨리면 되돌리거나 분리하세요. 실패한 요구사항, 정확한 입력, 예상 결과, 실제 결과를 보고합니다. ‘E를 반복하면 R3이 두 번 집계된다’가 ‘프로토타입에 버그가 있는 것 같다’보다 조치하기 쉽습니다.
사양과 테스트 기록 사이에서 SEELE 사용하기
SEELE는 자연어 게임 제작과 게임플레이, 장면, 에셋에 대한 반복적인 변경을 지원합니다. 미니 GDD를 디자인 입력으로 제공하고 범위가 제한된 구현 부분 하나를 요청하세요. 유용한 결과물은 같은 문서와 비교할 수 있는 빌드 후보이지 디자인 판단이나 완료된 테스트 기록의 대체물이 아닙니다.
후속 요청마다 변경된 요구사항과 안정적으로 유지돼야 할 요구사항을 명시하세요. 더 명확한 목적지 표시를 요청했다고 타이머가 조용히 추가되거나 문 순서가 바뀌어서는 안 됩니다. 잘 정리된 설명이 실제 동작을 대신하지 않도록 문서, 프롬프트, 관찰 결과를 버전으로 연결합니다.
GDD로 빌드를 미루지 말고 시작하기
유용한 GDD는 결정과 확인 사이의 거리를 줄입니다. Rain Route에는 더 긴 이야기 개요보다 명확한 수령 규칙, 목적지 순서, 초기화 정의가 먼저 필요합니다. 문서는 짧게 유지하되 다른 사람도 같은 빌드를 판단할 수 있을 만큼 규칙을 정확히 작성하세요.
사양을 SEELE에 복사하고 첫 배달 부분을 요청하세요. 문서, 작동하는 빌드, 테스트 기록의 버전을 맞춥니다. 같은 게임의 기존 규칙이 구현과 수정 후에도 유지될 때만 범위를 확장하고, 증거로 결정이 바뀌면 GDD를 업데이트합니다.
디자인을 플레이 가능한 검사까지 추적하기
이 표는 글에서 제안한 확인 사항을 정리합니다. 완료된 테스트 보고서가 아닙니다.
| GDD 요소 | 답하는 질문 | 승인 검사 예시 |
|---|---|---|
| 플레이어와 입력 | 누가 플레이하고 어떻게 행동하는가? | 데스크톱 플레이어가 지정된 키보드 컨트롤로 로봇을 움직일 수 있다. |
| 목표와 범위 | 이 버전에서 무엇이 일어나야 하는가? | 정의된 장면에서 지정된 소포를 배달할 수 있다. |
| 규칙과 경계 | 규칙이 발동하면 어떻게 되는가? | 배달이나 수령이 디자인에서 지정한 대로만 집계된다. |
| 실패와 복구 | 플레이어가 작업을 완료할 수 없으면 어떻게 되는가? | 명시된 실패 또는 재시작 동작이 게임을 문서화된 상태로 되돌린다. |
| 수정 기록 | 어떤 결정이 왜 바뀌었는가? | 관찰 결과, 바뀐 규칙, 검사를 다시 실행한 결과를 기록한다. |
자주 묻는 질문
프로토타입 GDD는 얼마나 길어야 하나요?
다음 구현 결정을 해결하면서 가능한 한 짧게 작성하세요. 완성된 예시는 방대한 제작 지침서 없이 범위, 컨트롤, 규칙, 테스트를 지정합니다. 누군가가 만들거나 확인할 내용을 바꾸는 경우에 섹션을 추가하세요. 상호작용 규칙 하나가 빠지는 비용은 배경 설정 한 페이지가 없는 것보다 큽니다.
AI가 문서를 대신 작성할 수 있나요?
AI는 섹션 초안을 작성하고 모호한 점을 드러낼 수 있지만 규칙을 결정하고 실현 가능성을 확인하는 것은 사용자의 몫입니다. 충돌하는 요구사항과 빠진 승인 기준을 찾아 달라고 요청하세요. 잘 정리된 문서를 재미, 구현 품질, 에셋 권리 또는 확인하지 않은 제품 기능의 검증으로 여기지 마세요.
GDD와 테스트 기록의 차이는 무엇인가요?
GDD는 의도한 동작과 결정을 명시합니다. 테스트 기록은 특정 빌드와 환경에서 실제로 발생한 일을 기록합니다. 둘을 연결하되 분리하세요. 통과할 것이라는 기대는 통과한 테스트가 아닙니다. 관찰 결과가 규칙 변경을 정당화하면 디자인을 명시적으로 업데이트하고 영향을 받는 검사를 다시 실행하세요.
더 큰 GDD에 대한 장 체크리스트
다음 빌드에 대한 결정을 내릴 때만 섹션을 추가하세요. 청중, 플랫폼 및 한 문장 피치로 시작하십시오. 핵심 루프, 컨트롤, 진행, 세계 또는 내러티브, 아트 및 사운드 제약 조건, 기술 요구 사항을 따르세요. 범위 내 각 기능에 대해 소유자, 재생 가능한 가장 작은 증거 및 팀이 다시 실행할 수 있는 테스트를 명시합니다. 선택적 아이디어를 별도의 백로그로 이동하세요.
