輸入一個節奏遊戲

Question

因此，Unity不會在android上做很多節奏遊戲。我決定找出原因，並將它編程爲作業（反正它的基礎）。我最重要的障礙是用戶輸入。由於我們知道輸入是基於幀速率的統一，而音樂遊戲（我假設）會更喜歡按鈕按下和動作之間的最小可能延遲。

如果我們看音樂，在15到20毫秒左右的延遲時間內，人耳聽到的東西就是「不合拍」。

我聽說Android Unity遊戲運行在30FPS（因爲60FPS吸乾電池），簡單的數學表明：1000/30 =每幀33ms。在15ms內計算，我們可能不會注意到，我們處於可能的災難18ms。假設我們在任何時候總是達到這個30FPS。

當我從用戶獲得輸入時，我可以在完全相同的幀上在該輸入上播放聲音。但是，我們可以在18分鐘內關閉。

現在有一種方法可以從鼠標和鍵盤獲取DIRECT控件，該控件使用OnGui（）而不是Update（）來當場獲取鍵盤或鼠標點擊的事件。問題是，android可能不適用於此（對於遊戲手柄也不適用），而且這些方法聽起來很奇怪，特別是當我們嘗試播放OnGui（）方法中的聲音時。我的問題： 你會怎麼做，爲什麼？我們是否應該接受18ms的可能性，並假設我們達到30FPS，還是應該尋找一種可靠的方式來直接獲得輸入，而不是等待更新來臨？

感謝您提供給我的任何見解，我還沒有發現任何有用的文章。 -Smiley

編輯 我只是做了一個節拍器一些基本的測試，在編輯器中（這應該是每幀10ms）的竊聽我的內部團結節拍器空格鍵在100FPS運行。我得到的結果非常糟糕。 快速點擊：我的節拍器刻度接近20ms，但沒有更接近。 敲擊節拍：我的目標節拍至少要200ms。除非我對這個節奏感到困惑，否則這是錯誤的。

目前我使用Debug.Log來獲取我的測試數據到日誌。任何人都可以請確認，如果這可能是原因（導致一些長時間的延遲？我知道調試不是那麼優化），或者實際上它的時間是不好的？

由於提前， -Smiley

Answer 1

首先，我想一些東西添加到您的評論和分析：

有很多的地獄更測量延遲在觸覺輸入和你的眼睛感知的東西之間。

可能是我看到在測試中缺少的最大的一個是圖形卡和您正在測試的PC顯示器之間的延遲。 Many common LCD monitors these days have a latency of between 15-30ms in processing lag。我不知道這與手機屏幕和硬件有多大關係，但我建議您花時間在您的目標硬件上執行額外的測試，然後再繪製進一步的結論。

更直接地回答你的問題：

我會繼續使用統一，但是我會繼續研究採取輸入和儘可能快地將其反饋給玩家的最佳方法。在上面的評論@rutter已經指出你看起來很不錯thread on the issue。

具體說明我會看看使用FixedUpdate()來解耦遊戲的幀速率與輸入處理速度。

我認爲還應該花時間研究延遲感知的心理。例如，如果您的遊戲是一種與正在播放的歌曲相匹配的吉他英雄遊戲，那麼您可以簡單地考慮您所知道的滯後時間，並在遊戲邏輯中檢查輸入時將其考慮在內。

Answer 2

我認爲你過分複雜化了這一點，並且準確性問題沒有你想象的那麼糟糕。

人們通常早點點擊按鈕以同步他們所看到和聽到的內容。

它也很大程度上取決於你是否有某種滾動顯示，他們試圖匹配......如果顯示器以30fps順利滾動（沒有大跳躍），他們仍然能夠進行定時壓力相當準確。

我會推測，雖然人們可以聽到他們的時間關閉，但他們在恰當的時間點擊按鈕的實際時間並不是那麼準確。

下面是另一個簡單的解決方案...我認爲這是搖滾樂隊和吉他英雄經常做的... 你開始在正確的時間播放音符/聲音......然後將其改爲如果你發現他們錯過了它或者被愚弄了，它會發出破碎的聲音。