我已經迫不及待地想給各位安利一項遊戲音訊新技術了
原因在於,他正在製作一款音樂遊戲,核心音遊受眾偏小是一個固有問題,而且在國內還有一個限制使用者群體增長的硬傷:國產安卓機在音遊裡普遍的斷觸、吃音、掉幀、爆音、卡屏等問題。而這項技術可以從軟體測極大程度緩解這類問題,也就有機會帶來更多的音遊玩家。
葡萄君是技術門外漢,無法直接判斷好壞,所以上手試了試實裝了這項技術的產品,結果大幅度超出我的設想。鑑於國內完全沒人報導SonicSYNC,索性今天就給各位讀者安利一下。
01、「音遊殺手」背後的頑疾
如果提及用什麼手機玩音遊,基本所有老音遊人的回答,都是不推薦安卓,百度搜尋「音遊 手機」你能得到一大堆類似的回答。
因為很多機型玩起音游來,真的能讓人抓狂,就像下面這個視訊裡,用小米11體驗《PJSK》的時候,會莫名其妙出現卡頓、掉幀,甚至卡屏的現象。遊戲體驗已經沒了,而且這不是隻有小米才會發生的問題。
音遊的玩法本質,是對準節奏和音符按準音鍵,當然,這個準度不是指絕對的分毫不差。
所有音遊都有各自的判定區間,以純Perfect判定而言,難一些的音遊能聚焦到±25ms的區間,而簡單一些的音遊則可能會放寬到±80ms,甚至±100ms的區間。
然而,儘管遊戲機制在追求兩位數毫秒級的精度,裝置卻很難跟上。在以往,不論是安卓機還是蘋果,基本所有機型的音訊延遲中位數(點選虛擬按鍵觸發按鍵音,直到玩家聽到按鍵音的延遲時間),只能控制在100ms左右,好一點的安卓機最低延遲大多在30ms左右,差一點的直接能飆到150ms以上。
2018年JUCE的部分測試資料(https://juce.com/maq),時間比較久遠僅做參考
對於一般的遊戲而言,100ms的延遲在聽感上基本可以忽略,但在音樂遊戲、FPS遊戲、重視打擊感的動作遊戲當中,這個級別的延遲會非常影響手感。尤其是音樂遊戲,100ms的延遲在±25ms的判定機制面前,根本不夠看。
所以在過去,玩家要麼主動人肉匹配遊戲體感,要麼調節遊戲的判定偏移率,來摸清楚裝置與自己的匹配度。另外對於用安卓機的老手,基本每次遊戲都需要根據自身的狀態、裝置的狀態,來調節偏移率。
葡萄君關注的一個神仙級拇指Arc玩家
而隨著近幾年日系音遊的走紅,國內逐漸出現了諸多這類遊戲的受眾,尤其以使用安卓機居多的學生群體為主。後來很多玩家都發現,除了固有的音訊延遲,日系音遊在國產安卓機上集體水土不服,出現了更多硬傷級別的問題。
如同前面小米11玩《PJSK》的卡頓一樣,小米系、華為係為代表的機型,多多少少都會有些影響音遊手感的問題,而且問題出現的概率參差不齊。也因此,很多國產安卓機都被冠上了「音遊殺手」的名號。
這類問題的原因,一方面可能在於硬體裝置的優化覆蓋不到音遊這麼小的品類,比如小米11的問題,被指出是因為MIUI優化問題導致的。
另一方面,可能在於音訊引擎沒有針對國內複雜的安卓硬體進行鍼對性優化。我查詢後發現,日本市場上基本所有音樂類頭部手遊,用的都是CRIWARE的音訊引擎,而這款引擎為日產引擎,日本市場上國產安卓機到去年為止還是全軍覆沒的狀態,顯然不會得到針對性的優化。
這個問題原本挺無解的,國內安卓廠商不可能在乎一小部分玩家玩音游到底爽不爽,一家日本企業理論上也顧不過來國內這麼複雜的安卓生態。但是CRIWARE專門給日本音遊市場搞攻堅的技術,很有可能剛好把這個國內玩家頭大的問題給解決了,而且是一勞永逸的那種。
02、100ms→53ms
目前日本市場上只有《迪士尼音樂遊行(ディズニー ミュージックパレード)》使用了CRIWARE提供的新技術SonicSYNC,就以這款遊戲做個簡單對照測試。在遊戲更新版本之前(即沒有實裝SonicSYNC的版本),用小米11體驗這款音遊,毫不意外地出現了嚴重的卡屏問題。
在更新版本之後,體驗了很長時間都沒有出現類似的問題,實際上手後的滯後感雖然仍然存在,但是已經不影響正常全連,打出Perfect的準確率也不低。換到經常被大家吐槽的華為P20以後,也和小米11一樣,雖然有小幅度的延遲感,但不影響操作,也沒有卡頓了,此外P10的體感比P20的情況更好一些。
以上三個機型在使用新版本的《迪士尼音樂遊行》之後,打出來的都是基本全Perfect,這裡就只放一個P20的視訊做參考了。
實測以後,超出我設想的地方在於兩點:一是原本硬體和軟體相互作用的優化問題,為什麼軟體側的技術改進以後變化會這麼明顯,二是體感上的反饋是幾乎沒有滯後感,那麼實際上的延遲資料到底變化有多大。
在翻看日媒近幾天對SonicSYNC的相關報導以後,我大致瞭解到一些具體情況。
官方提及的幾個賣點是:其一,這項技術實現了與硬體同步生成實時聲音訊號的效果,在軟體處理層面達到了0延遲。其二,實際音訊延遲只剩下硬體側的原因,所以整體音訊延遲為50ms左右(參照物:三角鋼琴按鍵之後發出聲音的延遲是40~60ms)。其三,用藍芽耳機也能達到正常玩音遊的水平。
機制層面,過往的遊戲音訊處理邏輯,是針對要用到的音訊,先做快取處理,再進行實際呼叫,由於音訊檔案一般都會壓縮處理,所以快取的量越多,處理起來的步驟會越多,造成的軟體處理延遲就越高。SonicSYNC的處理邏輯,是在極短的時間內,對系統處理音訊的工序進行徹底拆分,然後只針對「要用什麼音訊」的結果,以最小的動作來呼叫音訊,從而實現軟體側的0延遲處理。
所以理論上講,軟體如果做到0延遲呼叫和輸出,那麼對系統環境的要求就會被降到極低,即便不做專門優化,也有改進的空間。某種意義上,這就像是一套通用解決方案,硬體只要正常一些,之前很多因為優化不匹配導致的問題,大部分也就能緩解了。
而至於53ms的音訊延遲中位數,這絕對是音遊玩家可以喜大普奔的數字了。
現在市面上主流的移動音遊裡,偏硬核一類的如《Arcaea》最高判定區間為±25ms,大多數則是在±40~±60ms的區間,比如《Bang Dream》±40ms、《PJSK》±40ms、《Deemo》±50ms、《CGSS》和《Lanota》是±60ms等等。而且±40ms~±60ms也是大眾向音遊的主要採用區間。
在上手一款最高判定區間在±50ms左右的音遊時,如果用了前面這個技術,那麼玩家基本就不用再擔心裝置會不會不適合玩音遊,不用頻繁調整判定偏移率直接體感適配即可,而且實際玩起來,也不會感受明顯的滯後感。
換句話說,上手門檻降低,可能會讓玩家覺得音遊突然變簡單了,裝置要求降低,則有可能帶來更多的玩家。後者是我最希望看到的事,畢竟音樂無國界,音樂遊戲背後承載的趣味性,也值得被更多玩家感受到。
03、技術始終是行業基石
回想當年,葡萄君入坑手遊就是因為音遊,第一臺音遊裝置,就是國產安卓機,當時也飽受斷觸的折磨,被逼無奈攢了幾個月工資忍痛換了蘋果,後來就再也沒敢碰安卓機,頂多測試用一用。
如今不得不感嘆,有痛點的地方,就有解決方案,尤其是在我們的遊戲行業裡,大家天天都跟使用者體驗打交道,更容易出現針對特定痛點的技術鑽研和解決手段。雖然音訊技術只是一個很細分的領域,但能解決問題的技術,始終都會成為行業進步的基石。
來源:遊戲葡萄
原文:https://mp.weixin.qq.com/s/m4yqyqP1iu1Dhn_I9gXR4w
相關文章
- 對高精度數字的處理。給各位安利一個坑。我相信很多人會遇到過。
- 【SAP技術】SAP不能修改一個已經分配給交貨單的HU
- 想寫技術部落格了
- 再見,我的技術夢想
- 深夜,黑客給我發來了一條勒索簡訊黑客
- 音視訊技術基礎
- 給大家分享下騰訊菜鳥京東Java面經(已經收到 Offer) | 掘金技術徵文Java
- 無能駕駛技術已經成熟?NO!
- 我已經受夠了“系統異常”!
- JDK1.5 我已經不認識了JDK
- 我已經寫了48年程式碼了,我感覺我還能寫下去
- 向你安利了一個編輯器,並丟給你一堆外掛
- 既然來騙我了,那就站在技術角度給你分析一波這個詐騙資訊。
- 各位frontend developer們,時機已經成熟,讓我們開始用上pnpm吧DeveloperNPM
- 電子遊戲已經成為一種新的文學形式遊戲
- 光子音訊團隊亮相GDC,分享遊戲音訊背後的技術與匠心音訊遊戲
- 我想創業,但不懂技術怎麼辦?創業
- WebView,我已經長大了,知道自己區分是否安全了!WebView
- 我在 Google 做技術經理的一天Go
- Ink底層技術創新:“我們想改變整個區塊鏈世界”區塊鏈
- WebRTC 音訊抗弱網技術(上)Web音訊
- WebRTC 音訊抗弱網技術(下)Web音訊
- 我的啟蒙技術經理
- 我們在信創下的改變,新技術體系已佈局?
- 一點點技術難點請教各位道友
- 給大家安利一款我開發的VSCode多語言外掛VSCode
- 基於webRTC技術 音訊和視訊,IM解Web音訊
- 關於技術文章“標題黨”一事我想說兩句
- 如何給Flutter寫一個高德地圖定位外掛 | 掘金技術徵文Flutter地圖
- 無法理解那些標題黨,或者是我已經被同齡人給拋棄了!
- 一個遊戲已經設計了三年,如今我們到底折騰出個什麼名堂來?遊戲
- 我的秋招經驗分享(已拿BAT,頭條,網易offer) | 掘金技術徵文BAT
- 進了錢多技術落後的公司,想跑路
- 蘋果的創新力已經不如微軟了嗎?華爾街給出了答案蘋果微軟
- 請各位高人幫我指點一下我的職業規劃!謝謝了!(5年多工作經驗)
- 使用Octave音訊處理(三):數學技術處理音訊檔案音訊
- Linus Torvalds訪談:我已經不讀程式碼了
- -----清高手指點。。 我已經迷茫很長時間了。。。。