关于有人提到的客户端以服务端为准，不是很需要去多次验证，当服务端的时间到了00:00:00，客户端主动刷新，拉到和服务器一样的时间内，然后响应它，不就完了。
这种方法当然可以，但是考虑到高的开销，我更关注的是减少开销。
之前所提到的服务端和客户端中间是一种接受和发送然后验证响应的机制。
客户端处理图形资源外，还处理一些缓存消息。
国内游戏未满足富网络的状态，由于外挂等因素影响，更需要关注的是信息量和安全性部分。服务器会按优先等级比消息划分一个优先等级，分出重要、次要和不重要的。
服务端会把部分不重要的决策交给客户端去做，让客户端多承担一块，好好做他的“一事经理”。
突然服务端C发觉前端回馈的消息柱塞了，不乐意了。又是因为开发软件因素，无法去临时更改，于是把一些次要的消息也交给客户端处理，服务端常呼了一口气，轻松了。
写到这里插段题外话：我也觉得很小的一处盖房子，讲那么多。初步打算是讲完简单的时间同步后，会讲RPG内的多人同屏同步和组队状态显示正确问题。之前在公司无话事权，可惜没有早期介入那个项目，因个人观念冲突，多人同步问题未解决就换新公司，未尝是遗憾。
网游一旦出现制作工艺错了，敢去提的不多，除非捅大篓子了，还是继续往下做改进它。或许我意见不多多，混得更好。这行又要关注进度，又要改需求，做完的随时会delete，做为测试的我，看到程序这么纠结深感不容易。
继续话题 一个简单的过程：
客户端使用了寒冰箭，30米距离，寒冰箭暂定必然会命中，寒冰箭外置Cd6秒，物理释放3秒。释放结束开始计算，上个寒冰箭至下个寒冰箭也就是说一共需要约9秒，寒冰箭发出1箭命中了，怪物追击玩家为2米/秒，人物移动退后为4米/秒，准备再发一枚，立即释放时发现CD未到。
前讲一个过程没有受到阻塞时，遵守这一个流程。一切由请求去关联客户端和服务端看起来十分美好。但在游戏设计中，关联事务过多，还是需要建立一个完善的机制。
这就是客户端被动请求。考虑到关系平衡的战斗和玩家交互的影响，需要在二者之间建立1个ping的系统。这个系统本质意义上不是为了防外挂而服务的。
众所周知，游戏的体验感和平衡感都很重要，而过多的延迟，将大大影响游戏的体验感而导致流失。第二章放技能所说的，条件满足，传参验证通过了，技能就打了出去。如果延迟过高，完善的客户端保护下，技能会中断了，变相了影响了平衡。
服务器记录一个用户的客户端数据状态，当ping值较小，根据ping值，分为等待和执行该次行为。响应消息的同时进入等待，并且阻塞，服务器进行逻辑验证后，才可以执行动作。
介于延迟闪断，需要在本地建立一个有验证队列，消息入队按一定的规则等待验证，同时保存一份当前状态。这也是目前游戏通用的办法，具体工艺按需求改动。
注意这里如果是不满足条件类的，是不会加入队列，不会先响应再执行。
当ping值较大，客户端响应玩家消息，同时执行动作。同样放入队列，区别是个无验证信息的队列。
服务端最后通过请求，把消息反馈给客户端，带上客户端校对过的本地时间。
验证不通过，如果是释放1个技能，则技能打断。如果是一个策略游戏的建筑cd，则该次请求失败。
验证通过，顺利走完这个过程，客户端根据从服务器获得校对时间加上预测时间，双方验证结束后，寒冰箭释放出去命中，参照对象掉血，屏幕滑动悬浮上移的数字。同理盖的房子也一样。
而不同步的坏处，除了感观上的，还是会对程序造成B 类以上的bug。
本文主要阐述的是程序新人或者热爱游戏设计的非程序都能看明白的。我觉得概念比理论重要，只要概念清了，没啥完成不了的。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |