騰訊光子專家談他的力量：改進流程工具促進遊戲美術高效創作

國產遊戲研發團隊搭建自研體系經歷了怎樣的過程？目前我們的遊戲研發技術在全球範圍處於怎樣的水平？騰訊光子工作室群近期在知乎上發起“國產自研遊戲的發展之路”圓桌活動，本文來自圓桌議題“作為TA，如何改進流程工具，支援遊戲美術更有效地進行藝術創作？”話題下的回答。

作者：Timmy
騰訊光子工作室群技術美術專家

在聊這個話題之前，先鋪墊一下自己的工作經歷背景：我是Timmy，來自騰訊光子工作室群，負責工具開發。來騰訊前，我曾在影視行業實習流程 TD 的工作，主要負責流程工具的搭建 Maya 繫結的技術支援。

進入騰訊之後，我負責開發各種 DCC 工具，其間先後參與了 Maya、3dsMax、Blender、Photoshop、Unreal 等軟體的工具開發。一路走來，積累了一些在工具和流程向 TA 方面的工作經驗，藉此機會和大家分享。

他的話題比較巨集大，不同領域的 TA 視野也相差較大，本文章內容的觀點主要站在工具和流程向 TA 的角度，如果哪裡有錯誤的地方，歡迎指正。


上面的圖片就是流傳甚廣的TA能力圖譜。我的能力主要覆蓋在側邊的Rigging、Tools、Pipeline 三個方向上，所以，下面就聚焦於這三個方向來聊聊。

作為 TA，如何改進流程工具，支援遊戲美術更有效地進行藝術創作？

作為工具 TA ，我時常會自我調侃，說自己是美術爸爸的工具人。開發一個工具，美術只用一段時間，然後就再也沒用過了...

但是，其實這些瑣碎的問題可以抽絲剝繭地從更根源的地方著手，從而更高效地拿出解決方案。比如，我們來看這樣一個實戰場景：

實際專案過程中，我們會將很多美術資產發給外包團隊處理，但有時候，可能因為溝通出問題，或是外包疏忽了，導致收回來的資源存在一系列的問題。

我曾遇到，外包發回來的資源沒有按照專案規範中要求的方式來配置 Maya 的攝像機，導致輸出的效果並不理想。還好，這種情況解決起來也不復雜，將攝像機的配置修改一下就好了。

然而，實際上出現錯誤的問題往往不止一個。如果人力去修復的話，一方面有可能會出現二次紕漏，另一方面有好幾十個檔案，修改起來非常浪費時間。這時候，我們自然就希望工具 TA 可以用程式碼批量修復這些問題。

所以，我當初先是快速地弄了個修復指令碼來解決當前問題。考慮到不同批次檔案採用的配置可能是不一樣的，我還另外專門做了個修復工具，來修復檔案。

然而，我花了很多時間做完之後卻發現，這個修復工具並不能長期派上用場——因為這是針對當前情況定製的，下次美術外包可能又會出現其他問題，這個工具反而變得雞肋。

作為工具 TA，如果我們只是做修復工具來充當救火隊長，找不到問題的根源，那類似的問題還會大量出現，浪費大量時間。要想更好地支援美術團隊，進一步優化工具，就必須找到——

一、問題的根源

剖絲剝繭，問題的根源有可能在美術和外包的溝通上。但是，有人蔘與的地方難免會出現紕漏，因此，自然會想到可以用工具來檢查資源是否符合規範，以此規避人為疏忽的可能性。

工具本質上是一種基於固定規則解決重複問題，從而解放美術生產力的手段。美術規範也是規則，我們完全開發一套檢查工具交給外包去用，在資源返回之前檢查出問題，提前處理問題，避免問題資源流轉到下游，倘若檢查工具還附帶自動修復功能，那就更省事了。

在製作檢查工具時，TA 需要提前與美術溝通好相關資源的規範，可能涉及命名規範、路徑規範、製作規範、效能規範等等，這需要良好的溝通以及豐富的專案經驗。

當然，這個工具不只是給外包使用，也可以給內部美術使用，優化資源的釋出流程。

找到了問題的根源，那麼接下來就是——

二、解決方案

我在專案接入了開源的 pyblish 檢查框架用來跑資源測試。

pyblish 分了 CVEI 四個流程 (Colleciton Validation Extraction Integration)


通過這套工具，檔案如果不通過檢查就無法正常釋出，而這樣就可以使美術修復檔案的問題再流轉，避免問題檔案流轉到後續的流程。

三、方案落地

在讓新的工具方案落地時，需要尤其注意兩點：

1、溝通成本問題。

雖然我在專案組，大多數情況下都是與團隊面對面溝通的，但如果工具的使用者不斷增加，那麼對接本身也會十分費時，而且圖示也最好加上中文註解，避免理解錯誤。如果在工具加上幫助按鈕來跳轉說明文件，也會省事很多。

有時候，這些文件也是給自己看的，工具太久沒碰，作為開發者也可能會遺忘很多細節。

2、落地後的反饋與磨合

工具整理好之後要交給美術去測試，並聽取他們的反饋意見。落地一個新工具和新方案，多少會讓人抗拒，畢竟要改變原有的工作方式。因此清晰的文件和好的 UX 設計是非常重要的，這樣可以減少溝通成本。

文件製作方法：可以用靜態網站生成工具，比如：hugohexo mkdocs 去做，這樣只要寫 markdown 檔案就可以生成網頁。

四、問題延伸

有了工具之後，維護工具也是工具 TA 非常重要的日常。專案在發展，規範也在不斷更新，因此工具也是需要與時俱進的。而這也逐漸引申出額外的問題，它們會切實影響到美術對工具的使用：

A、部署問題

解決部署問題，有兩種解決方案：

1、共享路徑，只要更新一處地方，大家都可以共享更新，但是網路波動可能會導致體驗不好。

2、下載到本地，只要一次下載，後續不會有網路問題，但是本地檔案可能會被修改。無論那種方式都需要一個工具去配置美術機器，共享路徑會相對簡單，只要將配置 UNC路徑連線遠端就可以了。下載到本地則需要有工具去下載和管理程式碼包，需要快取來優化載入速度。

B、程式碼維護

• 統一程式碼規範
• 單元測試
• 程式碼審查
• ci 工具檢查程式碼
  

如果時間允許的話，寫單元測試是非常好的。

以前總是調侃自己不是在寫程式碼，而是在寫 BUG。但其實，如果有高度覆蓋的單元測試，我們就可以通過單元測試來驗證新新增的功能是否出現預期外的問題，比如：會不會因為修復一個 BUG引發了更多 BUG。

我們可以把遇到 BUG 的情況寫成單元測試，每次釋出之前都要確保單元測試通過，以此來降低 BUG 的出現概率。程式碼審查也是非常好的互相學習的機會，可以藉此統一大家的程式碼風格。另外有經驗豐富的人把關程式碼，可以規避很多坑。

在 Python 環境下也有很多工具可以輔助開發：

格式化程式碼可以使用 black isort；

檢查程式碼可以使用 flake8 或者 pylint；

使用 commitizen 規範化提交資訊；

可以配置 ci 流程，自動進行程式碼檢查，避免遺漏。

C、工具依賴 和 版本回退

使用 rez 進行包管理。

rez 可以管理包的依賴和版本。使用 rez 的命令可以構建出一個隔離的環境規避美術機器自身的環境變數影響。另外“版本”和“依賴關係”配置在包的定義裡。這樣排程包的時候可以自動解決依賴問題，也可以更具需要回退版本。

思路擴充：影視流程的解決方案

其實上面提到的這些問題，影視行業同樣會經常遇到。正因如此，影視行業早已有了很多成熟的解決方案。

比如說，使用 shotgrid、ftrack 之類成熟的流程平臺，可以更好地管理上下游流程。


在成熟的平臺上，美術甚至不用關心資源的儲存路徑，所有的流程都可以通過工具自動化實現。

在流程平臺上配置好任務，美術只要在 DCC 中開啟工具選擇任務，工具就會自動將任務關聯的資源開啟，可以開始製作了。當製作完成之後，可以用工具進行釋出，這個時候會自動更新到平臺的資料，並且通知到上下游關聯的人員。比如說，模型師做完了模型，會自動通知到主美來稽核，稽核通過之後，下游的繫結流程就會收到模型完成的通知，並且能夠在相應的工具上獲取到模型，開始工作。使用這些流程平臺管理資產和任務會讓整個製作流程更加自動化，平臺承載的資料也讓工具更加智慧。

當然了，這些流程平臺都存在不少的學習和使用成本，需要較多的二次開發才能更好支援遊戲專案。很多專案已經有自己的一套工作模式，要切換到新的流程上，大都有水土不服的情況。要想克服水土不服，需要自上而下地推動這些流程落地。