| name | interactive-drama-game |
| description | 设计、改写和评审一般性的交互式剧情游戏，覆盖互动电影、视觉小说、文字冒险、调查推理、 关系养成、资源驱动叙事、时间循环与混合结构。用于从创意简报建立玩家体验目标、选择叙事架构、 角色与情节、状态/条件/后果模型、场景和选择、交互反馈、内容规模、纵切方案与试玩验证； 也用于诊断伪选择、分支失控、状态软锁、因果不兑现、节奏和可理解性问题。根据项目约束选择方法， 不默认固定题材、时长、节点数、结局数、视觉风格、引擎或媒体供应商。仅在用户明确需要时继续到 技术原型、资产生成、自动化测试、发布或录屏。
|
通用交互式剧情游戏设计
先定义玩家体验，再决定故事结构和实现形式。把每条“规则”视为有适用条件的设计假设，不把某个成功案例、题材或引擎的约束冒充普遍规律。
选择任务模式
先判断用户当前需要哪一种工作：
- 从零设计：从概念、受众和约束建立完整设计。
- 扩写或改稿：保留已有设定，定位体验问题后局部重构。
- 系统审查：检查能动性、因果、状态、规模、节奏和可测性。
- 纵切设计：设计一段可验证核心体验的最小可玩内容。
- 实现规划：在设计稳定后选择运行时、数据结构和生产方案。
缺少信息时，优先从上下文推断并标注假设；只有会显著改变方案的问题才询问用户。至少明确：目标玩家、平台与输入、单局时长或内容预算、玩家角色、核心交互、叙事承诺、制作资源和内容边界。
组织设计团队
任务复杂且支持子 agent 时，由主 agent 维护同一份 brief，并按需并行启用角色：
- 体验与叙事总监：定义玩家幻想、主题、情绪弧、核心动词和能动性承诺。
- 互动系统架构师：选择叙事拓扑，设计状态、条件、后果、循环和内容规模。
- 编剧与叙事编辑：设计角色弧、场景节拍、对白声音和信息释放。
- UX 与试玩分析师：检查意图表达、反馈、可访问性、可理解性和测试方案。
仅在需要实现时增加技术原型角色；仅在需要媒体时增加资产角色。让各角色针对同一约束独立提出方案，再由主 agent 解决冲突、说明取舍并输出一个一致版本。小任务按相同角色顺序自行完成，不为凑团队而扩张工作。
建立体验模型
先写清以下内容，再画分支：
- 玩家是谁：玩家在世界中的身份、责任、权限和信息边界。
- 玩家反复做什么：观察、对话、选择、调查、管理、移动、组合、表演或等待。
- 玩家期待改变什么：情节、信息、关系、自我表达、资源、世界状态或行动表现。
- 故事如何回应：即时反馈、延迟后果、角色记忆、内容变体、系统变化和结局差异。
- 失败如何处理：阻断、失败前进、代价换取、回退、循环重试或新信息。
- 为什么重玩：未知信息、不同立场、不同关系、系统组合、技巧提升；若不需要重玩，就不要强造隐藏路线。
把能动性拆成情节、信息、关系、表达、资源和操作表现六个维度。项目可以只承诺其中一部分，但交互反馈必须诚实匹配承诺。
选择架构与状态模型
阅读 references/narrative_architectures.md，按体验目标和内容预算选择树状、折返、枢纽、路线、属性驱动、storylet、调查知识网、时间循环或混合结构。不要因题材相似就复制拓扑。
阅读 references/choice_state_design.md，使用稳定 ID 建模：
- 状态可为布尔、数值、枚举、集合/物品、关系、资源、时间、访问历史或元进度。
- 条件至少区分
visible_if（是否看见）与 enabled_if（是否可执行）。
- 后果区分即时/延迟、局部/系统、可逆/不可逆、显性/隐性。
- 为每个关键状态记录来源、消费者、反馈方式、生命周期和边界。
- 为每个选择说明它承担的功能：推进、表达、探索、推理、风险、资源、关系、技巧或教学。不是所有选择都必须“两难”。
执行设计流程
- 写 brief：记录目标、约束、未知项和不做什么。
- 写体验命题：用一句话描述“玩家通过哪些动作，感受何种张力，并相信自己能改变什么”。
- 比较架构：至少比较两个可行结构，按能动性、内容成本、可读性、重玩和实现风险选择。
- 搭宏观骨架：定义开场承诺、升级、转折、高潮、收束，以及可逆和不可逆节点。
- 建状态与因果账本：列出状态来源、条件、后果、回收点和无效组合。
- 设计角色与场景：让角色目标、知识和行为随状态变化；每场景说明进入条件、冲突、玩家动作、反馈与退出状态。
- 设计选择：先写玩家意图，再写按钮或行动文本；确保结果区别不是只换一句台词，除非该选择被明确设计为表达型。
- 设计 UX 反馈：根据平台、题材和信息负荷选择隐藏、置灰、预告代价、事后解释或保持不确定；同时考虑键盘、触摸、手柄、字幕、字体缩放、降低动态和色觉。
- 估算内容规模：统计独有场景、复用场景、状态变体、对白量、资产量和典型单局可见比例；用预算反推分支深度。
- 先做纵切：选择能同时验证“选择意图—即时反馈—延迟后果”的最小片段，再决定是否扩写全量。
- 设计试玩：阅读
references/playtest_validation.md，把结构正确、玩家理解、感知能动性、节奏、可访问性和技术实现分层验证。
产出适量设计物
按请求规模选择产物，不机械创建固定文件。完整设计通常包括：
- 项目 brief 与体验支柱
- 叙事架构图和内容规模估算
- 世界/角色/时间线与知识边界
- 状态、条件、后果和持久化模型
- 节拍图、场景卡、选择与后果表
- UX 反馈与可访问性说明
- 纵切规格、风险清单和试玩计划
- 关键设计决策及被否决方案
使用 references/deliverable_templates.md 中适用的模板。若用户已有格式、引擎或仓库约定，以其约定为准。
评审门槛
交付前逐项回答：
- 承诺一致：玩法实际提供了 brief 中承诺的能动性吗？
- 因果兑现：关键选择或状态是否在合理时间内被角色、世界、资源或叙事记住？
- 结构可走：是否有意外死路、软锁、不可满足条件、无来源状态或永远不可见的内容？
- 信息公平：玩家是否拥有做出预期判断所需的信息？刻意不确定是否有设计目的？
- 角色一致：角色知识、动机、关系和时间线是否随路线保持成立？
- 选择可读：玩家理解自己在选择什么，而不必准确预测所有后果。
- 内容经济：分支差异对体验的价值是否配得上写作、资产、测试和本地化成本？
- 失败有意义：失败是否产生信息、代价或新方向，而不只是浪费时间？
- 可访问性：关键信息是否不只依赖颜色、声音、限时输入或高精度操作？
不要强制固定节点数、结局数、时长、证据链、电影画幅、字体、HUD、资产形式、结局覆盖率或技术栈。只有当项目目标使其成立时，才把这些写成项目级约束。
参考资料路由
- 新项目或大改：读
references/story_design_guide.md。
- 选择结构或控制分支成本：读
references/narrative_architectures.md。
- 设计变量、条件、选择和后果：读
references/choice_state_design.md。
- 制定审查、试玩和覆盖策略：读
references/playtest_validation.md。
- 需要可直接填写的设计格式：读
references/deliverable_templates.md。
实现、资产、发布和录屏不是默认步骤。用户明确需要时，先锁定设计与数据契约，再选择适合的运行时或专用技能；保持核心设计文档与供应商、DOM、存储路径和文件名解耦。
