九乡新闻网音乐奇侠2天元斗士:关于网游同步处理的验证（上接第二章，这篇讲的有些凌乱）
来源：百度文库 编辑：九乡新闻网 时间：2024/04/20 15:24:52
上一部分讲到游戏里一切参照服务端为主
玩家A对野猪释放了1个寒冰箭，该技能的释放最大射程为30米。这个时候，在释放技能时，服务端确认了玩家和野猪的坐标点，客户端的自己和目标的距离作为参照，当中途无遮挡，满足条件后，服务端依然需要验证1次攻击目标和自己在服务端的距离是否满足该技能的最大射程。
客户端这个时候也没闲着，会做出1个预先判断的行为，比如说念咒和技能loading条。等服务端验证信息返回之后，就会告诉你，在你预读的时间内，之前满足条件的行为有没有变更，来保证正常的运作。这里客户端的预判行为也衍生为增加游戏的打击感和体验程度。
这个时候当条件满足了和传参通畅，技能就释放成功。网络延迟的话，你的loading时间就对应加长，直至你释放技能成功。
如果这里关键点在服务端如果计算位置错误了，必然会导致接下来一系列的预判失去效果，失去效果后，这样客户端觉得他的机器观和价值观崩溃，那么技能就会卡住。
卡住了玩家也崩溃了，无打击感之说了。
这里我们将讨论一种良好的对时协议。良好的对时协议基础在游戏中是应用于本地时间的变更不影响服务端的验收结果。
这里我们跳转循序渐进去讨论关于如何减少同步问题，先讨论下 一个B/s结构的轻量业务。
例子：
如一个策略游戏的盖房子，触发了该房子，到计时00;30;00，30分种后，该房子建筑完成，
Client的时间也开始计算，当二者时间校对一次，当一致的情况下，房子盖好。
这里可能会出现，服务端发现客户端的包先收到了，服务端却没有倒计时30分钟结果。
服务端不高兴了，勒令客户端去再次重新对时。同理，客户端也发现服务端的包早到了，也会主动向服务端重新对时。
可能这部分原因会因变速齿轮而导致的，只要不是自然呆的程序，都不会让客户端时间去改变服务端的结果。
这里所指的客户端时间，是game客户端时间，而用变速齿轮和其他方式去改变本地的OS时间基本是无效果的。网络游戏和单机游戏是不一样的。
并且记住这里去做验证时间并非是防止作弊，而是能使游戏系统更流畅
实际上盖房子开始，客户端会发一个数据包给服务端，里面记录下了发送时刻。服务端一看有新的短消息，收到后，立刻讲这个数据包添加了1个服务器的当前时刻信息，并发还给客户端。
这里有些人会有疑问，服务端本地计数和客户端是不需要一致的，好吧，没错，为了一些伪随机数的应用，但实际上他们在验证时会把故意错位的时间验证时加进去的。
大部分情况下，客户端不会马上处理这个包，所以在基础上还要分析一些环境因素，在处理时再加上1个时刻，这个时刻我们可以称为内部耽搁时间。多次校正这个时间又没有更好的办法呢，有的。下章节我们讲述。
关于tcp协议丢包问题又重发，也不参与考虑。
这里只是讲一些概念上的知识，但是利用游戏逻辑去作弊时间方式，是难避免的。需要我们这些专业验收人员去处理。
加速，减速等外挂问题，如果留言有兴趣，最近会穿插讲。
本文来自私人博客：http://blog.sina.com.cn/chendamao1983