PM 如何改變藝術製作:AAA 遊戲案例研究

免責聲明

在擔任專案經理期間,我經常聽到這樣的評論:「我們為什麼需要專案經理?他們實際上做什麼?他們只會說話,沒別的。」這是一個相當普遍的看法。

因此我準備了一篇文章,介紹專案經理實際上能做什麼(與他們的團隊一起)以及這項工作對專案的影響力有多大。正如我們專案經理和製作人喜歡的那樣——用數字、表格和圖表呈現。文章分為三個部分:美術流程、日常工作優化和JIRA禮儀。

這個案例來自我的個人經驗,重點介紹我們如何在一個AAA專案上從零開始建立外觀部門,最終優化美術製作,將速度提升了3.3倍。

非常感謝。祝您閱讀愉快。

美術流程

案例

有一次我以專案經理的身份進入製作部門,任務是:建立一個外觀部門,為戰鬥通行證和遊戲內活動提供造型(以及更多內容)。

同時,我們已經有一個角色美術部門。他們創建了八個處於不同完成階段的角色和一個包含幾何變化的高階造型。製作那個單一造型花費了美術師16個月的時間。

我的任務是建立一個正常運作的製作流程,並在發布日期前完全滿足發行商的要求:21+個包含新幾何的造型和40+個換色版本。之後,我們必須每月發布7+個不同類型的造型——而在接下來的一年中,將這些數字翻倍。

工作

首先,我分析了之前的經驗和當前網格(角色和造型)的製作速度。使用來自Jira和大量Excel表格的數據,我們確定了幾個弱點。

美術製作路線圖

總體上沒有角色美術製作的結構化路線圖,特別是外觀方面。網格被視為角色開發流程的一部分,所有相關工作都被放入三個大階段——L0、L1、L2——從原型到最終完善版本。這些超大型任務中的每一個都可能超出衝刺週期長度,不僅僅是兩個週期,有時甚至是三個或四個。

缺乏標準

每個網格都被視為研發功能。當我們比較不同案例中的L0/L1/L2階段時,我們發現它們花費的時間完全不同——無論是淨時間(記錄的工時)還是總時間(從任務創建、移至「進行中」到標記為「完成」之間的間隔)。即使是相同類型網格的任務數量也有很大差異,其中一些任務的描述幾乎無法理解。

一個特別突出的現象是:分配給任務的一位美術師從頭到尾負責網格工作(根據分配歷史記錄判斷)。在製作過程中,沒有合理的節點可以讓他在不損失品質或時間的情況下將工作交給其他人。整個任務看起來就像一個巨大、連續的工作塊。

缺乏流程透明度

不清楚開發過程中發生了什麼或如何進行。任務更新的品質和一致性完全取決於開發者本身。除了早晨的站立會議外,沒有辦法遠程追蹤進度。如果一位美術師生病了,主管可以部分接手他們的任務,完全不留任何註記,然後仍然關閉任務。

迭代次數

即使從基本的狀態歷史記錄中也很明顯,任務進入審核,然後返回,然後再次進入審核,然後又返回工作。更不用說完全沒有評論說明為什麼任務被退回工作然後又被重新提交——一個字都沒有。

我們與我們的小型光明會圈子——我自己(作為專案經理)、首席美術師和美術主管——聚在一起開始工作。

解決方案

首先,我們做出了兩個重要的高階決策,以停止頂層的混亂。

我們引入了等級

在此之前,專案中充斥著各種術語和標籤:換色、塗裝、造型、高級造型、老兵等等。每個詞都指代不同類型的工作,這只會讓我們更加困惑。我們放棄了所有這些,引入了一份文件,清楚地列出了造型及其等級之間的差異。

「一個造型=一個史詩=一個分支」規則

我從角色開發團隊借用了這個組織規則。一個史詩包含開發方面與造型相關的所有工作。每個史詩包含一個分支和一個專門用於該造型的拉取請求。反過來,史詩連結到相關賽季(或活動)計劃/功能,以便更容易導航。

這是我們的起點。從那裡開始,我們重建了整個工作流程。

我們取消了L0-L1-L2

相反,我們根據實際製作邏輯劃分製作:設計→幾何→紋理→實作。

每個階段都被分解為更小的邏輯步驟,例如:\n 概念:情緒板-2D草圖-3D草圖(如果需要)\n 幾何:低解析度-高解析度-FBX檔案匯入\n 實作:骨架-遊戲設計設定-美術審核-品保

造型本身也被分為三個部分:身體、武器和模組。這意味著從那時起我們可以有三個獨立的任務,例如:\n 身體-幾何低解析度,\n 武器-幾何低解析度,\n 模組-幾何低解析度。

這將過去的單一大型工作塊轉變為類似樂高的建構器,可以根據美術師的工作量在他們之間分配。現在可以準確追蹤製作目前處於哪個階段。

新的美術製作路線圖

基本上,我們上面所做的一切都被列為一系列操作。這個圖表幫助我們——以及任何可能需要在我病假或休假期間替換我的專案經理——了解在哪裡以及哪些流程可以並行執行以節省時間。

史詩和任務的統一格式

史詩現在只包含嚴格與造型等級相關的任務——沒有額外內容。

每個史詩在其描述中包含造型的概念,以及製作人的驗收標準。

這減少了混亂,讓美術師清楚了解每個階段的期望是什麼。(後來我們進一步完善了任務描述,但這與接下來的日常工作主題有關。)

我還在Confluence中建立了一個單獨的區域,其中包含一個Mira看板,列出了每個任務的所有這些描述,並為專案經理提供了註釋,說明何時以及應該創建什麼任務,以及可以簡單地複製並貼到任務主體中的Jira公式。

估算

我們試圖將任務分解得易於規劃。專案使用兩週衝刺,因此我們旨在找到一個通用結構:不要過度超出界限,同時仍為每個任務提供一個邏輯完成點。

非常感謝我的同事——沒有他們的經驗,我們無法如此精確地分解。僅依賴Jira數字會困難得多,因為在美術製作中,個別專家的技能非常重要,在設計估算時,我們必須在我們實際能交付的內容和我們想要實現的內容之間找到黃金中點。這就是我們得出一個開發步驟=最多一個衝刺加兩天公式的方式。

現在美術師可以看到他們每個任務有多少時間以及距離完成還有多近。通過適當的溝通,這成為一個支援工具。如果美術師看到他們還剩三天完成任務但知道自己無法完成——他們可以主動告訴我。

這意味著我不必「控制」開發者;他們擁有所有工具來幫助我,並在我們可能錯過截止日期的地方發出警報。

結果,我們成功實現了開發者自主權。打開史詩時,美術師會發現一個準備就緒、完全準備好的任務,他們可以立即開始——即使他們一開始並不完全確定該做什麼。我們使審核會議和評估標準變得透明。

結果

直入主題。只有數字。

就是這個案例。

\ \ \