Phaser 烹饪节奏小游戏：火候窗口、步骤队列和评分反馈要有手感

为什么这个系统不能临时拼

玩家在餐车关卡里切菜、翻炒、收汁、装盘，每一步都有短暂最佳窗口；做得好会得到香气特效，做晚了会糊锅。

真实项目里，最容易出问题的不是第一版能不能跑，而是后续能不能解释、能不能复现、能不能被内容团队稳定使用。如果每个按钮自己倒计时，步骤之间会互相抢状态，暂停、倍速、失焦和教学都会让火候窗口漂移。 这类系统一旦和奖励、存档、关卡进度或玩家输入有关，就不能只写在某个 Scene 的按钮回调里。更稳的做法是把规则层、表现层和调试层拆开：规则层只处理数据和状态，表现层负责 Phaser 动画、粒子、音效和 UI，调试层负责把中间状态暴露出来。

本文按一个可上线的小型系统来拆。它不追求一次覆盖所有商业项目的复杂度，而是把边界先立住：哪些数据进入模型，哪些事件触发表现，哪些失败可以恢复，哪些日志能帮助线上排查。只要这些边界清楚，后续加活动、加难度、加皮肤或加服务端同步，都不会把系统推倒重写。

核心架构

flowchart TD
  A["输入：玩家在餐车关卡里切菜、翻炒、收汁、装盘，每一步都有短暂最佳窗口；做得好会得到香气特效，做晚了会糊锅。"] --> B["RecipeRunner"]
  B --> C["TimingWindow"]
  C --> D["InputJudge"]
  D --> E["ScoreModel"]
  E --> F["KitchenView"]
  F --> G["Phaser 表现层：动画、UI、音效"]
  G --> H["调试与日志：复现、校验、上线观察"]

这个结构的重点是单向流动。玩法对象向系统提交意图或事件，核心系统计算结果，Phaser 层根据结果播放反馈。不要让 Sprite 的动画进度、按钮显示状态或粒子是否存在反过来决定规则。只要规则是纯数据，就能测试、回放、存档和迁移。

步骤队列是菜谱的骨架

菜谱不应是一串按钮回调，而是一组可执行步骤：准备、等待窗口、接收输入、结算、进入下一步。每一步都带有目标时间、容错范围、可用输入和失败策略。这样同一套菜谱可以用于剧情、挑战和每日任务。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

火候窗口要可解释

Perfect、Good、Late、Miss 的窗口应该写在配置里，并按菜品难度调整。新手菜给更宽窗口，挑战菜给更窄窗口。UI 上的指针、颜色和音效必须和窗口一致，否则玩家会觉得判定不准。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

暂停和失焦必须冻结厨房时间

浏览器切后台、打开设置、广告弹窗都会打断小游戏。KitchenClock 需要统一暂停，恢复后继续原窗口。不要用 Date.now 直接算火候，否则玩家切出去回来会整锅烧糊。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

评分不仅是最终分

每一步都可以记录 rating、连击、失误类型和补救动作。结算时展示“翻炒过晚”“装盘完美”，比只给 82 分更能指导玩家。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

失败恢复决定休闲感

烹饪小游戏通常不应该一次失误就失败。糊锅可以扣分并进入补救步骤，切菜失败可以产生更少食材，装盘失败影响小费。失败也要推进流程，避免玩家卡在单步。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

厨房 UI 要减少误触

移动端按钮要大，步骤高亮要清楚，关键输入不能放在屏幕边缘。若支持拖拽食材，拖拽轨迹和点击按钮不要共用同一判定区域。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

TypeScript 实现骨架

interface CookStep { id: string; startMs: number; perfectMs: number; goodMs: number; failMs: number }
type CookRating = "perfect" | "good" | "late" | "miss";

export function judgeStepInput(step: CookStep, elapsedMs: number): CookRating {
  const delta = Math.abs(elapsedMs - step.startMs);
  if (delta <= step.perfectMs) return "perfect";
  if (delta <= step.goodMs) return "good";
  if (elapsedMs <= step.failMs) return "late";
  return "miss";
}

这段代码只展示核心判断，不直接创建 Phaser 对象。实际项目里，你可以在 Scene 中把输入、时间、对象状态整理成快照，再交给这个函数或类。返回值用于驱动动画、音效和 UI，而不是让 UI 自己猜发生了什么。这样写的好处是很直接的：你可以为它写单元测试，也可以在调试面板里把输入和输出打印出来。

数据结构和配置边界

配置要尽量表达设计意图，而不是暴露太多底层实现细节。内容团队更关心“这个节点需要什么条件”“这个阶段持续多久”“这个奖励来自哪里”，不应该被迫理解 Phaser 的坐标、Tween 名称或对象池实现。底层字段可以存在，但要由工具生成或校验。

每份配置都应该有版本。只要系统会进入存档、奖励、关卡成绩或玩家长期进度，就不能假设配置永远不变。版本号能帮助你判断旧数据如何迁移，日志如何解释，客服如何复现。配置更新后，旧玩家的状态要么安全迁移，要么明确补偿或重置，不能静默损坏。

UI 和玩家反馈

玩家不需要看到所有内部数字，但必须理解关键结果。按钮为什么灰掉，失败为什么发生，奖励为什么没有到账，系统为什么选择了这个目标，这些都要有可见反馈。反馈可以很轻：一行原因、一个高亮、一个短音效、一个图标状态。比起华丽动画，可信的解释更能减少挫败。

移动端尤其要注意误触和信息密度。交互区域要足够大，状态变化不要只靠颜色，关键提示不要被刘海屏、虚拟摇杆或系统手势挡住。桌面端则要考虑键盘、鼠标、手柄和窗口失焦。Phaser 能同时覆盖很多平台，系统设计不能只按开发机体验来定。

调试工具

这个系统至少需要一个开发模式面板，显示当前状态、最近事件、配置版本和失败原因。调试面板不是奢侈品，而是内容生产工具。没有它，设计师只能通过反复试玩猜测系统为什么不工作；有了它，问题会变成可讨论的事实。

日志也要分层。开发环境可以详细记录每一步，正式环境只记录关键事件、异常和玩家失败前后的上下文。日志字段要稳定，不要只输出一段中文字符串。结构化日志能被脚本分析，也能帮助客服和运营复现问题。

上线前检查清单

• 菜谱步骤可配置
• 所有计时使用 KitchenClock
• 暂停恢复不改变火候
• 评分有步骤级原因
• 失败有补救路径
• 调试面板能跳到任意步骤
• 配置有版本，旧数据有迁移或回退策略
• UI 能解释失败原因和当前状态
• 关键操作有幂等保护，重复点击不会造成重复收益或重复扣费
• 低端设备有降级方案，不改变核心规则
• 调试面板能显示最近事件和当前计算结果

常见坑

第一，把表现当规则。动画没播完就不结算、粒子存在就算命中、按钮亮着就允许领奖，这些都会在暂停、跳过、切后台或弱网时出问题。

第二，只有成功路径。真实玩家会取消、重试、断网、切场景、连点、误触、读旧存档。每一个关键状态都要有失败恢复和安全回退。

第三，配置无校验。内容越多，拼写错误、引用缺失、数值越界越常见。启动时或导出时做校验，能拦住大量线上事故。

第四，缺少版本意识。只要系统会被存档、回放、排行榜、奖励或活动引用，就必须知道当时使用的是哪一版配置。

收束

这个 Phaser 烹饪节奏小游戏：火候窗口、步骤队列和评分反馈要有手感，真正难点不在于 Phaser API 本身，而在于规则能否被长期维护。把核心计算从 Scene 中拿出来，把配置、状态、表现和日志分清楚，系统就会从“能演示”变成“能上线”。这也是 Phaser 做中小型 Web 游戏时最值得坚持的工程习惯：用轻量工具快速表现，用清晰模型守住规则。

菜谱内容生产规范

烹饪小游戏如果要长期扩展，菜谱必须有制作规范。每道菜至少定义步骤数量、总时长、每一步最佳窗口、失败分支、评分权重和展示资源。不要让某道菜的“翻炒”按钮在左边，另一道菜的“翻炒”按钮在右边，除非这是明确的难度设计。玩家学习的是操作语言，内容变化不能破坏语言。

菜谱还应有难度标签。新手菜窗口宽、步骤少、失败可补救；挑战菜窗口窄、步骤多、允许多任务并行。每日任务或活动调用菜谱时，根据玩家等级选择难度池，而不是随机抽到超出玩家能力的菜。配置导出时可以检查总时长是否过长、窗口是否小于 UI 动画可读范围、是否存在没有失败反馈的步骤。

多订单和压力管理

餐车或餐厅玩法经常会从单道菜扩展到多订单并行。此时不要让每个订单独立跑一个倒计时 UI。更好的方式是 KitchenQueue 管理所有订单，RecipeRunner 负责单个订单。玩家在多个锅之间切换时，系统显示每个订单的关键危险点，例如即将糊锅、等待装盘、可加料。压力来自取舍，而不是信息混乱。

多订单下，失败也要可解释。玩家漏掉一锅汤，是因为它被 UI 遮住，还是因为提示不够明显？日志记录每个订单进入危险窗口的时间和玩家最后一次操作，能帮助调节节奏。烹饪玩法很依赖节奏曲线，数据比主观试玩更能发现过载点。

线上活动和难度分层

烹饪小游戏常被包装成节日活动，例如春节包饺子、夏日冰饮、万圣节糖果。活动菜谱可以换美术和奖励，但不要改掉基础交互语言。玩家已经学会“等待火候窗口再点击”，活动应在这个基础上增加变化，而不是突然要求完全不同的输入方式。活动难度可以通过步骤数量、窗口宽度、同时订单数量和失败扣分调整。

如果活动有排行榜，随机因素必须受控。菜谱顺序、顾客耐心、特殊事件最好由固定种子生成。否则玩家成绩无法比较。排行榜模式也要禁用过强的动态难度，避免某些玩家因为失败多反而获得更宽窗口。休闲模式可以照顾玩家，竞技模式要保持公平。

测试矩阵

QA 至少要覆盖：正常完成、每一步过早、每一步过晚、暂停后恢复、切后台、连续点击、低帧率、跳过教程、活动奖励领取、背包满、弱网结算失败。每个场景都要确认火候时间不漂移、评分原因正确、奖励不会重复发放。烹饪小游戏看起来轻，但它经常连接活动经济，测试不能只看动画是否好看。