3A급 게임 개발 문서(GDD) 스킬
경로 규칙: 본 파일의 모든
scripts/,references/,assets/는 이 SKILL.md 파일이 있는 디렉토리를 기준으로 합니다.python scripts/new_gdd.py를 실행하기 전에 해당 디렉토리로 이동하십시오(Cursor/Codex는install.ps1에 의해<프로젝트>/skills/game-dev/aaa-game-gdd/에 설치됩니다). 확실하지 않으면 먼저 이 SKILL.md의 절대 경로를 찾은 후 절대 경로로 스크립트를 호출하십시오. 프로젝트 루트에서 상대 경로를 직접 입력하면 file-not-found 오류가 발생합니다.
이 스킬의 기능
'게임 아이디어가 있습니다'를 '팀이 문서만 보고 바로 개발해서 Steam에 출시할 수 있고, 3A급 게임에 버금가는 게임'을 만들 수 있는 전체 문서로 변환합니다. 핵심 결과물은 구조화되고, 정량화되며, 검증 가능한 중국어 Markdown 문서(GDD)로, 막연한 기획안이 아닙니다.
생성된 각 문서는 다음 세 가지 철칙을 충족해야 합니다:
- 개발 가능성: 개발자가 문서를 받았을 때 '구체적으로 무엇을, 어느 정도 규모로, 어떤 기준으로 만들어야 하는지' 질문할 필요가 없습니다. 모든 정량화 가능한 것은 수치로 명시합니다(폴리곤 수, 프레임 수, 시간, 해상도, 주파수, 지연 시간, 트리거 조건).
- 검증 가능성: 모든 에셋, 시스템, 씬에는 Definition of Done(완료 정의) 체크리스트가 있어 완료 후 항목별로 확인 가능합니다.
- 일관성: 모든 문서는 동일한 비전 핵심, 아트 바이블, 명명 규칙, 성능 예산을 공유합니다. 문서 간에는 번호를 상호 참조하며 모순을 금지합니다.
문서 맵 (references는 필요 시 읽기)
모든 참조 문서를 한 번에 읽지 마십시오. 먼저 아래 표를 보고 사용자가 어떤 유형의 문서를 원하는지 확인한 후, 해당 문서만 읽으십시오. 각 reference의 구조는 다음과 같습니다: 해결하는 문제 → 작성 시기 → 장 구성 → 각 장 작성 방법(정량적 기준 포함) → 좋은/나쁜 예시 → 완료 정의 체크리스트.
| 문서 | 이 reference를 읽을 시기 | 해당 템플릿 (assets/templates) |
|---|---|---|
| 00 문서 체계 개요 | 신규 프로젝트 시작, 문서 목록과 단계 계획 수립 필요 시 | README.md |
| 01 비전과 피치 | 프로젝트 아이디어 초기, 한 페이지로 게임 설명 필요, 대외 발표 시 | 01-vision-pitch.md |
| 02 아트 바이블 | 아트 스타일 결정, 팀 미적 감각 통일, 아트 요구 사항 도출 시 | 02-art-bible.md |
| 03 씬과 레벨 | 씬 설명, 레벨 진행, 동선, 인카운터, 환경 스토리텔링 작성 시 | 03-scene-level.md |
| 04 게임플레이 시스템 | 코어 루프, 전투, 육성, 경제, 수치 테이블 설계 시 | 04-gameplay-systems.md |
| 05 내러티브와 대사 | 스토리 개요, 챕터 비트, 분기, 대사 스크립트, 더빙 작성 시 | 05-narrative-dialogue.md |
| 06 상호작용과 UI/UX | 조작, 상호작용 매트릭스, 게임 감각, HUD, 메뉴, 접근성 결정 시 | 06-interaction-uiux.md |
| 07 캐릭터 사양 | 주인공/적/NPC 설정, 외형, 액션 세트, AI, 수치 | 07-character-spec.md |
| 08 아이템 모델링 사양 | 소품/무기/환경 에셋의 모델링, 텍스처, LOD, 명명 및 전달 | 08-prop-modeling.md |
| 09 애니메이션 사양 | 3D 본 애니메이션, 애니메이션 상태 머신, 컷신, 2D 프레임 애니메이션 | 09-animation-spec.md |
| 10 오디오 디자인 | 음악, 음향 효과, 더빙, 다이나믹 뮤직, 버스 라우드니스 | 10-audio-spec.md |
| 11 기술과 성능 | 엔진 선택, 렌더링 파이프라인, 프레임률/메모리/패키지 예산, 플랫폼 | 11-tech-performance.md |
| 12 3A 품질과 Steam 검수 | 단계 게이트, QA 계획, Steam 스토어 및 출시, 3A 벤치마크 평가 | 12-steam-qa-checklist.md |
작업 흐름
흐름 A: 신규 프로젝트 (아이디어에서 완전한 문서 체계까지)
- 최소 필수 정보 확인 (한 번에 사용자에게 질문, 4개 이내): 게임 장르와 핵심 플레이를 한 문장으로, 엔진(Unity/Unreal/Godot/미정), 플랫폼 및 목표 프레임률(PC 60fps? Steam Deck?), 아트 스타일 선호도. 질문 후 바로 작업 가능하며, 정보가 완전하지 않다고 반복 질문하지 말고, 알 수 없는 항목은 문서에 명시적으로
【확인 필요】로 표시합니다. - 스캐폴딩 실행:
python scripts/new_gdd.py init --name "게임명" --out <출력 디렉토리> --engine <1단계에서 확인한 엔진>을 실행하여 전체 GDD 문서 트리를 생성합니다.--engine은 반드시 1단계에서 확인한 엔진을 사용해야 하며, 무조건 unity로 채우지 마십시오. 엔진에 따라 축, 충돌 명명, 탐색 및 데이터 에셋 규격이 결정됩니다. - 단계별 순서로 문서 작성 (아래 '단계 게이트' 참조), 각 문서는 해당 reference를 먼저 읽고 해당 템플릿을 작성합니다. 순서: 01 비전 → 02 아트 바이블 + 11 기술 예산 → 04 핵심 게임플레이 → 07/08/09/06 사양류 → 03/05 콘텐츠류 → 12 검수.
- 각 씬/캐릭터/소품/애니메이션/대화/시스템에 대해
scripts/new_gdd.py sheet로 독립된 단일 페이지 문서를 생성하여 GDD 해당 하위 디렉토리에 배치합니다. 핵심 문서에는 색인 테이블만 포함하고, 수백 개의 에셋을 하나의 파일에 쌓지 마십시오. - 품질 게이트 통과: 각 단계가 끝나면
12-steam-qa-checklist.md의 게이트 테이블로 항목별로 확인하고, 통과하지 못하면 다음 단계로 진행하지 않습니다.
흐름 B: 단일 문서 (사용자가 특정 유형의 문서만 필요한 경우)
대상과 용도 확인 → 해당 reference 읽기 → 해당 템플릿 복사 후 작성 → 문서 끝의 '완료 정의'로 자체 점검 → 전달. 사용자가 '씬 하나 작성해줘'라고만 말하면, 먼저 씬 이름/진행 위치/핵심 이벤트를 한 번에 질문한 후 전체 scene-sheet를 생성하세요. 빈 템플릿만 제공하지 마십시오.
씬 vs 레벨: 기본적으로 사용자가 요청한 것만 생성합니다. references/03에서 '씬은 공간, 레벨은 시간이며 분리해서 작성한다'고 말하는 것은 둘 다 필요할 때의 역할 구분이며, 매번 씬을 작성할 때마다 레벨 페이지를 첨부하라는 의미가 아닙니다.
역할 구분은 명확합니다:
- 씬 단일 페이지(SC_) = 이 공간이 제공하는 것: 지형, 시선, 엄폐물, 높낮이, 탈출구, 은신처, 적에 대한 공간적 제약(§7) 및 트리거 영역
TZ_(§4). - 레벨 단일 페이지(LV_) = 플레이어가 어떤 순서로 무엇을 경험하는가: beat 테이블(
EV_이벤트 번호 포함), 리듬, 인카운터 결과, 체크포인트.
따라서:
- 사용자가 씬만 원함 →
scene-sheet.md만 작성, 순서는 작성하지 않음. 레벨 페이지가 정말 필요하지 않은 경우에만 §7의 '경험 순서(간략)'에 한 줄을 추가합니다. - 사용자가 레벨 흐름이나 씬의 다단계 리듬을 원함 →
level-sheet.md를 추가로 생성하고, 둘은TZ_↔EV_로 상호 참조합니다. - 03에서 '분리해서 작성'했다고 해서 임의로 두 문서를 생성하지 마십시오. 이는 단순한 요청을 2-3배로 부풀릴 수 있습니다.
작성 전에 예시 문서를 먼저 읽으십시오 – 각 유형의 단일 페이지에는 완전한 예시가 있습니다. 작성할 유형에 따라 직접 해당 예시를 참조하십시오:
| 단일 페이지 유형 | 예시 문서 | 가장 참고할 사항 |
|---|---|---|
| 씬(선형/공포) | assets/examples/SC_01_외과동2층복도_예시.md | §7 공간 제공 = 시선 차폐와 '목격 후 접촉'; §10 인지와 리듬 중심 |
| 씬(개방형/BOSS) | assets/examples/SC_07_절단교망루_예시.md | §7 공간 제공 = 거리 조절 가능 / 시선 차단 / 위험 부담 가능; §10 전투 해결 가능성 중심 |
| 레벨 | assets/examples/LV_01_복도첫만남_예시.md | beat 테이블과 TZ_ 대조 방법; 강도 곡선과 튜토리얼 포인트를 팝업 없이 배치하는 방법 |
| 캐릭터(적) | assets/examples/EN_01_봉합자_예시.md | §6 상태 머신+속도 차이로 '도망 가능'을 명시하는 이유; §7 전투 시간 계산 방법 |
| 소품 | assets/examples/PR_017_바퀴없는휠체어_예시.md | §5 기술 사양 값; §7 DoD에서 '의도적으로 하지 않음'을 명시하는 방법 |
| 애니메이션 | assets/examples/AN_EN01_Slash_01_예시.md | §2 3단계 프레임 구간; §3 이벤트 임베드(예고음은 공정성의 기본) |
| 대화/컷신 | assets/examples/DL_07_간호사장녹음_예시.md | 대사 ID/시간/자막 규정 준수/중단 후 재생 정의 방법 |
| 시스템 | assets/examples/SYS_04_잡기풀기_예시.md | §4 매개변수 테이블은 '설계 의도'를 포함해야 함; §5 경계 조건 누락 금지 |
모든 예시는 이 수준의 세분화(모든 항목에 구체적인 숫자, 번호, 작업 할당 가능 내용)에 도달해야 합니다. 예시의 체크 항목은 완료 후 검증 기록(실제 폴리곤 수, 리뷰 날짜, 폐기된 설계 결정 포함)이며, 작업 시작 전의 작성 양식이 아닙니다. v0.1 단계에서는 빈칸으로 남겨두고, '실제 측정한 것처럼' 보이는 숫자를 임의로 작성하지 마십시오. §10 설계 위험 및 검증 필요 가정은 숫자가 없어도 되는 유일한 절이며, 숫자가 없는 것이 정상입니다.
흐름 C: 기존 문서/아이디어 검토
12-steam-qa-checklist.md의 '3A 10차원 평가표'에 따라 각 차원별로 점수(1-10점, 증거 포함)를 매기고, 출시를 막는 치명적 문제, 누락된 문서 목록, 심각도 순으로 정렬된 수정 제안을 제시합니다. 평가는 문서 원문 또는 누락 항목을 인용해야 하며, 추상적인 평가는 금지됩니다.
단계 게이트 (Stage Gates)
| 단계 | 완료 필수 문서 | 게이트 (통과하지 않으면 다음 단계 진행 불가) |
|---|---|---|
| 컨셉 | 01 비전, 04 핵심 게임플레이 프레임워크 | 핵심 재미가 플레이 가능한 종이/그레이박스 프로토타입으로 검증됨; 3가지 핵심 기둥이 모든 팀원의 승인을 받음 |
| 수직 슬라이스 | 02, 06, 11 + 각 유형별 최소 1개의 샘플 단일 페이지(씬/캐릭터/소품/애니메이션/대화) | 10-15분 분량의 흐름이 최종 품질 예상치에 도달; 모든 핵심 시스템 작동; 성능 예산 충족 |
| 양산 | 모든 핵심 문서 + 모든 에셋 단일 페이지 | 각 에셋 단일 페이지가 직접 작업 할당 가능; 생산 능력과 마일스톤 일정 수립 가능 |
| Alpha | 모든 콘텐츠 | Feature Complete: 처음부터 끝까지 클리어 가능, 대체 시스템 없음 |
| Beta | 위 동일 + 12 검수표 | Content Complete; S/A급 버그 0개; 전체 흐름 × 3개 설정 구성 완료 |
| RC/출시 | 12 중 Steam 목록 전부 체크 | 스토어 페이지, Deck 검증, 현지화, 등급, 저장 데이터 호환성 모두 통과 |
스캐폴딩 스크립트
# 전체 GDD 문서 트리 초기화 (출력 디렉토리에 <게임명>_GDD/ 생성)
python scripts/new_gdd.py init --name "게임명" --out "D:/MyGame" --engine unity
# --engine: unity | unreal | godot | agnostic (기본값)
# ★ 장식이 아닙니다: 선택 시 해당 엔진의 교환 형식, 축, 충돌 명명, 탐색, 데이터 에셋, LOD 규격이 실제로 작성됩니다.
# --genre: 선택 사항, 게임 장르 설명, 비전 문서에 작성됩니다.
# --dimension: 3d (기본값) | 2d (sprites/ tilesets/ 하위 디렉토리 추가 생성)
# 단일 객체에 대한 단일 페이지 문서 생성 (해당 하위 디렉토리에 자동 배치)
python scripts/new_gdd.py sheet --type scene --name "버려진 병원" --out "D:/MyGame/게임명_GDD"
# --type: scene | level | character | prop | animation | dialogue | system | sprite | tileset
# --subtype: character의 경우 player/enemy/npc (CH/EN/NPC); prop의 경우 item/weapon (PR/WP)
# 예: sheet --type character --subtype enemy --name "봉합자" → characters/EN_01_봉합자.md
# 예: sheet --type sprite --name "HeroIdle" → sprites/SPR_01_HeroIdle.md
init은 --dimension 2d도 지원합니다: sprites/, tilesets/ 하위 디렉토리를 추가로 생성합니다(2D 프로젝트용).
스크립트는 {{GAME_NAME}}, {{DATE}}, {{ENGINE}} 플레이스홀더를 자동으로 대체합니다. 스크립트를 사용할 수 없는 경우 assets/templates/에서 템플릿을 수동으로 복사하십시오.
일반 작성 규칙
- 문서 헤더: 각 문서의 시작 부분에 문서 번호, 버전 번호, 상태(초안/검토 중/잠김), 마지막 업데이트 날짜, 담당자, 관련 문서 번호를 고정적으로 작성합니다. 에셋 단일 페이지의 경우 엔진 내 리소스 명명도 포함합니다(예:
SM_Prop_HospitalWheelchair_01). - 정량화 우선: '조작감 좋음', '화면 아름다움', '적 강함' 등 검증할 수 없는 설명은 금지합니다. '공격 버튼 입력부터 판정 적용까지 8프레임(0.13초@60fps)', '적 HP 120, 플레이어 최대 강화 시 DPS 45, 예상 전투 시간 35-45초'와 같이 작성합니다.
- 확실하지 않으면 표시: 알 수 없는 값은
【확인 필요: 이유/담당자/기한】으로 표시하고, 확실한 척 숫자를 임의로 작성하는 것을 금지합니다. 업계 경험 값은 바로 사용할 수 있으며 문서에 '업계 기본값, 첫 테스트 후 조정'이라고 표시합니다. - 도형 및 이미지 요구 사항: 씬, 레벨, UI는 반드시 레이아웃 개요(ASCII 평면도, Mermaid 흐름/상태 다이어그램, 또는 컨셉 아트 번호 참조)를 포함해야 합니다. 상태 머신, 대화 트리, 메뉴 흐름은 Mermaid로 그리고, 매개변수와 목록은 테이블로 표시합니다.
- 모든 문서에 DoD 필요: 문서 끝에 완료 정의 체크리스트(체크 가능한
- [ ])를 첨부합니다. 이것이 전달 및 검수의 유일한 기준입니다. - 언어: 본문은 중국어로 작성합니다. 고유 명사, 엔진 API, 리소스 명명은 영어를 유지합니다. 대사 스크립트는 영어/기타 언어 필드를 미리预留합니다.
- 문서 수정 시 버전 관리: 잠긴 문서를 수정할 때는 문서 끝의 변경 기록에 버전, 날짜, 변경 내용을 기록합니다.
전달 요구 사항
- 전달물은 사용자의 프로젝트 디렉토리에 있는 Markdown 파일입니다(스캐폴딩 디렉토리 + 작성된 문서). 채팅의 개요가 아닙니다.
- 각 전달 후 사용자에게 다음에 작성할 문서와 어떤
【확인 필요】항목에 대해 결정해야 하는지 알려줍니다. - 문서 품질은 '새로 합류한 외주 아티스트/프로그래머가 해당 단일 페이지만 읽고도 적격 에셋을 독립적으로 제작할 수 있는 수준'을 검증 기준으로 합니다.