開放世界游戲如何做好協(xié)作？

整理/秋秋&林致

今年的GDC（游戲開發(fā)者大會）上，Sucker Punch工作室的工具程序員Roland Munsil，做了一場關于《羊蹄山之魂》編劇管線的分享。

簡單來說，他們給編劇做了一個編輯器，跑通了新管線。

曾經(jīng)《對馬島之魂》的舊管線，需要策劃手搓上萬條代碼，至少浪費600小時；而在《羊蹄山之魂》中，他們徹底變革工作流，讓編劇、策劃、制作人乃至音頻團隊，能在一套工作空間中協(xié)作——新工具細節(jié)到了界面上的一顆標點。

《羊蹄山之魂》的成績有目共睹。發(fā)售兩天收回全部開發(fā)成本，首月全球銷量破330萬份（PS5獨占），總收入超16億元，Metacritic媒體評分87，玩家評分8.5——這套編輯器管線支撐的，是一個經(jīng)過市場驗證的大體量產(chǎn)品。

對行業(yè)來說，這場分享的意義不止是怎么做一個編輯器。

開放世界仍是不少團隊的主流立項方向，但世界越做越大，文本體量跟著漲，編劇、策劃等崗位之間的空轉和重復勞動，已經(jīng)是很多大團隊繞不開的協(xié)作問題。

怎么讓數(shù)百人的團隊少做無用功？這場分享給了一個很具體的回答。

以下為演講實錄，為方便閱讀，內(nèi)容有所調(diào)整：

01

不做《博德之門》

我是Sucker Punch工作室的工具程序員Roland Munsil，今天主要分享我們在開發(fā)《羊蹄山之魂》時，對劇本寫作管線（Writing Pipeline）的重大重構。

先看一下我們的產(chǎn)品背景。

《羊蹄山之魂》是《對馬島之魂》的續(xù)作，兩款游戲都是日本歷史背景的開放世界動作游戲，帶有電影化故事（Cinematic Story）和戰(zhàn)斗玩法（Game play）。

同時，游戲的敘事內(nèi)容占比較大（Narrative Heavy），基本上所有任務都包含大量對話。每個主線任務可能有幾百句臺詞，哪怕是短支線也有幾十句，而且任務量本身就不少——畢竟這是一個大型開放世界游戲。

不過有一點需要明確，我們不是《博德之門》（Baldur's Gate），也不是《質(zhì)量效應》（Mass Effect），沒打算做復雜的動態(tài)網(wǎng)狀系統(tǒng)：如果你玩過這款游戲，那見過最多的對話選項，估計就是兩個分支的回答，這些回答沒有實質(zhì)性的影響，很快就會回歸主線。

02

原來的管線有多坑

首先，我們的核心團隊約150-200人。其中負責對話管線的有5名編?。╓riters），12名任務策劃（Mission Designers），2名制作人（Producers）。

在開發(fā)《羊蹄山之魂》的四年中，我們產(chǎn)出了約15萬字對話和5萬字文本素材。這其中，有75%是任務專屬對話，玩家只會聽一次；剩下25%是系統(tǒng)性對話（Systemic dialogue），比如戰(zhàn)斗呼喊、商人叫賣、背景村民閑聊，可以在多個場景里重復播放。

這個體量和《對馬島之魂》幾乎一模一樣，因此很多做法可以直接復用。

背景介紹完畢，我們接下來聊一聊管線（Pipelines）。

在講《羊蹄山之魂》的新管線之前，我們得先看看《對馬島之魂》的舊管線——后來做的很多決策，都是被舊流程逼出來的。

舊管線采用三方獨立分工的模式（Three-way Split）：

策劃、程序和美術在Perforce（版本控制軟件）里工作，處理代碼、任務結構和資產(chǎn)，這是構建實際游戲的地方；

編劇在Google Docs里寫劇本。策劃會參照這些文檔，先在游戲里搭好占位符對話（Placeholder Dialogue）；

制作人則負責把Google Docs里的臺詞，手動錄入內(nèi)部的臺詞數(shù)據(jù)庫（Line Database）。數(shù)據(jù)庫里每條臺詞都有源文本和元數(shù)據(jù)（Metadata）。制作人再從數(shù)據(jù)庫生成錄音表（Recording Sheets），送去錄制。之后制作人會把音頻拉回數(shù)據(jù)庫，這期間也可能會處理本地化。

最后，數(shù)據(jù)庫定期把錄好的音頻、字幕和文本打上對應的ID，推送到Perforce里——這些帶ID的文件，沒法直接在游戲里使用。

所以這一步最坑，策劃必須在引擎里，手動把每條臺詞的ID，掛到對應的觸發(fā)器上。我估計光這一項，就浪費了策劃至少600個小時的純苦力——還沒算上修改迭代和系統(tǒng)性對話。

編劇那邊也很痛苦。我們主編劇的原話是，感覺自己就是“把劇本隔著柵欄扔過去”。

因為他們在Google Docs里寫完文本就交出去了，沒辦法在游戲里自己測試。想改點東西，哪怕只是調(diào)換兩句臺詞的順序，都得找策劃幫忙操作，這就導致大家看似都很忙，但效率很差。

更要命的是，編劇長期不在引擎里工作，不知道引擎能實現(xiàn)什么，不能實現(xiàn)什么——只能祈禱自己寫的東西能跑起來。

此外，Google Docs、臺詞數(shù)據(jù)庫、Perforce這三個地方的由三組人維護，數(shù)據(jù)很容易脫節(jié)，來不及同步。

策劃可能在Perforce里刪了一句臺詞，但Google Docs和數(shù)據(jù)庫沒更新；編劇可能在文檔里加了臺詞，但沒進數(shù)據(jù)庫……最壞的情況是，一些臺詞已經(jīng)在游戲里刪了，但其他人不知道，把這些廢臺詞送去錄音、本地化后才會發(fā)現(xiàn)，最后錢白花了。

而且我們的劇本、錄音等環(huán)節(jié)，也不是一次就能完成的，所以這種數(shù)據(jù)同步的問題經(jīng)常會發(fā)生。

最后，我們對這些外部工具的控制力很有限：在Google Docs沒有發(fā)言權，臺詞數(shù)據(jù)庫又是索尼內(nèi)部的小團隊負責，他們無法及時響應我們的定制化需求。

03

如何讓編劇“寫代碼”

《對馬島之魂》做完的時候，我們決定徹底改掉這套管線。

方案上很簡單：不用臺詞數(shù)據(jù)庫，讓編劇直接在游戲內(nèi)的實現(xiàn)文件（Implementation）中工作。

理論上，這能一次性解決之前的所有問題：數(shù)據(jù)源統(tǒng)一了；不用手動掛臺詞了，因為編劇寫臺詞的過程，本身就是在完成連接；編劇直接接觸底層實現(xiàn)，對引擎的理解也會跟上來；而且我們甩掉了外部工具，控制權回到自己手里。

但具體執(zhí)行前，需要先解決兩個問題。

第一個比較簡單：怎么把原先存在數(shù)據(jù)庫里的元數(shù)據(jù)存到Perforce里？

我們做了一種自定義文本格式，直接作為文件存進Perforce，再寫代碼來讀寫和解析。下面這張圖可以看到它大致長什么樣。

第二個問題就大了：怎么讓不懂代碼的編劇，去編輯游戲的底層實現(xiàn)文件？

要回答這個問題，先得解釋一下我們游戲的底層架構。

游戲敘事管線的核心組件叫“對話對象（Conversation Object）”。觸發(fā)該組件后，系統(tǒng)會自動控制角色的動作，比如頭部運動和口型同步，然后逐句播放臺詞。

上面兩張截圖分別是兩段對話。第一段只有一句臺詞，第二段有六句。每句臺詞都有唯一的ID，圖里用紅色標出來了。

第一段對話掛在NPC角色Settler_Info_Tsuri身上。第二段里，四句來自同一個NPC，另外兩句來自Hero——這是我們內(nèi)部對主角Atsu的代稱。綠色部分則是附帶臺詞源文本的注釋。

這些對話對象是“觸發(fā)即棄”（Fire and Forget）的——代碼只需要啟動對話，系統(tǒng)會自動找到角色、按順序播放、播完自動結束，不需要額外的管理。

再看另一個稍微復雜的例子。

上面的對話涉及分支（Branching）。

玩家第一次遇到這個NPC時，他會問：“你擅長騎馬嗎？我需要找回一對離家出走的馬?！?/p>

但如果之前已經(jīng)對話過，再來找他，臺詞會變成：“我仍需要幫助，把我的馬找回來。這活應該能賺不少錢?！边@就是Branch_If ：Play_Count 0的意思——判斷玩家是不是第一次來。

而玩家的選項直接寫進了對話結構中。選擇Refuse（拒絕），跳到后面的收尾臺詞；選擇Accept（接受），則退出對話，觸發(fā)對應的任務（Mission Rigging）。

此外，對話系統(tǒng)還支持特殊命令（Special Commands）。比如Set Emotion可以改變角色的面部表情、Delay可以在兩句臺詞之間插入停頓……

我說這些，是為了說明：我們的對話不僅僅是一個臺詞列表，它還能做分支、選擇、各種控制行為，需要的話甚至可以直接觸發(fā)任意腳本（Scripts）。

而在《對馬島之魂》的開發(fā)中，這些東西全需要策劃手動創(chuàng)建和編輯。

了解之后，我們回到之前的問題——怎么讓編劇來編輯這些內(nèi)容？

顯然不能讓他們直接面對這堆代碼，編劇需要的是直接寫作。所以我們需要一個前端工具，提供更友好的編輯界面——最終，我們用Dear ImGui開發(fā)了這個工具，內(nèi)部叫“Sucker Punch Writing Tool”。

這個工具的截圖里有很多內(nèi)容，但我們只需要關注中間的腳本編輯器部分（Script Editor）。

首先，腳本編輯器會把對話對象文件、數(shù)據(jù)庫文件組合成一個腳本給編劇，編劇看到的不再是一堆/line ID和代碼注釋，而是實際的臺詞文本。

其次，我們還將編輯器界面做成了劇本格式（Screenplay Format）。這是影視和游戲行業(yè)的標準腳本格式：角色名在上方，有特定縮進；對話在下方，是另一種縮進；中間穿插動作描述——這種格式對編劇來說非常熟悉，同時也不影響游戲原本的對話結構。

第三，我們還專門模仿了業(yè)界標準劇本軟件Final Draft的操作邏輯。編劇可以用快捷鍵在角色名、對話、動作描述之間快速切換。這種全鍵盤邏輯，能讓編劇能保持連續(xù)的寫作節(jié)奏，不用在各種下拉菜單里用鼠標點來點去。

最后，我們沒有把底層指令完全藏起來。像Delay（停頓）、動畫觸發(fā)器這些元素，編劇在界面上仍然看得到、改得了。

這也是我們的設計思路：工具既要對編劇友好，也要對策劃有用，對話對象里的所有內(nèi)容都呈現(xiàn)在同一個視圖里，不對任何人隱藏。

04

新的工作流

現(xiàn)在編劇的工作流變成了這樣：

策劃搭好任務框架，放上占位符對話。編劇打開工具，直接修改臺詞，添加動作描述和表演指導（Direction）。

改完之后，編劇可以在本地編譯一次游戲，走到觸發(fā)點去實際聽一聽。

我們引擎內(nèi)置了一個叫Robo Voice的功能，沒有錄音的臺詞會用類似Microsoft Sam的合成語音（TTS）來播放。聽著不太自然，但能幫編劇感受對話節(jié)奏，比什么聲音都沒有強。

調(diào)到滿意，編劇能直接將其提交到Perforce，整個過程不需要策劃介入，除非要加什么復雜功能。之后交給制作人安排錄音，或者由主編劇、其他同事做腳本審查（Script Review）。

有時候流程也會反過來——編劇先寫好腳本，策劃再過來拆分成對話、連接任務邏輯。但不管哪個方向，雙方之間都不再需要來來回回反復交接。

除了線性劇本，這個工具還支持編輯網(wǎng)格對話（Gridded Dialogue）和UI文本。

網(wǎng)格對話就是前面提到的系統(tǒng)性對話，比如一群角色走向玩家時的招呼，因此我們需要用大量變體，對應不同的狀態(tài)和角色。這些內(nèi)容設定好之后，就可以跨場景重復播放。

UI文本編輯器則覆蓋了游戲里各種類型的文本需求，讓不同習慣的編劇都能在這里干活。

這條管線大約用了兩年部署到位，實現(xiàn)了我們想要的大部分功能。而且整個項目周期里，我們一直在給它加東西，因為會不斷發(fā)現(xiàn)新的改進空間。

先說預期之內(nèi)的收益：策劃再也不用手動掛臺詞了；大家不用再三個地方手動同步數(shù)據(jù)了；Google Docs和臺詞數(shù)據(jù)庫也退役了，編劇和策劃能統(tǒng)一用自己的工具了，想加什么功能自己說了算。

更重要的是，編劇的工作方式被徹底打通了。

首先，他們可以自己在引擎里測試、在本地迭代、調(diào)節(jié)奏、加停頓、改表情、設分支，不需要事事找策劃代勞。以前覺得太麻煩，不好意思開口請求的小調(diào)整，現(xiàn)在自己動手就行了。

其次，編劇摸清了引擎的技術邊界。他們每天在引擎里工作，能看到策劃是怎么連接任務的，能看到底層是怎么實現(xiàn)的，因此寫出來的東西，也更貼合游戲的實際限制。

你可能會問，那本地化該怎么辦？

這是新管線里唯一的例外——本地化團隊還得用舊的臺詞數(shù)據(jù)庫。但我們寫了腳本，能自動從Perforce把數(shù)據(jù)同步給他們，至少內(nèi)部不再有人手動維護臺詞數(shù)據(jù)庫了。

上線之后我們發(fā)現(xiàn)，這條新管線帶來的好處遠超最初的設想。

第一，為制作人提供了諸多便利。

一開始我們其實不確定制作人會不會想用這個工具。最初的想法是給他們做個導出到Excel的功能，再加上一些基本的元數(shù)據(jù)編輯，應該就夠了。但實際用起來之后我們很快發(fā)現(xiàn)，直接在工具里做功能方便得多。

我們做了一個自定義查詢界面（Custom Query Interface），制作人可以在里面搜索、篩選、批量修改對話。這比之前導出到Excel再導回來的流程好太多。

制作人也因此被拉進了編劇和策劃同一個腳本視圖里，能看到完整的上下文、分支邏輯和所有標注，對對話的整體理解更完整。

另外，我們還為錄音環(huán)節(jié)做了自定義導出功能。我們每次錄音要準備很多版本的材料：演員一份、導演一份、錄音棚各種角色各一份……以前這些全靠手工整理，現(xiàn)在制作人只要設定好查詢條件，就能一鍵導出所有格式，可以省掉大量重復工作。

第二，所有人都在同一個工作空間（Shared Workspace）里工作了：

• 策劃和程序能看到編劇寫的動作描述和情感備注，更容易理解劇情意圖；

• 編劇能看到策劃寫的底層邏輯和Bug備注；

• 主編劇開始直接在工具里做劇本審查（Script Review），直接批注修改，再也不用導成Word文檔了；

• 音頻團隊也進駐了，直接在里面調(diào)參數(shù)。

大家共享同一套文件組織架構（Organization Scheme），互相利用對方留下的注釋和標簽，形成了一個良性循環(huán)。雖然這需要大家共同維護資產(chǎn)，有時也難免會有摩擦，但這比之前三個團隊各自獨立工作要好太多了。

第三，我們在工具里加了一個粉色鉆石（Pink Diamond）圖標，用來顯示“這段對話到底有沒有在游戲任務里被觸發(fā)（Hooked up）”。

需要說清楚，這跟臺詞本身有沒有被連接是兩回事，臺詞的連接是自動的。粉色鉆石只驗證有沒有東西觸發(fā)這段對話。

說實話，這功能是我順手加的，有幾個人提了需求，我覺得有用就做了。沒想到最后成了整個工具里最受歡迎的功能之一。

對策劃來說，設置一個任務的工作量很大。一個大型任務可能要創(chuàng)建一百多段對話，過程中很容易漏配幾段，有了粉色鉆石，哪個沒亮一眼就看到了——而且這個東西大家都能看到，可以相互提醒。

對編劇來說，沒有粉色鉆石，說明游戲里沒有任何東西在調(diào)用它，放心刪。有粉色鉆石，那就得找策劃聊聊再說。

有策劃曾告訴我，在做《對馬島之魂》的時候，項目接近尾聲時專門做了一次大規(guī)模排查，把游戲里所有沒被引用的對話全找出來，一個個連上去；而到了《羊蹄山之魂》，這件事從來沒發(fā)生過。大家在日常工作中看著粉色鉆石，邊做邊就補了。

而且這個東西的技術實現(xiàn)簡單粗暴，但十分有效：它不用編譯游戲，就是打開工具時，全盤掃描所有文本文件，查找有沒有包含CONV_開頭的字符串。

這意味著它會有誤報（False Positives）?？赡苣硞€文件里引用了一段對話，但那個文件根本沒構建到游戲里，這種誤報也是難免的，你要檢查也根本不可能，所以大家也能理解；

而且它不會有漏報（False Negatives）。沒有粉色鉆石就是絕對沒被引用，可以安全刪除。

第四，我們還做了一個小功能，讓UI團隊在游戲運行時，記錄每個文本框的極限長度。

工具讀取這些數(shù)據(jù)后，會在編劇寫UI文本時給出視覺提示（膠囊圖標）?；疑碜謹?shù)安全，紅色代表超長，翻譯成其他語言可能會爆框——這既幫了編劇控制篇幅，也反過來幫UI團隊排查了哪些文本框的限制設得過嚴。

當然，我也有必要說說這個過程中踩過的坑。

首先，復雜的邏輯會嚴重影響劇本的可讀性。碰到復雜的網(wǎng)狀分支，比如商人NPC的對話樹，劇本界面里全是邏輯跳轉，一句臺詞都看不見（如下圖），這對配音演員和本地化人員來說簡直是災難。

如果時間允許，我們會把對話單獨導出成Word文檔，重新梳理分支結構方便演員理解角色。但實際情況是趕工居多，演員經(jīng)常連基本的臺詞分支都來不及捋清楚。

其次，Perforce合并沖突（Merge Conflicts）。

現(xiàn)在所有人都在Perforce里改同一套文件，沖突是家常便飯。有半年時間幾乎所有人都在密集修改內(nèi)容，我天天幫大家解決沖突，非常痛苦。

05

結語

回顧一下這次管線重構的前后對比。

以前在《對馬島之魂》里，同一份腳本散落在三個地方，我們必須手動保持同步，策劃必須手動掛每一條臺詞。大量時間耗在搬運和對接上，編劇覺得自己的修改總是不能快速落地，這整個流程一團亂。

現(xiàn)在，所有人在Perforce的同一套文件上工作。我們有一個自己開發(fā)的工具，簡化了每個人的工作，也讓我們能快速地往工作流里加各種功能。

粉色鉆石、UI字數(shù)提示這些需求，都是因為團隊自己掌控工具，發(fā)現(xiàn)痛點就能馬上做——這些功能的代碼未必漂亮，但能解決實際問題。

最重要的是，編劇的能力被釋放了。他們可以自己做編劇潤色，不需要把活交給策劃，可以自己進游戲調(diào)行為、試效果。這是整件事里最有價值的變化。

編劇也因此，把這個工具列為了《羊蹄山之魂》開發(fā)過程中最好用的工具之一。

最后想說一句，希望大家都能改善自己的管線，別再從Google Docs里復制粘貼成千上萬行臺詞了。

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

| |

| |

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

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