[讨论,请教]在线游戏玩家碰撞与同步的实现

hack86

研究抽样案例：《是男人下100层》

游戏玩法：
    4个玩家同屏互相有碰撞下100层，最后一个死亡者为冠军。

技术实现特点：
    踏板固定移动速度，不会因为任何碰撞改变方向或者任何属性，初始属性包括x坐标，类型，y匀速度。

游戏人物：
    不可变属性：y加速度，为与踏板碰撞时加速度有效，碰撞后站在踏板上，否则自由落体。人物碰撞，只做x碰撞，两玩家碰撞发生时，力量相等。也就是说人物y为完全自动，人物x又玩家控制，并有碰撞。

讨论案例时间段：
    从游戏正式开始到结束，中途不可中断暂停，人物死亡即退出碰撞列表。


已有成熟设计结构(个人认为无需更改的最优设计)：
   
    客户端指令执行同步：指令已时间为标准，客户端每次启动游戏时，记录开始时间毫秒值(st)，所有指令坐标属性都是基于这个时间的相对值，也就是说任何元素的指令或坐标都带有一个时间值(ct)，这个时间值是相对st的毫秒值(gt)，客户端在执行时，会根据当前帧的时间换算出的gt，在根据ct换算与gt的差值来计算当前元素位置。
    注：st:start time; ct:command time; gt:game time;

    踏板同步：服务器在游戏开始时广播4个人踏板数量，类型与坐标，启动时间，指定数量，客户端自行处理，运算，绘画，在必要时间消除，当客户端踏板快要用完时，向服务器再次申请新的，或按规则重置已有踏板顺序再次使用。


待讨论设计重点：

    角色同步：如果说人物之间没有碰撞，每次指令带坐标即解决所有问题。但是人物之间的碰撞可能影响他们的坐标。其次网络延时对彼此的操作产生了重大的影响，双方的指令达到时间都会有所延时，而且还不同，可以为客户端设计一个网络延时，来延时他的操作指令的执行时间，但是这种情况当网络延时超过他的设定时间时该如何处理？

    预算拉扯：预算拉扯再此处并不可行，或是本人能力有限，如果没有任何碰撞，预算是没有问题的，假设客户端操作角色A移动，在t400,x10时发送玩家将在t500时x移动10，那么预算t500的x比较容易，但是如果在这t100内发生了别的角色碰撞他，使他移动过，那么到t500时，事先预算的坐标就无效了所以这个预算拉扯在有玩家碰撞时，个人感觉不可行。

    服务器碰撞：人物为4人，像素坐标范围是800x600，服务器的碰撞运算依靠什么为依据，由于任何语言任何实现帧频的API几乎都是近似值，这种情况服务端即使用帧频也无法做到准确数据，那么唯一可靠的就是时间，依靠时间变量和初始向量计算目标向量，而得到准确数据，那么客户端该在合适发送怎么样的数据来保证彼此的同步呢？

    成熟产品讨论：跑跑卡丁车碰撞如何实现？魔兽世界玩家碰撞如何实现？星际争霸网络同步如何实现(要卡一起卡)？冰峰王座碰撞如何实现(视为最佳用户体验，网络延时后，会加速元素移动到最新同步数据，不是直接重置)？

    用户体验牺牲：用户体验可以包容，要保证在理想状态下：设定1kbit包(128bytes)延时50ms内的响应，也就是说用户操作的响应延时从50ms起，也就是响应延时至少为0.05秒。这种情况下该如何设计？

细节包容：

    以上设计在必要时可牺牲性能，因为每轮游戏至多4人，操作界面至多800x600(感觉这个并无所谓，碰撞上界限只是一个固定的值而已)。
    如果有合理的更优设计，可推翻以上整体框架。曾经尝试使用帧号来代替gt，但是这种方法在某客户端出现系统响应延时时整个框架完全作废。
    等待优秀设计方案，如果在杭州可约见吃饭，有偿讨论。

   

I社爱好者

太高深了
帮你填点人气。

hack86

为什么就没人顶呢？郁闷啊

FreeStyle_Chen

路过，学习

hack86

有人解答么? 有人有兴趣么？

liujxxf

ksk 呵呵有尝讨论……杭州的果然有钱……做控制同步和位置同步

powerfish

关于碰撞与同步，lz可以参考下对战平台关于这方面的实现，VPN技术，另外跑跑据说是p2p技术实现，war3的碰撞是以主机数据为准广播后显示在每个客户端，没有用延迟预判

qiaojie

2种方式
第一种：类似星际争霸，各个客户端之间锁步同步，这种算法的优点是不需要服务器参与，各个客户端之间严格同步，缺点是对网络延迟要求较高，延迟小于100ms时才会有比较流畅的游戏体验。
具体做法：客户端游戏逻辑按固定时间间隔同步，假设时间间隔设定为100ms。在每个同步间隔里缓冲用户的按键输入（而不是立即让游戏逻辑执行，这点是保证同步的关键），发送给其他客户端，到达同步时间点时等待其他客户端发过来的同步消息（这其中包含了其他用户的按键输入）当所有的客户端消息都到达后才继续执行下一轮同步，将用户的按键输入和接收到的其他客户端的按键输入作为本次同步的逻辑输入，由于各个客户端得到的逻辑输入是相同的，所以逻辑结果也是相同的，这就保证了严格的同步。如果某轮同步中某个客户端游戏网络阻塞没有将消息发送出来，其他客户端会等待这个客户端的消息而阻塞，而这个客户端也会因为等待其他客户端的同步消息而阻塞在下一轮同步中，这样就保证了各个客户端在执行时间上的严格一致。
第二种：类似CS，各个客户端独立计算逻辑，最后由一个仲裁者（可以是发起游戏的客户端担任也可以是一个独立的服务器）来决定逻辑冲突。这种算法的优点是对网络延迟不太敏感，游戏体验较好。具体做法：各个客户端独立计算游戏逻辑，将用户的输入和本角色的信息（如坐标，生命值等）发送给其他客户端做同步用，也就是自身角色由用户控制，其他的角色由其他客户端传过来的信息控制，同时这些信息也会传给服务器对逻辑冲突进行仲裁，比如两个狙击手同时看到对方并开火，A客户端的游戏逻辑认为杀死了B角色，B客户端逻辑认为杀死了A角色，逻辑本身是对的，只是因为延迟的关系产生了不同步，此时仲裁者就需要对这种矛盾进行修正，因为杀死A和的两个消息到达仲裁者必然是有先后的，所以一般来说可以判定先到达者的逻辑有效，而后到达者的逻辑无效，然后仲裁者对各个客户端的逻辑进行修正以实现同步。这种算法对网络快的用户非常有利，网络慢的用户会比较吃亏。

ixnehc

个人比较喜欢楼上说的第一种方法,因为客户端的架构比较清楚,不需要和server端有太复杂的消息交互,不过也有很多问题需要解决,两个客户端要保证运行的一模一样写代码的时候得很小心才行,否则容易出现非常难查的bug,而且可能不能使用浮点运算.server端的作弊检查也是个麻烦事.另外卡的问题也许可以通过一个预移动的虚拟角色来解决,

ebaozi12

影响是多元化的，学习了