工作流是讓工具去適應(yīng)創(chuàng)作者。

整理/大田&林致

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

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

以下是經(jīng)過整理的演講《Building the Cinematic Pipeline for Love and Deepspace（構(gòu)建《戀與深空》劇情演出管線）》具體內(nèi)容：

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

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

• 實時迭代（Real-timeIteration）：創(chuàng)作者必須能夠直接在引擎內(nèi)對他們的工作進(jìn)行即時預(yù)覽和修改。

• 生產(chǎn)規(guī)模護欄（Production-scale Guardrails）：我們需要一套系統(tǒng)，幫助團隊在這樣大規(guī)模的生產(chǎn)中維持內(nèi)容的一致性和穩(wěn)定性。

01

原生創(chuàng)作工作流

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

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

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

如你所見，不管是數(shù)據(jù)流還是工作流都相當(dāng)復(fù)雜。

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

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

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

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

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

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

換句話說，是工具去適應(yīng)創(chuàng)作者的工作流，而不是反過來。

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

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

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

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

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

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

到這里，整個早期的敘事工作流已經(jīng)被整合到了一個單一的工具中?！皠∏榫庉嬈鳌惫芾碇y(tǒng)一的數(shù)據(jù)流，同時還為不同工種保留了他們熟悉的工作環(huán)境。

我們還在它之上構(gòu)建了一個SDK，允許團隊開發(fā)額外的插件和自動化工具，進(jìn)一步提升生產(chǎn)效率。

02

實時迭代

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

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

動捕是生產(chǎn)管線的核心部分。在傳統(tǒng)的動捕工作流中，表演數(shù)據(jù)會流入到DCC（數(shù)字內(nèi)容創(chuàng)作）工具里進(jìn)行預(yù)覽，比如MotionBuilder或Maya。

為了更好地與之契合，我們搭建了一個叫“導(dǎo)演工作室”（Director Studio）的內(nèi)部系統(tǒng)。

這個系統(tǒng)將動作捕捉、面部捕捉和攝像機數(shù)據(jù)整合到了一個統(tǒng)一的系統(tǒng)中。它還能把表演數(shù)據(jù)實時流傳輸?shù)綄嶋H的游戲內(nèi)角色和環(huán)境中。這大大縮小了動捕預(yù)覽和最終游戲內(nèi)效果之間的差距，讓導(dǎo)演和演員在制作過程中能做出更準(zhǔn)確的決策。

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

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

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

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

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

如果通過反復(fù)導(dǎo)入導(dǎo)出資產(chǎn)來做這些事，效率會極低，livelink也無法提供動畫師所需要的那種響應(yīng)速度。

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

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

動畫師會創(chuàng)建可復(fù)用的動畫片段，可以根據(jù)場景需求進(jìn)行組合。在生產(chǎn)過程中，美術(shù)可以選擇合適的動畫層，并調(diào)整它們的權(quán)重和播放速度，以達(dá)到理想的表演效果。

這樣，相同的動畫資產(chǎn)就可以生成不同的結(jié)果。

第三個是暫停循環(huán)動畫（Pause Loop Animation）。

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

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

第四個是燈光系統(tǒng)（Lighting System）。

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

燈光美術(shù)可以在時間軸上選擇特定的參數(shù)，并通過打關(guān)鍵幀進(jìn)行精確調(diào)整。

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

這能顯著加快制作效率，并有助于保持穩(wěn)定統(tǒng)一的視覺品質(zhì)。

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

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

有了這個系統(tǒng)，就可以快速可靠地創(chuàng)建出復(fù)雜的舞臺燈光效果。

03

生產(chǎn)規(guī)模護欄

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

首先是資產(chǎn)所有權(quán)界定。

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

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

其次是自動化資產(chǎn)驗證流程。

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

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

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

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

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

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

為了應(yīng)對這種情況，我們實現(xiàn)了多個畫質(zhì)分級，并且渲染管線也包含了多個不同的執(zhí)行路徑。

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

還有視覺回歸監(jiān)測。

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

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

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

例如，我們?yōu)榻巧珓赢嫷幕旌蠘浼捌溥\行時狀態(tài)提供了可視化工具，還能復(fù)現(xiàn)過場動畫之間的過渡狀態(tài)，這類地方很容易出現(xiàn)動畫抖動或者跨過場對象的生命周期錯誤等問題。

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

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

今天其實只是涵蓋了我們管線中幾個關(guān)鍵的部分。在過去的六年里，這條管線從一個勉強能用的狀態(tài)，進(jìn)化成了一個能夠讓我們團隊持續(xù)高效、高質(zhì)量地產(chǎn)出劇情的系統(tǒng)。它是整個團隊多年來不斷試驗、迭代和持續(xù)優(yōu)化的結(jié)果，這一切離不開每一個人的貢獻(xiàn)。

感謝大家的聆聽。

游戲葡萄招聘商務(wù)經(jīng)理，

| |

| |

游戲行業(yè)書籍推薦： 葡萄書房

（星標(biāo)可第一時間收到推送和完整封面）