designing-mini-games

为任意输入方案设计或审查紧凑型游戏。本技能负责规则、控制、计分、危险、难度意图和引擎无关的不变量，而非渲染、碰撞代码、音频实现或数值调优。

除非平衡性结论需要阈值，否则常量应保持定性。根据预期的动作循环，将帧数交由实现阶段确定。如果尚无确定性生成机制，请说明种子／预检不变量，并标明首次案例检查需在实现时验证。

核心规则

• 用一句话表达核心体验。先确定按钮数量以及每个阶段／按钮的作用，再设计次要系统；遵守简报规定的数量，并记录每个动作的物理按键绑定，避免不同画面擅自设定互相冲突的按键。
• 游戏结束条件必须唯一且一目了然，并由危险或世界状态崩溃引发——绝不能因为“没有按下”而惩罚玩家。
• 让所有单调策略都明显逊于熟练操作：闲置和狂按始终如此；单按钮游戏中的仅按住；多按钮游戏中的单键狂按和所有按键全按住。
• 根据游戏内的原因计分（精准度、擦弹、连锁、路线、压力结算），绝不根据原始输入事实计分。只有当生存时间体现熟练度时才将其作为计分项，并说明什么熟练模式能将其与单调玩法区分开来。
• 只有在引入新的玩家决策时才添加状态。每个重要变量都需要触发条件、游戏内反馈（绝不能只有 HUD 数值）和决策目的；否则就移除它。如果仅凭几何或物理特性就能产生决策，则可以采用零状态设计——说明原因。
• 为安全／强化输入搭配可读的代价，例如失去分数、资源消耗、暴露、命中框、速度、压力或恢复时间。
• 说明哪些量会随难度缩放，以及原因。平滑移动／生成压力默认按 sqrt(difficulty) 缩放；仅在刻意提升强度时才采用更陡峭的缩放。
• 对每个影响平衡的单调性结论，至少给出一条可测试、与引擎无关的实现不变量。

单按钮专属规则：

• 仅允许一个二元输入：按下、按住、松开——不得使用第二个按键、组合键或滑动操作。
• 明确说明未使用的阶段为何无需使用；绝不可为了填满表格而添加无意义动作。

设计流程

1. **关联：**说明最先浮现的画面／感受。对于相互矛盾的种子（例如 on_pressed:jump 加上 on_pressed:shoot），请阅读参考指南 §7，并将矛盾视为张力；不要舍弃其中一方。
2. **偏离：**记录第一个显而易见的机制，将其排除，然后探索相反机制、否定机制或极端机制。
3. **确定：**说明瞬时核心体验，然后确定按钮数量、按键绑定和各阶段／按钮的作用。
4. **强化：**定义决策状态、触发条件、游戏内反馈以及安全／冒险之间的权衡。
5. **拒绝单调：**说明每种适用的单调策略为何会落败，以及未使用某阶段时，剩余输入为何仍能体现技巧。
6. **明确计分机制：**定义有因果关系的计分事件以及有依据的难度缩放。
7. **概述不变量：**说明每项高风险结论背后的实现规则；使用 implementing-gameplay-invariants 展开脉冲、护盾、蓄力、连击和重复计分窗口。
8. **验证：**执行参考指南 §9。如果实现暴露出涌现行为，请记录该行为，并明确保留为设计修订或予以否决。

将种子视为步骤 1–2 的灵感。从步骤 3 开始，不要受其束缚。完成后的设计不再提及原始标签也没问题。

对于新设计，请提交：名称／slug、种子、核心机制、状态／权衡、对象规格、设计原则分析、新颖性依据、相似性检查、因果计分、难度意图、控制／按键绑定以及实现不变量。请参考参考指南的附录 A，了解版式示例。

参考资料

• references/mini-game-design-guide.md — 详细原则、输入/移动表格、矛盾处理、检查项、输出格式和 SCAMPER 提示词。
• implementing-gameplay-invariants — 将有风险的平衡性主张转化为代码级检查。
• maximizing-game-feel — 在规则/平衡性稳定后，或润色会影响玩法时使用。