7

“Super Meat Boy”是最近推出的 PC 难度平台游戏，需要出色的控制和像素级完美跳跃。游戏中的物理代码依赖于帧率，锁定为60fps；这意味着如果您的计算机无法全速运行游戏，物理会变得疯狂，导致（除其他外）您的角色运行速度变慢并跌倒在地。此外，如果关闭垂直同步，游戏运行速度非常快。

那些有 2D 游戏编程经验的人能否帮助解释为什么游戏是这样编码的？以恒定速率运行的物理循环不是更好的解决方案吗？（实际上，我认为物理循环用于游戏的某些部分，因为某些实体会继续正常移动，而不管帧速率如何。另一方面，您的角色运行速度正好 [fps/60]。）

这个实现困扰我的是游戏引擎和图形渲染之间的抽象损失，这取决于特定于系统的东西，如显示器、显卡和 CPU。如果，无论出于何种原因，您的计算机无法处理垂直同步，或者无法以 60fps 的速度运行游戏，它就会严重崩溃。为什么渲染步骤会以任何方式影响物理计算？（现在的大多数游戏要么减慢游戏速度，要么跳帧。）另一方面，我知道 NES 和 SNES 上的老式平台游戏在大部分控制和物理方面都依赖于固定的帧速率。为什么会这样，是否有可能在不依赖帧率的情况下以这种方式创建一个patformer？如果将图形渲染与引擎的其余部分分开，是否必然会损失精度？

谢谢，如果问题令人困惑，对不起。

4

3 回答 3

7

没有理由说物理应该依赖于帧率，这显然是一个糟糕的设计。

我曾经试图理解人们为什么这样做。我对公司另一个团队编写的游戏进行了代码审查，我从一开始并没有看到它，但他们在代码中使用了很多硬编码值 17。当我在调试模式下运行游戏并显示 FPS 时，我看到了，FPS 正好是 17！我再次查看代码，现在很清楚：程序员假设游戏将始终具有 17 FPS 的恒定帧速率。如果 FPS 大于 17，他们会进行睡眠以使 FPS 恰好为 17。当然，如果 FPS 小于 17，他们什么也不做，游戏就会变得疯狂（比如以 2 FPS 玩并驾驶汽车时）游戏中，游戏系统提醒我：“太快了！太快了！”）。

所以我写了一封电子邮件，询问他们为什么硬编码这个值并使用它作为他们的物理引擎，他们回答说这样可以让引擎更简单。我再次回答，好的，但是如果我们在无法达到 17 FPS 的设备上运行游戏，您的游戏引擎运行起来非常有趣，但不如预期。他们说这将解决这个问题，直到下一次代码审查。

3 或 4 周后，我得到了一个新版本的源代码，所以我真的很想知道他们对 FPS 常量做了什么，所以我做的第一件事是在 17 之后搜索代码，只有几个匹配项，但是一个其中不是我想看到的：

最终静态 int FPS = 17;

所以他们从所有代码中删除了所有硬编码的 17 值，并改用 FPS 常量。以及他们的动机：现在如果我需要将游戏放在只能运行 10 FPS 的设备上，我需要做的就是将 FPS 常数设置为 10，游戏就会流畅运行。

总之，很抱歉写了这么长的信息，但我想强调的是，有人会这样做的唯一原因是糟糕的设计。

于 2010-12-27T20:41:33.840 回答
2

这里有一个很好的解释为什么你的时间步应该保持不变： http: //gafferongames.com/game-physics/fix-your-timestep/

此外，取决于物理引擎，当时间步长改变时系统可能会变得不稳定。这是因为在帧之间缓存的一些数据是时间步长相关的。例如，迭代求解器的初始猜测（这是解决约束的方式）可能与答案相去甚远。我知道 Havok（许多商业游戏使用的物理引擎）确实如此，但我不确定 SMB 使用哪个引擎。

几个月前在 Game Developer Magazine 上也有一篇文章，说明了如何以相同的初始速度但不同的时间步长实现不同的最大高度和不同的帧速率的跳跃。有一个来自游戏（托尼霍克？）的支持轶事，当在 NTSC 版本的游戏而不是 PAL 版本上运行时可以进行一定的跳跃（因为帧速率不同）。抱歉，我目前找不到问题，但如果您愿意，我可以稍后尝试挖掘它。

于 2010-12-28T00:00:43.557 回答
0

他们可能需要足够快地完成游戏，并决定用当前的实现覆盖足够的用户群。

现在，如果你在开发过程中考虑一下，改造独立性并不是那么难，但我想他们可能会走下一些陡峭的坑。

我认为这是不必要的，而且我以前见过它（一些早期的 3d-hw 游戏使用了相同的东西，如果你看天空游戏会更快，如果你看地面游戏会变慢）。

简直糟透了。对开发人员进行 Bug 并希望他们修补它，如果可以的话。

于 2010-12-27T20:40:55.650 回答