文/陳祥男
前言：
本文主要是個人利用一次周末時間，針對一場2019 GDC talk的導讀，完成後有不少朋友向我伸手索要，平日也沒什麼灌水的地方，在知乎上隨便發一下。看有許多人在GDC遊記里提過這個Talk，群眾基礎大概有了順帶安利一下,育碧在GDC上有很多非常棒的Gameplay方案的Talk，油管頻道里已經公開的比如Houdini地編三部曲,IK三部曲。
這次Talk的主講人是育碧魁北克的一個程式設計師兼項目領導，主要內容是介紹他們花了21人年製作推廣並且在刺客信條奧德賽落地實裝的自動化生產對白動畫的工作流。
他們的工作內容和CDPR在GDC2015上的關於巫師3對白動畫工具鏈的Talk上講到的內容有點關係，但CDPR的Talk主要是羅列自己在項目上製作的各種功能方案，對於有志加入血汗工廠的人而言能獲益更多，這場Talk主要是講如何從一個特定的切入角度出發,設計程序方案代替人力工作，並最後付諸落地的介紹。
正文：
首先,官宣ACOdyssey的文本數據,1200場對白場景,30小時演出時長,25000行對白文本。
提出高效製作內容的三種可選思路，模塊化，過程化，自動化。
項目分工
- 任務設計團隊，
- 劇情撰寫團隊，有些項目里是策劃擔任的，在這次分工里有點小製作人的意思
- 動畫設計團隊，從頭到尾跟進，包含動作，攝像和遊戲策劃
- 自動化系統，這次talk的主題，由他們項目組引入的工作流
程序化生成的優勢，穩定性高，用已有的資源催生靈感，有工具鏈，內容數量有保障。
工具展示，對白內容分支可視化工具，時間軸可視化工具，遊戲畫面是P上去的，可能是分屏也可能是演示；每次按下「魔法按鈕」重新生成,軌道結構和內容都會變化。
生產流程問題，生成器控制不了很多細節，比如角色走一圈，一開始對Write的需求沒有限制，導致所有動畫都要重新修改一遍。後面優化成分類製作的模式（一口吃不成胖子，羅馬城牆要慢慢推到）
官宣分級化的生產結果，完全自動化-20%，不新增資源-70%，額外資源需求-9%，完全定製-1%。
以上是一批比較宏觀的內容，從中可以一窺幾乎每個項目都會遇到的關於人員協作和工作流規劃的參考，20%的數字看似不高，但伺時找到自動化的切入點，改善工作流，並最後給出了數據可觀的工作成果，已是不易。許多項目剛邁出方案協作的第一步就被打死了，技術落地和技術調整更是無從談起。
生成器的輸入，對話內容文字，說話的人，情緒標籤，說話對象，音頻
總結對白內容，角色，對白，動作，相機，燈光（環境）
舞台的概念，確定人物的位置，創建出所有可能的相機位置，人物站位的方式有很多，相同的人數也可以有不同的站位方式,但可枚舉。
相機倉庫，人越多鏡頭就越多（如果用參數鏡頭描述其實就是幾個維度的參數的排列組合）
直觀口語描述鏡頭，三個方向，標準（微斜），側身，越肩；由近到遠五種距離（這裡並沒有用攝像術語,簡單描述幾個分類而已）
程序化鏡頭，鏡頭全是100%程序化生成的（主要是程序算出鏡頭位置的意思）
解釋鏡頭計算原則，保持人物頭部在螢幕空間的位置，人有高矮之分，鏡頭有俯仰之別，用程序計算都是一套參數方案。
三種不同的鏡頭跟隨方式（在Unity里可以嘗試用Cinemachine的方案）
時間跨度上的鏡頭生成規則，誰說話給誰鏡頭，從3*4-5個選項中根據規則打分選擇一個高分鏡頭；這些規則包含前後鏡頭關係（比如三鏡頭法，正反打一類的），有表情給特寫有動作給中景以上鏡頭，多人場景保證說話的人都在鏡頭裡，等。
時間維度上增加細節保持對話場景的生動，比如切開過長的鏡頭，合併過短的鏡頭，鏡頭提前或滯後。
動作，根據情緒標籤，分析文本詞彙，從動作庫里選擇合適的動作；事先給動作標記好動作幅度閾值和峰值，根據這部分數據融合動畫，（每個動畫切分播放特寫畫面里容易動畫斷裂,從頭到尾播完段落感太強）
這部分內容涉及到了業務內容的核心，從製作人員一定會提供的三個重點輸入（對話,人,音頻）；僅在語義上增加對象和情緒兩個輸入，就直接根據業務標準（當然要做好預期管理）完成大面積的工作內容。這其中，生成結果的預期管理，構建足夠舞台和相機數據,準備充足並規劃標記處理的動作庫，是大多數項目都無法做到的。但如果降低要求，只是從手K鏡頭和程序大特寫過度到程序正反打鏡頭，只是從idle變成偶爾播放情緒動畫，派出一兩個程式設計師熟悉業務功能後折騰下效果，還是能負擔得起的.至於更多周邊系統和細節,看個人能力量力而為。
周邊系統
口型匹配方案，播片里每個角色持著各國語言秀自動口型，Ref 2006GDC的Talk
LookAt系統，規則很簡單，沒說話的看向說話的，說話的看向對話目標(輸入里填)或者上一次說話的人；子系統單獨用來控制角色眼球製造人物情緒。
補光,介紹里只有一盞鏡頭方向附近的面光，沒有補光和輪廓光，強度會根據環境發生變化，（可能他們的景深足夠突出角色,在光照上省了功夫）
排除npc干擾，（好像是用navmesh禁區做的,在巫師的動畫talk里也提到類似的方案）
適配雙主角的對白長度差異（大概是生成兩遍）
以上內容就是這場方案里公開的全部技術細節，以前有個同事如此評價育碧，他們的所有方案我們都能想到，但後面添加的細節和為之付出的人力時間，把他們的每個方案拔到大多數公司都不可企及的高度上，我深以為然,而且，育碧在每次talk中表現出的關於方案發展和項目管理的思辨，也是十分充飢的精神食量。
流程和測試，生成方案已經定了，但內容
- "如何提交"
- "如何測試"
- "如何確認就位"
的問題就擺上台前，對此，他們方案組提供了三個解決思路：
- 可隨時手動生成
- 隨時可調整效果
- 每天晚上定時全生成
「如果和美術說有個機器人每天晚上都在改你們的場景，美術肯定高興不起來，所以這件事情要很小心處理」
- 需要持續穩定的展示效果
- 讓美術配合調整自動化效果
- 讓美術也有完全控制力
- 對於一些問題需要耐心解釋是場景問題而不是自動化系統的問題
從美術角度思考流程，生成器這種東西從美術角度看是很不一樣的：
- 需要展示給他們看結果，讓他們滿意
- 需要在很大層面上設計規則去滿足他們
- 需要讓Writer明確知道系統能做什麼不能做什麼，因為他們是設計的瓶頸
得到使用者的信任
- 方案的目標是如何更」聰明」的製作內容
- 很多項目推出了新方案但是覺得不值得做工具，或者覺得值得,然後讓一個工具組去做。「你知道這個系統這個用戶，所以你應該自己寫好這個工具」
- 我們是從頭到尾跟下了所有工作吹了下育碧之前的一些自動化
- 自動化不意味著不需要美術，我們需要美術確認規則，指導效果，這部分很困難（一些安撫美術的話術...自動化不意味著不需要美術）
找到自動化方案的切入點
- 現在有很多工作都能被總結，有很多工作都有自動化的切入角度
- 後面可能結合機器學習生成動畫，運動路徑之類的
- 方案的出發點是生產內容
結尾雞湯
- 穩定自動化能讓人物設計團隊耕作進入流程，疊代工作
- Writer能更快在遊戲里看到效果
- 能讓製作人更快更簡單就能看到任務的敘事結構
- 我們會持續完善這些系統，希望你們也能有所啟發，在項目里使用這種思路製作方案
QA環節
整場Talk加上QA環節幾個關鍵性的問題，基本向我們展示了這個項目的輪廓。因為只是導讀不是翻譯，有些字詞夾帶著個人私貨。如果你曾經在跨職能分工協作上有過經歷和思考，或者曾經嘗試過推廣渲染或Gameplay技術框架，相信這個Talk分享的項目經驗,能夠成為不錯的範本。
官網詳情：
https://gdcvault.com/play/1026381/Procedural-Generation-of-Cinematic-Dialogues
專欄地址：
https://zhuanlan.zhihu.com/p/75046600