我试图了解服务器 - 客户端网络如何适用于实时多人游戏。
假设我正在构建像FPS这样的实时多人游戏。
如果玩家 A 射击玩家 B ，后端server需要告诉玩家 B 他们被枪杀了。
我知道如何让玩家 A 告诉后端server他开了一枪，只是向server发送了一个请求，但后来如何制作后端server告诉玩家B他们被枪杀了吗？
玩家 B 是否必须经常检查后端server 每0.1秒以查看是否发生了某些事情，或者是否更高效方式吗
答案 0 :(得分：1)
让我们向前跳几个月。你的游戏有几百万次下载，你的server部分必须24/7/365全天候在线应对大量敏锐的游戏玩家。
此格局将有助于展示分布式系统设计属性的核心重要性，以及任何低延迟控制软件的痛苦（游戏无可置疑案例）将放在桌面上。
为何延迟？优秀的游戏设计致力于创造和维护真实的用户体验。让我们举个例子 - 如果玩家 A 达到摧毁目标 X ，然后瞄准 Y ，最后瞄准 Z 在最后几分钟内，但是 C 的玩家在＆＃34;之前已经击中了 A 甚至＆＃34;玩家 A 开始拍摄，而由于端到端游戏连接延迟的差（不等）延迟，＆＃34;子弹＆＃34;从 C 到达server＆＃34;迟到＆＃34;并且在＃34;之后分发了＃34;目标 X ， Y 和 Z 被确认销毁 - 你会杀死 A 并重生 X ， Y ， Z 或者您会离开 X ， Y ， Z 爆炸，让 A 以后死亡，在蓝天下没有警告，或者你会让他/她继续前进，就好像没有被玩家 C 杀死一样？ - 您的平台游戏体验对于不仅仅是其中一个 C ， X ， Y ， Z 参与。用户讨厌这个。火焰将跟随非常快。
时间的延迟变化（延迟抖动）是另一个问题 - 一些非凡的平台，IL2-Sturmovik就是这样的情况，可以说出一些经验丰富的＆＃34;跳跃＆＃34;由于这种类型的未处理延迟相关的分布式游戏引擎控件而导致的游戏内对象。游戏社区很快就意识到了这种障碍，而黑人MOD-ers催生了许多MOD，其中这种弱点被开发成为（欺骗）玩家的不公平利益，他们受益于阻止数据包，分发游戏中的现实更新并使用这个黑客他们的由于某些飞机的游戏3D坐标迟到/很晚到达，飞机变得隐身（攻击者和子弹不受攻击），有时甚至是3D场景中的UFO-ed-ed ;更新。
如果您意识到， 0.1 sec 不会高于 10 FPS 的游戏内现实更新，而当前的游戏内现实力争为高保真用户体验提供50 - 80 - 120 FPS，你将面临的痛苦会更高。
ZeroMQ 是分布式系统的精彩框架。掌握这个工具无疑将帮助您学习很多关于非阻塞，关于有效的端到端消息传递（任何类型的更新，控制，信令），您还将学习，如何减少网络流量（想象10个游戏玩家v / s 1.000游戏玩家v / s 100.000游戏玩家网段加载）。
ZeroMQ 还可以帮助您在多台服务器端计算机之间加入工作负载平衡，从而随着玩家数量的增加提高后端功能 - {{ 1}} 支持几乎线性可扩展性，这在一个学习曲线中值得一些痛苦，不是吗？
服务器端通常有许多职责要同时处理。游戏中分布式消息传递框架事件处理引擎的过度简化的核心循环看起来类似于：
ZeroMQ您可能会对更多详情感兴趣 - What is a difference between WebSockets and ZeroMQ
但是for your further questions you might want to see a bigger picture on this subject >>> 更多参数，一个简单的信号平面/消息传递平面插图和指向必读书籍的直接链接来自Pieter HINTJENS。
答案 1 :(得分：0)
从服务器获取数据有两种方法：
1）同步方法（或轮询方法） - 这是你所描述的 - 检查每个间隔的更新。
2）异步方法（或推送方法） - 对于您描述的用例更有效 - 客户端订阅更新一次，服务器在客户端获得更新时通知客户端。例如，您可以使用websockets实现它。如果您未绑定http - 仅限图层，则可以使用 ZeroMQ 来实现它。