节奏游戏的输入

Question

所以，Unity 并没有在 android 上做很多节奏游戏。我决定找出原因，并将其编程为作业（无论如何都是它的基础）。我最重要的障碍是用户输入。正如我们所知，输入是基于统一的帧速率，而音乐游戏（我假设）更喜欢按钮按下和动作之间尽可能小的延迟。

如果我们看音乐，在大约 15 到 20 毫秒的延迟时，人耳会听到“不合拍”的声音。

我听说 Android Unity 游戏以 30FPS 运行（因为 60FPS 会耗尽电池电量），简单的数学表明：1000/30 = 33ms 每帧。在 15 毫秒内计算我们可能不会注意到，我们处于可能发生灾难的 18 毫秒。假设我们总是在任何给定时刻达到这个 30FPS。

当我从用户那里获得输入时，我可以在完全相同的帧上播放该输入的声音。但是，我们可能会延迟 18 毫秒。

现在有一种方法可以从鼠标和键盘获取 DIRECT 控件，它使用 OnGui() 而不是 Update() 来获取键盘或鼠标点击的事件。问题是，android 可能无法使用这个，（这也不适用于游戏手柄）并且这些方法听起来非常奇怪，尤其是当我们尝试从 OnGui() 方法播放声音时。

我的问题： 你会怎么做，为什么？我们应该接受可能的 18 毫秒关闭，并假设我们达到 30FPS，还是应该寻找一种可靠的方式直接获取输入，而不是等待更新到来？

感谢您提供的任何见解，我还没有找到任何有用的文章。 -笑脸

编辑 我只是用节拍器做了一些基本的测试，在编辑器中以 100FPS（应该是每帧 10 毫秒）在 unity 内的节拍器上点击我的空格键。我得到的结果太可怕了。 快速敲击：我的节拍器滴答声接近 20 毫秒，但没有更接近。 敲击节拍：我的目标滴答声至少有 200 毫秒。除非我对这种节奏感到困惑，否则这是错误的。

目前我使用 Debug.Log 将我的测试数据写入日志。任何人都可以帮我确认这是否是原因（导致一些长时间的延迟？我知道调试没有那么优化），或者时间真的那么糟糕吗？

提前致谢， -笑脸

Answer 1

首先，我想为您的 cmets 和分析添加一些内容：

要测量触觉输入与您的眼睛感知之间的延迟还有很多事情要做。

可能我在您的测试中看到的最大缺失是显卡和您正在测试的 PC 显示器之间的延迟。 Many common LCD monitors these days have a latency of between 15-30ms in processing lag。我不知道这与移动屏幕和硬件有多大关系，但我建议您在得出进一步结论之前花点时间对您的目标硬件进行额外测试。

更直接地回答您的问题：

我会继续使用 Unity，但我会继续研究获取输入并将其尽快反馈给玩家的最佳方法。在上面的 cmets 中，@rutter 为您指出了一个看起来相当不错的 thread on the issue。

我会特别注意使用FixedUpdate() 将游戏的帧速率与输入处理速度解耦。

我认为花时间研究延迟感知的心理学也是值得的。例如，如果您的游戏是一种匹配播放歌曲的吉他英雄游戏，您可以简单地考虑您所知道的延迟，并在您的游戏逻辑中检查输入时考虑到这一点。

Answer 2

我认为你过于复杂了，而且准确性问题并没有你想象的那么糟糕。

人们通常会提前一点点按下按钮，以便同步他们所看到和听到的内容。

这也很大程度上取决于您是否有某种滚动显示，他们试图匹配...如果显示以 30fps 平滑滚动（没有大跳跃），他们仍然能够进行定时按下相当准确。

我猜想虽然人们可以听到他们的时间关闭，但他们在正确的时间按下按钮的实际时间并没有那么准确。

这是另一种简单的解决方案...我认为这是摇滚乐队和吉他英雄经常做的... 无论如何，您都会在正确的时间开始播放音符/声音....然后如果您发现他们错过了它或弄错了，则将其更改为破碎的声音。