目錄(39 節)

Unity/Unreal 粵語 TTS 整合:NPC 對白動態生成

遊戲 NPC 對白唔再逐句配音:Unity/Unreal 接入粵語 TTS 嘅三層架構、預生成同動態生成兩條管線、對白模板設計、聲線管理、QC 流程同成本捉算。

— 港嘢內容團隊約 10 分鐘gamedevunityunreal
分享:

一句答你:遊戲 NPC 對白要動態生成,正確架構係三層分工——遊戲用戶端唔直接叫語音 API(金鑰唔可以放落 client),經你自己嘅後端代理提交生成任務,生成好嘅音頻落快取層,用戶端只負責拉取同播放。常用對白預先批量生成,真正動態嘅內容先行即時排隊。

香港開發者做遊戲,配音長期係痛位:粵語配音員稀缺、逐句錄音成本高、對白一改就要重約時間。結果係粵語遊戲好多時只有字幕冇聲,或者得開場幾句有配音。語音生成引擎嘅成熟,令「每個 NPC 都有把聲」變成細團隊都做得到嘅嘢。呢篇講點樣喺 Unity 或者 Unreal 度接得企理——由架構、管線、對白設計、QC 流程到成本捉算,一次過講晒,照住行可以少行好多冤枉路。

Key Takeaways

  • 三層架構:用戶端(播放)、後端代理(提交任務、管金鑰)、快取層(存生成結果),金鑰永遠唔入用戶端
  • 兩條管線:常用對白喺 build 時批量預生成;真正動態嘅對白執行時行排隊生成,玩家等以秒計
  • 每個生成任務文字上限 500 個字符,批量一次最多 25 個任務(專業/工作室方案功能)
  • 動態對白用「模板加變量」設計:固定句骨幹保證質素,變量位先係真正動態
  • 聲線一致性靠「角色參數卡」:同一個 NPC 永遠同一組聲線同參數,重生成先唔會變聲
  • 一個 NPC 嘅常用對白庫(幾百句)生成成本以十蚊計,改一句嘅成本係幾毫子

點解遊戲需要語音生成

傳統配音嘅成本結構

真人配音嘅成本係「逐句計」:錄音室、配音員、導演時間、改稿重錄。一個有幾百句對白嘅 NPC,配音預算隨時五位數,而且改一句對白就要成套流程行多次。細團隊計完條數,多數決定「對白用字幕算」——聽覺沉浸感就咁冇咗。

動態內容根本冇得預錄

模擬經營、roguelike、AI 伴侶類遊戲嘅對白係動態嘅:玩家名、隨機事件、程序生成嘅任務描述。呢啲內容無可能預錄——組合數目係天文數字。語音生成係唯一可行嘅出口:對白文字由遊戲邏輯產生,語音即場合成。

玩家係真係在意把聲

香港玩家社群對「有粵語配音」嘅遊戲反應一直好熱烈——字幕版同配音版嘅討論熱度係兩個世界。聲音帶嚟嘅唔止係資訊傳遞,係情感投入:同一句台詞,有聲同冇聲,玩家記住嘅程度完全唔同。細團隊以前做唔起呢樣嘢,而家技術門檻同成本門檻都落咗嚟。

粵語市場嘅缺口位

國際語音平台對粵語嘅支援長期半生不熟,粵語遊戲要配音,好耐以嚟都係「自己諗辦法」。粵語原生嘅語音引擎出現之後,呢個缺口先有正經嘅填法——遊戲做粵語本地化,終於可以連聲音一齊本地化。有關遊戲配音嘅整體方法論,可以睇《遊戲角色粵語配音指南》。

架構:三層分工

邊層做邊樣

  • 用戶端(Unity/Unreal):只負責向後端要音頻、播放入音頻系統。唔直接接觸語音 API、唔碰金鑰
  • 後端代理:你嘅伺服器。收用戶端請求、組裝文字稿、向語音服務提交生成任務、輪詢結果、寫入快取
  • 快取層:生成好嘅音頻檔按對白 ID 存好。同一句對白全服務器玩家共用,冇人想為同一句「你好,冒險者」生成一千次

金鑰安全係第一原則

語音 API 金鑰(sk_live_ 開頭嗰把)只可以活喺後端。用戶端反編譯係日常——任何擺入用戶端嘅金鑰都等於公開。後端代理仲有一個好處:你可以喺呢層做限流、做內容過濾、做用量統計,全部喺自己控制範圍入面。

快取策略決定體驗

對白類型策略玩家感受
常用問候、固定教學Build 時預生成,打包入遊戲零等待
半動態(模板加變量)上線後首次生成,落地快取第一個玩家等,之後零等待
完全動態(玩家名、即時事件)即場生成,行過渡動畫兜等一至兩秒,可以接受

兩條生成管線

管線一:Build 時批量預生成

遊戲入面八成對白其實係固定嘅:教學、劇情、常用對白。呢啲喺 build 管線度處理:對白表(試算表或者 JSON)→ 批量提交生成(一次最多 25 個任務)→ 音頻落資源庫 → 隨遊戲打包。每個任務文字上限 500 個字符,一句對白通常幾十個字,好少撞頂。

批量驗證係全有或全無:一句出事成批拒收,所以對白表要先過檢查腳本——有冇超長句、有冇生僻字、專名讀法有冇標注。工程細節可以參考《Python 整合 cookbook》同《批量生成工作流》。

管線二:執行時動態生成

真正動態嘅對白行呢條:遊戲邏輯產生文字 → 後端代理提交任務 → 輪詢結果 → 音頻連結交返用戶端播放。語音服務嘅任務係排隊制,由提交到完成一般以秒計,玩家嗰邊用過渡動畫(NPC 轉身、鏡頭切換、打字音效)兜住就自然。

要記住嘅規格:在途任務上限按方案由 3 至 20 個唔等,多人同時觸發動態對白嗰陣,後端要自己排隊,唔好硬頂。另外音頻連結有時效(1 小時或者 7 日),拿到手即刻落自己嘅快取層,唔好當永久連結用。

動態對白嘅文字稿設計

模板加變量:動態嘅位越少越好

設計動態對白嘅第一原則:成句得少數幾個字係動態,其他全部固定。例:「{玩家名},你今次嘅任務係去{地點}搵{物品}。」——呢個設計令生成質素可控(固定部分語氣穩定),快取友好(同一模板加同一組變量就係同一條音頻),成本最低(重複模板唔使重複生成)。

變量注入嘅格式約定

變量入文字稿之前要格式化:玩家名照原字注入但要過內容過濾;數字轉做香港口語讀法(「3」變「三」,時間「19:30」變「夜晚七點半」);專名加讀音標注。呢個格式化層放喺後端,所有模板共用一套,改一處全域生效。

為將來加語言留位

就算今時今日只做粵語,對白表設計嗰陣已經將「文字內容」同「邏輯 ID」分開——他日出英文版或者普通話版,邏輯唔使動,換一套對白表重跑生成管線就得。呢個位設計好,多語言版本嘅邊際成本就係「另一套對白表嘅生成費」。

Unity 同 Unreal 實務

音頻資源管理

Unity 嗰邊:預生成音頻入 Resources 或者 Addressables,動態拉取嗰啲用網絡請求拉音頻再入 AudioClip。Unreal 嗰邊:預生成嘅入 Sound Asset,動態嘅用線上檔案下載再建程序化聲波。兩個引擎嘅做法唔同,但架構原則一樣:預生成走資源管線,動態走網絡下載加本地快取。

預載同記憶體

手機遊戲要留意記憶體:成個對白庫一次過載入會爆。正確做法係按場景分組預載——入咗呢個地圖先載呢組 NPC 嘅對白,離開就釋放。音頻用壓縮格式,播嗰陣先解壓,記憶體佔用可以壓到好細。

命名規範救咗你之後嘅人生

音頻檔案名用「角色_情境_序號」格式(例如 ahchan_greet_001),對白表同一套 ID。改對白嗰陣,腳本可以準確搵到要重生成嗰幾句;QC 聽檔嗰陣,一睇檔名就知道聽緊乜。亂數檔名喺第一個月無問題,第三個月就是災難。再進一步,將每個音頻檔嘅校驗值記入版本控制,改咗邊句、幾時改嘅,一查就有。

音質位

遊戲音頻要同音樂、音效混音,人聲嗰條軌要留動態空間。生成完嘅音頻入引擎之前,統一過一次響度標準化,唔好靠引擎入面逐個 clip 調。有關音頻品質嘅整體評估,睇《粵語 TTS 音質指南》。

聲線管理:角色參數卡

一個角色一張卡

每個有聲 NPC 開一張參數卡:用邊個聲線(聲線圖庫嘅 slug)、演繹風格、語氣設定、專名讀音表。所有生成調用都由呢張卡出參數——冇卡嘅角色唔生成。呢個制度保證三個月之後重生成對白,角色唔會無端端變咗聲。

Design 同 Clone 模式嘅注意位

除咗用現成聲線圖庫,仲可以按性別同年齡層設計新聲線,或者用聲音複製。要留意:設計同複製模式出嘅聲線係按次生成嘅,唔會自動儲存做可重用資產——即係話每次生成都要帶齊同樣嘅參數(或者參考音頻),先保得住同一把聲。呢個特性令參數卡更加重要:卡入面存嘅唔係「聲線 ID」,而係完整參數組合。

QC:生成完唔係即刻上

三級檢查

生成完嘅音頻過三級:一級係腳本自動檢查(時長合理範圍、無靜音段異常);二級係抽聽(每批抽一至兩成,新角色新聲線全聽);三級係場景內試播(喺遊戲實際場景聽一次,驗證同音樂音效嘅混音效果)。好多問題唔係音頻本身嘅問題,係場景入面先聽得出。

讀音問題點追

專名、生僻字、外來詞讀錯係最常見嘅 QC 發現。處理方法係喺參數卡嘅讀音表位記低,重生成嗰句;每個讀音修正都要順手檢查該角色其他句子,睇下有冇同類問題。讀音表會越積越厚——呢個就係你嘅遊戲嘅「讀音資產」,換聲線、出續作、出多語言版都用到。

成本捉算:一個 NPC 幾多錢

生成費係零頭

語音生成按字符計,大約 240 個字符生成一分鐘語音。假設一個 NPC 有 300 句常用對白、每句平均 40 個字符,共 12,000 字符——以港嘢專業方案(HK$338 一個月、600,000 字符)計,呢個 NPC 嘅整套對白庫成本唔夠七蚊,仲要係一個月配額入面嘅零頭。十個 NPC、八個支線角色加埋,都仲係一個月配額處理到嘅量。

改稿成本先係革命位

改一句對白:重生成嗰一句,幾毫子。呢個先係語音生成對遊戲開發嘅真正革命——唔係初次成本低,係改嘅成本接近零,令你能夠負擔「聽咗先知唔啱」嘅迭代方式。真人配音年代,改稿係要約時間重錄嘅大件事;而家改稿係編輯器入面撳一下嘅小事。

工時成本都要計

生成費平唔等於零成本:對白表整理、試聽 QC、引擎接入都要工時。合理嘅預期係:第一次接入用幾日至一星期(含架構同測試),之後每加一個 NPC 嘅邊際工時係幾個鐘(寫對白表、揀聲線、試聽)。呢個工時水平,係細團隊真正負擔得起嘅位。

常見問題 FAQ

動態生成嘅延遲,玩家會唔會覺得卡?

任務排隊以秒計,用過渡動畫兜住(NPC 行埋嚟、鏡頭切換、打字聲)體驗就自然,一至兩秒嘅過渡係玩家完全接受嘅節奏。真正要即時接話嘅場景(語音對話型遊戲)係另一個難度級別,要專門嘅串流架構,唔係呢篇嘅範圍。

金鑰放喺後端,用戶端點知邊句對白要生成?

用戶端只向後端講「我要角色 A 嘅對白 ID 123」,後端查快取:有就返音頻,冇就生成。對白 ID 表由你定義,用戶端永遠唔接觸文字稿組裝邏輯以外嘅嘢。

玩家名係粗口或者其他奇怪嘢,點算?

後端代理嗰層做輸入過濾:玩家名入對白之前過一次檢查,唔過關嘅用替代方案(稱呼「冒險者」)。呢個位千祈唔好慳——遊戲上架平台對用戶生成內容嘅審查會因為一個名字令你成隻遊戲落架。

聲音複製可以用嚟做真實人物嘅 NPC 聲?

唔可以冇授權咁做。用任何真人聲線做商業遊戲內容,一定要書面授權。用自己或者團隊成員把聲冇問題,但建議都簽返一份簡單嘅同意文件,日後授權糾紛係遊戲發行嘅常見炸彈。

預生成同動態生成嘅比例點分?

經驗法則:八二分。八成對白行預生成(固定內容、教學、劇情),兩成行動態(玩家名、隨機事件)。動態嗰部分越多,對後端同快取嘅要求越高,先用預生成試水溫係穩陣路線。

離線模式點算?

單機離線場景只可以用預生成音頻——生成服務本身需要網絡。所以對白表設計嗰陣要標注邊啲對白係離線必要內容,呢啲全部行預生成管線,隨遊戲打包。動態對白當作線上加值功能處理係常見做法。

[!CTA]

俾你嘅 NPC 開口講廣東話

去港嘢 Playground 揀定角色聲線,攞對白表上 API 批量生成,第一版配音庫今日可以開工。