我正处于移动多玩家实时游戏的计划阶段,我正在考虑要实施哪种架构以便在游戏大厅内跟踪状态。
我曾考虑让游戏成为点对点游戏,同一游戏大厅内的所有设备(最多4名玩家)将随着游戏的进行向其他玩家发出自己的位置。我还考虑让玩家连接到服务器和服务器跟踪游戏状态并将状态发送给每个玩家。
如果我采用这条路线并使用节点实现服务器,我需要考虑哪些注意事项?
我预测可扩展性将成为一个主要问题,因为服务器必须跟踪名义上以60 fps运行的每个游戏大厅的状态。如果我有100个活跃的大厅,我可以预见可能出现的问题。是否会出现这种情况,我应该研究一下不同的网络架构吗?或者我可以获得大容量,直到服务器达到最大值?
答案 0 :(得分:2)
在很大程度上取决于游戏类型。 点对点解决方案可能很棘手,除非您在每个客户端上验证它,但是因为您想在移动客户端上运行它会导致游戏速度变慢,因此作弊很容易。
验证中央服务器上的数据并发送经过验证的数据更有意义。
通常,FPS对服务器完全没有影响。 每个客户端只是向服务器发送用户输入而不是每个帧 (按下按钮 - 释放按钮)。 服务器使用所有这些信息并计算需要发生的事情并定期向客户端发送更新。 然后客户端渲染过去200ms(实际上取决于游戏类型)的所有内容,并“预测”服务器在下次更新时将发送的内容,使其看起来流畅。 只要阅读这篇文章,它就会比我更好地解释它:https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
但是,它会比普通网站消耗更多的力量。 但是,单个游说团体不需要彼此通信,因此您可以非常轻松地并行使用3个服务器。 与大多数替代方案相比,您可以期望Node的性能非常好,因为它可以很好地处理并发连接。只要确保你没有运行CPU繁重的东西,因为这几乎会杀死Node(如果你只是接收状态更新并使用基本数学来验证它并再次发送它 - >完美选择)。
希望有所帮助
答案 1 :(得分:-1)
您将遇到的最大问题是Node不是为处理与实时模拟一样对延迟敏感的应用程序而构建的。
HTTP是一种臃肿的协议,它是基于文本的。它不适用于大多数人会考虑多人游戏的游戏类型。它可能适用于高延迟不是Facebook游戏等问题的游戏。