遊戲技術中臺要想起作用，沒有3年很難

網上一直流傳中臺的概念起源的事，據說是源於芬蘭的一家遊戲公司Supercell。當年馬雲參觀了Supercell之後，受到Supercell大中臺的啟發，回來後就在阿里大搞中臺。

我一直對這件事挺好奇的，所以有一次我特意去問了Supercell的一位朋友，他表示有點扯淡，其實Supercell並沒有所謂的大中臺，有也只是比較小的一些中臺，比如引擎工具類的技術中臺。至於這個訊息是從哪裡傳出來的，我不知道，完全不重要，重要的是中臺確實有它的價值，從而發展到如今各家大中型公司都在搞中臺。

網際網路中臺

那麼先來隨便扯一扯網際網路的中臺。國內的網際網路大公司，這幾年基本已經陸陸續續搭建了中臺，還有很多中小企業，也在追隨網際網路大公司的步伐，開始嘗試中臺化。

中臺的概念的核心比較簡單：公用資源，避免重複造輪子，從而提升工程效率，降低時間經濟成本。但是中臺的邊界卻沒有明確的定義，而且實行起來會有各種問題。當中臺的概念被炒了起來，很多似是而非的東西都在往中臺上面湊，很多不應該屬於中臺的範疇卻被錯誤地劃入了中臺，從而導致最後中臺搭建失敗，所以行業內也出現了一些反對的聲音，說中臺不利於事情的開展，不利於產品的把控，中臺無用論等等。

遊戲行業中臺現狀

遊戲行業的中臺跟網際網路公司有一定的類似，因為遊戲公司的產品基本都帶有聯網屬性，所以有一定的關聯，但是畢竟不是純粹的網際網路公司，所以很多概念其實還是不大一樣。

我從事遊戲研發工作已經差不多12年了，雖然做遊戲行業技術中臺也有好幾年了，也經歷過從0開始搭建一個技術中臺，趟過不少坑，踩過不少雷，但是可能還是有很多理解不到位的地方，所以如果說的不妥，還請大佬們輕拍。

當前的遊戲公司，騰訊，網易，巨人，盛大，遊族，完美，心動等都擁有不小的中臺，中臺的概念涉及到的不僅僅是技術，還有美術，UI/UX, 專案管理， IP文案， 音訊音效等等，有些公司甚至在打造大中臺，小前臺，從而提高前臺部門專案的靈活性，以及中臺部門的健壯性。

除去這些上市大公司，發展中的中小型公司也陸陸續續在打造中臺，比如鷹角，紫龍，疊紙等等。網易，騰訊之類的大公司的中臺目前發展已經相對比較成熟了，但是像其他類公司的中臺基本也是最近2，3年之間興起的，當一箇中臺真正能發揮大作用也需要一定時間的積累。比如技術中臺，如果打造某一個框架，首先框架開發可能需要不少於1年時間，然後經過專案的優化與迭代，可能又是一年多甚至2年時間。

所以當一個技術中臺真正發揮作用，沒有3年是很難做到的，而且技術中臺也需要時間去積累口碑，樹立權威。跟網際網路中臺類似，遊戲行業中臺我也經常聽到很多聲音，指有些遊戲公司的中臺，尤其技術中臺，做的一些事情比較獨立，甚至有點邊緣化，與核心產品核心內容相距比較遠。其實中臺不像前臺業務，不直接創造經濟價值，有些時候確實會受到不少的挑戰。

技術中臺的目的

雖然遊戲公司技術中臺問題很多，為什麼還有這麼多公司要去搭技術中臺？我主要是覺得中臺的目的還是比較美好的，我歸納為3點：

提高人效，技術內容做乘法，避免重複造輪子，從而降低成本。

積累不同專案的經驗，沉澱核心技術，開發流程及工具，提升技術壁壘，縮短研發週期。

預研新技術，提高產品品質上限。

不管是技術中臺自己預研的產品，整理的工作流，沉澱的經驗及問題解決方案，還是打造的工具鏈，都具有通用性，或者可以做少量修改就可以很快在專案中使用的。

雖然通用化過程可能比較難和耗時，但是對於產品研發效率的提升還是有很大的幫助。一個產品可以同時用在多個專案，大家也不用各自都搞類似的研發從而浪費人力與財力。而且由於不同技術人員可能會參與不同的專案研發，因為同屬於技術中臺，便於分享問題與經驗，對於疑難雜症也許可以很快的尋找到一個解決方案。因為你碰到的問題可能其他專案已經解決了。

遊戲技術中臺的構成

技術中臺的拆分有各式各樣的形式，大部分公司都會有有以下一些部門組成：

引擎部門。引擎部門是比較核心的部門，而且最容易中臺化，比如渲染的框架，物理的演算法，動畫的優化，引擎底層的架構，優化的經驗等等，都可以以中臺元件化，經驗化的形式進行。引擎相關的人力從前期參與，到中期的量產，再到中後期的優化與問題解決都需要重度參與。但是到了專案後期，臨近上線或者上線後，引擎部門的工作已經完成的差不多了。基本可以撤回大部分團隊，留少量的人力繼續維護，其他人可以快速進行其他專案的開發，從而達到人力的最優化使用。

技術美術部門。TA部門的情況跟引擎部門差不多，前期負責效能預算的執行，美術方向及效果的嘗試，美術的培訓及一些工作流及工具的制定，到中後期實現特殊的渲染效果，到尾期也可以撤回大部分人力，留少量人力維護和支援。

程式框架部門。程式框架部門用於實現公用的一些元件，工具及相關SDK，比如服務端框架，技能框架，等等。當然這些需求應該大部分都是來自專案，所以技術人員應該參與到專案的研發中，然後再沉澱成通用化的產品，到第二個專案去迭代更新。可以根據遊戲品類的不同，實現分開的多套方案與框架。等框架完善了，成熟了，後面產品的研發就大大減少了研發週期，而且由於框架經過幾個產品的迭代，質量上也會有很好的保證。

工程效率部門。工程效率部是指那些可以提升研發效率，解決研發流程向的問題的部門。比如說CI/CD的搭建與實現，版本控制工具的二次開發工具，甚至一些自動化相關的測試與開發也可以放入該部門，比如自動化測試等。因為這些內容每個專案的需求都大同小異。

AI部門。遊戲行業的AI應用其實很多， 比如：

• 遊戲內容生產：用AI生成模型，生成貼圖，優化動作；
• 自動化測試；
• 遊戲AI：表現出更逼真，更擬人的NPC；
• AI圖形效果提升：AI實時光追, AI抗鋸齒（DLSS)；
• AI遊戲運維與運營: 動態定價，動態遊戲活動推廣等；
  

AI在遊戲行業的應用已經有不少國外的3A遊戲公司和國內的大公司在嘗試和研究。從最近幾年的GDC來看，AI相關的講座逐年增多，一年比一年火熱。但是AI部門還是僅僅存在於大公司或者少量其他公司。也有可能是AI這一塊人才不多，而且網際網路公司的AI相關的職位也許更香。

遊戲安全部門。遊戲安全相關的人才真的是“屈指可數”，僅僅存在於大公司。所以放在中臺用作通用加密，加殼軟體的開發,外掛的防護及開展遊戲安全相關的培訓，增強其他工程師的安全意識等等。

其他部門。

杜絕避門造車，直面與專案組的衝突

作為技術中臺，我一直提倡幾乎所有的需求是需要來自前臺專案，滿足專案需求為出發點做研發，只允許一小部分在目前專案研發的前提下做前沿性的思考與預研，杜絕閉門造車。

其中很重要的一部分工作是要跟專案組有很深度的合作，以滿足專案的需求為前提，來做日常性的工作安排。所以技術中臺的相關人就需要進入專案，與前臺人員一起進行深度的開發合作。合作初時，中臺人員也許是進入了一個完全陌生的環境，困難重重，專案不熟，人不熟，其中的難點更多。以下是我之前碰到的一些問題：

1. 天然不信任感

不管是專案組還是技術中臺部門，由於互相的不瞭解與一些資訊的不對稱，都會覺得對方的團隊很弱（做技術的人有種天然的不服精神）。所以在合作過程中，互相挑戰是難免的，剛開始的幾次溝通，雙方都會小心翼翼，互相質疑。另外對新進入的專案各種不熟悉，技術中臺部門會小心翼翼地展開工作，生怕出了什麼岔子，從而導致進度的推進不是很理想。

2. 績效的不一致性

使用別人的方案和技術永遠是被動的，如果你幫別人實現了方案，那麼可能自然而然地認為這是別人的成果與業績。主程或者技術總監很有可能覺得自己的團隊沒有什麼輸出和成果。所以在合作過程中，推行技術中臺部門的方案存在著種種的阻力，即使方案可行，在執行過程中也存在著種種的隱性的延期與不配合。

3. 資訊溝通的延時性與不全面

有些技術中臺會存在遠端支援，就是部門的人不跟專案組的坐一起，甚至異地支援（我們之前就有國外的技術人員支援上海這邊的專案）。由於遠端支援，有些資訊在溝通的時候，難免對接不到位或者反饋延遲。因為你不能保證在溝通的時候對方會不會被其他事情打斷，或者不知道對方是否能及時跟你溝通。又由於溝通不在同一地方，技術中臺團隊原以為很不錯的方案，往往是專案組上次討論拋棄的方案。

由於對專案本身瞭解的片面性，這種情況會經常出現。比如，我們之前在支援一個專案時討論動畫的優化方案時，我們嘗試過各種方案，比如2D序列幀，動畫烘焙到貼圖上，GPU Instance+Skinning方案等等，由於專案需要拉近鏡頭，記憶體有限和支援opengl es2等原因，這種方案很自然地就被斃掉了。而且這些溝通的問題往往會導致你下一次合作的某個障礙。另外在遠端溝通中，身體語言這一溝通中的重要一環缺失，在溝通的成效上會有不少的影響。

4. 決策的干擾因素過多

在專案組中支援，方案的決策是最難的，除非已經樹立了技術權威，不然動了任何一方的內容都會有不少的反對。比如優化了一個地形，美術覺得，不行，這畫質降得太厲害了。優化了一個動畫，程式覺得不行，這記憶體增得太多了。

當然在不影響其他因素的情況下優化是最理想的，而往往遊戲優化中會有各種權衡：畫質和效能的權衡，記憶體和效能的權衡，研發時間和功能複雜度的權衡等等，魚和熊掌不可兼得，有時候你不得不損壞一方利益去保證整體的效果。所以在方案的取捨過程中會有不少的干擾因素影響實施的推進。

5. 方案落地的困難

在支援的過程中，我們會提出各種方案及測試結果，但是在落地的過程中經常執行不到位。甚至一個測試的方案前前後後多次出現在討論大會上，看似很簡單的一個方案，卻遲遲沒有落地。因為專案組在研發的階段，方案的執行人受其他任務的干擾比較大，由於執行人員會有“那是他們部門主導的任務，優先順序不高”等類似的內心想法，方案的執行就很容易不被重視，從而導致延期甚至中止。

如何緩解衝突

1. 明確目的的重要性，並得到高層的支援

首先要跟工作室老大，專案製作人達成一致，明確我們這個支援工作的重要性。並且得到高層的強力支援。這樣的話對進入專案支援的人的自信，和工作的開展都有很大的幫助。

2. 選擇更好的合作方式

我是比較提倡中臺的人跟前臺專案組坐一起，或者靠近，有利於人員的溝通和融入專案的開發氛圍。減少專案組的人幫你當做“外人”從而導致的各種不利。使中臺的人完全成為專案的一份子，而不是遙不可及的專家。

3. 樹立一個共同的目標與研發週期，利益捆綁

一定要明確共同的目標和研發週期，把前中臺相關人的利益捆綁在一起，這樣大家才會一心朝著共同目標努力。相關人員也更容易理清事情的優先順序。為了大家的共同利益，更為了自己的成績，一起努力。從而也為了防止出了問題而導致的互相甩鍋的情況發生。另外工作的最終效果一定要體現在資料或者具體的內容上，一份報告，一次真機演示等等。比如優化，我們需要拿QA的客戶端效能測試報告去衡量最終的效果。

4. 保持良好的私交

比如一起吃個飯，一起聊聊天，一起抽個煙等一切私底下的交好，都有助於我們在專案組中獲得更好的支援，從而便於工作的開展。

5. 處理好前中臺的利益分配

這一點真的很重要，很多人進入一個專案都是為了更多的獎金或者能夠分到一點成功專案的紅利。如果沒有利益的驅動，對於中臺的人員會少了很多激勵與動力。有些公司的中臺的人可能永遠是一個固定的工資，比如16薪，那麼對於他們努力不努力，在利益的回報上是差不多的，所以專案組的人也許還在加班加點趕進度，他們可能早早的下班回家了。

其他注意的問題

1. 如果是深入專案合作的人員，務必降低姿態，以一種服務的精神參與開發，把自己當作專案的成員。

2. 很多問題是問出來的，而不是前臺主動反饋出來的。

3. 如果技術中臺推行的不好，很容易就成為了一個人力外包的部門，前臺部門發現人手不夠或者進度來不及了，就跟技術中臺要人，技術中臺的人過去也就補充個人力，做著不利於技術中臺的工作內容，然後又由於沒有特殊的技術產出，前臺又會覺得中臺的作用也不過如此。所以該說不的時候就堅決說不，千萬別偏離了自己的核心價值觀與正確方向。

4. 多開展技術分享，調動大家分享技術與學習技術的熱情，有助於在內部形成工程師文化的氛圍，對於吸引人才，穩定人才也能起一個很好的輔助作用。

相關閱讀：遊戲行業應該如何建設資料中臺？


作者：費洪暉，某二次元公司技術中臺負責人
來源：遊戲葡萄
地址：https://mp.weixin.qq.com/s/f3n536xUKiCVLFxtULO0kA