[转载] Bucket Synchronization 同步方法翻译

出处 http://blog.163.com/stefanie_kaka/blog/static/18973516220117292448474/

------------------------------------

原地址: http://www.pyramid-inc.net/lab/archives/121

本人高中英语就没及格过, 如果有人发现不妥之处麻烦指出, 我会马上修改

 

不久前一个名字MiMaze的VRML 3D网络游戏发布了. 是什么使他区别于其他的网络游戏, 那就是他是完全分布式(p2p)的网络结构.

因为没有中心主机, 分布式结构拥有很好的优势如: 可扩展性, 没有中心点失效情况和低延迟.

由于在分布式结构中没有主机, 所以每个客户端必须维持一个游戏的世界, 换言之就是所有的其他玩家共享的世界是一致的.随之而来的问题就是这个世界会非常容易的变得不同步, 因为事件是从其他客户端无序的到达的. 这种情况的触发是由lag, latency①或者其他原因造成的.

首先来看看左边的图A. 这是一种没有延迟的情况. 玩家A和B与对同一个对象处于相同的距离. 如果A在T1时刻想该对象发射, 而B在T2时刻对该对象发射, A将首先击中对象, B将错过他, 因为这个对象已经被A击落了.

 

现在来看看图A右边. 如果”A攻击对象”命令到达B需要更多的时间, 比较A和B不同的射击时间, 则结果将看起来不同. B将在T2时刻攻击对象, 但是这个时候还没有收到A的射击数据包, 直到T2之后才收到, 那么这将意味着在B的世界里B将首先击中, A将错过. 但是在A的世界里看起来A击中对象, B错过.

 

Mimaze使用一种叫Bucket Synchronization  的技术来避免了这种问题的发生, Bucket Synchronization  来源于LockStep技术. 在Bucket Synchronization 中我们只在某个离散时间段调用Buckets, 而不是马上调用. 所有在两个Bucket之间发生的事件, 以队列的方式放在指定时间间隔的Bucket中.

 

有一件很重要的事情, 事件被使用一个”delay synchronization time”(延迟同步时间)延迟放入到后面的Bucket中, 同时通过网络接收到的其他客户端事件也将被存放在一个指定时间间隔的Bucket中, 这个时间间隔是最初就指定好的. 这允许所有的客户端在更新他们的游戏状态以前接收到其他客户端的所有信息. 你可以将它想象成为一个”等候游戏同步的时间”.”delay synchronization time”通过玩家之间最高的延迟时间加上一些缓冲时间计算出来.这里有一些困惑, 所以我将给你展示一个例子.

 

例如一个游戏使用:

+ 50ms bucket 间隔;

+ 100ms delay synchronization;

50 100 150 200 250

A – L – B – R – C – - D – - E

本地包”L” 被建立在75ms. 他将被延期到 d(L) = time created(75ms) + delay sync time(100ms) = 175ms. 这个包将放在C和D之间. L被放到D对应的Bucket中.

 

对于一个远程包而言, 我们获得的时间是他被建立的本地时间(125ms)加上delay sync time(100ms + 125ms = 225ms). 所以数据包将被放到E对应的Bucket中.

 

 

图B展示了和图A同样的情况, 但是使用的是Bucket Synchronization. 灰色的矩形框表示的是Buckets, 黑色的虚线箭头表示事件被放置的bucket, 而红色的虚线箭头表示delay synchronization time.

 

在T2玩家B建立一个本地射击命令, 被放入到Bucket D的队列中. 在那之后, 玩家B从网络收到来自A的事件, 同时立即将A放入到Bucket C的队列中.C是一个处理加工时刻同时A注册了一个碰撞. Bucket D是下一个处理但是A的事件已经在Bucket C中被处理了, 所以B的事件注册为miss. 现在两个客户端的结果是一致的了.

 

如果在一个Bucket里面超过1个以上的事件, 我们能够决定顺序或者使用一个时间戳.

 

可能会有一些疑问进入你的脑袋里, 例如”没有立即处理操作, 客户端是否会有延迟?””如果lag的值比delay synchronization time大会发生什么?”

 

事实上如果你delay操作反应, 玩家将会感到一些lag. 这个技术不适用于FPS游戏, 但是能很好的适用于慢战略游戏或者回合值游戏, 在这些游戏中delay能够使用像winding up animators这样的技巧掩饰起来.

 

如果lag > delay synchronization time 那是我们必须丢弃这个包, 因为这个数据包不再有效了. MiMaze使用Dead Reckoning技术来补偿处理这种情况, Dead Reckoning方法是基于原来有效的数据去推断下一个状态. 另外一种从Bucket Synchronization衍生的技术Breathing Bucket Synchronization ,这种技术试图解决这种情况, 它基于接收包的延时计算同步动态延时.

 

Bucket Synchronization对网络游戏也非常的有用, 它完全的通过输入驱动. 帝国时代使用类似的方法来驱动他们的游戏.

 

我建立了一个简单的app去证明这个概念. 这里有两个世界, 每个世界有一个主要玩家. 一个代理和一个本地游戏对象. 红色的玩家是本地玩家在左边, 绿色的玩家在右边. 当你点击一个fire按钮, 红色或绿色的玩家将建立一个本地事件摧毁白色物体. 你能够看见谁击中谁miss. 紧挨着他们的是一个白线, 它你能够查看buckets. 红点代表本地事件, 蓝点代表来自远端玩家的事件. 尝试调整参数看看将会发生什么吧.

①http://blog.163.com/stefanie_kaka/blog/static/189735162201172112742308/