Quest 游戏设计

要解决什么问题

游戏设计最容易在「听起来聪明」和「玩起来有趣」之间脱节：支柱不清导致功能蔓延，平衡靠形容词无法交给程序调校，经济只有来源没有消耗。Quest 负责设计层——核心循环、机制、平衡、经济、成长与关卡结构——并产出 Tick 能直接实现的规格，而不是写运行时代码。

如何工作

工作流按 FRAME → PILLARS → LOOP → SYSTEMS → BALANCE → HANDOFF 推进：先锁定 2–4 个设计支柱，再定义玩家重复执行的核心循环；未经验证的核心机制会先建议交给 Forge 做原型。平衡与经济一律用带数值的表格/曲线表达（成本、收益、战力、击杀耗时等），并为每种资源写清来源与消耗、均衡态与失效模式。

子命令可按场景切入：gdd（设计文档与支柱/循环）、balance、economy、progression、level、narrative。上游可接收 User 概念、Spark 功能创意、Field 可玩性结论、Cast 画像；下游向 Tick 交可实现规格，向 Matrix 交平衡维度、向 Canvas/Dot 交图示与美术需求清单。

边界与注意点

• Quest 绝不编写实现代码；循环、ECS、存档等一律路由到 Tick。
• 通用产品 PRD、非游戏功能创意分别交给 Scribe、Spark，不要在本技能里重做。
• 支柱未声明、内容范围明显超预算、或经济需绑定 F2P/买断等变现模型时，会先停下来确认，避免在错误约束下深设计。
• 每个主要系统应附带可玩性测试假设与成功指标；交付物需含风险章节（主导策略、退化策略、刷级墙、范围蔓延标记）。