第(2/3)页

    当然，杰斯特要说的还没有说完。

    “然后，就是一个重中之重的概念，我们内部将其称之为hit-box，可以简单的解释为命中框或者是命中面积，这样说似乎就顾名思义了，一个人物的3d模型包含了一些区域来判断命中。长宽高的数据在3d世界里面精确的描述一个物体。你看不到命中框，你只能看到玩家模型。命中框可大可小，也可某种程度上无法命中，这都要根据游戏如何编写来判定。在命中和未命中方面。命中框能够带来比快照速率更大的不同。”

    “另外的一个非常重要的东西，叫做卡顿补偿，这可能在不同的游戏里面会有完全不同的表现。”

    “卡顿补偿是在服务端的一种功能，意在减少客户端延迟的直观感受。如果没有卡顿补偿，或者卡顿补偿不够理想，你就会朝着一个目标瞄准想要打中。但是由于客户端电脑“看到”的延迟后的游戏世界，你并不会命中原先瞄准的区域。本质上讲，卡顿补偿是在解读从客户端接收到的动作，比如开火，尽管动作已经发生过了。服务端游戏世界和客户端游戏世界的不同，或者说我们通常所说的客户端延迟，都可以总结为：客户端延迟=(1/2*延迟)+内插帧延迟。”

    “这其实是一个很复杂的机制，我原本想要三言两语的将其说明白，但是我发现这根本没有办法做到，索性我就详细的说一下什么叫做卡顿补偿或者更加确切的一个说法，就是卡顿补偿这个机制到底是怎么运行的？”

    “现在我描述一个这样的玩家在游戏里面的游戏场景，来通过这个场景简单的说一下什么叫做卡顿补偿。”

    “这个场景是这样的。”

    “玩家a看到玩家b向一个拐角行进，玩家a开了1枪，客户端把开枪这个动作发送给服务端。服务端接收到xms后的数据，x为玩家a，latency(延迟)的一半。服务端这时查看过去发生过的(在记忆加载中)，查找到当玩家a开枪的时候玩家b的位置。在基础的例子中，服务端会返回(xms+玩家a的内插帧延迟)到玩家a看到玩家b的时间点，但是其他的数值因素或许由游戏程序员想要卡顿补偿如何施行来决定。”

    “服务端决定玩家a开的枪是否命中。开枪想要被算做命中，需要它必须打在玩家模型的命中框中。在这个例子里，服务端认为玩家a命中玩家b。尽管如此，玩家b的屏幕可能已经看到自己在墙后了，但是在玩家b看到自己在墙后的时间和服务端认为玩家b被命中的时间的差异等于：1/2玩家a的延迟+1/2玩家b的延迟+距离上一次快照的时间。”

    “在下一次快照中，服务端更新玩家a、b的客户端上的数据。玩家a看到命中瞄准的位置x，玩家b看到自己的生命值减少或者死亡。”

    “看完这一个过程之后，是不是就对于什么叫做卡顿或者说是延迟有了一个完全不同的清晰的定义了呢？”

    杰斯特写完这些之后，想要将帖子发出去。但是他突然的想起了一个玩家经常争执的问题，正好可以利用这个机会解释一下，于是他便在这个帖子的下面紧接着写道：“我突然的想起了一个fps游戏玩家之间经常的进行争吵的经典问题，那就是我跟另外一个玩家同时开火。并且同样命中，为什么我死了对方却没事呢？”

    “因为这是不同的游戏存在着不同的设定的原因，在一些游戏中，比如《反恐精英》，如果先开的一枪到达服务端的时候杀死了目标。那么任何接下来的所有到达服务端的命中目标的开火将被服务端忽略。这种情况下，就不可能存在同时击杀，因为2玩家在1快照中向对方开枪并都死亡。”

    “但是，在另外的一些游戏当中，比如说有一些人已经试玩过的《军团要塞》，共同击杀是可行的。这里有一个叫做权重的东西在影响着游戏的进程。”

    “如果你用《反恐精英》的模型，玩家在良好的延迟下会有明显的优势，并且在一些时候可能会出现‘oh，我在死前打了他一枪，但是他并没有死！  ’的情况。你甚至会在你死前听到你发出的枪声。但仍没有造成任何伤害。”

    “如果你用目前的《军团要塞》模型，反应时间的微小差别并不会意味很多，举例，如果服务端快照连拍率是64，如果玩家a比玩家b快了15ms开枪，但是他们都是在15.6ms的快照中完成这个动作，那么他们就会同归于尽，整个过程其实就是这么的简单。”

    “如果卡顿补偿过量，会显示结果为我在他之后开枪但是还是打死了他。”
    第(2/3)页