编辑“︁RolePlayingDesign”︁（章节）

=Perceptions=
向客户端发送的世界更新的基本结构称为感知。

有两种感知:
* 同步感知：用于将客户端与服务器世界同步。 这是了解世界状态的唯一有效方式.
* Delta 感知：这用于仅发送世界自上次感知以来的变化。

我们实际的感知系统称为 Delta<sup>2</sup>。 它与 Marauroa 核心紧密相连，因此我建议您使用它 :)

== 感知和动作是怎么工作的 ==
动作从客户端发送到服务器，以使角色执行动作。 为了让客户端知道操作的结果，服务器需要向客户端发送回复。 那么，这些是怎么完成的呢？

刚开始的时候，我们向客户端发送一个它的操作结果的操作。 然而，这使得代码变得非常困难，因为我们必须更新两个不同的东西，感知和动作。 一个直观的解决方案是：为什么不把动作结果和感知放在一起呢？

因此，动作结果存储在每个对象（执行动作）中，并带有一组属性，这些属性确定动作返回状态和属性。 这种发送结果的方式给 RPManager 编程带来一些困难，但它大大简化了新客户端的创建。

请参阅 Objects 文档中的 Actions 响应以了解返回的内容。 但是，请记住，返回结果取决于每个特定的游戏。

==Delta<sup>2</sup> 感知算法==
DPA 背后的想法是避免每次都将所有对象发送给客户端，而只发送那些已修改的对象。

假设我们有 1000 个对象，只有 O1 和 O505 是活动对象，每回合都会修改。

传统方法是:
<pre>
- 获取玩家应该看到的对象 ( 1000 objects )
- 将它们发送给玩家 ( 1000 objects )
- 下一回合
- 获取玩家应该看到的对象 ( 1000 objects )
- 将它们发送给玩家
- 下一回合
...
</pre>

我希望你已经看出问题了……我们发送的对象每回合都没有改变。

delta感知算法:
<pre>
- 获取玩家应该看到的对象 ( 1000 objects )
- 将列表缩减为修改后的列表( 1000 objects )
- 同时存储不再可见的对象 ( 0 objects )
- 将它们发送给玩家 ( 1000 objects )
- 下一回合
- 获取玩家应该看到的对象 ( 1000 objects )
- 将列表缩减为修改后的列表 ( 2 objects )
- 同时存储不再可见的对象 ( 0 objects )
- 将它们发送给玩家 ( 2 objects )
- 下一回合
...
</pre>

delta 感知算法的下一步非常明确：delta<sup>2</sup> 想法是只发送发生变化的对象。 通过这种方式，我们可以节省更多带宽，使感知大小约为原始增量感知大小的 20%。

delta<sup>2</sup> 算法基于四个容器:

* List of added objects
* List of modified added attributes of objects
* List of modified deleted attributes of objects
* List of deleted objects

与 DPA 非常相关的一个领域是 RPZone（请参阅本文档后面部分）

如您所知，MPEG 视频每 X 帧添加一个完整帧，可以用作同步，以防文件损坏。 这个想法是，如果你无法继续解压缩数据，那么可以忽略一些数据，直到获得下一个完整的帧，从而再次同步。 这里的想法是类似的，如果我们无法与服务器同步，我们会向它发送一个 Out of Sync 消息，以便服务器发送一个同步感知，使客户端同步。 请记住，UDP 不是安全传输。

为了让感知起作用，调用 RPZone 中的 modify 方法很重要，这样修改的对象就会存储在修改列表中。