概论

方法论：将所有部分抽象成一个GameObject（GO）进行处理；用组件逻辑优秀于其相关的继承逻辑。

游戏世界的组成

可见部分

  • 可交互-动态游戏物体
  • 不可移动-静态游戏物体
  • 地形系统/环境：地形系统（Terrain）、植被系统（Vegetation）、天空系统（Sky）

不可见部分

  • 空气墙
  • Trigger box 触发区域

Object的机制、逻辑

属性-行为逻辑

将物体描述时，我们将其抽象为属性 和行为，在大部分面向对象的语言(OOP)中,我们可以基于属性和行为对其进行抽象以实现一个属性效果。利用对象的派生 继承逻辑来完成类的设计

Weakness

随着逻辑的复杂化，其父子关系并未类似设计的初衷那样灵活且直观。（例如水陆两栖属性父类是水类还是陆类？）-菱形继承等逻辑可能解决了一部分这个问题，不过在大多数情况下，我们认为组合大于继承

组件组合逻辑

我们将多个组件抽象出来，向属性中组合，来重新对物体进行描述。 组件化组成逻辑

在设计和抽象时，我们力求尽可能实现符合设计直觉的设计来保证组件系统的逻辑，以保证良好的实用性和可维护性。

两种主流商业引擎的组件架构概览

基于Object的tick逻辑

根据Tick的间隔，我们在每一个Tick间隔，将各个组件逻辑进行物体的更新，以帧更新作为一种简要理解。我们以系统为单位逐步进行Tick的更新。

更新时，进行逐系统更新能够最大化优化计算效率，以及相同类型数据的内存空间连续，其处理效率会提高，且优化了更好的并行性（简要来说就是局部性原理。） 在每次tick更新时的产生逻辑

Object之间的交互

在游戏中物体之间需要进行处理和信号的互相传递，因此我们需要通信逻辑。

Hardcode逻辑

交互就是两个物体互相影响(不是我在说什么233)， 一开始的设计逻辑中，我们将交互的逻辑硬编码化（Hardcode，即谁与谁交互时，直接将对象保留而实行）， 这种效果不容易拓展与维护，且每增加一种类型其复杂程度都在显著提升，不利于逻辑推进。

Event 事件逻辑

我们将GO中的逻辑解耦，将所有的行为逻辑由Event处理。所有的交互将会通过Event被观察，并依赖Tick机制，在下一帧率被有选择的逻辑更新处理；我们将事件分为广播和接收，将消息发送出来在其他部分被接收，并完成各种策略。这种信息机制是对拓展开放，对改编相应闭合的。

场景的管理

最简逻辑：P2P

我们在发送广播的时候，我们不加筛选的进行广播。在小型游戏的逻辑可以接受，不过在大型游戏中性能容易发生爆炸

分块管理逻辑（Many Stragies）

  • Grid管理：在逻辑处理时我们将不同地方进行区块化；由于角色的视觉距离有限，因此我们利用网格进行划分，只管理近处有影响的逻辑管理部分；在区块的管理和分化中有许多的流派，在这里只简要提及。

均匀网格对物体的密度没有一个很好的平衡策略，从数据结构讲、逐步地，我们将世界进行了多种多样的划分逻辑，以获得更佳的逻辑体验。 几种经典的划分逻辑：包围盒、二进制分布、八叉树等

物体的同步逻辑

  • 由于GO之间的直接绑定会产生一些逻辑上的冲突（两者互相攻击时，谁先攻击到的？还是左脚踩右脚上天？），因为核的多线程并行问题，每一次的执行顺序如果不确定，会对对战的时序产生不确定性，会产生逻辑上的差异（两个客户端的对战结果是完全不同的）；
  • 对于各种持续的逻辑，以及逻辑上存在父子关系的时候，收到消息的处理逻辑可能出现逻辑的不同步问题，从而导致效果的不同步。
  • 消息的传递会依赖时序关系，需要保证执行顺序的稳固。