這是一個我去年年底寫的文章，當時在和很多人討論如何優化他們現在的開發管線。費了好大勁寫的，點贊收藏再看吧。
1、定義與作用
遊戲管線，或者遊戲開發管線，指的是一種“工作流程”。
每個遊戲項目因為其選擇的核心玩法、渲染風格、敘事方式或者純粹的體量要求，都會導致管線的特異性。
這個所謂的“管線”在一個項目中，不是一個，而是會有許多個。這些管線交織在一起，形成針對不同資產、不同階段的遊戲內容生產軌道。它們彼此關聯，互相影響。
好的遊戲開發管線有兩個最顯著的作用：提高質量下限、優化整體效率。
做出一些足夠出彩的細節來吸引玩家是必須的，但是這和工業化與提效不衝突
以一些常見的情況來舉例：
有多少團隊會在“結版本出包”這件事上讓整個團隊停下來幾天，甚至數週？
有多少團隊會出現遊戲資產的質量參差不齊，有的很精緻，有的很拉跨？
有多少團隊會經常出現”開發瓶頸“——大家在經常要等某幾個人，這幾個人的進度決定了整體的進度？
而這些問題之所以存在，正是因為”電子遊戲“是一種”擁有商業屬性的高技術濃度裝置藝術“。這種產品與傳統互聯網產品完全不同，反倒是和汽車工業等有點像。
一個優秀的產品往往具備設計壁壘、技術壁壘、工作量壁壘中的至少一個（常見的大多具備兩個以上）。而前兩個壁壘在小型獨立遊戲領域問題可能不大，但是一旦項目成一定規模，就必須建設可靠的開發管線，以保證壁壘的持續和堅挺。
而所謂的”遊戲工業化“就是遊戲開發管線的設計、搭建、維護和優化的過程。
2、管線設計
大概知道開發管線是怎麼回事之後，我們來聊“管線設計”。
眾所周知，工業化的基礎是標準化。而標準的制定，卻是整個環節設計的”第3步。
第1步，是做Demo和立項 —— 大家先說清楚我們做的是啥。
很多時候立項只是因為有個“點子”。這本身沒有問題，但是實際上這個點子是否成立是需要實際論證甚至驗證的。因為不是所有人都具備足夠的“演繹法”能力，為了不讓以後出大麻煩，開發團隊需要在一開始就錨定整個項目的目標，並用Demo將這個目標講清楚。在這個Demo的開發過程中，整個初始團隊要進行瘋狂的磨合，一方面瞭解團隊和目標的關係，一方面探索流程的合理性。
可能你覺得想的內容不多，但為了讓Demo有說服力，會衍生出一堆東西，要學會做減法，MVP
在這個階段中，我們還需要確定幾件事：
a. 美術資源品質要達到什麼程度。
b. 標準形態下的核心玩法需要做到什麼程度。
c. 達到這個程度，當下最合理的工作流是什麼樣的。
d. 為了展示上述內容，我們有什麼資源是必須新做？
用儘可能少的“新資源”來製作Demo，說明標準和目的是一種能力
第2步，制定里程碑 —— 別一下子把攤子鋪太大，大家一起向一個方向用力。
在這個階段，大家需要圈定好項目的邊界和範圍。然後根據團隊的能力和預算，分好開發階段。儘可能不要在實際開發走起來之後，發現做每一件事都需要打補丁和產生不可預估的前置任務。
在這個階段中，我們需要確定幾件事：
a. 項目一共有多少內容量。說清楚有多少功能、多少玩法、多少系統。
b. 根據我們的產能，制定多個可以量化內容的階段。每個階段不能超過三個月。
團隊必須能用文字清晰的描述每個階段——里程碑 的驗收內容和每個內容的保準。如果可以的話，用形象的語言描述此時如果是玩家能看到什麼、體驗什麼。
c. 詳細的拆解每個里程碑的開發內容，排清楚開發順序。
第3步，現在，我們就可以面向目標定標準了。
這裡的標準主要包含兩部分：
a. 流程的標準 —— 大流程包括了誰先誰後，前置環節做到什麼程度才能啟動後置環節，每個不同類型的需求由誰發起，誰跟進，每個環節的負責人如何指定，最終結果誰負責。
b. 資產的標準 —— 除了各類美術資產，也包括策劃資產、技術資產，甚至會議記錄的內容。
而管線的設計也就由此開始：
a. 簡單的遊戲資產管線設計：明確的規範遊戲開發的每個環節，包括資產的生產，人員的協作，並作的驗收，多個成果的組合。
你必須可以明確的描述遊戲開發流程中每個資產從無到有的各個環節的負責人，以及每個開發任務的前後置關係。
b. 不同事項的依賴關係和優先級定義：
有些需求雖然看似明確，但卻依賴於其他的需求的結果；
有些需求雖然看似關鍵，卻是個無法確定耗時的“研究”；
有些非常耗時的研究和探索，可能會導致後續工作流的變化；
有些工作項是嘗試性的，可能其成果不一定會真的有用。
這些工作項可能彼此依賴，或在冷靜的討論下被調整優先級。因為團隊的規模有限，需要在項目開始的時候決定好，每個人在每個階段的工作重心是什麼。尤其是每個領域的核心角色。
第4步：管線的維護和優化
管線優化的主要目的是提高效率，那麼就會有如下幾個方向的思考：
a. 優化單個環節工活兒的時間
i. 人員的適配在這個環節是最有感覺的。優秀的項管人員能將合適的人放在合適的活兒上。
ii. 很多工具、插件也是在這個部分發力的。
此時，管線的設計者需要明確的判斷這些工具的價值和影響：
這個工具的對象是雕花還是鋪量，提高質量還是提高速度，代價是什麼？這個工具的引入帶來的影響是一個人的還是一條線的還是一個面的，對整個團隊來說整體的結果是不是利大於弊？
尤其是在AI時代逐步來臨之後，越來越多的工具在這個環節努力將已經標準化的流程從工業化推向智能化。但是這往往帶來工作流程和團隊結構的改變。需要有額外的管理成本和人員培訓成本。
將重複量很高且可以規範的工作工標準化、工具化、自動化
比如我們為之前公司設計開發的劇情動畫工具↑，它是個服務，由插件和引擎關聯。
我們可以很清晰的描述它的定位就是鋪量，能夠保證整家公司劇情表演動畫的下限。 它的利弊：但是它無法負責雕花。它能將劇情動畫的鋪量工作從數週一條變成一分鐘一條，而且可以讓劇情策劃直接操作。在策劃完成這部分工作後，讓劇情動畫組或者PV組的美術同學在此基礎上做選擇並優化結果。
它產生的開發管線影響：它需要項目開發團隊的工作流程和資產準備的順序產生影響，需要團隊更早的規劃每個角色的動作庫。釋放劇情動畫人員的人力需求和時間需求，大幅度降低這個環節前置步驟的開發成本。
衡量下來整體是增利大於弊的，而且利弊對比懸殊。這個工具也因此成為了在全公司在全國各類團隊中都非常受歡迎的自研提效工具之一。
iii. 當發現因為“標準不明確”導致的返工時，要格外注意。
有些時候，“你之前沒說清楚”或者“我怎麼知道你以後要這麼做”是一個很容易被忽略的管理問題。作為管線的維護人員，我們絕不能把這種話看作是“甩鍋”。絕大部分的人，都不存在能力問題。但是大部分人都是不想“為溝通浪費時間”。那麼如何讓單次的溝通更有效率，更準確，是要時刻去關注的。這也是幫助團隊中一個管線下的各個環節形成默契的手段之一。
“你為什麼不看文檔”和“你開會的時候怎麼沒說”。也是在規則之上要針對“人”去做處理的。當然，如果某些可以量化的標準是普遍要遵守的，也可以做一些工具出來：
我們曾經為美術開發過資產檢查工具，檢查不通過是不能上傳到庫裡的。
b. 優化整體時間
這裡其實更多的是和很多“一直以來都是這麼做的”去較勁的，衝破歷史和習慣的枷鎖。 i. 時刻關注耗時的高峰，將削峰作為使命。
遊戲開發的過程中，經常會出現一些計劃外但又無法預估耗時的事情。
比如每次“打包”“打版本”前的混亂。包括了衝突、配置錯誤、因為性能不合規導致的資源修改和不合適的渲染方案優化。
其實所有有點經驗的開發者都知道這件事應該前置。但是本來每個人的開發工作量幾乎就是排滿的，而且屎山上的屎也不全是自己的。種種原因就會導致誰也不願意提早進行這部分工作，就算想，這件事的優先級也提不起來。
所以，削峰就成為了一個要去“設計”的事情。比如說，使用UWA等工具在遊戲第一次成功出包之後，就進行全自動的每日打包，配一個自動安裝啟動的腳本。這個腳本每天後半夜運行。指派一個人，早上來了看一眼，如果失敗了，就立刻找人解決一下。讓問題不堆積。 在此基礎上，我們完全可以做一個簡單的性能監控腳本，這個腳本就是打開遊戲裡一些主要的功能玩法，和美術、程序最擔心性能問題的地方。每週一次，週末自動運行，只要包打的出來，就去這些地方跑一下，把性能記下來。週一上午讓主程主美引擎TA一起看一下，如果發現又隱患，立刻插個小單下去，爭取週三之前就消化掉。
我們在前司的部分項目中搭建了這套流程，有一套自動化的SaaS守護著這些項目，他們也從來沒為這種問題擔心過。
簡易的日常監控設備牆
ii. 減少瓶頸環節的存在感
這裡主要針對“科研”類任務。這些任務往往擁有很高的必要性和不可預估的耗時。 所以，這些事必須做，但必須“單獨處理” —— 不把這件事放在里程碑的常規規劃裡，而是作為一件單獨的時間線進行管理。所有它的後置任務先不排。能不能流出人力Buffer看團隊的實際情況而定。但是反正不能讓別人等它。
注意，瓶頸工作項是一定會存在的，但是如果你想打造一個健康的工業化管線，就要努力讓瓶頸工作項的影響範圍更小。
iii. 合理的利用工具進行職權轉移
每個崗位都有他自己的“垃圾時間”。
比如，我會認為界面最上層的邏輯和某些關卡元素的搭建對於前端來說，就是垃圾時間。因為這些事對於策劃和UX來說可能是需要頻繁調整的事情，而這些事對於這兩個工種來說是非常必要且持續的，對前端來說就是細碎且沒有營養的。
於是我會非常推薦使用一些圖形化編程工具，讓非技術人員可以先把Demo和效果調到滿意，再讓真·程序員去把最後一公里走完。這件即節省了程序的開發時間，也節省了程序與策劃和UX的溝通時間。
當這些非技術人員培養出來後，關卡玩法、社區功能、UI製作、表演控制都可以由他們來完成了。（從某個角度來說，這也是省錢的方法，畢竟程序的時薪比別的工種都貴啊）
藍圖類的工具用好，真的可以方便很多。
c. 持續提高環節通過率
這是每一個管線維護人員都要去因地制宜去思考的。
尤其是一條新管線在剛跑起來的時候，一定要持續跟進一段時間。觀察環節和環節的交互是否順暢。有些時候，規矩是好的，但反人性，也需要規則的設計者進行換位思考。而且在早期不要害怕嘗試，也不要怕捱罵。
舉個例子：我曾經有連續兩三個月對一個大型項目的五十多個管線進行大規模的刪減。最有趣的是，大部分時候，我刪掉了一些環節，整個團隊毫無感覺 —— 這些環節規則上存在，但是因為反人性，所以大部分團隊成員是不願意遵守的，甚至已經故意無視它們了。而在這個時候，你要意識到：因為這些環節的被忽略，一定有風險和隱患出現了，我們需要去檢查之前的產出物，看是否有問題。
溝通方式優化、文檔內容減少廢話、規範和標準的清晰、不墨守陳規的嘗試新的工具都是要去做的事。
尤其是努力嘗試將垃圾時間釋放掉。比如我們會意識到大部分項目的美術資源規範是程序制定的。但是當美術不遵守規範時，程序很難主動張嘴去維護這個規範 —— 一來是覺得還有更重要的事兒，二來畢竟早晚是要做優化的。
從削峰的角度來看，這件事就需要去解決。所以我們在請程序為每個項目主要的DCC開發了資源檢查插件 —— 這個插件的目的除了給美術增加約束外，還必須具備讓美術舒服的功能：
a. 美術可以通過插件直接上傳資產到庫裡。
b. 通過插件上傳的資產可以自動關聯工單，美術同學再也不用去網頁上去改任務狀態了。
c. 自動生成符合規範的命名主體，美術同學只用根據規範寫這個東西最後一部分的名字就好。
d. 在上傳前，插件會自動檢查資產規範，如果不符合要求就不讓上傳。
整一個方便美術策劃查找資料的網盤形態的資產管理工具，就更舒適了。
總結：
遊戲開發管線必須建立在一個明確的目標的基礎上，這個目標包括了核心玩法、美術目標、發行策略等。
遊戲開管線的重點在於讓遊戲能夠穩定、高效的生產出來，而並不能解決遊戲是否出彩、是否好玩、是否賺錢的問題。它更多的是保證下限。
很難說有沒有一種範式可以適配所有遊戲的開發。因為運作順暢的管線和這個團隊裡的每個人都有關係。
當年做發行的時候，發現80%的項目都是做不完的。而所謂“做完了”的項目也有80%最終沒能走到上線那一步。我自己也曾在做製作人的時候遭遇項目中道崩殂的情況。
雖然大環境一定是有鍋要背的，但是我們身在其中卻也只能繼續前行。
希望，看到這篇文字的你們和我自己，都可以順利的完成下一個作品、再下一個作品。
麻煩點贊收藏，分享給你覺得需要的人。
歡迎關注我的公眾號”靈思AIgame“ 和 知乎： 做遊戲的羅大萌
麼噠