节奏游戏的输入

Question

因此，联合并不在android上做很多节奏游戏。我决定找出原因，并将其中之一作为作业(无论如何，它的基本原理)。我最重要的障碍是用户输入。正如我们所知道的，输入是基于帧速率的统一，而音乐游戏(我想)更倾向于按钮按下和动作之间最小的延迟。

如果我们看音乐，在大约15到20毫秒的延迟，人的耳朵听到的东西是“不拍子”。

我听说安卓联合游戏运行在30 33ms (因为60 33ms吸干电池)，简单的数学表明: 1000/30 =33毫秒每帧。计算在15毫秒内，我们可能不会注意到，我们在18毫秒的可能的灾难。假设我们总是在任何给定的时刻达到这个30 any。

当我从用户那里得到输入时，我可以在完全相同的帧上播放该输入的声音。不过，我们可能还差18毫秒。

现在有一种从鼠标和键盘获得直接控件的方法，它使用OnGui()而不是Update()来获取键盘事件或鼠标当场单击。问题是，android可能无法处理这个问题(这也不适用于游戏垫)，而且这些方法听起来很奇怪，特别是当我们尝试播放OnGui()方法中的声音时。

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

谢谢你能给我的任何见解，我还没有发现任何关于这方面的文章是有用的。-Smiley

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

目前，我使用Debug.Log将测试数据发送到日志。有谁能帮我确认一下这可能是什么原因(造成一些长时间的延误？)我知道调试不是优化了的)，或者时间实际上有那么糟糕吗？

谢谢你，-Smiley

Answer 1

首先，我想在您的评论和分析中添加一些内容：

测量触觉输入和你的眼睛感觉之间的潜伏期还有很多。

在您的测试中，我所看到的最大的缺失可能是图形卡和您正在测试的PC监视器之间的延迟。如今，许多常见的LCD显示器在处理延迟时的延迟时间在15-30 in之间。。我不知道这与移动屏幕和硬件有多大关系，但我建议您在得出进一步结论之前花时间对目标硬件执行额外的测试。

更直接地回答您的问题：

我会继续使用团结，但我会继续研究最好的方法，以获取输入和反馈给球员尽快。在上面的评论中，@rutter向您指出了一个看起来不错的关于这个问题的线索。

特别要注意的是，我将考虑使用FixedUpdate()将游戏的框架与输入处理速度解耦。

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

Answer 2

我认为你把这件事搞得太复杂了，而且准确性问题也没有你想象的那么糟糕。

人们通常很早就按下按钮，以便同步他们所看到和听到的内容。

这也取决于你是否有某种滚动显示，他们试图匹配.如果显示器在30英尺(没有大跳跃)时平稳滚动，它们仍然能够使定时按压相当准确。

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

这是另一个简单的解决方案..。我认为摇滚乐队和吉他英雄经常这样做.无论如何，你在正确的时间开始播放音符/声音.然后，如果你发现他们漏掉了它或者傻乎乎的，就把它改成一个坏声音。