疊紙GDC首次揭秘：《戀與深空》300人團隊的內容生產管線

工作流是讓工具去適應創作者。

整理/大田&林致

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

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

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

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

• 原生創作工作流（Creative-Native Workflows）：管線必須能自然地契合創意團隊的工作習慣，這包括文案、敘事設計師以及劇情演出美術。

• 實時迭代（Real-timeIteration）：創作者必須能夠直接在引擎內對他們的工作進行即時預覽和修改。

• 生產規模護欄（Production-scale Guardrails）：我們需要一套系統，幫助團隊在這樣大規模的生產中維持內容的一致性和穩定性。

01

原生創作工作流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

02

實時迭代

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03

生產規模護欄

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

首先是資產所有權界定。

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

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

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

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

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

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

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

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

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

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

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

還有視覺回歸監測。

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

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

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

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

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

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

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

感謝大家的聆聽。

游戲葡萄招聘商務經理，

| |

| |

游戲行業書籍推薦： 葡萄書房

（星標可第一時間收到推送和完整封面）