【问题标题】:Multiplayer game NodeJS, HTML, JS - server/client side validation多人游戏 NodeJS、HTML、JS - 服务器/客户端验证
【发布时间】:2018-10-26 06:20:28
【问题描述】:

我的问题更多与游戏中动作的验证有关,游戏是跳棋。我正在开发一个跳棋游戏,在 html、css、js 和 nodeJS 中,游戏将是多人游戏。

所以我的问题是关于验证,最好的方法是什么。

现在所有的验证(有效的移动等)都是在客户端完成的(当然必须在服务器端)。

我的问题是,最好的方法是什么:

  1. 具有客户端验证,如果验证正常,则将验证发送到服务器并在那里验证,如果一切正常,则更改下一个玩家的回合,否则服务器拒绝移动,玩家必须做一个有效的动作。

  2. 没有客户端验证,只是基础,所有验证都在服务器端完成。

场景1:我认为这是最好的,因为我们不那么依赖服务器,如果移动客户端出错,它甚至不会将它发送到服务器,如果玩家有恶意(修改代码)尝试做坏动作有服务器端验证。

场景 2:我们更依赖服务器,它会消耗更多的资源,并且对于所有在线玩家来说会更慢,但在客户端会有点“快”,因为没有那么多验证与场景 1 相同。

我认为场景 1 是最好的方法,因为:

  • 更多的安全性、客户端和服务器验证
  • 其他玩家的延迟更少,因为只有来自客户端的经过验证的动作才会在服务器中得到验证
  • 更少的资源 = 更少的基础设施,因此总体上更便宜。

您有什么意见,或者您有更好的方法吗?

感谢大家的阅读。

【问题讨论】:

  • 客户端验证是为了方便,服务器端是为了安全;)两者都有,每个人都会开心

标签: javascript html node.js


【解决方案1】:

我会说 senario 1 更​​好。

您需要同时使用这两种类型的验证。当用户点击时,通过 javascript 验证在客户端显示运动,并在后台将运动代码发送到服务器进行验证,以便坐在另一个人上的玩家可以看到它。无论如何,您必须将数据发送到服务器,以便其他玩家可以看到玩家的移动。

添加客户端验证也可以防止对服务器的不必要请求,这也会增加玩家的等待时间。

【讨论】:

    【解决方案2】:

    这个问题对于 SO 来说可能有点过于开放和基于意见,但这里是:

    就我个人而言,我认为让客户端充当游戏服务器的“观察者”是理想的。游戏服务器应具有权威性,并执行所有逻辑以确保一致性。

    我现在正在开发一个联网的 JS 游戏 + 引擎,并按如下方式处理:

    服务器向所有客户端广播 2 个带有时间戳的游戏状态。然后每个客户端在状态n 和n+1 之间进行插值。在此期间,任何用户输入都将被发送回服务器,然后将其合并到状态n+1 和n+2 中,在下一次广播中发送。当客户端在插值中到达n+1 时,n+1 将使用新的n+1 和n+2 对进行更正。

    这意味着如果一个事件在插值开始时被触发并且在下一次状态广播之前不广播给其他客户端,则客户端最多可以体验 1 个滴答的延迟。这可能需要大约 200 毫秒才能被注意到,但根据我的经验,这是可以容忍的。

    我之所以采用这种方法,很大程度上要归功于 Gabriel Gambetta 的这篇非常有用的文章:

    I. Client-Server Game Architecture

    II. Client-Side Prediction & Server Reconciliation

    III. Entity Interpolation

    IV. Lag Compensation

    显然我不能包含所有文章,但我上面写的内容的要点在第一篇文章的这张图片中:

    【讨论】:

    • 很好的资源,但我认为这更侧重于像反恐精英这样的游戏,每个毫秒都很重要。游戏是跳棋,像 20 毫秒这样的小延迟不会有什么大不了的,因为这种延迟只会发生在对手玩家身上,而不是实际移动棋子的玩家,因为客户端已经验证了所有内容并承认了移动,然后服务器收到请求,如果一切正常,则更改玩家回合,如果没有,则在客户端撤消玩家回合。
    • 是的。这在 FPS 之类的游戏中最为重要。我正在使用 RTS 的方法,其中单元切换方向或活动之间的 100 毫秒延迟是不明显的。尽管如此,我仍然认为拥有权威服务器是最好的方法,也是为了防作弊。另外,在每个客户端上复制相同的场景只是在浪费时间。在回合制游戏中,完全没有理由这样做,因为延迟不是问题。
    【解决方案3】:

    我通常更喜欢在服务器端进行验证,原因如下:

    • 客户端未加载验证负担。
    • 如果验证失败,后端会知道,因此会集中记录失败,您可以根据多个失败案例决定某些操作。 (发布消息?发送电子邮件?查看故障趋势?)
    • 更轻松的代码调试。
    • 客户端代码在安全方面不值得信赖。
    • 与游戏相关,无论如何您都必须发送更新,因此,如果您的代码都是服务器端的,您的代码将更易于管理,并且您可以优化它的各个方面。

    tip:使用socket.io,非常容易掌握,非常可靠,支持服务器推送消息

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-07-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-05-08
      • 2015-03-24
      • 1970-01-01
      相关资源
      最近更新 更多