Questions tagged «networking»

通过电缆绑定或无线通信链接将两台或更多台计算机连接在一起,以进行信息交换。

7
如何为测试目的模拟不良的互联网连接?
我正在开发在线多人游戏。当我在局域网上对其进行测试时,它可以很好地工作,但是在发布它之前,我想测试一下对于与服务器连接不佳的用户的用户体验。在本地环境中,如何模拟具有高延迟,低带宽,抖动和偶发数据包丢失的不良Internet连接?

6
如何编写网络游戏?[关闭]
基于为什么开发MMO如此困难?: 网络游戏的发展并非易事。不仅要克服延迟,而且还要防止作弊,状态管理和负载平衡,这是一大障碍。如果您没有编写网络游戏的经验,那么这将是一个困难的学习练习。 我知道有关套接字,服务器,客户端,协议,连接之类的理论。 现在,我想知道如何学习编写网络游戏: 如何平衡负载问题? 如何管理游戏状态? 如何保持事物同步? 如何保护通信和客户端免受逆向工程的影响? 如何解决延迟问题? 应该在本地计算哪些内容,在服务器上计算哪些内容? ... 是否有关于此的好书,教程,网站,有趣的文章或其他问题? 我正在寻找广泛的答案,但是也可以使用特定的答案来学习区别。

10
在数据量大的实时游戏中,UDP是否仍优于TCP?
我知道对于高数据使用率的实时多人游戏通常建议使用UDP。 大多数文章都是有用的,并且由于互联网上传输的所有数据中约80%是TCP,因此必须对TCP进行很多优化。 这让我感到奇怪:UDP在速度和延迟方面是否仍然优越?最近的TCP优化是否可以使TCP的性能优于UDP?
71 c++  networking  udp  realtime 

9
TCP协议是否足以应付实时多人游戏?
过去,拨号/ ISDN /慢速宽带上的TCP连接导致游戏断断续续,因为单个丢包会导致重新同步。这意味着许多游戏开发人员必须在UDP之上实现自己的可靠性层,或者他们将UDP用于可能会被丢弃或乱序接收的消息,并将并行TCP连接用于必须可靠的信息。 鉴于现在普通用户的网络连接速度更快,FPS之类的实时游戏能否通过TCP连接提供良好的性能?
57 networking 

9
面对浮点非确定性,确定性游戏怎么可能?
为了使游戏像RTS网络游戏一样,我在这里看到了许多答案,这些建议建议使游戏完全具有确定性。那么您只需要彼此转移用户的操作,并稍微延迟所显示的内容,以便在呈现下一帧之前“锁定”每个人的输入。这样,诸如单位位置,健康状况之类的事情就不需要通过网络不断更新,因为每个玩家的模拟都是完全相同的。我也听到过建议进行重放的同一件事。 但是,由于浮点计算在机器之间,甚至在同一机器上同一程序的不同编译之间是不确定的,真的可以这样做吗?我们如何防止这一事实在整个游戏中引起波动的玩家(或重播)之间产生微小差异? 我听说有人建议完全避免使用浮点数int来表示小数的商,但这对我来说并不实用-例如,如果我需要取一个角度的余弦值怎么办?我是否真的需要重写整个数学库? 请注意,我主要对C#感兴趣,据我所知,在这方面,C#与C ++存在完全相同的问题。


4
非射击者的运动预测
我正在开发具有中等规模的多人游戏的等距2D游戏,大约有20-30个玩家同时连接到持久性服务器。在实现良好的运动预测实现方面,我遇到了一些困难。 物理/运动 游戏没有真正的物理实现,但是使用基本原理来实现运动。状态更改(即/鼠标下移/上移/移动事件)不是持续轮询输入,而是用于更改玩家正在控制的角色实体的状态。玩家的方向(即东北方向)与恒定速度结合在一起,并转换为真实的3D矢量-实体的速度。 在主游戏循环中,在“平局”之前调用“更新”。更新逻辑触发“物理更新任务”,该任务以非常零的速度跟踪所有实体,并使用非常基本的积分来更改实体位置。例如:entity.Position + = entity.Velocity.Scale(ElapsedTime.Seconds)(其中“ Seconds”是浮点值,但相同的方法适用于毫秒整数值)。 关键是没有插值用于运动-基本物理引擎没有“先前状态”或“当前状态”的概念,只有位置和速度。 状态更改和更新数据包 当玩家控制的角色实体的速度发生变化时,“移动化身”数据包将发送到服务器,其中包含该实体的动作类型(站立,行走,奔跑),方向(东北)和当前位置。这与3D第一人称视角游戏的工作方式不同。在3D游戏中,速度(方向)会随着玩家的移动而逐帧变化。发送每个状态更改将有效地每帧发送一个数据包,这太昂贵了。取而代之的是3D游戏似乎忽略了状态更改,而是以固定的时间间隔(例如,每80-150毫秒)发送“状态更新”数据包。 由于速度和方向更新在我的游戏中的发生频率要低得多,因此我可以避免发送每个状态更改。尽管所有物理模拟都以相同的速度发生并且具有确定性,但是延迟仍然是一个问题。因此,我发出常规的位置更新数据包(类似于3D游戏),但发送频率却要低得多-现在每250毫秒发送一次,但是我怀疑有了良好的预测,我可以轻松地将其提高到500毫秒。最大的问题是,我现在已经偏离规范了-所有其他在线文档,指南和示例都会发送例行更新并在这两种状态之间进行插补。看来与我的架构不兼容,我需要提出一种更好的运动预测算法,该算法更接近(非常基本的)“网络物理学”架构。 然后,服务器接收该数据包,并根据脚本根据其移动类型确定玩家的速度(玩家是否可以跑步?获取玩家的跑步速度)。一旦具有速度,便将其与方向相结合以获得向量-实体的速度。会进行一些作弊检测和基本验证,并且服务器端的实体将使用当前速度,方向和位置进行更新。还执行基本限制,以防止玩家因移动请求而淹没服务器。 更新其自身的实体后,服务器向范围内的所有其他玩家广播“头像位置更新”包。位置更新包用于更新远程客户端的客户端物理模拟(世界状态),并执行预测和滞后补偿。 预测和滞后补偿 如上所述,客户具有自己的地位。除作弊或异常情况外,服务器将永远不会重新定位客户端的头像。客户的化身不需要进行推断(“立即移动并稍后更正”)-玩家看到的是正确的。但是,所有正在移动的远程实体都需要某种类型的外推或内插。客户的本地模拟/物理引擎中显然需要某种类型的预测和/或滞后补偿。 问题 我一直在努力使用各种算法,并且遇到许多问题: 我应该外推,内插还是同时进行?我的“直觉”是我应该使用基于速度的纯外推法。客户端接收状态更改,客户端计算出补偿滞后的“预测”速度,而常规物理系统则完成其余工作。但是,它与所有其他示例代码和文章都不一样-它们似乎都存储了许多状态并在没有物理引擎的情况下执行插值。 当数据包到达时,我尝试在固定的时间段内(例如200ms)用数据包的速度对数据包的位置进行插值。然后,我利用插值位置和当前“错误”位置之间的差值来计算新矢量,并将其放置在实体上而不是发送的速度上。但是,假设另一个数据包将在该时间间隔内到达,并且很难猜测下一个数据包何时到达-尤其是因为它们并非都按固定的时间间隔到达(即,状态也发生变化)。这个概念从根本上是有缺陷的,还是正确的,但是需要一些修复/调整? 远程播放器停止播放时会发生什么?我可以立即停止该实体,但是它将定位在“错误”位置,直到再次移动为止。如果我估计一个矢量或尝试进行插值,则会遇到一个问题,因为我不存储先前的状态-物理引擎无法说“到达X位置后需要停止”。它只是了解速度,没有什么更复杂的了。我不愿意将“数据包移动状态”信息添加到实体或物理引擎,因为它违反了基本的设计原则,并在游戏引擎的其余部分流失了网络代码。 当实体碰撞时会发生什么?共有三种情况-控制玩家在本地发生冲突,两个实体在位置更新期间在服务器上发生冲突,或者远程实体更新在本地客户端上发生冲突。在所有情况下,我都不确定如何处理碰撞-除了作弊外,这两种状态都是“正确的”,但是处于不同的时间段。在远程实体的情况下,将其拖过墙是没有意义的,因此我在本地客户端上执行碰撞检测并使其“停止”。基于上面的第二点,我可能会计算出一个“校正向量”,该向量将不断尝试将实体“穿过墙”移动,但此操作将永远不会成功-远程化身被卡在那儿,直到错误变得过高并“捕捉”到位置。游戏如何解决这个问题?

2
如何将此实体系统联网?
我已经为FPS设计了一个实体系统。它基本上是这样的: 我们有一个“世界”对象,称为GameWorld。它包含一个GameObject数组以及一个ComponentManager数组。 GameObject拥有一个Component数组。它还提供了一个非常简单的事件机制。组件本身可以向实体发送事件,该事件将广播到所有组件。 Component基本上是赋予GameObject某些属性的东西,并且由于GameObject实际上只是它们的容器,因此与游戏对象有关的所有事情都发生在Components中。示例包括ViewComponent,PhysicsComponent和LogicComponent。如果需要它们之间的通信,可以通过使用事件来完成。 ComponentManager只是一个类似于Component的接口,对于每个Component类,通常应该有一个ComponentManager类。这些组件管理器负责创建组件,并使用从XML文件之类读取的属性来初始化它们。 ComponentManager还负责组件的大量更新,例如P​​hysicsComponent,我将在其中使用外部库(该库一次执行世界上的所有操作)。 为了实现可配置性,我将为实体使用一个工厂,该实体将读取XML文件或脚本,创建文件中指定的组件(这还将在正确的组件管理器中添加对它的引用以进行批量更新),以及然后将它们注入GameObject对象。 现在出现了我的问题:我将尝试将其用于多人游戏。我不知道该如何处理。 首先:客户从一开始就应该拥有哪些实体?我首先要说明单人引擎如何确定要创建的实体。 在关卡编辑器中,您可以创建“画笔”和“实体”。刷子用于墙壁,地板和天花板等事物,基本上是简单的形状。实体是我告诉过您的GameObject。在关卡编辑器中创建实体时,可以为其每个组件指定属性。这些属性直接传递给实体脚本中的类似构造函数的对象。 保存要加载的引擎的级别时,它会分解为实体及其关联属性的列表。画笔将转换为“ worldspawn”实体。 当您加载该级别时,它只是实例化所有实体。听起来很简单,是吗? 现在,对于实体的联网,我遇到了许多问题。首先,从一开始就应该在客户端上存在哪些实体?假设服务器和客户端都具有关卡文件,则客户端可能会实例化该关卡中的所有实体,即使它们只是出于服务器上的游戏规则而存在。 另一种可能性是,客户端在服务器发送有关实体的信息后立即实例化该实体,这意味着客户端将仅具有其所需的实体。 另一个问题是如何发送信息。我认为服务器可以使用增量压缩,这意味着它仅在发生变化时才发送新信息,而不是在每帧都向客户端发送快照。尽管这意味着服务器必须跟踪每个客户端当前所知道的信息。 最后,应该如何将网络注入引擎?我在考虑一个组件NetworkComponent,它被注入到每个应该联网的实体中。但应该如何在网络组件知道什么变量网络,以及如何访问这些,最后如何在客户端上相应的网络组件应该知道如何改变网络变量? 我在处理此问题时遇到了很大的麻烦。如果您能帮助我,我将不胜感激。我也欢迎有关如何改进组件系统设计的提示,因此不要害怕提出建议。

4
客户端预测如何工作?
我已经阅读了Valve + Gafferon和Google的数百页内容,但是出于任何原因,我都无法理解客户预测。 据我了解,基本问题是: 客户端A在以下位置发送输入 T0 服务器在以下位置接收输入 T1 所有客户都在以下位置收到更改 T2 在T2然而,使用客户预测,客户端A现在是在合适的位置来T4。 在预测服务器将接受移动请求时,如何确保客户端A不在服务器之前?显然,它们一直都在前进,这导致返回到服务器上次看到它们的位置。经过我尝试的所有更正,当您停止时这仍然很明显,因为服务器在您身后停止了

5
联网2D游戏的延迟补偿
我想制作一个2D游戏,基本上是物理驱动的沙箱/活动游戏。我确实有些不明白。根据研究,似乎服务器更新仅应大约每100毫秒一次。我可以看到这对玩家是如何工作的,因为他们可以同时模拟物理并通过插值进行滞后补偿。 我不明白的是,这对于其他玩家的更新如何起作用。如果客户仅每100毫秒就收到玩家位置的通知,我就看不到这是怎么回事,因为在100毫秒内会发生很多事情。玩家可能在那个时候两次改变了方向。我想知道是否有人会对这个问题有所了解。 基本上,这对于射击之类的东西如何起作用? 谢谢

3
如何在MMO游戏中处理大量拾音器
Minecraft之类的游戏或任何带有拾音器的MMO游戏如何处理它们? 假设您每次挖掘地形时都会产生3滴“污垢”。假设每个项目都有每帧计算的旋转动画。如果全世界的取件数量非常高,那么对于给定服务器中的客户端而言,这将是无用的大量帧开销,因为很可能其中许多取件项距离您仅光年。 所以我认为您只需要在接近本地玩家的拾音器上“做东西”,但这仍然意味着我必须检查每一帧是否有其他拾音器项目足够近以至于必须开始动画。 我的实际问题是:其他MMO如何解决此问题?


9
增量压缩如何减少通过网络发送的数据量?
许多游戏使用增量压缩技术来降低发送的数据负载。我不明白这种技术实际上如何降低数据负载? 例如,假设我要发送职位。如果不进行增量压缩,则发送vector3带有实体确切位置的,例如(30, 2, 19)。使用增量压缩时,我发送的vector3数字较小(0.2, 0.1, 0.04)。 我不明白如果两条消息都是vector3-每个浮点数为32位-32 * 3 = 96位,它将如何降低数据负载! 我知道您可以将每个浮点数转换为一个字节,然后将其从字节转换回浮点数,但这会导致可见的精度错误。

2
实时FPS游戏向服务器发送什么?
将本地播放器的位置告诉服务器的正确方法是什么?一些文档说,最好在产生输入时发送输入。还有一些文件说,客户以固定的间隔发送其头寸。 使用发送输入方法:如果玩家按住方向键该怎么办?这意味着我需要在每个帧中将包发送到服务器。是不是太多了?鼠标输入还可以播放播放器。这是一个例子: http://www.gabrielgambetta.com/fpm_live.html 如何以固定间隔的方式发送头寸。它向服务器发送的消息太少。但这也会降低响应速度。 那么哪种方法更好呢?

9
防止非官方客户端参与网络游戏的技术?
在多人网络游戏中,存在哪些技术可以尝试确保用户与官方客户端应用程序连接,而不是与某些被黑客入侵的客户端应用程序连接? 我意识到可能没有确定的方法可以做到这一点,但是我对可以用来减轻问题的技术很感兴趣。 我对可以用于基于Web的游戏的任何技术特别感兴趣,但是我想大多数可以普遍应用。 谢谢!

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.