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

Gandalf Mu 發表於 2022-07-19
專案管理
前言:筆者曾在影視後期Pipeline領域工作多年,後來轉至遊戲行業並繼續從事Pipeline方向的工作。影視Pipeline百花齊放,而且不斷在進步,而隨著遊戲工業化的不斷髮展,遊戲研發當中的Pipeline也越來越受到重視。遊戲工業化包含諸多模組,其中美術流程工業化這一點,絕對繞不開,並且也是其中的重要部分。本篇文章主要和大家討論一下影視Pipeline、遊戲Pipeline,以及他們之間的異同點,涉及專案管理和資料管理兩方面。文中的內容均是我個人的經歷以及朋友們的經歷,並不代表整個國內遊戲行業。如果你那裡的情況不同,非常歡迎你在評論區留言,讓大家的資訊更加同步,相互學習,共同進步。

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

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

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

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

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

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

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

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

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

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

開發和維護 Pipeline 系統的人,在影視行業,叫做 Pipeline TD(Technical Director)。

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

遊戲美術生產工業化:專案管理&資料管理
[ 圖源:https://www.illuminationmacguff.com ]

可以看到,(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