从后端思维到游戏循环
后端通常在请求到来时工作；游戏即使没有点击，也会持续更新画面、推进动画或模拟运动。这个差异决定了代码组织方式。
把熟悉的经验放到正确位置
| 后端经验 | 游戏中能借用的部分 | 类比的边界 |
|---|---|---|
| 请求处理器 | 点击事件、按钮回调 | 游戏并不随回调结束而停止 |
| 领域状态机 | 准备、游玩、暂停、结算 | 画面状态还可能与规则状态分离 |
| DTO 与配置 | 关卡配置、道具定义 | Node、SpriteFrame 等引擎对象不能直接当 DTO 存盘 |
| 模块职责 | 规则、表现、平台调用分开 | Component 不是每种后端服务都要对应一个 |
| 幂等与事务 | 结算、奖励、支付回调 | 客户端状态可以被修改，关键事务仍在服务端 |
| 性能分析 | 先测量再优化 | CPU、GPU、内存、加载时间要分别看 |
一帧里发生什么
这是简化的概念顺序，不是引擎全部子系统的严格调度表。业务脚本经常用 update(dt) 参与更新，其中 dt 是上一帧到当前帧的时间间隔，单位秒。
例如移动速度是每秒 120 个场景单位，增量应是 120 * dt，而不是每帧固定移动 2 个单位。后者会让速度跟帧率绑定。生命周期会展示完整脚本。
不把所有工作放进 update
积分只在加分时更新；按钮只在触发时处理；网络只在明确的同步节点调用。每帧重新查找节点、解析存档或请求服务端，都会浪费资源，甚至放大故障。
一个实用的拆分是：
- 规则状态：当前分数、关卡、是否已经结算。
- 表现：读取规则结果，修改 Label、播放动画。
- 外部交互：存档、登录、广告、请求服务端。
初期可以放在一个清楚的小脚本里。等出现独立变化的职责，再拆模块，不必先建立复杂框架。
时间规则要先决定
倒计时有两种常见语义：只累计前台游玩时间，或按现实世界截止时间结算。remaining -= dt 接近前一种，但应用暂停、首帧大间隔等情况仍需处理；现实时间规则需要绝对截止时间，关键活动还要以服务端时间为准。
本指南的入门案例采用显式开始、结束与重开，不承诺后台计时策略。微信接入时再补齐前后台切换规则，避免把引擎示例误当成上线规则。
检查你是否理解了
试着解释：玩家一分钟没点屏幕，哪些系统还在工作？如果帧率减半，角色速度会不会变？如果客户端把积分改成一百万，服务端应不应该相信？
给 AI 的约束：“请区分事件触发的工作与每帧工作；移动使用 dt；关键奖励由服务端校验；不要引入暂时用不到的事件总线。”
依据：生命周期回调。