Claude Code Game Studios 关卡设计文档模板全解从空间布局到技术交付的完整实践指南【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文档是 Claude Code Game StudiosCCGS项目中.claude/docs/templates/level-design-document.md的完整技术解读与实操指南。它定义了一份可被 Agent 生产、可被审查、可被测试的关卡设计文档Level Design Document, LDD的标准结构从 Quick Reference 元数据、Narrative Context、Layout 布局、Encounters 遭遇、Pacing Chart 节奏图到 Audio/Visual 视听方向、Collectibles 收集要素与 Technical Notes 技术备注。在 CCGS 中这份模板既是 level-designer 智能体.claude/agents/level-designer.md的输出骨架也是团队级编排技能/team-level.claude/skills/team-level/SKILL.md的最终交付格式同时还支撑着 level-designer 的质量门Gate审查。读完本文你将掌握如何用这套模板产出一份信息密度高、可实施、可验证的关卡设计文档并理解它与 CCGS 的 49 个 Agent、72 个工作流技能协同运转的机制。一、模板定位关卡设计文档在 CCGS 中的角色1.1 一份可执行的设计交付物与普通的创意随笔式关卡描述不同CCGS 的 LDD 模板是一份面向生产管线的结构化契约。从 level-designer agent 定义 的 Level Document Standard 可以看到每个关卡文档必须包含关卡名称与主题Level Name and Theme预估游玩时长Estimated Play Time布局图Layout DiagramASCII 或文字描述关键路径Critical Path玩家必经路线可选路径Optional Paths探索与秘密遭遇列表Encounter List类型、难度、位置节奏图Pacing Chart强度随时间变化叙事节拍Narrative Beats关卡内的故事时刻音乐/音频提示Music/Audio Cues音频何时切换对比.claude/docs/templates/level-design-document.md的章节结构可以发现模板正是这套标准的可填写表格化实现。也就是说模板把 agent 的设计职责翻译成了文档字段每个字段都有明确的填空位[X]占位符这使得Agent 可以增量生成level-designer 遵循 Question-First 协作协议先建骨架全部章节标题再逐节填写每节经用户批准后立即写入文件。机器可以校验完整性审查方如/design-review、gate 流程可以检查每个章节是否缺失而不是凭主观判断设计得好不好。下游可以直接实现.claude/rules/design-docs.md明确要求设计文档No hand-waving即系统应该手感好这类话术不算有效规格——LDD 的表格化字段正是为了避免这类模糊表述。1.2 模板在协作流水线中的位置在.claude/skills/team-level/SKILL.md中LDD 是/team-level技能的最终编译产物编排者依次让 narrative-director、world-builder、art-director、level-designer、systems-designer、accessibility-specialist、qa-tester 协同产出叙事、世界观、视觉、布局、系统、无障碍、QA 等输入最后combining all team outputs into the level design template format保存到design/levels/[level-name].md。因此这份模板扮演三个角色角色说明创作骨架指导 level-designer 逐节产出布局、遭遇、节奏、环境叙事等内容协作接口是/team-level团队各成员输出的汇聚格式是叙事/视觉/系统/QA 输入的交汇点审查标的level-designer 的 Gate 审查APPROVED / REVISION NEEDED与/design-review都以它为检查对象二、Quick Reference开篇的元数据契约模板第一小节要求填写一行紧凑的元数据这是整个文档的索引卡字段含义填写建议Area/Region关卡位于游戏世界的哪个区域引用世界观文档中的正式区域名保持与 world-builder 的 Lore 数据库一致Type关卡类型Combat / Exploration / Puzzle / Hub / Boss / Mixed可选多个Estimated Play Time预估游玩时长用范围表示如 15-25 minutesDifficulty难度1-10 相对量表这是相对本游戏的量表。参照 difficulty-curve 模板 的说明soulslike 的 6/10 与 cozy sim 的 6/10 不是一回事Prerequisite玩家到达此关卡的先决条件例如完成主线第 2 章供后续做依赖检查Status文档/关卡生命周期阶段Concept → Layout → Graybox → Art Pass → Polish → Final从源码结构看Status 字段与 CCGS 的阶段门gate机制呼应阶段转换由/gate-check等技能把关文档状态是判断关卡是否可进入下一阶段的关键证据。Difficulty 字段则与 difficulty-curve.md 的 1-10 量表完全对齐便于把单个关卡插入到全局难度曲线中做一致性校验。三、Narrative Context让叙事与空间互相锚定本小节用四个字段把关卡挂接到游戏叙事弧上Story Moment关卡发生在叙事弧的哪个位置开端/中点危机/高潮前/终章……。Narrative Purpose本关卡交付哪个故事节拍。注意在 CCGS 中故事弧的决定权属于 narrative-directorlevel-designer 只负责将已定的叙事节拍翻译成空间设计。Emotional Target玩家在本关应该感受到什么情绪。这在后续节奏图、视听方向中会反复被引用。Lore Discoveries玩家在这里能找到哪些世界观信息。从 level-designer 测试规格Agent Test Spec 的 Case 5Context pass可以看到CCGS 期望 level-designer 能使用 gate context 中给定的游戏手感词汇game-feel notes逐段评估关卡。例如若设计输入规定探索段应感觉 vast and lonely辽阔而孤独、战斗段应感觉 urgent and claustrophobic紧迫而幽闭、奖励房间应感觉 safe and visually distinct安全且视觉上醒目则审查结论必须逐段对照这些词。这解释了为什么 Narrative Context 中 Emotional Target 必须写得具体且可验证而不是玩家应该感到兴奋这类空话。3.1 环境叙事的归属边界模板中的 Lore Discoveries 字段对应 level-designer 的职责之一Environmental Storytelling.claude/agents/level-designer.md 的 Key Responsibilities #4用空间元素无文字地传达叙事。但要注意职责边界环境叙事的落地由 level-designer 负责用道具摆放、空间构图讲故事世界设定与 Lore 的一致性与由 world-builder 负责.claude/agents/world-builder.md 要求 Lore 数据库交叉引用、不允许矛盾玩家可见文本与对白由 writer 负责剧情弧线的决定权在 narrative-director。这意味着在填写 Lore Discoveries 时应当引用已经成文的 loreCanon Level: Established而不是现场发明设定。四、Layout布局图、关键路径与空间可读性4.1 Overview MapASCII 符号约定模板规定了绘制顶层布局 ASCII 图的标准图例这是跨 Agent 协作的通用语言[S] Start point [E] Exit/end point [C] Combat encounter [P] Puzzle [R] Reward/loot [!] Story beat [?] Secret/optional [] One-way passage [] Two-way passage [] NPC [B] Boss encounter使用建议保持符号一致不要让同一种元素出现两种画法比例不必精确但要保持相对方位正确上下左右对应实际关卡方位在图的旁边或下方标注坐标/编号如 A1、B2供 Encounters 表的 Position 字段引用——模板中 Encounters 表使用[Map ref]就是引用的这个编号体系把地图拆成入口区/中段/高潮区/出口区几段绘制与 Pacing Chart 的横轴对应。4.2 Critical Path关键路径关键路径是所有玩家必经的路线模板要求逐步描述1. Player enters at [S] 2. [Description of what happens along the path] 3. Player exits at [E]填写时应当只写必经路线把可跳过内容排除在外每一步描述玩家看到什么、做什么、遇到什么在/team-level中关键路径是 QA 测试用例的编写基础.claude/skills/team-level/SKILL.md Step 5 要求 qa-tester 为关键路径写测试用例并识别序列破坏、软锁等边界情况。4.3 Optional Paths可选路径表可选路径用四列表格记录这是探索回报设计的最小数据模型列含义Path路径名称/位置Access Requirement解锁条件是否需要特定能力、钥匙、解谜完成Reward回报装备、lore、捷径、收藏品Discovery Hint玩家如何被提示发现它环境线索、NPC 暗示、可透视缝隙等4.4 Points of Interest兴趣点列含义Location位置对应地图坐标Type类型地标、叙事道具、谜题、NPC、补给点……Description一句话描述Purpose它的设计目的从 level-designer 的 Key Responsibilities #6Flow Analysis 看兴趣点尤其是**地标Landmarks**承担着引导职责保证玩家随时有明确的方向感和目标感。这也与/team-levelStep 1 的要求一致——art-director 先行指定视觉地标目标Step 2 中 level-designer 布局时必须让主路线对齐这些地标layout must work within these targets, not contradict them。换句话说Points of Interest 表里的 Landmark 行不能与 Visual Direction 小节的 Landmarks 字段矛盾两份信息必须互相引用。4.5 空间可读性与Leading空间可读性spatial readability是 level-designer 审查的核心维度之一。在 Agent Test Spec Case 1 中一个布局被 APPROVED 的前提包含spatial readability supports player navigation。落实到文档填写上意味着关键路径上的每个转折点都要有leading元素灯光、几何、音频支撑在 Points of Interest 或 Layout 描述中标注这些引导元素的位置单向通道[]与双向通道[]的区分要严格准确因为方向性直接影响玩家是否会迷路。五、Encounters遭遇设计的量化表达5.1 Combat Encounters战斗遭遇表模板给出了两条示例行直接展示了填写格式| ID | Position | Enemy Composition | Difficulty | Arena Notes | |----|----------|------------------|-----------|-------------| | E-01 | [Map ref] | [2x Grunt, 1x Ranged] | 3/10 | Open area, cover on flanks | | E-02 | [Map ref] | [1x Elite, 3x Grunt] | 5/10 | Narrow corridor, no retreat |关键点ID 编号体系E-01、E-02…… 与布局图坐标对应方便文档内部交叉引用和 QA 用例引用Enemy Composition写明敌人种类与数量如2x Grunt, 1x Ranged这是 systems-designer 做数值平衡的输入.claude/skills/team-level/SKILL.mdStep 3 要求 systems-designer 指定敌方构成与遭遇公式Difficulty与 Quick Reference 的 1-10 量表一致但注意 level-designer 的边界Set difficulty parameters for the whole game (only per-encounter)——agent 只能设定单次遭遇的难度全局难度参数属于 game-designer / systems-designer 的职权Arena Notes描述地形对战斗的影响——模板示例给出开阔地带、侧翼有掩体与狭窄走廊、无法后撤两个对仗案例说明同一批敌人放在不同地形里难度与体验完全不同。这条信息对平衡审查至关重要。5.2 Non-Combat Encounters非战斗遭遇表列含义ID编号N-01、N-02……Position位置Type类型谜题、NPC 对话、环境事件、追逐、平台挑战……Description描述Solution Hint解决方案提示解谜线索、NPC 引导这条表承接 level-designer 的spatial puzzles设计职责。值得注意的边界从 level-designer Agent Test Spec 的 Coverage Notes 可以读到项目自认spatial puzzle design review 尚未覆盖——应在谜题机制定义后补专门用例。因此现阶段填写本表时谜题机制本身应引用 systems-designer 或 GDD 中已定义的内容避免现场发明无依据的机制。5.3 遭遇密度与节奏的冲突处理遭遇设计常与节奏产生张力。在 Agent Test Spec Case 4 中给出了标准的冲突升级路径game-designer 想提高全关遭遇密度而 level-designer 认为这会摧毁 tension-release 节奏消除休息段。预期行为是level-designer 清晰说明节奏影响消除休息段失去松紧交替的律动承认 game-designer 的挑战目标升级到 creative-director 裁决挑战密度 vs 节奏律动哪个优先。这与 .claude/docs/coordination-rules.md 的规则 3冲突升级至共享父节点设计冲突由 creative-director 裁决完全一致。在 LDD 文档层面这类决策应被记录避免后续实现时反复争执。六、Pacing Chart强度曲线与节奏设计模板用 ASCII 强度图表达关卡全程的张力变化Intensity 10 | * 8 | * * * 6 | * * * * * * 4 | * * * ** * * * 2 | * ** ** * * * * * 0 |S-----------------------------------------E [Start] [Mid] [Climax] [Exit]并配有一句要求Describe the intended rhythm: where are the peaks, valleys, rest points?描述预期律动峰、谷、休息点在哪里。6.1 填写与解读要点横轴是时间/流程顺序不是地图距离纵轴是强度1-10建议与遭遇表的 Difficulty 字段一致避免图上强度 8 的战斗遭遇难度写 3这类自相矛盾必须设计谷模板示例中有明显的下凹段。这与 difficulty-curve.md 的锯齿形曲线理论心流模型应用于宏观结构一脉相承——Flat difficulty creates boredom; uninterrupted escalation creates fatigue平直难度造成无聊不间断升级造成疲劳必须注明休息点休息段安全区、补给点、存档点是节奏设计的显式元素不是忘记放敌人的结果注意幅度而非频率节奏图的形状变化升降幅度比节点数量更重要审查者关注的是是否有足够的呼吸空间。6.2 与难度哲学对齐节奏图不是孤立设计的。CCGS 的 difficulty-curve 模板 定义了四种难度哲学痛苦挑战、低门槛高深度、难度服务叙事、休闲体验其中Difficulty serves narrative pacing难度服务叙事节奏尤其与 LDD 强相关故事高潮处玩家应当感到威胁故事收束处玩家应当感到胜任。因此 Pacing Chart 的峰谷应当与 Narrative Context 的 Story Moment 对应着填两者共同构成一条弧线而非两条独立轨道。七、Audio Direction 与 Visual Direction视听协同指引7.1 Audio Direction音频分区表列含义Zone/Moment区域或时刻Music Track音乐曲目/音轨切换点Ambience环境音Key SFX关键音效模板示例本身就演示了进入→战斗→战后的三段式Zone/MomentMusic TrackAmbienceKey SFX[Entry][Track][Ambient sounds][Door opening][Combat][Combat music][Muted ambience][Combat SFX][Post-combat][Calm transition][Return to ambience]注意战后行的 Key SFX 为空这是有意的设计——战斗结束后音效清空、环境音回归本身就是松的信号。这一节同时服务两个目标对 audio-director / sound-designer这是音频资产需求清单的输入对玩家引导音频是 level-designer Key Responsibilities #6 中leading 元素之一灯光、几何、音频。7.2 Visual Direction视觉方向字段模板要求描述五个方面字段含义Lighting主光、补光、环境光描述Color Palette主导色及原因Mood Board References视觉参考描述非外部链接而是文字化的风格参考Landmarks可见的导航辅助物及其位置Sight Lines玩家在关键位置应看到什么关键协作约束在.claude/skills/team-level/SKILL.md中视觉主题方向由 art-director 在 Step 1 先行确立these are INPUTS to layout, not outputs of itlevel-designer 在 Step 2 必须在这些视觉目标内做布局。因此 Visual Direction 小节的字段本质上承接 art-director 的方向输入——Landmarks 必须与 Points of Interest 中的地标一致Sight Lines 服务于空间可读性Color Palette 不与相邻区域冲突。这与 level-designer 的职权边界 吻合视觉艺术风格不属于 level-designer它只负责在既定视觉方向内做空间设计。八、Collectibles and Secrets收集品与秘密设计列含义Item物品Location位置Visibility可见性显眼/半隐藏/完全隐藏Hint提示方式Required For用途成就、装备、lore、支线任务设计原则源自 level-designer Key Responsibilities #5奖励探索但不惩罚关键路径玩家——隐藏内容绝不能成为推进主线的障碍。这要求收集品只放在 Optional Paths 可达的位置Visibility 与 Optional Paths 表的 Discovery Hint 字段互相印证有隐藏物的地方要有可察觉的线索Required For 若引用成就/进度系统应与 systems-designer 或对应 GDD 的定义一致。九、Technical Notes技术约束与交付检查9.1 四个技术字段字段含义服务对象Estimated Object Count预估对象/资产数量性能与资产预算performance-analyst、technical-artistStreaming Zones流式加载切分点引擎层engine-programmer与 Godot/Unity/Unreal 引擎参考文档对接Performance Concerns已知的重负载区域性能分析与优化对应/perf-profile技能Required Systems本关启用的游戏系统系统依赖声明供实现与测试排期9.2 为什么必须显式填写CCGS 的审查哲学是每个关键结论都要有可验证依据见 .claude/rules/design-docs.md验收标准必须可测试、依赖必须双向声明、不得含糊其辞。Technical Notes 就是把设计意图与实现/测试成本挂钩的位置Required Systems相当于设计文档与系统 GDD 之间的双向依赖声明——若本关需要复活点系统对应的系统 GDD 中也应反向提到本关依赖双向性规则Streaming Zones与Performance Concerns为后续/perf-profile、/tech-debt等分析技能提供输入缺失的字段会被审查视为REVISION NEEDED的理由因为 level-designer Gate 审查 要求输出with spatial specifics, not abstract design opinions带空间细节而非抽象设计观点。十、模板驱动的完整工作流从/team-level到交付把本模板放回 CCGS 的流水线中一份 LDD 的完整生命周期是10.1 创作阶段用户运行/team-level [关卡名].claude/skills/team-level/SKILL.mdStep 1narrative-director叙事目的、情感弧、world-builderlore 基础、环境叙事机会、art-director视觉主题、地标目标并行产出 → 对应模板的 Narrative Context 与 Visual Direction 输入Step 2level-designer 基于全部 Step 1 输出设计布局关键路径、可选路径、秘密、节奏曲线、遭遇、兴趣点 → 对应模板的 Layout、Encounters、Pacing Chart 章节同时做相邻区域依赖检查引用的相邻区域若在design/levels/中无对应.md必须标记为 UNRESOLVED 并列出严禁凭空补写Step 3systems-designer 指定敌方构成、掉落表、难度平衡、区域机制 → 对应 Encounters 与 Collectibles 的数值侧Step 4art-director 产出基于最终布局的定点概念灯光、视线、VFX accessibility-specialist 做无障碍审查导航清晰度、色盲安全、认知负荷→ 对应 Visual Direction 与 Technical Notes 的细化BLOCKING 级无障碍问题必须被用户确认才能继续Step 5qa-tester 为关键路径写测试用例、识别边界情况序列破坏、软锁、产出试玩检查清单与验收标准 → 对应 Technical Notes 的 Required Systems 与验收信息编排者将全部输出按本模板格式编译保存为design/levels/[level-name].md并输出摘要区域概览、遭遇数、资产清单、叙事节拍、跨团队依赖与开放问题、无障碍关注项及解决状态。10.2 审查与迭代阶段运行/design-review design/levels/[level-name].md校验完成的 LDDlevel-designer 的 Gate 审查以 APPROVED / REVISION NEEDED 词汇输出结论见 level-designer Agent Test Spec 的 Case 1/3审查不通过时模板字段本身就是问题定位器Case 3 的示例场景第 3 区难度骤升、无可读性线索、附近无检查点能精确对应到 Pacing Chart 的峰、Points of Interest 的引导缺失、Technical Notes 的 Required Systems 缺失设计批准后运行/dev-story进入实现或运行/qa-plan生成本关 QA 计划。10.3 跨层级一致性保障LDD 不是孤立文档它与 CCGS 的多个模板共享同一套数值语言与职责边界关联资产关系difficulty-curve.md关卡 Difficulty、Pacing Chart 的 1-10 量表与全局难度曲线对齐峰谷设计遵循同一心流理论game-design-document.md本关 Required Systems 引用的系统机制其详细规格在对应 GDD 中level-designer agent本模板是 agent 的 Level Document Standard 的表格化实现也是其审查标的team-level skill本模板是/team-level的编译输出格式与协作接口coordination-rules.md冲突升级如遭遇密度 vs 节奏遵循共享父节点裁决规则world-builder agentLore Discoveries 必须引用已确认的 lore保持 Canon Level 一致design-docs 规则全文须遵守无空话、依赖双向、验收可测的写作纪律结语把关卡设计变成可验证的工程CCGS 的 level-design-document 模板的精髓在于它把关卡设计这一传统上高度依赖个人审美的活动翻译成了一套字段化、可交叉引用、可机器校验的工程契约Quick Reference 提供索引Narrative Context 锚定叙事Layout 定义空间Encounters 量化挑战Pacing Chart 表达节奏Audio/Visual 绑定视听协同Collectibles 管理探索回报Technical Notes 挂接实现与性能。当你用这套模板写下一份关卡文档时你交付的不仅是这个关卡长什么样更是它为什么这样设计、它依赖什么、它如何被测试、它何时算完成——这正是它能够被 49 个 Agent 协作生产、被 Gate 严格审查、并被下游实现与 QA 无缝接管的根本原因。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考