我的问题与游戏中的动作验证更相关,游戏是Checkers。我正在开发一个Checkers游戏,在html,css,js和nodeJS中,游戏将是多人游戏。
所以我的问题是关于验证,什么是最好的方法。
现在所有的验证(有效的移动等)都在客户端完成(当然必须是服务器端)。
我的问题是,最好的方法是什么:
进行客户端验证,如果验证结果正常,则将验证发送到服务器并在那里验证是否一切正常改变下一个播放器,如果不是服务器拒绝移动并且播放器必须做一个有效的运动。
没有客户端验证,只是基础知识,所有验证都在服务器端完成。
场景1:我认为这是最好的,因为我们不会严重依赖服务器,如果移动客户端是错误的,那么它甚至不会将其发送到服务器,如果是一个意图不好的玩家(修改代码)尝试做坏动作有服务器进行边验证。
场景2:我们更依赖服务器,它将消耗更多资源,并且对于所有在线玩家整体而言会更慢,但在客户端会有一点“更快”,因为没有那么多方案1中的验证。
我认为场景1 是最佳方法,因为:
您有什么看法,或者您有更好的方法?
感谢大家的阅读。
答案 0 :(得分:1)
对于SO来说,这个问题可能有点过于开放和基于意见,但这里有:
就我个人而言,我认为让客户表现为游戏服务器的“观察者”是理想的选择。游戏服务器应具有权威性,并采用所有逻辑来确保一致性。
我正在开发一个联网的JS游戏+引擎,并按如下方式处理:
服务器向所有客户端广播带有时间戳的2个游戏状态。然后,每个客户端在状态n
和n+1
之间进行插值。在那段时间内,任何用户输入都会被发送回服务器,然后将其合并到下一次广播发送的状态n+1
和n+2
中。当客户在插值中达到n+1
时,n+1
会使用新的n+1
和n+2
对进行更正。
这意味着如果在插值开始时触发事件并且在下一个状态广播之前不向其他客户端广播,则客户端可以经历最多1个tick的延迟。这可能在它变得明显之前大约200毫秒,但根据我的经验,这是非常容忍的。
由于Gabriel Gambetta的这篇非常有用的文章,我开始采用这种方法:
I. Client-Server Game Architecture
II. Client-Side Prediction & Server Reconciliation
显然我不能包括所有的文章,但我在上面写的内容的主旨是在第一篇文章的这张图片中:
答案 1 :(得分:0)
我会说senario 1更好。
您需要使用这两种类型的验证。当用户点击时,通过javascript验证在客户端显示移动,并在后台将移动代码发送到服务器进行验证,以便坐在另一个上的玩家可以看到它。无论如何,你必须将数据发送到服务器,以便其他玩家可以看到播放器的移动。
添加客户端验证也可以防止对服务器发出不必要的请求,这也会增加播放器的等待时间。
答案 2 :(得分:0)
我通常更喜欢在服务器端进行验证,原因如下:
提示:使用socket.io,它非常容易掌握,非常可靠,支持服务器推送消息