遊戲美術生產工業化：專案管理&資料管理

我們在工作中會碰到如下問題：


我們把上述的問題，按照相關的工作崗位，聚類一下：


Pipeline 就是來解決上述問題的。

更概括一點說，Pipeline 是管理專案的資訊和資料的流動。

· 資訊被高效、正確、及時地傳達到位

· 資料的來龍去脈、前世今生、脈絡關係管理的清清楚楚明明白白

它是誰，它從來哪裡，它要到哪裡去

非常重要的前言：沒有放之四海而皆準的 Pipeline 系統，一定要根據專案的實際情況，只有適合你的 Pipeline才是好的 Pipeline。如果是一個幾人的小團隊，喊一嗓子就能溝通到位的事情，沒必要花時間精力去折騰 Pipeline系統，得不償失；或者專案的美術資產很少，也確實沒必要。

開發和維護 Pipeline 系統的人，在影視行業，叫做 Pipeline TD（Technical Director）。

下面一張圖片，展示了一個動畫電影的完整製作流程，你能找到 TD 在哪裡嗎？（友情提示，圖超長）


可以看到，（Pipeline）TD 們都是在小房間之外（不參與內容製作）走動，負責監控和維護，保障整個管道正常執行的人。

繼續我們的話題，本文我們從剛開始提到的三個崗位的工作內容角度，將 Pipeline 要管理的範疇，分為三大類：

· 專案管理

· Review

· 資產管理（檔案和 Metadata 的管理）

這三者並不是隔離的，而是緊密結合在一起的，之間的資料和資訊流動是要絲滑的、無縫的。

其實 Review 是包含在了專案管理中的 ，但在遊戲過程中，由於大家經常忽視 Review 這一塊的重要性，所以我就把它單獨拎出來。

按照影視的說法，就是分 Production Management 和 Asset Management。

專案管理

我們這裡不涉及專案管理模式，如Agile、Waterflow。

這裡的內容主要包含：

· 任務分配、排期

· 任務的上下游關聯

· 任務的資產關聯

· 跟蹤資產完成度、發行版本、專案進度等

這裡涉及到的資料型別：

· Project（最頂層的，遊戲專案、電影專案，或者因為某些原因拆分出來“子”專案）

· Phase（或者叫Sprint，指一段時間，加很多個 milestone，用來做階段性排期，比如遊戲要上線的6.0 版本等）

· Asset（包括影視的 Sequence/Shot、遊戲的美術資產、關卡等）

· Task（將 Asset的製作拆分出來的最小級別的、可以分配到具體人的任務，並且有期望起止時間和預計時長）

· People（可以是個具體的美術人員，也可以是外包公司）

· TimeLog（記錄每個 Task 的製作實際製作時長，用來衡量工作效率或者是任務預算是否合適）

大概的關係是：


上述涉及到的內容，最好有甘特圖來協助檢視和便捷編輯。

另外要有多樣的 filter，協助專案每個人檢視他感興趣的部分，比如：

· 列出所有動畫任務

· 列出所有兩週內要過期的任務

· 列出包含在xxx版本要上線的任務

該系統必須可以應對變化，大到比如外部環境變化導致的延期、比如老闆突然要調整遊戲上線日期，小到人員離職，多增加美術、多外包、系統可以快速調整和更新排期，確保每個人都知道自己該做什麼、該什麼時候做、先做哪個後做哪個。

具有專案管理功能的軟體/系統有很多，影視或遊戲行業在這方面的基礎需求也沒有太多的特性，強烈建議直接使用一個使用者量多的、適合你專案體量的商業系統就行，前提是這個系統必須支援二次開發，因為只滿足基本需要可遠遠不夠，按照之前的經驗，我們 Pipeline 在這個部分的主要精力放在了

· 將生產資料進行各種角度的視覺化，幫助PM 精細化管理專案週期和人力安排，把控專案風險，避免空轉/過載

· 開發各種自動化監聽指令碼，比如當A任務完成80%就把 B任務狀態改為“可以開始”，減少 PM 手動、重複工作量，減少人為出錯

· 開發各種RTX通知機器人，比如提醒美術臨期任務。及時提醒，避免遺漏

· 開發各種小工具，包括並不限於瀏覽器外掛、基於管理系統的選單擴充等，減少PM 操作步驟

· 生成產能報告，展示進度、落後的部分、資源閒置等等狀況

另外，提到它必須提供二次開發介面，還因為這裡的資訊，是要出現在美術的工作環境中的，比如DCC、引擎裡的（第三部分）

再次，還需要強調的是，該系統的資料庫支援一定程度的自定義：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 Column。

隨著專案越來越複雜，需求量增多，Pipeline 崗位再次被細分，甚至前幾年國內都有公司招聘製片TD（在遊戲可以理解為配給APM 的TA）。在我查詢小黃人那張圖片的時候，看到做小黃人的 Illumination 公司竟然也有招 Production Technical Director。

Review

主要包含兩方面：

· Review 工具（如何更好地Review）

· 管理和跟蹤反饋

美術上傳工作內容，總監對其進行反饋；美術拿到反饋繼續修改，不斷迭代，直到效果通過。

這裡涉及的有：

· Task（上個部分中的Task）

· Version（內容一般是圖片或視訊，美術的一次迭代）

· Playlist（將多個 Version 放在一起的播放列表，方便開 Review 會議時檢視）

· Note（反饋，一般有文字描述、示意圖片、或者其他檔案作為附件）

· People（這裡指上傳 Version的美術/外包公司，和負責 Review 的組長或總監）

大概的關係是：


影視的幾種 Review 形式：

· 直接日常線上Review，美術/外包隨時提交，組長或總監隨時反饋，Review 流程超快

· rounds，直白翻譯叫巡視，走一圈：總監帶著PM，走到 Artist的工位上，直接檢視其 DCC 內容

· 正式的 Review 會議，有專業投影儀，標準的色彩顯示，有組長、總監、PM，興許有客戶，預先準備好的 Playlist 進行挨個 Review

遊戲還會有直接開啟遊戲，邊體驗邊 Review，我們的反饋方式就要加上錄音、錄屏、截圖。

另外，不得不提一下 Client Review，就是客戶，或者是導演、老闆、IP方等，在內部已經迭代了不少版，總監覺得已經離定稿不遠了，可以拿出來給客戶看看。

client Review 的note 需要做隔離，不能直接讓相應的美術看到。

一方面，確實有語言翻譯的原因，另外，還是需要“翻譯”一下客戶的反饋，再一方面，需要“過濾”一下客戶的反饋。

Review 工具需要具備的功能

· 可以寫文字描述

· 有各種畫筆功能，可以直接在畫面上塗鴉

· 可以錄音、錄屏、截圖

· Ghost and Hold Annotations（可以把視訊其他幀畫面的塗鴉半透明顯示，適合動畫環節 Review）

· Live Review （多人線上協作 Review ）

· 多版本對比看：並排著對比、疊在一起對比

· 可以檢視歷史 Note 反饋

· 可以切換歷史Version 版本

· 可以切換其他環節的Version 版本

· 影視：可以看到前後shot，串起來看

· ......

沒有全部功能都有的產品，各個產品有差異、有自己的護城河，我們可以把某一個功能做的特別好的小軟體納入進來，一起使用，然後將它們結果資訊同步到我們的 Review系統中。

同樣的，該部門的軟體或者系統必須支援二次開發，我們 Pipeline 在這個部分的主要精力放在了

· 讓美術及時看到反饋，可以是發郵件、發即時訊息

· 甚至讓美術直接在自己的 DCC 裡面看到，把反饋圖片貼在場景裡

· 根據新的Note 反饋，自動建立 Task，方便追蹤後續是否解決了該反饋

· 美術可以更方便的上傳 Version

· 批量上傳 Version

· 視訊標準化：畫面水印、檔案解析度、檔案編碼、色彩空間、規範命名......

· 統計：task 有多少個 version、多少個 note，跟task 的bid 比，滯後了還是超前了，反向修正排期，讓排期更合理。

· 增加更多格式支援，比如支援 3d檔案預覽

同時具備了專案管理和 Review 功能的軟體有ShotGrid 、Ftrack。遊戲跟影視不同，需要有軟體開發的管理部分，這部分如果讓諸如 ShotGrid 來管，也不是很合適（雖然它的確有軟體開發管理的模組）。所以，可以兩個都用，對關鍵的資料進行實時雙向同步。

這時候，肯定有人說，用兩個商業系統，那成本多高啊。

這裡肯定是忽略了隱形成本，因為覺得貴：

就使用 excel 來管理，帶來了協作難題，多版本資訊不同步，歷史修改丟失，直接影響了生產，這個成本呢？

如果選用了不合適的或者成熟度低的系統，再僱一個TA/TD 來全職開發補齊功能，請問他年包幾何，開發能不能按時完成、bug有多少，這個成本呢？

非要 Google Docs/騰訊文件，支援協作，也能高階查詢過濾，但公式複雜的逆天，PM 能不能學會、啥時候能學會、要不要直接招個已經會的，這個成本呢？

再次強調那句話，美術資產量不大，確實沒必要。

資料管理

有一個我常被問到的問題是：那我的工程檔案，是上傳到 ShotGrid 裡嗎？這個問題，簡單地回答是或不是，遠遠不夠。所以索性就說個明白。

Data vs Metadata

Data ，在我們討論的上下文中，指的是我們能在硬碟上看到的具體檔案，比如.max、.mb、.hip檔案.

這些檔案有的是二進位制檔案，可以理解為用記事本開啟，裡面都是亂碼，人根本就看不懂；

有些是非二進位制檔案，常常是類似xml 、json 、yaml 等，可以理解為用記事本開啟，裡面都是人類可讀的單詞符號，偶爾你還能“喲這不是我的節點名字嘛”

Metadata ，後設資料，是描述資料的資料。

比如說 Data  是你這個活生生的人， Metadata  就是你的簡歷內容，什麼身高、體重、身份證號等等，在沒看到你這個人站在我面前之前，我通過你的 Metadata （從你簡歷上看到的），就可以掌握個大概，有時候就能判斷出你是不是我要招的人，等我具體想深入瞭解你的時候，再把你喊過來當年交流（就是用相應軟體開啟檔案）。

玩攝影的朋友可能更熟悉，Data 就是你拍的影像檔案，Metadata是這張照片的 ISO、焦距、光圈、拍攝時的地點、曝光......

在我們討論的上下文中，一般是這幾類：

· 檔案本身的資訊：建立時間、修改時間、大小、建立者、存放路徑、檔案格式

· 檔案內容的資訊：面數、有沒有UV、有沒有骨骼、多少根、在level 裡的世界座標、燈光的亮度、相機的景深

· 人為新增的資訊：“這個檔案我增加了地面模型”、“這個版本把角色的腿拉長了一些”

· 檔案的依賴關係：模型檔案依賴的貼圖檔案們、動畫 reference了哪個繫結檔案、關卡里面放置的資產們

· 你想記錄的其他資訊：這個檔案的質檢結果

一定要根據你們的需要，選擇真的要經常檢視的 Metadata

存放方式

這兩種Data，存放方式有所差別。

Data

Data  通常會比較大，毫無疑問，是存放在檔案儲存系統，比如我們的硬碟、 NAS 、百度網盤、 P4V 、 SVN 、 Git  等等地方。

Data 檔案的儲存，在視效行業，基本採用 NAS 。

儲存是影視公司的頭等大事，它涉及訪問速度、寫入效率、快照系統、日誌系統、許可權管理、吞吐量、儲存頻寬、協議延遲、冷熱資料分層、分散式儲存等等，總而言之，不是簡簡單單的找個地方放檔案就行了，是個很花錢的工作。

而遊戲這邊，美術資產分為：

· 進引擎之前的，就是.max、.fbx、.sd、.spp等等檔案。這跟影視的沒有任何區別。

· 進引擎之後的，就是遊戲引擎專案工程了。

進引擎之前的檔案

我所見過的管理軟體有 P4V 、 Git 、 SVN 、Alienbrain 以及，只存放在美術本地硬碟上... ...

就算是使用了上述的儲存管理，也並不是每個工程檔案版本都上傳的，大部分還是專案組強制要求，必須至少傳一個最終版，上下游交接的檔案倒還是有上傳的。

影視公司的理念：Artist 製作的所有檔案，都是公司的數字資產，必須 publish 到儲存伺服器！

當然啦，這是缺少資料夾放置規範和自動化工具，換位思考一下，沒有一鍵無腦上傳工具，你讓我每個版本都上傳，我也覺得很煩。

進引擎之前的檔案儲存方式，建議使用

· NAS ，推薦指數，五顆星，下面一個段落專門講一下。

· P4V ，推薦指數，三顆星。專門給遊戲行業設計的。尤其是，如果引擎工程也使用 P4V 了的話，我不清楚它的收費模式，但從美術角度講，可以減少一個需要理解的系統。如果有人能說服我遊戲公司真的不能用 NAS ，那麼 P4V 可以變成四顆星。

· 雲儲存 ，推薦指數，一顆星。類似百度網盤，但不要用百度網盤！如果你不知道為什麼就證明你根本不適合它。物件儲存這塊，影視有強大的、專業的、專門服務TD 的 IT，都還沒敢全換，只敢稍微嘗試一下（跟外包進行檔案交接），除非你能找來核心開發者專門來給你服務。

· SVN 、 Git ，推薦指數，零顆星。這倆就不是幹這個事的！相當於你讓一個模型師去設計汽車的發動機，原因是他們都用 Max 來建模。就我上面提到的儲存要涉及的功能特性，他們兩位能有的寥寥無幾。

單獨介紹一下 NAS


使用方式：每個美術，把 NAS 伺服器對映為統一的一個碟符，比如 x:/ ,相當於美術插了一塊“移動”硬碟，跟 D 盤一樣。只是這塊盤，每個人都有，而且都是同一個。

入門：美術 A 建立了個 x:/aaa/bbb.txt ，美術 B 那裡馬上也有了 x:/aaa/bbb.txt

高階：美術 A 建了個模型 x:/prop_desk_model_v001.mb ，然後裡面引用了幾張貼圖 x:/prop_desk_normal.tga x:/prop_desk_diffuse.tga ，儲存。美術 B 此時開啟x:/prop_desk_model_v001.mb，不會有任何問題，全程沒有上傳下載的步驟。這裡只是簡單舉例，影視並不是這麼粗暴使用的，但就是這個理兒。

在上文中提到，不能責怪遊戲TA 工具部署那麼繁瑣，影視的工具、Pipeline系統程式碼直接部署在NAS 上，把 NAS 上的程式碼檔案更新了，工具就更新了（ps：工具裡不要長時間 open一個程式碼裡面的檔案，不close），然後這個資料夾許可權鎖死，只有自動部署的CI 機器有許可權寫入，防止美術誤刪誤改。

另外有一點，因為檔案都放在了 NAS 上，如果網速夠快，美術直接在 NAS 上製作，本地的硬碟就不會被佔了，只需擴容 NAS 即可。

對比一下 P4V ，美術製作過程中的檔案都在本地，要是跟其他人交換檔案，首先需要別人上傳（這個上傳過程可不簡單），還得把別人的檔案下載到他本地，也就是說，同一個檔案，出現在了多個硬碟裡，不浪費嗎？我見過一個專案才是初期，開啟美術的資源管理器，一片紅彤彤的硬碟空間告警，然後每個人都去再次申請增加個人硬碟，不浪費嗎？

P4V 主打的版本管理，在 DCC這裡沒用，二進位制檔案merge 不了，就算是非二進位制檔案也 merge 不了。（你讓美術去解決兩個sd檔案的衝突？美術打爆你的狗頭！）

你可能說，那我就喜歡我依賴的檔案，一直都叫 prop_desk_model，可以自動更新 ，你說的 NAS 儲存，它今天叫 prop_desk_model_v0002 ，明天又多出一個新版本叫 prop_desk_model_v0003 ，我還得手動更新呢。

這位客官請留步，首先，誰告訴你 NAS 不能搞檔案一直叫 prop_desk_model ，而且永遠是最新版。symbolic link 瞭解一下。

其次，這個更新的確有自動更新，和手動更新兩種，但你 P4V 也不是自動更新的呀（不二次開發的話），也得點一下更新按鈕。

最後，我們不使用 symbolic link 是因為掉過坑。美術 B 用了美術 A 的檔案，乾的好好的，第二天，檔案打不開了，經排查，是美術 A 更新的檔案導致的。然後有一天美術C 也要用美術 A 的檔案，並提出個修改，美術A 修改了，但是美術 B 並不需要這個修改，又悲劇了......

所以，我們最後選擇了每個版本都是單獨的檔案，通過檔名裡面帶著版本號來進行管理。這個也符合美術的直覺。

Pipeline 系統自動獲取是否有新版本，詢問美術是否更新，然後美術可以一鍵更新，美術也可以隨時回溯到任意版本，資料隔離美滋滋。

說了這麼多，但 NAS 在遊戲這邊聞所未聞，除了大公司是有一些 IT 安全方面的考量，中小公司我完全不瞭解。

的確，遊戲行業進引擎之前的檔案，沒有影視整個公司的多（不能跟專案比，影視有的專案也可小了），那你 NAS 硬碟可以買少點啊！

難道是因為訪問速度？那我們可以在本地硬碟製作，完成後 publish 到 NAS 上啊。（請明白的人幫忙解惑，感激不盡。）

進引擎之後的檔案

遊戲專案工程，必須必須必須選擇一個有版本管理功能的軟體，如 P4V 、 SVN 、 Git，這一點大家都沒有疑問。

Metadata

Matadata  則存在兩種方式，以 json  或者 xml  檔案形式，一般存放在它要描述的 Data 旁邊，看起來可能是這樣：

prop_desk_model_v002.max

prop_desk_model_v002.json

另一種方式，則是將 Metadata 存入資料庫裡面。


看你們的實際需求吧。

你非要問我的意見，那我肯定是選擇資料庫。

為啥不用“存放在檔案中”方式呢，當我們要檢視、要搜尋的時候，比如過濾出模型面數超過2千的武器，這種方式基本就是去遞迴掃描武器資料夾裡面，模型檔案旁邊的 Metadata檔案，開啟、讀取，哎呀不符合，下一個.....資產量稍微上去一點，可能幾分鐘、十幾分鍾過去了，突然我覺得，我也不是那麼的想知道超過2千面數的武器有哪些了。雪上加霜的是，如果是存放在了 P4V 、 SVN 、Git ，本地都沒有下載全部資產，還怎麼搜尋！

那我就去 P4V 伺服器上搜嘛！——你這是把存放檔案中的唯一優點也捨棄了。

另外，前文也提到：專案管理系統的資料庫要支援一定程度的自定義：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 column。

ShotGrid  和 Ftrack 都支援資料庫自定義（可能程度不一樣），一魚三吃，白得一個資料庫！而且 UI、API、賬號許可權管理...存放在資料庫方式的缺點，全解決了，還不用額外花錢！

除此之外可以省去TD 一大部分工作量，還能拿它去當人才庫、資產庫、材質庫、日報管理、Pipeline團隊的開發管理、各種工具的後臺。

書歸正傳。還有個問題。

Data 和 Metadata  有時候不是那麼好區分，尤其是那種整合拼裝其他二進位制檔案的軟體 ，同時也不把引用的檔案內容封裝寫入到自己的工程檔案裡面的，比如 Nuke Studio、Substance Designer 等。還有，遊戲引擎的專案工程！

這時候，我們就要發自內心地好好想想，到底哪些資料，是我們不想開 data 檔案，就想知道的。

這事做到極致的就是達芬奇軟體（DaVinci Resolve），它的工程檔案就是個資料庫！

命名規範

這包含檔案命名規範和資料夾規範。具體如何去制定就再說吧......看有沒有人願意看

這裡就提一下它的重要性。

規範命名主要的目的是，給資產檔案提供一個全域性唯一的標識。

· 當我們提到一個資產的時候，就知道在哪裡可以找到對於的檔案。

· 當我們看到檔案的名字，就可以確定資產的位置和型別。

· 有了規範的層級和命名，Pipeline 工具就可以自動化幫你上傳下載、匯入匯出。

Metadata 怎麼記錄

最好是美術使用 Pipeline 工具，在檔案被上傳/同步到伺服器上時，自動提取出來，自動上傳到我們們的Metadata 資料庫裡。

額外的也需要使用者輸入，比如本次檔案修改的內容。雖然我過往的經驗是，蒐集上來的都是“修改了一下”、“1111”這種無效資訊。但我們可以在填寫的輸入框裡，自動填充一下模板，引導美術大大們寫上合適的內容。


來源：騰訊遊戲學堂
原文：https://mp.weixin.qq.com/s/lM5aV8K5t1QWW5j085dnKw