游戏可以被认为是实时系统吗?

12
我一直在研究实时系统及其工作原理等方面。我看了维基百科上的一篇文章,说每步棋都有时间限制的国际象棋游戏可以被视为实时系统,因为程序必须在规定时间内计算出下一步棋。那其他游戏呢?我们知道,游戏通常都会尝试以25帧/秒(FPS)以上的速度运行,如果低于这个阈值(顺便说一下,我用的是预定义的阈值),就只是性能受到了一定影响,而不至于导致游戏崩溃。
此外,游戏还有必须处理的事件。用户使用键盘/鼠标,系统必须在(再次)预先定义的时间内相应地处理这些事件,否则游戏将被认为“失败”。
噢,我现在只谈单人游戏,以简化问题。
听起来游戏符合软实时系统的标准,但我想知道是否遗漏了什么……谢谢。

一些游戏可能是可以的。射击游戏和车辆模拟器可能是最有可能的。 - FrustratedWithFormsDesigner
为什么是它们而不是其他的呢?据我所知,系统必须在处理数据(由玩家移动物体或与物理相关的数据)时显示信息(即游戏图形、模型等)。这几乎描述了每一个现代游戏,不是吗? - Harry
1
这取决于您是否认为在特定时间框架内未返回结果是失败的定义。对于FPS,可能不会引起注意,或者实际上可能导致严重的延迟(我们是否将其视为系统故障?) - Jean Azzopardi
我同意这取决于你如何定义“失败”。请注意,PvP游戏最容易将延迟情况视为失败,原因是显而易见的。 - o0'.
9个回答

19

来自维基百科

如果一个系统的总体正确性不仅取决于其逻辑正确性,还取决于执行该操作所需的时间,则称该系统为实时系统。经典观念认为,在硬实时或即时实时系统中,超过截止日期后完成操作被认为是无用的 - 最终,这可能导致整个系统的严重故障。另一方面,软实时系统将容忍这种延迟,并可能以降低服务质量(例如,在显示视频时省略帧)作出响应。

因此,我认为这些FPS游戏绝对是软实时系统的例子。如果有些帧被丢弃,那没关系。维基百科还指出,国际象棋引擎如果未能在分配的时间内给出一步走法则被视为关键故障,因此是硬实时系统。

另一个想法是FPS中的人工智能。如果它不能及时返回结果并最终导致冻结,那么可以将其视为“失败的系统”。


5

是的,但需要强调实时性。

实时性并不仅仅是快速的表现,而是指在一定时间内得出正确结果的定义中必须包含“足够及时”的要求。


1

你可以这样称呼它们,但我认为这会扭曲“实时”的定义。在行业中,“实时”通常意味着事件将在最长时间内得到处理,而这个时间通常是毫秒甚至微秒的问题。相比之下,象棋程序的速度非常缓慢(至少就交互而言)。对于编写“缓慢”的交互式游戏,不需要满足硬实时约束所需的特殊编程约束。

“交互式”是一个适用的词。至于视频游戏,“FPS”实际上已经成为一个用来分类此类程序的术语,这些程序的特点是循环更新图形并计算游戏机制。


我是一名游戏玩家,除非你在谈论每秒帧数,否则我从未听说过将游戏通称为“FPS”。 - RCIX
这正是我所说的。这一测量方法被用来命名这个流派。 - Carl Smotricz
一个帧必须在20毫秒或更短的时间内渲染,才能达到平滑的效果。 - recursive

1
维基百科表示(这也是我在大学里学到的):如果一个操作的总正确性不仅取决于其逻辑正确性,还取决于执行该操作的时间,则该系统被称为实时系统。实时系统以及它们的截止日期根据错过截止日期的后果进行分类。
一般来说,大多数游戏都是软实时的,因为虽然帧速率目标(例如30 fps)定义了截止日期,但偶尔未能满足此截止日期并不会使底层计算无用。失败会降低计算的有用性,因为它们会降低游戏体验的质量。
正如您提到的,象棋引擎是实时系统的一个例子。然而,这通常是一种硬实时应用程序,因为超过时间控制会导致自动失误,计算结果将变得无用。

0

实际上,我认为游戏并不是真正的实时系统。事实上,在大多数情况下,它们在某些时候相当不受调度影响,特别是在加载时。

当你坐着盯着加载进度条时,系统会因为缓存未命中而变得很慢,通常会受到I/O限制。但每个人都觉得这是可以接受的。

当游戏实际运行时,当然,你可以认为它是实时的。但如果由于即时加载新纹理而使游戏变得I/O限制,人们也会觉得这是可以接受的,只要它不经常发生。回合制游戏同样如此,当你等待电脑的回合时。

当考虑到多人游戏时,情况变得更加混乱。尤其是MMO游戏,它们“在过去”运行以掩盖延迟问题。所有这些都只是掩盖了游戏真正非实时的本质。

编辑:我的实时系统定义是指使用每个CPU周期进行有意义工作的系统。例如,如果系统因为I/O限制而被调度出去,那么它就不是真正的实时系统。


你的定义有点偏差:实时系统是指每个指令都保证在指定时间内完成的系统。事实上,许多实时系统还保证了一个更低的下限。实时系统的重点不是最佳性能,而是可预测的性能。这可能意味着处理器需要在几个周期内旋转其轮子以符合规格要求。 - tloflin
是的,有时候由于I/O限制会导致性能不可预测。 - Blindy

0
我的x386上运行的波斯王子游戏看起来对我来说是实时的,没有明显的延迟。然而,如果条件“不理想”,性能肯定会恶化,并且游戏在这种情况下没有任何性能保证。
要使游戏真正实时,它不能仅仅是一款游戏。它必须控制硬件、操作系统、可用资源,并定义这些保证有效的条件。我认为没有任何游戏做到了这一点。
虽然我部分同意软实时的定义。我不认为任何游戏都会发布任何性能服务水平协议,但他们会尽力在大多数情况下实现实时性 - 这符合他们的最佳利益。话虽如此,除了定义之外,大多数游戏机- Xbox、PS[x]、Wii等都针对实时体验进行了高度优化,并且在实现了该目标。可能只有极少数情况下会出现性能下降的情况,例如房间温度接近沸点时,但这也适用于大多数所谓的实时系统。必须满足一组特定条件,才能在实时方面表现最佳,否则性能会下降。

SLA是什么意思?服务水平协议?帧率(因此响应时间的上限)通常是商业游戏技术要求的一部分。 - Kylotan
游戏开发者在游戏发布后,这些技术要求有多具约束力? - Anurag

0
“实时”是一个模糊的概念。更准确地说,应该根据“硬度”来讨论实时系统的特征。使实时系统更难的特征包括:
  • 有界延迟(截止日期)
  • 有界抖动(即响应时间的变化)
  • 未能满足截止日期的后果,以及系统在错过截止日期或完全失败时“安全失败”的能力。
  • 截止日期的短暂性。实时系统通常必须在一秒内响应,大多数情况下在100毫秒内响应。
因此,虽然从技术上讲,国际象棋游戏符合“实时”定义,但实际上它太软了,这个术语并不适用。另一个极端是战斗机中的“电传飞控系统”,如果未能满足时间要求,可能会导致飞机坠毁。

0
我会将游戏描述为硬实时系统。以射击游戏为例 - 如果你不能在敌人开枪之前射中他,那么能够射中他就毫无意义,你就输了。对于许多其他类型的游戏,你也可以做出类似的比喻。任何玩家实时进行游戏的游戏都可以这样描述。
也许它们的实现并不是硬实时的,但玩起来确实是这样的。

你正在描述游戏玩家的表现,而不是游戏本身。玩家死亡并不意味着游戏失败,这是标准操作程序。 - recursive

0

虽然我们认为我们的系统是(软)实时的,但我想知道的是模拟保真度方面的工作。

为了将所有内容适应于16.6ms的时间段,我们通常会在一些地方做较低保真度的工作,这些地方可能不影响结果,但会产生一个与采取少量捷径时有所不同的结果(由“屏幕闪烁的图像”测量)。明显的顶层捷径是反锯齿和景深,对观察者来说更微妙且不太明显的是当我们有很多敌人出现时,“低保真度”敌人智能的变化。例如,我参与开发的一些早期游戏中,我们没有时间更新每个敌人的“世界观”,因此我们使用轮流方式处理敌人,并将玩家角色与敌人交织在一起。因此,如果有五个敌人出现,就需要十帧才能更新每个敌人(因为玩家每隔一帧更新一次)。但是这并没有使动画变得不流畅,因为我们仍然运行正确的动画,但敌人的决策可能基于旧数据或已失效的数据。

事实证明,这样做的有趣效果是敌人会像处理信息需要一些时间一样去做事情。例如,即使玩家已经死亡,他们也会继续向玩家射击,或者他们可能要花费一些时间才能注意到他们的同伴已经全部被杀害,并在比我们运行“完整”模拟更新稍后的某个时刻触发他们害怕逃跑状态。
因此,为了符合实时标准,进行低分辨率计算以适应你的时间是否是可以接受的折衷方案?

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接