如何在虚拟宠物游戏循环中分离空闲状态与交互状态

将它们视为行为模式，而不一定是非要放在不同的场景或独立的循环中。在**空闲（idle）模式下，宠物执行其常规事务：选择一个微小的环境动作、推进计时器，或播放次要动画。在交互（interactive）**模式下，游戏正在处理蓄意操作，例如点击、拖动或选定的命令。宠物在交互期间仍可能播放动画；两者的区别在于哪个系统有权做出决策并更改游戏状态。

首先列出玩家可以执行的操作以及宠物可以执行的自主行为的简短清单。标出每一项可能会更改哪些状态变量。例如，环境眨眼动作可能只会影响表现呈现，而选定的玩耍动作可能会改变宠物当前的活动并启动计时器。这种简单的归属关系映射有助于在代码量膨胀之前发现潜在冲突。

引擎的帧回调应该负责协调工作，而不是容纳所有的宠物规则。一个实用的执行顺序是：收集输入、应用有效命令、推进模拟，然后渲染最新状态。将输入收集与模拟分离开来，这样点击就不会被意外当作计时器计时（tick），同时保持渲染过程不发生游戏逻辑变更。《游戏编程模式》（Game Programming Patterns）将这种分离描述为在重复循环中处理输入、更新游戏和渲染；当模拟需要稳定的时间间隔时，固定步长（fixed-step）更新非常有用。游戏循环，《游戏编程模式》

对于 Web 游戏，requestAnimationFrame 会在重绘之前调度工作，并提供可用于测量流逝时间的时间戳。浏览器通常会在标签页处于隐藏状态时暂停这些回调，因此不要假设在游戏后台运行时它们仍能作为可靠的时钟继续走动。Window.requestAnimationFrame(), MDN

将原始输入转换为小型命令，例如 start_play、stop_play 或 pet_tap。命令处理程序会检查该操作对当前模式是否有效，对共享模型进行一次更新，并发出生成的任何展示提示。这样可以避免将操作逻辑同时散落在按钮回调、动画回调和空闲例程中。

例如，如果玩家在宠物已经在玩耍时点击，应明确定义其结果：忽略点击、选择其他活动，或停止该活动。避免允许空闲选择器和点击处理程序在同一次更新中同时分配新活动。在具有事件传播机制的引擎中，应在合适的阶段处理游戏玩法输入并遵从 UI 的事件消耗；Godot 的 Node 文档指出，当 GUI 控件需要优先权时，未处理的输入（unhandled input）通常更适合用于游戏玩法。Node 类，Godot 文档

对于应在可见会话期间持续推进的行为，应累积流逝的模拟时间，并在达到其时间间隔时触发空闲决策。不要计算帧数：帧率是波动的。在 Godot 中，_process(delta) 接收自上一空闲帧以来的时间，而 _physics_process(delta) 遵循物理时钟循环；文档还指出，在某些情况下，累积的 delta 可能会偏离真实世界的秒数。Node 类，Godot 文档

根据行为选择时钟。纯视觉动作通常可以使用帧流逝时间。碰撞相关的运动属于引擎的物理更新。宠物的“每隔几秒选择一个环境动作”计时器可以使用模拟计时器，但要决定在长帧或暂停后会发生什么：限制最大流逝时间量、只执行一次决策，或者以有限的步长进行追赶。无限制的追赶可能导致游戏恢复时宠物瞬间跳过许多状态。

在添加更多状态之前，先写下一个简短的转换表。例如，idle → playing 开始玩家选择的活动；playing → idle 在活动结束或玩家取消时发生；idle → resting 可以由自主例程选择。在一个地方集中定义进入和退出效果，例如启动或清除计时器以及选择相关动画。不要仅将动画播放完成作为游戏模式已经改变的依据：视觉播放可能会被中断或跳过。

转换函数应该验证当前模式、更新模型并返回渲染器可以显示的结果。这样可以将“宠物正在做什么”与“如何绘制该动作”区分开来。这也为测试提供了明确的目标：提交命令、检查生成的模式，然后验证空闲例程不再将其覆盖。

有两种常见的策略，具体采用哪一种取决于游戏设计。仅针对单次会话的宠物可以在挂起时停止模拟，并在恢复时从先前的状态继续。如果游戏旨在让计时器在关闭时继续推进，则必须记录一个时间参考点，并在返回时对流逝的时间进行对齐补偿。应将其视为独立的恢复计算，而不是尝试在后台运行帧循环；对于隐藏的标签页，浏览器的动画回调可能会被暂停。Window.requestAnimationFrame(), MDN

对于简单的宠物，只需对齐那些确实应该推进的数值（可能只有一个活动计时器），并为追赶设置一个合理的上限。然后测试在短暂和漫长的时间间隔后关闭并重新打开游戏。时钟的选择、挂起行为以及追赶上限属于设计决策；引擎的帧回调不会替你做出决定。

使用一些可重复的场景来测试循环：让游戏在若干个时间间隔内保持空闲；在刚好要进行空闲决策之前发出命令；按住或重复输入；暂停并恢复；以及在动画仍在播放时触发新操作。验证每个命令是否仅更改模型一次、空闲逻辑是否不会替换玩家选择的状态，以及流逝时间的行为是否与所选的暂停策略相匹配。

如果使用固定更新来进行模拟，请记住在渲染帧之间它可能会运行零次、一次或多次。Unity 在其针对 FixedUpdate 的文档中记录了这一行为，并建议将其用于物理计算；输入和视觉更新具有不同的时序考量。FixedUpdate(), Unity 文档 Unity 的 Input System 还会将设备事件排入队列，并根据其配置的更新模式对其进行处理，因此请使输入处理与消费这些命令的循环保持一致。输入事件队列，Unity Input System

保持架构精简：一个共享宠物模型、一条“输入到命令”路径、一个空闲行为更新、一个显式转换函数，以及一个读取该模型的渲染器。仅在对时序敏感的行为需要时才添加固定模拟步长；不要让每个动画或环境选择都依赖物理时钟节拍。当出现错误时，检查是谁最后更改了模式以及是哪个时钟推进了它。这使得每次更新都有明确的职责分工，并且随着宠物动作的增多，空闲和交互行为仍然能够保持可预测。

• 游戏循环，《游戏编程模式》
• Window.requestAnimationFrame(), MDN
• Node 类，Godot 文档
• FixedUpdate(), Unity 文档
• 输入事件队列，Unity Input System