[简化版 GAMES 104] 现代游戏引擎 06：从Tick时序到邮局模型，拆解确定性世界的底层密码

$简化版 GAMES 104$ 现代游戏引擎 06：从Tick时序到邮局模型，拆解确定性世界的底层密码

[✨ 开篇：你有没有想过，游戏里的"分手"为什么不会乱？](#✨ 开篇：你有没有想过，游戏里的"分手"为什么不会乱？)
[🔄 Tick是什么？游戏世界的"心跳"](#🔄 Tick是什么？游戏世界的"心跳")
- [1.1 两种Tick模式：逐对象 vs 逐组件](#1.1 两种Tick模式：逐对象 vs 逐组件)
- [1.2 父子节点的"潜规则"：爹先动，儿子跟上](#1.2 父子节点的"潜规则"：爹先动，儿子跟上)
[Bilibili 同步视频](#Bilibili 同步视频)
[💌 "分手信悖论"：并行执行的致命陷阱](#💌 "分手信悖论"：并行执行的致命陷阱)
- [2.1 当Tick变成多线程，麻烦就来了](#2.1 当Tick变成多线程，麻烦就来了)
- [2.2 为什么确定性这么重要？](#2.2 为什么确定性这么重要？)
- [2.3 直接通信的三大罪状](#2.3 直接通信的三大罪状)
[🏤 邮局模型：游戏世界的"时间管理大师"](#🏤 邮局模型：游戏世界的"时间管理大师")
- [3.1 解决方案：引入第三方"邮局"](#3.1 解决方案：引入第三方"邮局")
- [3.2 PreTick / Tick / PostTick：三段式精密设计](#3.2 PreTick / Tick / PostTick：三段式精密设计)
- [3.3 时序错乱的直观后果](#3.3 时序错乱的直观后果)
[🧩 组件化架构：灵活的代价](#🧩 组件化架构：灵活的代价)
- [4.1 组件化为什么火？](#4.1 组件化为什么火？)
- [4.2 组件化的两大缺点](#4.2 组件化的两大缺点)
- - 缺点一：性能损耗
  - 缺点二：循环依赖
[⚡ 多系统交互的那些坑](#⚡ 多系统交互的那些坑)
- [5.1 逻辑线程 vs 渲染线程：两条时间线](#5.1 逻辑线程 vs 渲染线程：两条时间线)
- [5.2 动画与物理的"双人舞"](#5.2 动画与物理的"双人舞")
- [5.3 Tick耗时过长怎么办？四大策略](#5.3 Tick耗时过长怎么办？四大策略)
[🌍 空间划分：动态世界的加速秘籍](#🌍 空间划分：动态世界的加速秘籍)
- [6.1 为什么需要空间划分？](#6.1 为什么需要空间划分？)
- [6.2 动态物体怎么办？](#6.2 动态物体怎么办？)
[🎯 总结：游戏引擎的"时间哲学"](#🎯 总结：游戏引擎的"时间哲学")

✨ 开篇：你有没有想过，游戏里的"分手"为什么不会乱？

想象一下这个场景 🎬：你兴冲冲地写了一封分手信，正准备投到女朋友寝室楼下，结果一抬头------她也拿着一封信走出来了！

这时候问题来了：到底是你甩了她，还是她甩了你？ 🤯

你可能觉得这是情感问题，但在游戏引擎的世界里，这是一个致命的技术问题。如果两个游戏对象同时给对方发消息，谁先收到？谁的行为先触发？

今天这篇文章，我们就来聊聊游戏引擎里最精妙、也最容易被忽略的设计------Tick时序与事件机制。看懂了这个，你才算真正入门了游戏引擎的内核。

本文核心看点：

🔄 Tick机制：游戏世界的"心跳"是怎么跳动的？
💌 分手信悖论：为什么直接发消息会出大问题？
🏤 邮局模型：如何保证并行世界的确定性？
🧩 组件化架构：灵活的代价是什么？
⚡ 性能优化：C++层面如何优化组件查询？

🔄 Tick是什么？游戏世界的"心跳"

1.1 两种Tick模式：逐对象 vs 逐组件

在游戏引擎里，Tick就是游戏世界的"时间步长"------每一帧，所有游戏对象都要更新一次自己的状态。就像心脏跳动一样，每跳一下，世界就前进一点点。

但Tick的执行顺序，里面的学问可大了去了 🧐

最直观的方式是Object-based Tick（逐对象更新）：遍历每个GameObject（简称GO），把它身上所有组件挨个Tick一遍。这种方式逻辑简单、好调试，就像你挨个给员工派活一样。

但现代引擎更常用的是Component-based Tick（按组件系统批量更新）：先把所有Transform组件更新完，再更新所有Motor组件，再更新动画、物理......同一类组件集中计算。

为什么要按组件批量更新？

答案是：CPU缓存友好 + 多核并行。同类型数据放在一起，CPU缓存命中率飙升；同类任务可以分发到不同核心并行执行，性能直接拉满！🚀

1.2 父子节点的"潜规则"：爹先动，儿子跟上

在Object-based Tick里，有一个天然的时序规则：

父节点先Tick，子节点后Tick。

为什么？举个例子 👇

你坐在一辆车里 🚗，车往前开了30厘米，你是不是也得跟着往前挪30厘米？如果先Tick你再Tick车，那你就会发现------哎？我的车跑了，我还在原地？这就离谱了！

所以父子Tick的顺序，本质上是依赖关系的体现：被依赖的先执行，依赖别人的后执行。

▲ 图1：父子节点Tick时序示意图------父节点先更新位置，子节点再跟随同步

这个规则在简单场景下很好用，但一旦进入并行世界，事情就复杂了......

Bilibili 同步视频

$简化版 GAMES 104$ 现代游戏引擎 06：从Tick时序到邮局模型，拆解确定性世界的底层密码

💌 "分手信悖论"：并行执行的致命陷阱

2.1 当Tick变成多线程，麻烦就来了

现代游戏引擎为了榨干CPU性能，会把大量Tick任务分发到不同核心上并行执行。这就引出了一个经典的问题------

如果两个对象同时给对方发消息，谁先收到？ 🤔

回到开头的"分手信"例子：你和女朋友并行执行，同时发出分手信。结果就是------

你觉得是你甩了她
她觉得是她甩了你
两边的逻辑都"正确"，但结果完全不一样

这在游戏里叫逻辑歧义（Ambiguity），是并行编程的噩梦。

2.2 为什么确定性这么重要？

你可能会说："不就是个先后顺序吗，有什么大不了的？"

那你可就太天真了！在游戏里，**确定性（Deterministic）**是一个核心要求：

确定性 = 相同输入 → 相同输出

只要玩家的操作完全一样，游戏世界里发生的每一件事、每一个动作、每一次碰撞都必须100%一致。

为什么这么重要？举个最常见的例子------精彩回放 🎥

你以为回放是把整个游戏过程录成视频？太天真了！那文件得多大啊！

真正的回放是这样的：只记录玩家的输入操作，然后把游戏重新跑一遍。因为有确定性，相同的输入一定会跑出相同的结果，所以回放和你刚才打的时候一模一样！

如果没有确定性......那回放就成了"平行宇宙模拟器"，每次看都不一样，那还叫回放吗？ 😂

2.3 直接通信的三大罪状

如果GO之间可以直接互发消息，会带来什么问题？

问题	表现	后果
时序不确定	谁先收到消息全看线程调度	每次运行结果可能不一样 ❌
调试困难	Bug复现全靠运气	程序员头发掉光 🥲
回放失效	相同输入跑出不同结果	对战游戏直接没法玩

▲ 表1：GO直接通信带来的三大问题

所以，直接通信这条路，走不通！

🏤 邮局模型：游戏世界的"时间管理大师"

3.1 解决方案：引入第三方"邮局"

怎么解决并行通信的时序问题？答案是------引入一个全局的"邮局" 📮

规则很简单：

所有组件禁止直接投递消息，统一先把事件写到全局邮局（事件队列）里
当前帧所有Tick逻辑执行完毕后，邮局统一分发全部缓存的事件
接收方下一帧Tick才能读取、处理消息

就像现实中的邮局一样：你今天寄的信，对方明天才能收到。这样时序就完全确定了！

▲ 图2：邮局模型时序图------所有消息统一在帧末分发，下一帧才能被处理

3.2 PreTick / Tick / PostTick：三段式精密设计

光有邮局还不够，现代引擎还把Tick拆成了三个阶段：

PreTick

读取消息、处理输入、准备数据

📥 "收信"阶段

Tick

执行业务逻辑、更新状态

🔧 "干活"阶段

PostTick

发送新消息、清理资源

📤 "寄信"阶段

这样设计的好处是什么？

因为所有消息都在PreTick阶段统一读取，在PostTick阶段统一发送，中间的Tick阶段大家专心干活，互不干扰。这样并行执行时，就不会出现"边读边写"的混乱情况了。

一句话总结邮局模型：

今天收到的信，明天再回；今天写的信，明天才到。大家步调一致，世界就确定了。

3.3 时序错乱的直观后果

如果引擎的时序设计得不好，会出现什么现象？

最常见的就是1~2帧的逻辑延迟（lag）：

你按了跳跃键，角色过了一帧才跳起来 🦘
子弹打出去了，碰撞检测慢了半拍 💥
动画切换总是慢一拍，打击感全无 🥊

这些看似是"优化问题"，本质上都是时序设计问题。

🧩 组件化架构：灵活的代价

4.1 组件化为什么火？

聊完了时序，我们再说说组件化架构本身。

传统的面向对象做法是：用继承树来组织游戏对象。比如GameObject是基类，下面派生出Character、Vehicle、Prop......然后再继续派生。

但这样很快就会遇到类爆炸问题 💣：

想要一个"会飞的车"？你是继承Vehicle还是继承Aircraft？想要一个"会说话的箱子"？这继承关系怎么画？

组件化架构就不一样了------用组合代替继承。

GameObject就是一个空容器，你往里面挂什么组件，它就有什么功能：

挂个Transform → 有位置了 📍
挂个MeshRenderer → 能渲染了 🎨
挂个Rigidbody → 有物理了 🏋️
挂个AI → 有脑子了 🧠

想做"会飞的车"？简单！把飞行组件挂到车上就行了 ✈️+🚗=🚀

4.2 组件化的两大缺点

但是！世界上没有银弹，组件化也不是完美的。它有两个很明显的缺点：

缺点一：性能损耗

访问组件需要实时Query查询。比如AI组件想知道"我现在血量多少"，它得先去GO上找有没有血量组件，找到了再读取数值。

这个查询过程，在高频的帧循环里开销可不小！

我们来看一段典型的C++代码 👇

cpp 复制代码

// ❌ 每帧都要查询，性能开销大
void AIComponent::Tick(float deltaTime) {
    // 每次都要去哈希表/数组里找组件
    HealthComponent* health = GetOwner()->GetComponent<HealthComponent>();
    if (health && health->GetCurrentHp() < 30.0f) {
        SetBehavior(Behavior::Defensive);
    }

    TransformComponent* transform = GetOwner()->GetComponent<TransformComponent>();
    if (transform) {
        // 移动逻辑...
    }
}

这段代码看起来很正常对吧？但在每一帧、每个AI对象上都执行的话，GetComponent的查询开销会累积成一个不小的数字。

优化方案是什么？缓存组件指针！

cpp 复制代码

// ✅ 初始化时缓存，避免每帧查询
class AIComponent : public Component {
public:
    void Initialize() override {
        // 只在初始化时查询一次，缓存起来
        m_health = GetOwner()->GetComponent<HealthComponent>();
        m_transform = GetOwner()->GetComponent<TransformComponent>();
    }

    void Tick(float deltaTime) override {
        // 直接使用缓存的指针，零查询开销
        if (m_health && m_health->GetCurrentHp() < 30.0f) {
            SetBehavior(Behavior::Defensive);
        }

        if (m_transform) {
            // 移动逻辑...
        }
    }

private:
    HealthComponent* m_health = nullptr;
    TransformComponent* m_transform = nullptr;
};

性能小贴士：

组件查询的开销主要来自哈希表查找或数组遍历。对于每帧都要访问的组件，一定要在初始化时缓存指针，能省则省！

更进阶的方案是ECS（实体组件系统），把同类组件的数据连续存储，直接用数组索引访问，连指针都不用存了------这才是性能的终极形态 🏆

缺点二：循环依赖

组件之间经常会出现"你影响我，我影响你"的循环依赖。

举个例子 👇

▲ 图3：组件间的循环依赖------移动影响动画，动画影响物理，物理又反作用于移动

Motor组件说："我先动，动画你跟着变"；Animation组件说："我的腿伸出去了，物理你检测一下"；物理组件说："撞到东西了，Motor你停一下"......

这就形成了一个环。单靠基础的Tick分段，很难完全消除这种循环带来的延迟。这也是为什么很多游戏会有"一帧延迟"的感觉------不是优化不到位，而是架构本身的限制。

⚡ 多系统交互的那些坑

5.1 逻辑线程 vs 渲染线程：两条时间线

现代游戏引擎里，逻辑和渲染通常是两个独立的线程：

逻辑线程（Logic Thread）：跑游戏逻辑、物理、AI、动画状态机
渲染线程（Render Thread）：准备渲染数据、调用图形API、提交Draw Call

它们的Tick顺序是：先完整执行逻辑Tick，再执行渲染Tick。

这样设计的好处是渲染和逻辑可以并行：逻辑线程算下一帧的时候，渲染线程在画这一帧，互不耽误。

但代价是什么？延迟。

逻辑算完了，渲染要等一帧才能画出来；画面准备好了，帧缓冲区交换又要等一帧。层层叠加下来，你按手柄到画面有反应，可能已经过了3~4帧，也就是一百多毫秒 😱

冷知识：

早期主机游戏的输入延迟可以达到100+毫秒，但玩家为什么感觉不到？因为引擎用了大量的"障眼法"------比如按下按键立刻播放音效、手柄震动、动画预演......让你"觉得"很实时，但实际上画面还没跟上。

这就是游戏开发的"魔术" 🎩✨

5.2 动画与物理的"双人舞"

动画和物理的关系，是游戏引擎里最微妙的话题之一。

你可能见过游戏里的"布娃娃系统"------角色被打飞后，整个人像没有骨头一样软塌塌地飞出去。物理上很真实，但看起来......就很假，像个破布娃娃 🧸

纯动画呢？动作很帅、很有设计感，但又不够真实------倒地姿势永远是那几个，看多了就腻了。

现代引擎的做法是------插值混合！

▲ 图4：动画与物理的权重插值混合------从全动画过渡到全物理，兼顾设计感与真实感

具体来说：

受击瞬间：动画权重100%，保留美术设计的酷炫受击动作 💥
过程渐变：逐步降低动画权重、提升物理模拟权重
倒地阶段：完全交给物理刚体模拟，肢体姿态随机真实 🤸

这样出来的效果就是：角色被打飞的姿势很帅很英雄，但倒地后的手脚位置又是随机的、真实的。玩家觉得"又帅又真实"，但其实是两个系统"跳双人舞"的结果 💃🕺

5.3 Tick耗时过长怎么办？四大策略

理想很丰满，现实很骨感。有时候一帧的计算量太大，Tick根本算不完，怎么办？

这里有四种常见的处理策略：

策略	做法	适用场景	风险
步长补偿	Tick传入deltaTime，位移按实际耗时插值	轻度卡顿、移动类逻辑	低 ✅
丢弃单帧	直接跳过一帧逻辑，赶上下一帧	非关键逻辑	高 ❌ 可能丢碰撞/伤害
分帧延迟处理	高负载任务拆分多批，分散到后续帧	爆炸、批量受击、物体生成	中 ⚠️ 5帧内人眼可接受
架构优化	重构系统、减少并行冲突、降低计算量	长期优化、性能瓶颈	低 ✅ 治本之策

▲ 表2：Tick耗时过长的四种处理策略对比

其中**分帧延迟处理（Deferred Processing）**是最常用的技巧。比如一个爆炸产生了100个物体的受击事件，没必要在一帧内全部处理完，分成5帧，每帧处理20个------人眼对0.2秒内的分批处理几乎感知不到，但性能压力直接降了80%！

🌍 空间划分：动态世界的加速秘籍

6.1 为什么需要空间划分？

想象一下：一个开放世界里有10000个物体，每次物理检测都要两两配对判断碰撞------那就是1亿次检测！这谁顶得住啊 😵

空间划分的核心思想就是：只检测可能碰撞的物体。离得八丈远的两个物体，根本不用浪费算力去检测。

常见的空间划分算法有三种：

BSP / PVS

二叉空间分割

✅ 室内关卡神器

❌ 动态物体更新慢

Octree 八叉树

立方体八等分递归

✅ 动静皆宜

⚠️ 中等更新开销

BVH 包围盒层级

包围盒合并成树

✅ 动态场景首选

✅ 更新开销极低

6.2 动态物体怎么办？

静态世界的空间划分很简单，建好就完事了。但动态物体呢？总不能每一帧都把整棵树重建一遍吧？那也太蠢了 🤪

这就是为什么**BVH（包围盒层级树）**在开放世界里这么受欢迎------

每个物体都有自己的包围盒，物体移动时，只需要更新它自己的包围盒，然后往上回溯更新父节点的包围盒就行了。大部分节点都不用动，更新代价极低！

就像你搬家了，只需要更新你家的地址，再更新一下小区的统计信息，整个城市的地图不用重画------就这么简单 🏠→📍

引擎设计建议：

一个成熟的游戏引擎，至少应该支持2~3种空间划分算法，交给游戏项目按需选用：

室内关卡 → BSP/PVS
混合场景 → Octree
开放世界 → BVH

没有最好的算法，只有最合适的场景。

🎯 总结：游戏引擎的"时间哲学"

聊了这么多，我们来收个尾。

游戏引擎的Tick时序、事件机制、组件化架构......这些东西看起来是"技术细节"，但背后其实藏着一套关于时间与秩序的哲学。

🎯 核心要点回顾：

Tick是游戏世界的心跳，按组件批量更新才能发挥多核性能，但并行带来了时序难题
邮局模型是确定性的保障------所有消息统一收发，PreTick读、PostTick写，中间专心干活
组件化是灵活的代价------用组合代替继承，但要付出查询性能和循环依赖的代价
多系统协作需要智慧------逻辑与渲染分离、动画与物理混合、空间划分按需选择

最后想说：游戏引擎最迷人的地方，不是它用了多么高深的技术，而是它用这些技术，构建了一个有规则、有秩序、有确定性的虚拟世界。

就像我们的现实世界一样------虽然复杂，但背后有一套精密运转的规律。而引擎程序员，就是这个虚拟世界的"创世神" 🌍✨

📚 延伸阅读：

想深入了解ECS架构？可以看看Entity Component System的设计思想
对空间划分感兴趣？推荐阅读《Real-Time Collision Detection》
想做自己的小引擎？可以关注Piccolo引擎的开源项目

如果这篇文章对你有帮助，别忘了点赞收藏关注三连哦！你的支持是我持续输出的最大动力 💪

有任何问题欢迎在评论区留言，我们一起探讨游戏引擎的奥秘 🎮✨

[简化版 GAMES 104] 现代游戏引擎 06：从Tick时序到邮局模型，拆解确定性世界的底层密码

简化版 GAMES 104 现代游戏引擎 06：从Tick时序到邮局模型，拆解确定性世界的底层密码

✨ 开篇：你有没有想过，游戏里的"分手"为什么不会乱？

🔄 Tick是什么？游戏世界的"心跳"

1.1 两种Tick模式：逐对象 vs 逐组件

1.2 父子节点的"潜规则"：爹先动，儿子跟上

Bilibili 同步视频

💌 "分手信悖论"：并行执行的致命陷阱

2.1 当Tick变成多线程，麻烦就来了

2.2 为什么确定性这么重要？

2.3 直接通信的三大罪状

🏤 邮局模型：游戏世界的"时间管理大师"

3.1 解决方案：引入第三方"邮局"

3.2 PreTick / Tick / PostTick：三段式精密设计

3.3 时序错乱的直观后果

🧩 组件化架构：灵活的代价

4.1 组件化为什么火？

4.2 组件化的两大缺点

缺点一：性能损耗

缺点二：循环依赖

⚡ 多系统交互的那些坑

5.1 逻辑线程 vs 渲染线程：两条时间线

5.2 动画与物理的"双人舞"

5.3 Tick耗时过长怎么办？四大策略

🌍 空间划分：动态世界的加速秘籍

6.1 为什么需要空间划分？

6.2 动态物体怎么办？

🎯 总结：游戏引擎的"时间哲学"

$简化版 GAMES 104$ 现代游戏引擎 06：从Tick时序到邮局模型，拆解确定性世界的底层密码