遊戲技術中台要想起作用，沒有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. 多開展技術分享，調動大家分享技術與學習技術的熱情，有助於在內部形成工程師文化的氛圍，對於吸引人才，穩定人才也能起一個很好的輔助作用。