2

我是一名新手游戏开发人员，我遇到了一个我正在尝试处理的问题。我正在使用 JAVA 开发 Android 游戏。

情况是我正在使用 deltaTime 在任何设备中进行平滑运动等，但我遇到了一个问题。在游戏的特定时刻，它实现了一个非常昂贵的操作，该操作会增加下一次迭代的 deltaTime。有了这个，下一次迭代会有点滞后，并且在旧的慢速设备中可能会非常糟糕。

为了解决这个问题，我想出了一个解决方案，我想与您分享，并对可能发生的情况提供一些反馈。算法如下：

1) Every iteration, the deltatime is added to an "average deltatime variable" which keeps an average of all the iterations

2) If in an iteration the deltaTime is at least twice the value of the "average variable", then I reasign its value to the average

有了这个，游戏将适应设备的实际性能，并且不会在具体迭代中滞后。

你怎么看？我只是编造的，我想更多的人遇到了这个问题，还有另一个更好的解决方案......需要提示！谢谢

4

1 回答 1

1

有一种比存储平均值更简单、更准确的方法。我不相信你的提议会得到你想要的结果。

  • 取自上一帧开始以来的总时间跨度（包括分数） - 这是您的增量时间。它通常是毫秒或秒。
  • 在应用之前将移动速度乘以增量时间。

这为您提供了帧速率独立性。您将需要进行试验，直到您的速度正确为止。

让我们考虑一下我上面评论中的例子：

如果您有一帧需要 1 毫秒，并且每帧移动 10 个单位的对象以每毫秒 10 个单位的速度移动。但是，如果一帧需要 10 毫秒，您的对象会减慢到每毫秒 1 个单位。

  • 在第一帧中，我们将速度 (10) 乘以 1（增量时间）。这给了我们10的速度。
  • 在第二帧中，我们的 delta 为 10 - 该帧慢了十倍。如果我们将速度 (10) 乘以 delta (10)，我们得到 100。这与对象在 1ms 帧中移动的速度相同。

无论屏幕更新的频率如何，我们现在在游戏中都有一致的移动速度。

编辑：

回应您的评论。更快的计算机就是答案；) 帧率一致性没有简单的解决方法，它可以通过多种方式表现出来——屏幕撕裂是最严峻的困境。

您在具有非常不一致的增量的帧中做什么？考虑优化该代码。以下操作真的可以杀死你的帧率：

  • 像 Pathing 这样的 AI 例程
  • IO 操作，如磁盘/网络访问
  • 程序资源的生成
  • 物理！
  • 其他任何不呈现代码的东西......

这些都会导致增量增加 X，具体取决于算法的顺序和正在处理的数据量。考虑在单独的线程中执行这些长时间运行的操作，并在它们准备好时对结果进行操作/显示。

更多编辑： 无论游戏规则如何，您在解决方案中有效地做的是减慢一切，以避免跳入屏幕位置。

考虑一个射手，反应就是一切，速度估计非常重要。如果帧速率翻倍，而您将播放器的旋转速度减半，会发生什么？现在玩家已经经历了帧速率的飙升，并且他们的十字准线移动得比他们想象的要慢。更糟糕的是，因为您使用的是运行平均值，后续帧的移动速度会变慢。

对于一个慢帧来说，这似乎是一种连锁反应。如果你有一个物理引擎，那么慢帧甚至可能对游戏世界产生非常真实的影响。

最后的想法：增量时间的想法是将游戏规则与您正在运行的硬件断开 - 您的解决方案重新连接它们

于 2013-10-24T13:54:36.160 回答