游戏世界的构成
- 动态物体（Dynamic Game Objects）：玩家、可移动可以交互物体等
- 静态物体（Static Game Object）：环境、石头、房子等（无法交互）
- 环境（Environments）：天气系统（Sky、TOD）、植被（Vegetation）和地形（Terrain）
- 其他看不见的物体：事件触发检测体（Trigger Box/Area）、空气墙（Air Wall）、导航网格（Navigation Mesh）等
以上物体统称为游戏对象（Game Object,GO）
如何描述/构建游戏对象
一个游戏物体的行为可以分为属性（Property）和行为（Behaviour），比如他的外形(Shape)、位置（Position）、（Capacity of Battery）就是属性，而移动（Move）、巡逻（Scout）就是行为。
通过对象的派生和继承可以更方便的制作对象。但是很多时候游戏逻辑非常复杂，于是现代引擎就引进了**组件（Component）**的形式来定义和设计对象（类似于游戏内自定义的思路）。比如定义一个组件的Base基类，再由此派生出各种接口类如Transform、Model、Motor、AI、Animation（各自实现并update）等，并以此作为构建游戏世界的基础逻辑。
-
现代游戏引擎一般的update顺序是按照每个组件处理的，比如先全部处理Transform、再全部处理Controller（流水线化），这样可以提高处理效率（可以批处理）。
-
unity和UE在GO上的差别：
注意：这里的UE基类UObject和unity的Object并不代表我们讲的GO，而是高级语言里的Object，方便进行生命周期、内存等管理。UE里的Actor和unity的GO才是本章讲的GO。
游戏对象的交互–Events机制
早期交互是通过把比如子弹也创建一个GO，并在检测附近的GO，在爆炸时对其影响，但这样显然很低效。现代游戏引擎通过Events机制来实现这一过程，触发时像周围GO发送一个受伤指令，下一个Tick里周围GO收到这个指令后扣血或死亡；通过这种方式使GO和GO之间的通信解耦合（Decouple）
- 在unity里用SendMessage()，UE中用DECLARE_EVENT_XXX函数（蓝图里也有），其他引擎也有自己的消息系统
如何管理游戏对象
- 每个GO都有唯一编号UID（unique ID）和自己的位置，通过这两个信息进行GO管理（场景管理）
- 位置管理时去遍历太低效了，可以通过场景划分（Division）来优化GO位置管理
- 但当GO位置都挤在一起时，普通场景划分也不管用了，这时可以使用四叉树或八叉树将每个网格划分为更细小的网格，这样只需要在兄弟节点往下找即可。除此以外还有很多优化方法，比如经典BVH，见图
tick的时序问题
有时GO之间会有绑定的情况，比如人坐在车上人和车绑定，这时就要考虑tick的时序。
但由于现在组件的tick一般是分散到不同CPU上并行执行的，所以时序问题会很复杂，会产生逻辑混乱问题。这时就需要一个“邮局”（事件总线）来统一管理消息的先后性，在引擎中表现为有pretick和posttick，确定收到消息和执行消息的是当前帧还是下一帧。（有些游戏时序部分没做好就会有一两帧的延迟）
Q&A
- 如果一个tick过于复杂用时过长怎么办：1，可以把每个tick的步长传入，对比如位移做一个补偿；2，可以跳过下一个tick；3，正常还是会去优化引擎，比如大规模处理可以分批次完成，人的感受也不会很明显（子弹类不适用）。
- 空气墙和其他GO有什么区别：相当于透明体积盒子，用途特殊而已
- tick时渲染线程和逻辑线程怎么同步：一般逻辑线程和渲染线程是两个线程，tick逻辑是是更新各个组件，tick渲染更多是做各种数据准备（比如粒子系统）；一般逻辑是在渲染之前，但有些引擎会有延迟一帧渲染的问题
- 空间划分怎么处理动态对象：一般会选择更新起来比较轻量的场景管理优化方法，比如BVH，做引擎的话需要支持2-3中空间划分算法供选择
- 组件模式有什么缺点：1，接口过多效率肯定不如class高，但使用ECS批处理可以优化；2，组件间的通讯时不太透明，需要经常做其他组件是否存在的查询（query），降低效率
- 事件机制怎么调试：比如UE的蓝图可以逐帧的看每个事件，有些游戏会锁定某个GO发送和接受的消息显示出来----最有效的debug机制就是打log😄，现在比较流行可视化的debug模式
- 物理和动画相互影响时怎么处理：一些差值处理，或者动画作为物理初始化处理
扫一扫
632
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
