以下文章來(lái)源于騰訊游戲?qū)W堂 ，作者Gandalf Mu

筆者曾在影視后期Pipeline領(lǐng)域工作多年，后來(lái)轉(zhuǎn)至游戲行業(yè)并繼續(xù)從事Pipeline方向的工作。影視Pipeline百花齊放，而且不斷在進(jìn)步，而隨著游戲工業(yè)化的不斷發(fā)展，游戲研發(fā)當(dāng)中的Pipeline也越來(lái)越受到重視。游戲工業(yè)化包含諸多模塊，其中美術(shù)流程工業(yè)化這一點(diǎn)，絕對(duì)繞不開(kāi)，并且也是其中的重要部分。本篇文章主要和大家討論一下影視Pipeline、游戲Pipeline，以及他們之間的異同點(diǎn)，涉及項(xiàng)目管理和數(shù)據(jù)管理兩方面。文中的內(nèi)容均是我個(gè)人的經(jīng)歷以及朋友們的經(jīng)歷，并不代表整個(gè)國(guó)內(nèi)游戲行業(yè)。如果你那里的情況不同，非常歡迎你在評(píng)論區(qū)留言，讓大家的信息更加同步，相互學(xué)習(xí)，共同進(jìn)步。

我們?cè)诠ぷ髦袝?huì)碰到如下問(wèn)題：

我們把上述的問(wèn)題，按照相關(guān)的工作崗位，聚類(lèi)一下：

Pipeline 就是來(lái)解決上述問(wèn)題的。

更概括一點(diǎn)說(shuō)，Pipeline 是管理項(xiàng)目的信息和數(shù)據(jù)的流動(dòng)。

• 信息被高效、正確、及時(shí)地傳達(dá)到位
• 數(shù)據(jù)的來(lái)龍去脈、前世今生、脈絡(luò)關(guān)系管理的清清楚楚明明白白

它是誰(shuí)，它從來(lái)哪里，它要到哪里去

非常重要的前言：沒(méi)有放之四海而皆準(zhǔn)的 Pipeline 系統(tǒng)，一定要根據(jù)項(xiàng)目的實(shí)際情況，只有適合你的 Pipeline才是好的 Pipeline。如果是一個(gè)幾人的小團(tuán)隊(duì)，喊一嗓子就能溝通到位的事情，沒(méi)必要花時(shí)間精力去折騰 Pipeline系統(tǒng)，得不償失；或者項(xiàng)目的美術(shù)資產(chǎn)很少，也確實(shí)沒(méi)必要。

開(kāi)發(fā)和維護(hù) Pipeline 系統(tǒng)的人，在影視行業(yè)，叫做 Pipeline TD（Technical Director）。

下面一張圖片，展示了一個(gè)動(dòng)畫(huà)電影的完整制作流程，你能找到 TD 在哪里嗎？（友情提示，圖超長(zhǎng)）

[ 圖源：https://www.illuminationmacguff.com ]

可以看到，（Pipeline）TD 們都是在小房間之外（不參與內(nèi)容制作）走動(dòng)，負(fù)責(zé)監(jiān)控和維護(hù)，保障整個(gè)管道正常運(yùn)行的人。

繼續(xù)我們的話題，本文我們從剛開(kāi)始提到的三個(gè)崗位的工作內(nèi)容角度，將 Pipeline 要管理的范疇，分為三大類(lèi)：

• 項(xiàng)目管理
• Review
• 資產(chǎn)管理（文件和 Metadata 的管理）

這三者并不是隔離的，而是緊密結(jié)合在一起的，之間的數(shù)據(jù)和信息流動(dòng)是要絲滑的、無(wú)縫的。

其實(shí) Review 是包含在了項(xiàng)目管理中的 ，但在游戲過(guò)程中，由于大家經(jīng)常忽視 Review 這一塊的重要性，所以我就把它單獨(dú)拎出來(lái)。

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

項(xiàng)目管理

我們這里不涉及項(xiàng)目管理模式，如Agile、Waterflow。

這里的內(nèi)容主要包含：

• 任務(wù)分配、排期
• 任務(wù)的上下游關(guān)聯(lián)
• 任務(wù)的資產(chǎn)關(guān)聯(lián)
• 跟蹤資產(chǎn)完成度、發(fā)行版本、項(xiàng)目進(jìn)度等

這里涉及到的數(shù)據(jù)類(lèi)型：

• Project（最頂層的，游戲項(xiàng)目、電影項(xiàng)目，或者因?yàn)槟承┰虿鸱殖鰜?lái)“子”項(xiàng)目）
• Phase（或者叫Sprint，指一段時(shí)間，加很多個(gè) milestone，用來(lái)做階段性排期，比如游戲要上線的6.0 版本等）
• Asset（包括影視的 Sequence/Shot、游戲的美術(shù)資產(chǎn)、關(guān)卡等）
• Task（將 Asset的制作拆分出來(lái)的最小級(jí)別的、可以分配到具體人的任務(wù)，并且有期望起止時(shí)間和預(yù)計(jì)時(shí)長(zhǎng)）
• People（可以是個(gè)具體的美術(shù)人員，也可以是外包公司）
• TimeLog（記錄每個(gè) Task 的制作實(shí)際制作時(shí)長(zhǎng)，用來(lái)衡量工作效率或者是任務(wù)預(yù)算是否合適）

大概的關(guān)系是：

上述涉及到的內(nèi)容，最好有甘特圖來(lái)協(xié)助查看和便捷編輯。

另外要有多樣的 filter，協(xié)助項(xiàng)目每個(gè)人查看他感興趣的部分，比如：

• 列出所有動(dòng)畫(huà)任務(wù)
• 列出所有兩周內(nèi)要過(guò)期的任務(wù)
• 列出包含在xxx版本要上線的任務(wù)

該系統(tǒng)必須可以應(yīng)對(duì)變化，大到比如外部環(huán)境變化導(dǎo)致的延期、比如老板突然要調(diào)整游戲上線日期，小到人員離職，多增加美術(shù)、多外包、系統(tǒng)可以快速調(diào)整和更新排期，確保每個(gè)人都知道自己該做什么、該什么時(shí)候做、先做哪個(gè)后做哪個(gè)。

具有項(xiàng)目管理功能的軟件/系統(tǒng)有很多，影視或游戲行業(yè)在這方面的基礎(chǔ)需求也沒(méi)有太多的特性，強(qiáng)烈建議直接使用一個(gè)用戶(hù)量多的、適合你項(xiàng)目體量的商業(yè)系統(tǒng)就行，前提是這個(gè)系統(tǒng)必須支持二次開(kāi)發(fā)，因?yàn)橹粷M足基本需要可遠(yuǎn)遠(yuǎn)不夠，按照之前的經(jīng)驗(yàn)，我們 Pipeline 在這個(gè)部分的主要精力放在了

• 將生產(chǎn)數(shù)據(jù)進(jìn)行各種角度的可視化，幫助PM 精細(xì)化管理項(xiàng)目周期和人力安排，把控項(xiàng)目風(fēng)險(xiǎn)，避免空轉(zhuǎn)/過(guò)載
• 開(kāi)發(fā)各種自動(dòng)化監(jiān)聽(tīng)腳本，比如當(dāng)A任務(wù)完成80%就把 B任務(wù)狀態(tài)改為“可以開(kāi)始”，減少 PM 手動(dòng)、重復(fù)工作量，減少人為出錯(cuò)
• 開(kāi)發(fā)各種RTX通知機(jī)器人，比如提醒美術(shù)臨期任務(wù)。及時(shí)提醒，避免遺漏
• 開(kāi)發(fā)各種小工具，包括并不限于瀏覽器插件、基于管理系統(tǒng)的菜單拓展等，減少PM 操作步驟
• 生成產(chǎn)能報(bào)告，展示進(jìn)度、落后的部分、資源閑置等等狀況

另外，提到它必須提供二次開(kāi)發(fā)接口，還因?yàn)檫@里的信息，是要出現(xiàn)在美術(shù)的工作環(huán)境中的，比如DCC、引擎里的（第三部分）

再次，還需要強(qiáng)調(diào)的是，該系統(tǒng)的數(shù)據(jù)庫(kù)支持一定程度的自定義：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 Column。

隨著項(xiàng)目越來(lái)越復(fù)雜，需求量增多，Pipeline 崗位再次被細(xì)分，甚至前幾年國(guó)內(nèi)都有公司招聘制片TD（在游戲可以理解為配給APM 的TA）。在我查找小黃人那張圖片的時(shí)候，看到做小黃人的 Illumination 公司竟然也有招 Production Technical Director。

Review

主要包含兩方面：

• Review 工具（如何更好地Review）
• 管理和跟蹤反饋

美術(shù)上傳工作內(nèi)容，總監(jiān)對(duì)其進(jìn)行反饋；美術(shù)拿到反饋繼續(xù)修改，不斷迭代，直到效果通過(guò)。

這里涉及的有：

• Task（上個(gè)部分中的Task）
• Version（內(nèi)容一般是圖片或視頻，美術(shù)的一次迭代）
• Playlist（將多個(gè) Version 放在一起的播放列表，方便開(kāi) Review 會(huì)議時(shí)查看）
• Note（反饋，一般有文字描述、示意圖片、或者其他文件作為附件）
• People（這里指上傳 Version的美術(shù)/外包公司，和負(fù)責(zé) Review 的組長(zhǎng)或總監(jiān)）

大概的關(guān)系是：

影視的幾種 Review 形式：

• 直接日常線上Review，美術(shù)/外包隨時(shí)提交，組長(zhǎng)或總監(jiān)隨時(shí)反饋，Review 流程超快
• rounds，直白翻譯叫巡視，走一圈：總監(jiān)帶著PM，走到 Artist的工位上，直接查看其 DCC 內(nèi)容
• 正式的 Review 會(huì)議，有專(zhuān)業(yè)投影儀，標(biāo)準(zhǔn)的色彩顯示，有組長(zhǎng)、總監(jiān)、PM，興許有客戶(hù)，預(yù)先準(zhǔn)備好的 Playlist 進(jìn)行挨個(gè) Review

游戲還會(huì)有直接打開(kāi)游戲，邊體驗(yàn)邊 Review，我們的反饋方式就要加上錄音、錄屏、截圖。

另外，不得不提一下 Client Review，就是客戶(hù)，或者是導(dǎo)演、老板、IP方等，在內(nèi)部已經(jīng)迭代了不少版，總監(jiān)覺(jué)得已經(jīng)離定稿不遠(yuǎn)了，可以拿出來(lái)給客戶(hù)看看。

client Review 的note 需要做隔離，不能直接讓相應(yīng)的美術(shù)看到。

一方面，確實(shí)有語(yǔ)言翻譯的原因，另外，還是需要“翻譯”一下客戶(hù)的反饋，再一方面，需要“過(guò)濾”一下客戶(hù)的反饋。

Review 工具需要具備的功能：

• 可以寫(xiě)文字描述
• 有各種畫(huà)筆功能，可以直接在畫(huà)面上涂鴉
• 可以錄音、錄屏、截圖
• Ghost and Hold Annotations（可以把視頻其他幀畫(huà)面的涂鴉半透明顯示，適合動(dòng)畫(huà)環(huán)節(jié) Review）
• Live Review （多人在線協(xié)作 Review ）
• 多版本對(duì)比看：并排著對(duì)比、疊在一起對(duì)比
• 可以查看歷史 Note 反饋
• 可以切換歷史Version 版本
• 可以切換其他環(huán)節(jié)的Version 版本
• 影視：可以看到前后shot，串起來(lái)看
• ......

沒(méi)有全部功能都有的產(chǎn)品，各個(gè)產(chǎn)品有差異、有自己的護(hù)城河，我們可以把某一個(gè)功能做的特別好的小軟件納入進(jìn)來(lái)，一起使用，然后將它們結(jié)果信息同步到我們的 Review系統(tǒng)中。

同樣的，該部門(mén)的軟件或者系統(tǒng)必須支持二次開(kāi)發(fā)，我們 Pipeline 在這個(gè)部分的主要精力放在了：

• 讓美術(shù)及時(shí)看到反饋，可以是發(fā)郵件、發(fā)即時(shí)消息
• 甚至讓美術(shù)直接在自己的 DCC 里面看到，把反饋圖片貼在場(chǎng)景里
• 根據(jù)新的Note 反饋，自動(dòng)創(chuàng)建 Task，方便追蹤后續(xù)是否解決了該反饋
• 美術(shù)可以更方便的上傳 Version
• 批量上傳 Version
• 視頻標(biāo)準(zhǔn)化：畫(huà)面水印、文件分辨率、文件編碼、色彩空間、規(guī)范命名......
• 統(tǒng)計(jì)：task 有多少個(gè) version、多少個(gè) note，跟task 的bid 比，滯后了還是超前了，反向修正排期，讓排期更合理。
• 增加更多格式支持，比如支持 3d文件預(yù)覽

同時(shí)具備了項(xiàng)目管理和 Review 功能的軟件有ShotGrid 、Ftrack。游戲跟影視不同，需要有軟件開(kāi)發(fā)的管理部分，這部分如果讓諸如 ShotGrid 來(lái)管，也不是很合適（雖然它的確有軟件開(kāi)發(fā)管理的模塊）。所以，可以?xún)蓚€(gè)都用，對(duì)關(guān)鍵的數(shù)據(jù)進(jìn)行實(shí)時(shí)雙向同步。

這時(shí)候，肯定有人說(shuō)，用兩個(gè)商業(yè)系統(tǒng)，那成本多高啊。

這里肯定是忽略了隱形成本，因?yàn)橛X(jué)得貴：

就使用 excel 來(lái)管理，帶來(lái)了協(xié)作難題，多版本信息不同步，歷史修改丟失，直接影響了生產(chǎn)，這個(gè)成本呢？

如果選用了不合適的或者成熟度低的系統(tǒng)，再雇一個(gè)TA/TD 來(lái)全職開(kāi)發(fā)補(bǔ)齊功能，請(qǐng)問(wèn)他年包幾何，開(kāi)發(fā)能不能按時(shí)完成、bug有多少，這個(gè)成本呢？

非要 Google Docs/騰訊文檔，支持協(xié)作，也能高級(jí)查詢(xún)過(guò)濾，但公式復(fù)雜的逆天，PM 能不能學(xué)會(huì)、啥時(shí)候能學(xué)會(huì)、要不要直接招個(gè)已經(jīng)會(huì)的，這個(gè)成本呢？

再次強(qiáng)調(diào)那句話，美術(shù)資產(chǎn)量不大，確實(shí)沒(méi)必要。

數(shù)據(jù)管理

有一個(gè)我常被問(wèn)到的問(wèn)題是：那我的工程文件，是上傳到 ShotGrid 里嗎？這個(gè)問(wèn)題，簡(jiǎn)單地回答是或不是，遠(yuǎn)遠(yuǎn)不夠。所以索性就說(shuō)個(gè)明白。

Data vs Metadata

Data ，在我們討論的上下文中，指的是我們能在硬盤(pán)上看到的具體文件，比如.max、.mb、.hip文件.

這些文件有的是二進(jìn)制文件，可以理解為用記事本打開(kāi)，里面都是亂碼，人根本就看不懂；

有些是非二進(jìn)制文件，常常是類(lèi)似xml 、json 、yaml 等，可以理解為用記事本打開(kāi)，里面都是人類(lèi)可讀的單詞符號(hào)，偶爾你還能“喲這不是我的節(jié)點(diǎn)名字嘛”

Metadata ，元數(shù)據(jù)，是描述數(shù)據(jù)的數(shù)據(jù)。

比如說(shuō) Data 是你這個(gè)活生生的人， Metadata 就是你的簡(jiǎn)歷內(nèi)容，什么身高、體重、身份證號(hào)等等，在沒(méi)看到你這個(gè)人站在我面前之前，我通過(guò)你的 Metadata （從你簡(jiǎn)歷上看到的），就可以掌握個(gè)大概，有時(shí)候就能判斷出你是不是我要招的人，等我具體想深入了解你的時(shí)候，再把你喊過(guò)來(lái)當(dāng)年交流（就是用相應(yīng)軟件打開(kāi)文件）。

玩攝影的朋友可能更熟悉，Data 就是你拍的圖像文件，Metadata是這張照片的 ISO、焦距、光圈、拍攝時(shí)的地點(diǎn)、曝光......

在我們討論的上下文中，一般是這幾類(lèi)：

• 文件本身的信息：創(chuàng)建時(shí)間、修改時(shí)間、大小、創(chuàng)建者、存放路徑、文件格式
• 文件內(nèi)容的信息：面數(shù)、有沒(méi)有UV、有沒(méi)有骨骼、多少根、在level 里的世界坐標(biāo)、燈光的亮度、相機(jī)的景深
• 人為添加的信息：“這個(gè)文件我增加了地面模型”、“這個(gè)版本把角色的腿拉長(zhǎng)了一些”
• 文件的依賴(lài)關(guān)系：模型文件依賴(lài)的貼圖文件們、動(dòng)畫(huà) reference了哪個(gè)綁定文件、關(guān)卡里面放置的資產(chǎn)們
• 你想記錄的其他信息：這個(gè)文件的質(zhì)檢結(jié)果

一定要根據(jù)你們的需要，選擇真的要經(jīng)常查看的 Metadata

存放方式

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

Data

Data 通常會(huì)比較大，毫無(wú)疑問(wèn)，是存放在文件存儲(chǔ)系統(tǒng)，比如我們的硬盤(pán)、 NAS 、百度網(wǎng)盤(pán)、 P4V 、 SVN 、 Git 等等地方。

Data 文件的存儲(chǔ)，在視效行業(yè)，基本采用 NAS 。

存儲(chǔ)是影視公司的頭等大事，它涉及訪問(wèn)速度、寫(xiě)入效率、快照系統(tǒng)、日志系統(tǒng)、權(quán)限管理、吞吐量、存儲(chǔ)帶寬、協(xié)議延遲、冷熱數(shù)據(jù)分層、分布式存儲(chǔ)等等，總而言之，不是簡(jiǎn)簡(jiǎn)單單的找個(gè)地方放文件就行了，是個(gè)很花錢(qián)的工作。

而游戲這邊，美術(shù)資產(chǎn)分為：

• 進(jìn)引擎之前的，就是.max、.fbx、.sd、.spp等等文件。這跟影視的沒(méi)有任何區(qū)別。
• 進(jìn)引擎之后的，就是游戲引擎項(xiàng)目工程了。

進(jìn)引擎之前的文件

我所見(jiàn)過(guò)的管理軟件有 P4V 、 Git 、 SVN 、Alienbrain 以及，只存放在美術(shù)本地硬盤(pán)上... ...

就算是使用了上述的存儲(chǔ)管理，也并不是每個(gè)工程文件版本都上傳的，大部分還是項(xiàng)目組強(qiáng)制要求，必須至少傳一個(gè)最終版，上下游交接的文件倒還是有上傳的。

影視公司的理念：Artist 制作的所有文件，都是公司的數(shù)字資產(chǎn)，必須 publish 到存儲(chǔ)服務(wù)器！

當(dāng)然啦，這是缺少文件夾放置規(guī)范和自動(dòng)化工具，換位思考一下，沒(méi)有一鍵無(wú)腦上傳工具，你讓我每個(gè)版本都上傳，我也覺(jué)得很煩。

進(jìn)引擎之前的文件存儲(chǔ)方式，建議使用：

• NAS ，推薦指數(shù)，五顆星，下面一個(gè)段落專(zhuān)門(mén)講一下。
• P4V ，推薦指數(shù)，三顆星。專(zhuān)門(mén)給游戲行業(yè)設(shè)計(jì)的。尤其是，如果引擎工程也使用 P4V 了的話，我不清楚它的收費(fèi)模式，但從美術(shù)角度講，可以減少一個(gè)需要理解的系統(tǒng)。如果有人能說(shuō)服我游戲公司真的不能用 NAS ，那么 P4V 可以變成四顆星。
• 云儲(chǔ)存 ，推薦指數(shù)，一顆星。類(lèi)似百度網(wǎng)盤(pán)，但不要用百度網(wǎng)盤(pán)！如果你不知道為什么就證明你根本不適合它。對(duì)象存儲(chǔ)這塊，影視有強(qiáng)大的、專(zhuān)業(yè)的、專(zhuān)門(mén)服務(wù)TD 的 IT，都還沒(méi)敢全換，只敢稍微嘗試一下（跟外包進(jìn)行文件交接），除非你能找來(lái)核心開(kāi)發(fā)者專(zhuān)門(mén)來(lái)給你服務(wù)。
• SVN 、 Git ，推薦指數(shù)，零顆星。這倆就不是干這個(gè)事的！相當(dāng)于你讓一個(gè)模型師去設(shè)計(jì)汽車(chē)的發(fā)動(dòng)機(jī)，原因是他們都用 Max 來(lái)建模。就我上面提到的存儲(chǔ)要涉及的功能特性，他們兩位能有的寥寥無(wú)幾。

單獨(dú)介紹一下 NAS

使用方式：每個(gè)美術(shù)，把 NAS 服務(wù)器映射為統(tǒng)一的一個(gè)盤(pán)符，比如 x:/ ,相當(dāng)于美術(shù)插了一塊“移動(dòng)”硬盤(pán)，跟 D 盤(pán)一樣。只是這塊盤(pán)，每個(gè)人都有，而且都是同一個(gè)。

入門(mén)：美術(shù) A 創(chuàng)建了個(gè) x:/aaa/bbb.txt ，美術(shù) B 那里馬上也有了 x:/aaa/bbb.txt

高級(jí)：美術(shù) A 建了個(gè)模型
x:/prop_desk_model_v001.mb ，然后里面引用了幾張貼圖 x:/prop_desk_normal.tga x:/prop_desk_diffuse.tga ，保存。美術(shù) B 此時(shí)打開(kāi)
x:/prop_desk_model_v001.mb，不會(huì)有任何問(wèn)題，全程沒(méi)有上傳下載的步驟。這里只是簡(jiǎn)單舉例，影視并不是這么粗暴使用的，但就是這個(gè)理兒。

在上文中提到，不能責(zé)怪游戲TA 工具部署那么繁瑣，影視的工具、Pipeline系統(tǒng)代碼直接部署在NAS 上，把 NAS 上的代碼文件更新了，工具就更新了（ps：工具里不要長(zhǎng)時(shí)間 open一個(gè)代碼里面的文件，不close），然后這個(gè)文件夾權(quán)限鎖死，只有自動(dòng)部署的CI 機(jī)器有權(quán)限寫(xiě)入，防止美術(shù)誤刪誤改。

另外有一點(diǎn)，因?yàn)槲募挤旁诹?NAS 上，如果網(wǎng)速夠快，美術(shù)直接在 NAS 上制作，本地的硬盤(pán)就不會(huì)被占了，只需擴(kuò)容 NAS 即可。

對(duì)比一下 P4V ，美術(shù)制作過(guò)程中的文件都在本地，要是跟其他人交換文件，首先需要?jiǎng)e人上傳（這個(gè)上傳過(guò)程可不簡(jiǎn)單），還得把別人的文件下載到他本地，也就是說(shuō)，同一個(gè)文件，出現(xiàn)在了多個(gè)硬盤(pán)里，不浪費(fèi)嗎？我見(jiàn)過(guò)一個(gè)項(xiàng)目才是初期，打開(kāi)美術(shù)的資源管理器，一片紅彤彤的硬盤(pán)空間告警，然后每個(gè)人都去再次申請(qǐng)?jiān)黾觽€(gè)人硬盤(pán)，不浪費(fèi)嗎？

P4V 主打的版本管理，在 DCC這里沒(méi)用，二進(jìn)制文件merge 不了，就算是非二進(jìn)制文件也 merge 不了。（你讓美術(shù)去解決兩個(gè)sd文件的沖突？美術(shù)打爆你的狗頭?。?/p>

你可能說(shuō)，那我就喜歡我依賴(lài)的文件，一直都叫 prop_desk_model，可以自動(dòng)更新 ，你說(shuō)的 NAS 存儲(chǔ)，它今天叫 prop_desk_model_v0002 ，明天又多出一個(gè)新版本叫 prop_desk_model_v0003 ，我還得手動(dòng)更新呢。

這位客官請(qǐng)留步，首先，誰(shuí)告訴你 NAS 不能搞文件一直叫 prop_desk_model ，而且永遠(yuǎn)是最新版。symbolic link 了解一下。

其次，這個(gè)更新的確有自動(dòng)更新，和手動(dòng)更新兩種，但你 P4V 也不是自動(dòng)更新的呀（不二次開(kāi)發(fā)的話），也得點(diǎn)一下更新按鈕。

最后，我們不使用 symbolic link 是因?yàn)榈暨^(guò)坑。美術(shù) B 用了美術(shù) A 的文件，干的好好的，第二天，文件打不開(kāi)了，經(jīng)排查，是美術(shù) A 更新的文件導(dǎo)致的。然后有一天美術(shù)C 也要用美術(shù) A 的文件，并提出個(gè)修改，美術(shù)A 修改了，但是美術(shù) B 并不需要這個(gè)修改，又悲劇了......

所以，我們最后選擇了每個(gè)版本都是單獨(dú)的文件，通過(guò)文件名里面帶著版本號(hào)來(lái)進(jìn)行管理。這個(gè)也符合美術(shù)的直覺(jué)。

Pipeline 系統(tǒng)自動(dòng)獲取是否有新版本，詢(xún)問(wèn)美術(shù)是否更新，然后美術(shù)可以一鍵更新，美術(shù)也可以隨時(shí)回溯到任意版本，數(shù)據(jù)隔離美滋滋。

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

的確，游戲行業(yè)進(jìn)引擎之前的文件，沒(méi)有影視整個(gè)公司的多（不能跟項(xiàng)目比，影視有的項(xiàng)目也可小了），那你 NAS 硬盤(pán)可以買(mǎi)少點(diǎn)啊！

難道是因?yàn)樵L問(wèn)速度？那我們可以在本地硬盤(pán)制作，完成后 publish 到 NAS 上啊。（請(qǐng)明白的人幫忙解惑，感激不盡。）

進(jìn)引擎之后的文件

游戲項(xiàng)目工程，必須必須必須選擇一個(gè)有版本管理功能的軟件，如 P4V 、 SVN 、 Git，這一點(diǎn)大家都沒(méi)有疑問(wèn)。

Metadata

Matadata 則存在兩種方式，以 json 或者 xml 文件形式，一般存放在它要描述的 Data 旁邊，看起來(lái)可能是這樣：

prop_desk_model_v002.max

prop_desk_model_v002.json

另一種方式，則是將 Metadata 存入數(shù)據(jù)庫(kù)里面。

看你們的實(shí)際需求吧。

你非要問(wèn)我的意見(jiàn)，那我肯定是選擇數(shù)據(jù)庫(kù)。

為啥不用“存放在文件中”方式呢，當(dāng)我們要查看、要搜索的時(shí)候，比如過(guò)濾出模型面數(shù)超過(guò)2千的武器，這種方式基本就是去遞歸掃描武器文件夾里面，模型文件旁邊的 Metadata文件，打開(kāi)、讀取，哎呀不符合，下一個(gè).....資產(chǎn)量稍微上去一點(diǎn)，可能幾分鐘、十幾分鐘過(guò)去了，突然我覺(jué)得，我也不是那么的想知道超過(guò)2千面數(shù)的武器有哪些了。雪上加霜的是，如果是存放在了 P4V 、 SVN 、Git ，本地都沒(méi)有下載全部資產(chǎn)，還怎么搜索！

那我就去 P4V 服務(wù)器上搜嘛！——你這是把存放文件中的唯一優(yōu)點(diǎn)也舍棄了。

另外，前文也提到：項(xiàng)目管理系統(tǒng)的數(shù)據(jù)庫(kù)要支持一定程度的自定義：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 column。

ShotGrid 和 Ftrack 都支持?jǐn)?shù)據(jù)庫(kù)自定義（可能程度不一樣），一魚(yú)三吃，白得一個(gè)數(shù)據(jù)庫(kù)！而且 UI、API、賬號(hào)權(quán)限管理...存放在數(shù)據(jù)庫(kù)方式的缺點(diǎn)，全解決了，還不用額外花錢(qián)！

除此之外可以省去TD 一大部分工作量，還能拿它去當(dāng)人才庫(kù)、資產(chǎn)庫(kù)、材質(zhì)庫(kù)、日?qǐng)?bào)管理、Pipeline團(tuán)隊(duì)的開(kāi)發(fā)管理、各種工具的后臺(tái)。

書(shū)歸正傳。還有個(gè)問(wèn)題。

Data 和 Metadata 有時(shí)候不是那么好區(qū)分，尤其是那種整合拼裝其他二進(jìn)制文件的軟件 ，同時(shí)也不把引用的文件內(nèi)容封裝寫(xiě)入到自己的工程文件里面的，比如 Nuke Studio、Substance Designer 等。還有，游戲引擎的項(xiàng)目工程！

這時(shí)候，我們就要發(fā)自?xún)?nèi)心地好好想想，到底哪些數(shù)據(jù)，是我們不想開(kāi) data 文件，就想知道的。

這事做到極致的就是達(dá)芬奇軟件（DaVinci Resolve），它的工程文件就是個(gè)數(shù)據(jù)庫(kù)！

命名規(guī)范

這包含文件命名規(guī)范和文件夾規(guī)范。具體如何去制定就再說(shuō)吧......看有沒(méi)有人愿意看

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

規(guī)范命名主要的目的是，給資產(chǎn)文件提供一個(gè)全局唯一的標(biāo)識(shí)。

• 當(dāng)我們提到一個(gè)資產(chǎn)的時(shí)候，就知道在哪里可以找到對(duì)于的文件。
• 當(dāng)我們看到文件的名字，就可以確定資產(chǎn)的位置和類(lèi)型。
• 有了規(guī)范的層級(jí)和命名，Pipeline 工具就可以自動(dòng)化幫你上傳下載、導(dǎo)入導(dǎo)出。

Metadata 怎么記錄

最好是美術(shù)使用 Pipeline 工具，在文件被上傳/同步到服務(wù)器上時(shí)，自動(dòng)提取出來(lái)，自動(dòng)上傳到咱們的Metadata 數(shù)據(jù)庫(kù)里。

額外的也需要用戶(hù)輸入，比如本次文件修改的內(nèi)容。雖然我過(guò)往的經(jīng)驗(yàn)是，搜集上來(lái)的都是“修改了一下”、“1111”這種無(wú)效信息。但我們可以在填寫(xiě)的輸入框里，自動(dòng)填充一下模板，引導(dǎo)美術(shù)大大們寫(xiě)上合適的內(nèi)容。