前面把「怎么让游戏跑起来、怎么做得好看」都铺得差不多了，今天补一块最容易被忽略、却最影响「第一印象」的底层体验：顺滑。玩家在你 Steam 商店页看完预告片、下载、进游戏，第一次移动角色的那 10 秒里，如果画面「一顿一顿地往前走」，他心里的分数已经掉了一半。而这种抖动，往往不是帧率不够，是物理 tick 和渲染帧在打架——物理插值就是来调停这场架的。

今日速览

  • 抖动 ≠ 掉帧：物理以固定频率（默认 60 TPS）跑，渲染以显示器刷新率（60/120/144/165Hz…）跑。两者不是整数倍关系时，同一个物体在两个物理 tick 之间会被「重复渲染同一位置」，宏观上就是周期性一顿。
  • 物理插值核心一句话：在两次物理 tick 之间，按「已经过了多少个 tick 的比例」把物体位置插值补出来，让渲染帧拿到平滑坐标，而不是等下一个 tick。
  • 开法极简：Project Settings > Physics > Common > Physics Interpolation 打钩即可，剩下的功夫全在「把该搬到物理 tick 的逻辑搬过去」。
  • 三条硬规矩：① 位移/AI/输入逻辑搬到 _physics_process；② Tween / Animation / Navigation 这些「间接位移」也要改成物理 tick 模式；③ 传送/重生时调用 reset_physics_interpolation() 防止「拉丝」。
  • 调试神器：调试阶段把 physics_ticks_per_second 临时调到 10，抖动会被放大 6 倍，一眼就能看出问题在哪。

核心学习内容

一、为什么会有「周期性抖动」

游戏里其实有两条独立的时间线：

  1. 物理线：physics_ticks_per_second（默认 60）固定步长推进，所有 _physics_process、碰撞、move_and_slide() 都在这里发生。固定步长是为了让物理稳定、可复现。
  2. 渲染线：_process 和实际绘制，跟着显示器刷新率走，可以是 60 / 120 / 144 帧。

当你把角色位移写在 _process 里、或者物理跑 60 而屏幕跑 144Hz 时，一个物理 tick 之间会渲染出 23 帧。这 23 帧拿到的都是同一个物理坐标，于是画面是「停、停、动、停、停、动」。反过来如果屏幕 60Hz 而机器跑不满，又会跳帧。只要两条线不同步，就有抖动——只不过在高刷屏上特别明显。

物理插值做的事：渲染时不再直接用「上一个物理 tick 的坐标」，而是在「上一次 tick 坐标」和「当前 tick 坐标」之间按时间比例做线性插值。物体于是有了连续的中间位置，抖动消失。

二、开启插值后的三条硬规矩

官方文档讲得很清楚，插值「大部分游戏改几行就能用」，但有几条不能破：

规矩 1：位移和逻辑搬进 _physics_process。 把角色的移动、输入响应、AI 决策都放到 _physics_process。原因很直接：插值依赖「物体只在物理 tick 里改变 transform」这个前提。一旦你在 _process 里（渲染帧）改了 transform，插值计算的前后两个坐标就错了，反而会产生新的抖动——而且可能只在部分玩家机器上出现，很难复现。副作用是好的：高帧率时 AI 逻辑不再每帧跑，CPU 也省了。

规矩 2：间接位移也要走物理 tick。 节点不只被你的脚本移动，还会被 Tween、AnimationPlayer、导航系统移动。凡是「用来移动物体」的这类机制，都要把它们的处理时机设成物理 tick：

  • Tween：tween.set_process_mode(Tween.TWEEN_PROCESS_PHYSICS)
  • AnimationPlayer / AnimationTree：把 callback_mode_process 设为 ANIMATION_CALLBACK_MODE_PROCESS_PHYSICS
  • 别忘了父节点的移动也算——父节点在渲染帧里动，子物体的插值一样会错。所以父节点也必须只在物理 tick 里动。

规矩 3：传送/重生时 reset_physics_interpolation()。 绝大多数时候插值就是你要的，但有一个例外：物体被瞬移（关卡开始摆放、死亡后重生、从对象池取出复用）。这时你要的是「瞬间到位」，不是「从原点滑过去」。做法是设好新 transform 后立刻调用 reset_physics_interpolation()，它会把手里的「上一帧 transform」直接设成等于当前 transform，于是插值出的结果是「不动」。

  • 站立起步（玩家）：先设 transform，再 reset_physics_interpolation()。
  • 带初速度起步（子弹）：设 transform → reset_physics_interpolation() → 再设「一个 tick 之后应该在的位置」，这样子弹第一帧就在飞，不会先愣一下。

三、物理 tick 该设多少？

插值把物理和渲染解耦之后，你**不再被限制成「显示器刷新率的整数倍」**了，可以按游戏需要挑：

低 tick（10–30）中 tick（30–60）高 tick（60+）
CPU 更省复杂场景物理更稳高速物理更准
输入会有一点延迟适合第一人称适合赛车
物理行为偏简单

刚上手建议就用默认 60，等游戏成型再调。调试期间务必试一次 10 TPS：抖动、拉丝、以及「哪些别的系统偷偷跟物理 tick 同步」，都会原形毕露。还有一个细节——2D 里开启「可见碰撞形状」调试时会跟着插值走；3D 里不会，所以 3D 下看到碰撞体和美术错位一点点是正常的，别当成 bug。

🎯 DeepSeek 提示词（可直接复制）

提示词 1 · 让 DeepSeek 帮我把项目改造成「插值安全」的

适用场景：已经写了一些脚本，想开物理插值但怕改漏、改错。

你是 Godot 4 引擎专家。我正在给项目开启物理插值（Project Settings > Physics > Common > Physics Interpolation），需要你帮我做「插值安全检查」。

【输入】下面是若干 GDScript 脚本（可能只贴了片段）：
（把脚本贴在这里）

【任务】逐文件扫描，找出所有会破坏物理插值的写法，并按严重程度列出。

【必须检查的项】
1. 是否在 _process / _input / _unhandled_input 里修改了节点的 position / global_position / transform / rotation；
2. 是否有 Tween 用于移动节点，但没设置 process_mode 为物理；
3. 是否有 AnimationPlayer / AnimationTree 在移动节点，但 callback_mode_process 不是物理模式；
4. 是否有「瞬移/重生/从对象池取出」却没有调用 reset_physics_interpolation()；
5. 是否有父节点在渲染帧里移动（会导致子节点插值出错）。

【输出格式】对每个问题给出：
- 文件 + 大致行号
- 问题类型（上表 1–5 选一）
- 一句话说明为什么会导致抖动
- 修改后的代码片段（保持原逻辑不变，只改时机/补调用）

【约束】
- 只做「时机与调用」层面的修改，不要重写业务逻辑；
- 不确定的地方明确标注「需人工确认」，不要编造 API；
- 最后给出一份「改动清单」，方便我逐条 review。

【使用说明】把脚本粘进【输入】即可。建议先只贴一个脚本，确认 DeepSeek 的改动风格符合你习惯后再批量处理。

提示词 2 · 让 DeepSeek 写一段「可复用」的插值安全工具

适用场景：想一次性把「传送 + 重置插值」封装成通用方法，全项目复用。

你是 Godot 4 专家。请帮我写一个可复用的 GDScript 工具类（Autoload 或 class_name 静态工具），用于安全地「瞬移」节点并处理物理插值。

【需求】
1. 提供一个函数 safe_teleport(node: Node2D, target: Vector2)：
   - 先把 node.global_position 设为 target；
   - 然后调用 node.reset_physics_interpolation()；
   - 加必要的空值/类型判断，避免传错节点崩溃。
2. 再提供一个函数 safe_spawn_with_velocity(node: Node2D, pos: Vector2, velocity: Vector2, delta: float)：
   - 用于子弹/投射物「出场即运动」：设置初始位置、重置插值、再设置「一个物理 tick 之后的位置」；
   - 用一个物理 tick 的时间 delta 计算下一位置。
3. 顶部用注释写清楚：这两个函数在什么场景用、为什么必须按这个顺序调用（顺序错了会「拉丝」）。

【输出格式】
- 先给完整代码（一个 .gd 文件），带中文注释；
- 再给一个 30 字以内的「一句话用法」；
- 最后列 3 条「常见误用」。

【约束】
- 只用 Godot 4 稳定版 API；
- 不要引入第三方插件；
- 代码要能直接存成 .gd 文件运行，不出现伪代码。

【使用说明】推荐存成 autoload 单例，之后凡是「重生敌人 / 重置玩家 / 发射子弹」都调它，省得每次手写 reset 顺序。

提示词 3 · 用 DeepSeek 排查「画面抖动」的通用模板

适用场景：游戏跑起来感觉卡/抖，但帧率显示是满的，不知道从哪查。

你是游戏性能与手感调试专家（熟悉 Godot 4 物理插值）。我要排查「画面周期性抖动」问题，请按下面框架帮我一层层定位。

【症状】（选填，尽量具体）
- 帧率显示：正常 / 波动，大约 ___ FPS
- 屏幕刷新率：___ Hz
- 抖动表现：规律性一顿一顿 / 只在高速移动时 / 只在特定场景
- 是否已开启物理插值：是 / 否

【请按此顺序输出排查清单】
1. 区分「掉帧」和「插值问题」：给出各自的特征和一句话判别方法；
2. 若没开插值：列出开启步骤 + 最可能被忽略的一条硬规矩；
3. 若已开插值：按「_process 里动节点 → Tween/Animation 时机 → 父节点 → 传送未 reset」逐条问诊，每条给「怎么验证」；
4. 给我一个 10 TPS 的复现实验步骤，以及「用 10 TPS 能看到什么」；
5. 最后给一张「症状 → 最可能原因 → 修复动作」的三列对照表。

【约束】不要泛泛而谈「优化性能」，只聚焦「物理 tick / 渲染帧同步」这一条线索；不确定的地方说不确定。

学习心得

联系「用 DeepSeek 从零做一款能上架 Steam 的游戏」这个目标，今天最大的收获是：顺滑度是一个可以「一次性配置」的工程问题，不是玄学手感。

以前我以为画面顿是「电脑不行」，会去加硬件、降画质。其实很多抖动来自一个开关没开、或者把逻辑写错了回调函数。对独立开发者来说，这特别划算——开插值、把位移搬进 _physics_process，可能只花半天，却能让所有玩家的第一印象从「有点糙」变成「挺顺」。

更妙的是，这类改造极其适合交给 DeepSeek 干：它有明确的规则（三条硬规矩）、明确的输入（我的脚本）、明确的输出（改动清单），正是「AI 写代码」最擅长的结构化任务。这也反向提醒我：越是规则清晰的工序，越应该固化成提示词，让 DeepSeek 反复执行。我打算把上面三条提示词存进项目根目录的 docs/prompts/，以后每加一个会移动的系统就过一遍「插值安全检查」。

明日关注

  • 在自己的 Godot 项目里打开 Physics Interpolation，把 physics_ticks_per_second 临时调到 10，录一段屏看看有没有暴露隐藏抖动。
  • 用「提示词 1」让 DeepSeek 审查现有脚本，把 _process 里的位移逻辑迁移到 _physics_process。
  • 给所有「重生/传送」点补上 reset_physics_interpolation()，并顺手检查 Tween 与 AnimationPlayer 的物理回调模式。

本文由自动化学习流水线每日生成，坚持即学即记。