c# - 输入节奏游戏

Question

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

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

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

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

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

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

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

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

目前我使用 Debug.Log 将我的测试数据写入日志。谁能帮我确认这是否是原因(导致长时间延迟？我知道调试没有那么优化)，或者时间真的那么糟糕吗？

提前致谢，-笑脸

Answer 1

首先，我想对您的评论和分析补充几点:

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

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

更直接地回答您的问题:

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

特别值得注意的是，我会考虑使用 FixedUpdate() 将游戏的帧速率与输入处理速度分离。

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