Smi*_*tor 7 c# android playback unity-game-engine
因此,Unity并没有在Android上做很多节奏游戏.我决定找出原因,然后将其编程为任务(无论如何都是基础).我最重要的障碍是用户输入.我们知道输入是基于统一的帧速率,而音乐游戏(我假设)更喜欢按下按钮和动作之间的最小可能延迟.
如果我们看一下音乐,在大约15到20毫秒的延迟时间,人耳会听到一些"被击败".
我听说Android Unity游戏以30FPS运行(因为60FPS吸干电池),简单的数学表明:每帧1000/30 = 33ms.我们可能没有注意到在15ms内计算,我们可能遇到18ms的灾难.假设我们总是在任何特定时刻达到这个30FPS.
当我从用户那里得到输入时,我可以在完全相同的帧上播放该输入的声音.但是,我们可以休息18ms.
现在有一种方法可以从鼠标和键盘获取DIRECT控件,它使用OnGui()而不是Update()来获取当场键盘或鼠标点击的事件.问题是,android可能无法解决这个问题(这对游戏手柄也不起作用)并且这些方法听起来很奇怪,特别是当我们尝试从OnGui()方法播放声音时.
我的问题:你会做什么,为什么？我们应该接受可能的18ms关闭,并假设我们达到30FPS,或者我们应该寻找一种可靠的方式直接获得输入,而不是等待更新来吗？
感谢您给我的任何见解,我还没有找到任何有用的文章.-Smiley
编辑 我只是用节拍器进行了一些基本的测试,在编辑器中以100FPS运行(每帧应该是10ms),在统一内部的节拍器上点击我的空格键.我得到的结果太可怕了.快速攻击:我的节拍器嘀嗒声接近20毫秒,但没有接近.点击节拍:我的目标嘀嗒声至少减少了200毫秒.除非我对这种节奏感到困惑,否则这是错误的.
目前我使用Debug.Log将我的测试数据提供给日志.任何人都可以请确认,如果这可能是原因(导致一些长时间的延迟？我知道调试不是那么优化),或者实际上是时间错了吗？
提前谢谢,-Smiley
首先，我想对大家的评论和分析补充几点：
测量触觉输入和眼睛感知之间的延迟还有很多事情要做。
我在您的测试中发现的最大缺失可能是显卡和您正在测试的 PC 显示器之间的延迟。如今，许多常见的 LCD 显示器的处理延迟在 15-30 毫秒之间。我不知道这与移动屏幕和硬件有多大关系，但我建议您花时间对目标硬件进行额外的测试，然后再得出进一步的结论。
为了更直接地回答你的问题：
我会继续使用 Unity，但我会继续研究获取输入并将其尽快反馈给玩家的最佳方法。在上面的评论中，@rutter 向您指出了关于这个问题的一个非常好的线索。
特别值得注意的是，我会考虑使用FixedUpdate()将游戏的帧速率与输入处理速度分离。
我认为花时间研究延迟感知的心理学也是值得的。例如，如果您的游戏是一种匹配播放歌曲的吉他英雄游戏，您可以简单地考虑您知道存在的滞后，并在您的游戏逻辑中在检查输入时考虑到这一点。