疊紙GDC首次揭祕：《戀與深空》300人團隊的內容生產管線-遊戲-漫步新聞-陪你看看

在今天的2026GDC（Game Developers Conference，遊戲開發者大會）現場，疊紙遊戲分享了《戀與深空》的劇情演出管線設計。

《戀與深空》全球註冊用戶超過8000萬，這麼多用戶的遊戲體驗背後，是一個超過300人的創作團隊，涵蓋了文案、分鏡、動畫等多個工種。爲了讓這300多人高效協同，《戀與深空》團隊用六年時間，打磨出了一套面向開發者的內部管線，避免在繁雜的數據轉換和跨部門溝通中陷入混亂。

以下是經過整理的演講《Building the Cinematic Pipeline for Love and Deepspace（構建《戀與深空》劇情演出管線）》具體內容：

大家剛剛看過《戀與深空》的短片，這些畫面背後，其實是一個相當龐大的製作團隊在支撐。要持續不斷地生產龐大體量的劇情演出內容，我們需要一套非常高效且健壯的工具集。爲了實現這個目標，我們的管線設計始終圍繞着三個核心理念展開：

原生創作工作流（Creative-Native Workflows）：管線必須能自然地契合創意團隊的工作習慣，這包括文案、敘事設計師以及劇情演出美術。
實時迭代（Real-time Iteration）：創作者必須能夠直接在引擎內對他們的工作進行即時預覽和修改。
生產規模護欄（Production-scale Guardrails）：我們需要一套系統，幫助團隊在這樣大規模的生產中維持內容的一致性和穩定性。

原生創作工作流

要理解原生創作工作流的重要性，先來看看我們整體的工作流。

流程從劇本撰寫開始，接着是分鏡設計、語音錄製、動畫製作，最後所有資產整合到遊戲引擎中，和玩法系統組裝起來。聽起來很簡單吧？

但實際上，我們早期的工作流程是這樣的：

如你所見，不管是數據流還是工作流都相當複雜。

文案們用一套系統自己的系統來標記說話人、記錄配音語氣提示。音頻團隊則需要導出單獨的錄音腳本，因爲配音演員在錄音時可能會即興發揮調整臺詞，或者拆分長句。策劃們則需要追蹤變動，及時更新。

那麼，爲什麼管線會變成這麼複雜呢？第一個原因是，不同的工種天生就偏好不同的工具。文案更習慣在Word裏工作，而策劃則習慣使用Excel裏管理對話數據。甚至同樣使用Excel，不同團隊使用的表格式也往往完全不同。

第二個原因在於，每個工種都需要有附加數據。策劃需要管理對話ID和分支邏輯，而音頻團隊則需要錄音備註和語音相關的元數據。

因此，數據必須在各種格式之間不斷轉換，最後再導入到遊戲引擎中。而且每一次轉換，都會增加版本控制和數據同步的複雜性。

爲了解決這個問題，我們需要統一且靈活的方式來管理對話元數據。所有的對話ID、臺詞類型、錄音備註以及其他生產數據，都需要放在一箇中心化的系統裏，同時又要保證只有相應的權限角色才能查看和編輯。

但光解決數據問題是不夠的，我們還得確保這個工具讓使用者覺得順手。文案寫對話應該就像在Word裏打字一樣；音頻團隊準備錄音時應該像在用電子表格。

換句話說，是工具去適應創作者的工作流，而不是反過來。

爲此，我們開發了一款名叫“劇情編輯器”（Story Editor）的工具。對文案來說，它屬於開箱即用，文案只需要直接打字就行了，這是一個鍵盤優先的工作流。

我們在這個文檔的形式中加入了一些結構化的設計。在左側，每一行都有明確的角色定義，告訴系統當前是誰在說話，這段對話屬於哪個場景，以及玩家在這個對話節點是否可以做出選擇。當然，我們也能訪問所有的元數據。

所有的敘事上下文都集中在了一個地方，再也不需要在不同工具之間進行格式轉換了。而且因爲這個系統是基於架構的，我們可以在需要時輕鬆添加新的元數據字段，同時保持所有的內容向前兼容。

評審工作流對我們來說也非常重要，我們讓這部分體驗儘量貼近Word，評審人員可以留下批註建議修改，或者直接使用修訂模式修改文本，作者可以逐一過一遍這些修改，選擇接受或拒絕。

當進入語音錄製階段時，可以將編輯器切換到錄音模式。在這個模式下，界面會變成一個類似電子表格的視圖，看起來非常像Excel。

這讓音頻團隊能夠規劃和管理錄音批次、追蹤進度。錄製完成後，他們可以把音頻和劇本進行對比，預覽語音臺詞，並管理不同的版本。最後一鍵把數據和音頻資產同步到語音項目中。

到這裏，整個早期的敘事工作流已經被整合到了一個單一的工具中。“劇情編輯器”管理着統一的數據流，同時還爲不同工種保留了他們熟悉的工作環境。

我們還在它之上構建了一個SDK，允許團隊開發額外的插件和自動化工具，進一步提升生產效率。

實時迭代

相比早期的創意階段，動畫生產的後期階段要繁重得多，不同部門之間的迭代很常見。嚴格的線性工作流會讓跨部門的修改極其痛苦。

所以，我們真正需要的是貫穿整個管線的快速、實時的迭代。

動捕是生產管線的核心部分。在傳統的動捕工作流中，表演數據會流入到DCC（數字內容創作）工具裏進行預覽，比如MotionBuilder或Maya。

爲了更好地與之契合，我們搭建了一個叫“導演工作室”（Director Studio）的內部系統。

這個系統將動作捕捉、面部捕捉和攝像機數據整合到了一個統一的系統中。它還能把表演數據實時流傳輸到實際的遊戲內角色和環境中。這大大縮小了動捕預覽和最終遊戲內效果之間的差距，讓導演和演員在製作過程中能做出更準確的決策。

在動作捕捉和動畫打磨之後，所有的東西都會被組裝到時間軸上，同時加上剪輯和錄製好的對話，形成一系列的過場動畫。這些都是在我們的過場動畫編輯器裏完成的。

這張截圖展示了我們過場動畫編輯器的不同面板。每一個過場片段都是由幾十條，有時甚至幾百條軌道和剪輯片段構成的，每一條軌道代表一個特定的功能。所有的軌道都可以進行實時預覽和編輯。美術們就是在這裏把所有不同的表演元素組裝成最終的過場動畫效果。

總的來說，這個編輯器包含十幾個子系統和許多不同的軌道類型，以支持各種各樣的過場動畫創作需求。但由於今天時間有限，我重點講其中四個。

第一個是細粒度控制器（Fine-grained Controllers）。

像前面提到的，過場動畫製作中的一個常見痛點，就是在管線後期進行精細的動畫調整。比如，將角色的視線與攝像機對齊、協調與道具的交互、或者微調角色之間微妙的互動。

如果通過反覆導入導出資產來做這些事，效率會極低，livelink也無法提供動畫師所需要的那種響應速度。

爲了解決這個問題，我們在引擎內部直接實現了一套DCC級別的細粒度控制器。這允許動畫師在實時調整表演的同時，能跟燈光、技術攝像機等其他部門協同工作，從而確保最佳的最終效果。

第二個是分層動畫（Layer Animation）。

動畫師會創建可複用的動畫片段，可以根據場景需求進行組合。在生產過程中，美術可以選擇合適的動畫層，並調整它們的權重和播放速度，以達到理想的表演效果。

這樣，相同的動畫資產就可以生成不同的結果。

第三個是暫停循環動畫（Pause Loop Animation）。

我們的遊戲中包含很多QTE，角色需要等待玩家輸入才能繼續接下來的動作。如果動畫只是簡單地僵在一個姿勢上，表演就會有明顯的斷裂感，這個時刻的張力也就流失了。

所以我們開發了一個叫做“暫停循環動畫”的功能。當遊戲進入QTE時，動畫系統會切換到一個特殊的循環動畫，同時等待玩家的輸入。一旦玩家做出反應，系統就會無縫過渡到後續動作，這讓表演始終保持鮮活，並保全了場景的過場沉浸感。

第四個是燈光系統（Lighting System）。

我們的角色使用一個平行光，和多個補充光源配合特寫軟陰影，再加上幾十種後處理效果，有海量的參數需要控制。

燈光美術可以在時間軸上選擇特定的參數，並通過打關鍵幀進行精確調整。

但如果每次都從頭搭建一套完整的燈光設置，會非常耗時，也很難在整個遊戲中保持視覺一致性。爲此，我們引入了一個預設系統。燈光美術可以將一組參數值保存爲預設，從而快速搭建一個基礎的燈光佈置。

這能顯著加快製作效率，並有助於保持穩定統一的視覺品質。

在舞臺卡里模擬複雜的舞臺燈光效果，需要同步移動許多燈光，所以手動去調整每一盞燈幾乎是不可能的。

所以我們借鑑了現實世界中舞臺燈光控制檯的工作流，並做了一個引擎內版本。這讓美術能夠控制燈光組，並生成程序化的燈光序列。

有了這個系統，就可以快速可靠地創建出複雜的舞臺燈光效果。

生產規模護欄

爲了支撐大規模的生產，我們還需要強大的護欄。如果沒有它們，即使是這麼複雜管線裏的一個小失誤，也很容易演變成系統級的問題，這會耗費大量的時間和精力去Debug。

首先是資產所有權界定。

正如前面提到的，過場動畫的生產需要多個部門協同工作。團隊經常需要參考彼此的工作，但絕對不能意外修改不屬於自己職責範圍的資產。

因此，我們將過場動畫項目劃分爲基於角色的資產目錄，並明確界定了所有權，自動提交工具確保只有屬於用戶職責範圍內的資產纔會被提交。比如在“過場動畫編輯器”中，燈光美術可以加載動畫資產作爲參考，但無法修改它們。

其次是自動化資產驗證流程。

我們的管線涉及海量的過場片段資產，修改本地文件、合併衝突等還是會導致配置錯誤。

爲了解決這個問題，我們建立了一系列自動化的資產驗證流程。這些檢查會定期運行，生成報告，一旦檢測到問題，就會通知提交者和該模塊的所有者。

這讓團隊能夠迅速定位有問題的資產和具體故障，從而快速修復。

再次，性能驗證也是管線中非常重要的一環。

我們將性能指標和Debug視圖直接整合到了編輯器裏。比如，特效美術可以使用Overdraw視圖來快速找出需要優化的資產。當一個過場片段完全組裝好後，創作者可以直接在編輯器裏播放整個序列，同時收集關鍵的性能指標，結果會以時間軸的形式呈現，有問題的片段會自動高亮顯示。

我們剛纔討論的性能剖析工具主要是在生產階段使用的，用於在開發環境裏進行快速診斷。然而，遊戲最終要跑在各種各樣的移動設備上，面對諸多不同的芯片組和操作系統，性能差異可能會非常大。

爲了應對這種情況，我們實現了多個畫質分級，並且渲染管線也包含了多個不同的執行路徑。

我們還搭建了一個性能監控平臺，由我們的自動化測試框架驅動，每天24小時在數百臺設備上跑測試。這讓我們能持續收集不同軟硬件配置下的性能數據，並在每次發佈前揪出潛在的性能熱點。

還有視覺迴歸監測。

從美術資產到渲染管線的修改，很多因素都可能無意中影響最終的視覺效果。一旦發生這種情況，程序往往要花好幾個小時回滾版本，找到變更源頭。

爲了解決這個問題，我們建了一個渲染農場，每天晚上都會錄製視頻進行自動化對比。我們還發現QA和美術複查問題的速度也快多了，因爲對比視頻比直接在遊戲引擎裏檢查資產要容易得多。

我們還構建了許多Debug工具來幫助工程師更快地診斷問題。

例如，我們爲角色動畫的混合樹及其運行時狀態提供了可視化工具，還能復現過場動畫之間的過渡狀態，這類地方很容易出現動畫抖動或者跨過場對象的生命週期錯誤等問題。

最後，我們支持快速打包並部署到移動設備上，以便進行快速的真機測試。

至於實時遊戲環境，我們使用了騰訊的Crash Sight來收集和分析崩潰報告，它提供了實時的搜索、統計和分析工具，能讓我們迅速定位問題，並對生產環境中的崩潰做出響應。

今天其實只是涵蓋了我們管線中幾個關鍵的部分。在過去的六年裏，這條管線從一個勉強能用的狀態，進化成了一個能夠讓我們團隊持續高效、高質量地產出劇情的系統。它是整個團隊多年來不斷試驗、迭代和持續優化的結果，這一切離不開每一個人的貢獻。

感謝大家的聆聽。