從作曲到引擎整合的規範與檢核
說明遊戲音頻的取樣率與位元深度選擇、壓縮格式的取捨、響度標準與動態範圍控制、檔案體積與載入效能的平衡，以及從作曲、混音到引擎整合的完整交付流程。
所有音頻素材都應以高規格母帶製作與保存，再轉出遊戲使用的壓縮版本。 製作階段建議統一使用 48 kHz / 24 bit 的無損格式，保留足夠的動態餘裕； 一旦母帶以低品質儲存，後期再怎麼處理都無法把細節找回來。
取樣率決定可重現的最高頻率，44.1 kHz 與 48 kHz 都能覆蓋人耳可聽範圍； 短促的介面音效即使降到 22.05 kHz，多數玩家在手機喇叭上也難以分辨， 這是壓縮體積時最先可動用的空間。 位元深度則決定動態範圍，輸出到遊戲時降為 16 bit 已完全足夠。
音頻交付最常被忽略、卻最容易出問題的環節是響度一致性。 若各素材由不同人在不同環境下混音，遊戲中就會出現 「某個音效特別大聲、某段音樂特別小聲」的狀況，事後逐一調整音量既費時又難以收斂。
正確的做法是在交付前統一以整合式響度（LUFS）為基準正規化， 而非依賴峰值音量。背景音樂建議落在約 -16 LUFS， 音效則依類別分層，介面音最低、慶祝音最高，各層保持固定的響度差； 同時保留約 -1 分貝的真實峰值餘裕， 避免多個音效同時播放時的振幅疊加造成數位破音。
動態範圍也要考量情境。玩家多半在嘈雜環境中以手機喇叭遊玩， 過大的動態會讓安靜段落聽不見；但壓縮過頭會讓聲音黏成一團，分級音效的層次感隨之消失。
在 Web 端老虎機開發中，壓縮格式的選擇直接影響相容性和檔案大小：
最佳策略是同時準備兩種格式， 在執行時期透過瀏覽器提供的格式支援查詢介面，動態選擇可播放的版本。 若循環音樂必須使用會產生靜音填充的格式， 則需在音頻管理器中以精確的循環點參數指定起訖位置，繞過格式本身的限制。
行動端的頻寬與記憶體限制要求嚴格控制音頻資源總量， 一般建議整款遊戲控制在 3 至 5 MB 以內。 可行策略包括：依素材類型分配不同取樣率； 將短促音效轉為單聲道（聽感幾乎無差異，體積直接減半）； 採用可變位元率編碼；以及清除素材頭尾殘留的多餘靜音。
另一個容易被低估的成本是解碼後的記憶體佔用。 壓縮檔可能只有幾百 KB，解碼成未壓縮取樣資料後體積可能膨脹十倍以上。 評估預算時，必須同時看「下載體積」與「解碼後常駐體積」。
載入策略需要在「首屏速度」和「播放即時性」之間取得平衡：
此外，多數行動端瀏覽器有自動播放限制，必須由玩家的第一次觸控解鎖音頻輸出， 因此載入流程需安排明確的進入互動點，並在該次互動中完成音頻環境初始化。
專業的音效系統採用多組獨立匯流排，讓玩家分別控制各類音頻的音量：
所有匯流排最終匯入一個主輸出，玩家的總音量開關作用於此。 這種架構也大幅簡化動態混音： 音量閃避只需對單一匯流排調整增益，不必逐一處理個別音效的播放狀態。
在製作開始前，遊戲企劃需準備一份音效需求規格書，逐項列出所需音效：
統一的命名規範對團隊協作至關重要。 建議採用「類型前綴 + 場景 + 動作 + 序號」的結構化命名：
全部使用小寫與底線，避免大小寫敏感度造成載入失敗。
音效整合時採用事件驅動（Event-Driven）的觸發架構： 遊戲邏輯層不直接呼叫播放函式，而是發送語意化的事件通知， 由音頻管理器決定播放什麼、用哪個匯流排、以什麼優先權播放。 這種解耦讓音效邏輯能獨立調整而不動到核心邏輯，也讓同一套機制在不同專案間重複使用。 無論在 Cocos Creator、Unity 或純網頁環境中，這個原則都同樣適用。
還建議搭配一份由音效設計師維護的事件與素材對照表。 替換音效或調整分級門檻時只需修改對照表，不必變更程式碼， 讓調音回到最懂聲音的人手上，也縮短反覆試聽的迭代週期。
整合完成後，需要在多種環境下進行測試：
完整的音頻流程從需求定義到最終交付，需要遊戲企劃、音效設計師與前端工程師的緊密協作， 透過標準化的規範與品質把關，才能確保每款遊戲都呈現專業水準的聽覺體驗。
而這些規格與流程服務的對象，是背景音樂建立的情緒基調， 以及音效分級與互動音頻系統構築的回饋層次。 本系列的另外兩篇分別針對這兩個主題有更深入的討論。