打钩

要解决什么问题

很多游戏在原型阶段能跑，但一旦加上物理、存档或联机，就会出现「帧率一变逻辑就飘」「重放对不上」「卡顿后物理爆炸」这类问题。根因往往是：把渲染帧和游戏模拟绑在一起，或在需要确定性时仍使用未播种的 RNG、无序的系统更新。

打钩（Tick）面向运行时架构与系统实现：在固定时间步上跑模拟，用插值做渲染；把游戏逻辑从具体引擎里拆出来，便于无头测试与移植。

核心能力与工作方式

技能按 FRAME → DESIGN → IMPLEMENT → INTEGRATE → VERIFY 推进，并在动手前批量确认关键分叉：

• 游戏循环：固定/可变时间步、delta time 钳位、累加器追赶上限，避免死亡螺旋
• 实体架构：按实体规模在 ECS（稀疏集/原型）与 OOP/组件对象之间选型，而不是默认上 ECS
• 游戏状态：场景/屏幕堆栈（暂停覆盖、返回），与玩家 FSM 区分；复杂状态机可对接 Weave
• 物理与碰撞：宽相 + 窄相；物理步进落在 simulate() 的固定步内
• 存档：模式带 version 与向前迁移；序列化模拟状态，而非引擎渲染对象
• 联机基础：先选权威模型（客户端-服务器 / 确定性锁步 / 回滚），再写同步——锁步与回滚要求确定性核心

交付物会明确写出时间步结构（代码或表）、系统更新顺序、确定性声明与帧预算说明；深度帧分析交给 Bolt，确定性/系统测试交给 Radar，资产挂钩交给 Dot。

适用边界

• GDD、数值平衡、经济曲线属于 Quest：Tick 只实现设计给出的系统，不重新「调平衡」
• 一次性小改循环片段可当普通编辑；需要架构级设计与多系统落地时再调用本技能
• 非游戏业务 API、一般 SaaS 逻辑应路由到 Builder；像素/精灵生产交给 Dot