R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

在過去的2020年,3A遊戲的「翻車」事故似乎越來越多。而伴隨著翻車事故一起被爆出來的,往往還有很多工作室內部的管理問題:無休止的加班、永遠緊迫的開發進度、人人自危的工作環境……龐大而臃腫的開發團隊,外加看不到頭的需求清單,似乎已經成了所有3A遊戲頭頂上的達摩克里斯之劍,壓得所有人喘不過氣來。

除了技術、市場和眼界上的差距之外,項目管理能力也是我們邁向3A遊戲的路上必須要跨過的坎。如何去構建一個充滿戰鬥力的3A遊戲團隊,如何把控遊戲的各個環節不會失控,如何減少返工提升效率,不讓項目多次延期,在這個3A越來越容易暴雷的現在,將變得更有現實意義。

在去年的TGDC(騰訊遊戲開發者大會)上,3A遊戲行業的老兵,現任騰訊Lightspeed LA工作室總經理的Steve Martin,就從自己的經歷出發,談了談他認知中的3A遊戲開發管理經驗。希望大家能在遊玩3A之餘,也能看見從業者對於「如何把它們做出來」這個環節上的一些思考。

R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

以下是分享實錄:

大家好,我是Steve Martin。我從1996年開始為索尼PlayStation主機開發遊戲。在接下來的24年里,我先後在全球各地的多家工作室任職,曾參與《極速快感:地下狂飈》、《馬克思·佩恩》、《俠盜獵車手》和《碧血狂殺:救贖》等系列遊戲的開發。在R星工作了14年之後,我渴望新的挑戰和機會,於是與光子接觸,最終開設了位於加利福尼亞的全新3A工作室。

R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

接下來,我將結合我的經驗,談一談3A遊戲開發中的團隊規模和團隊建設等問題。

團隊規模:做3A真的需要一支超大的團隊嗎?

這是一個超大規模全球團隊(global meta team)的時代。我們可以構建跨越時區、國家甚至大洲的研發體系。而且在新冠疫情期間,大家也都在嘗試居家辦公、遠程辦公。

但是,我們一定要打造一個多地協作的超大團隊嗎?我們可以先看看超大團隊的利弊。

R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

好處:

  • 擁有大量的開發資源;
  • 能夠在全球范圍內挑選頂尖人才;
  • 擁有7×24小時工作的潛力——比如研發團隊和QA團隊可以放在兩個時區,形成接力式的開發流程;
  • 可以把一些技術要求不高的崗位放在成本比較低的地方,以此降低支出。
  • R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    但它也有一些弊端:

  • 容易增加人員數量,而不是縮減規模;
  • 人才資源庫雖然龐大,卻無法提升流程的效率——如果公司人員有富餘,那就交給多餘的人去做事就好了,幹嘛還費勁去優化流程和系統呢?
  • 人才稀釋——找到40個3A標準的美術是一回事,但組建一支400人的團隊又是另一回事。除非你有一個很多年的團隊,否則不可能在團隊規模這麼大的前提下,還能保證相同的人才標準;
  • 更高的管理成本。中層管理人員的數量和團隊人數可不是一個線性的關系,一個40個人的美術團隊,可能需要8名資深員工,2個組長和1名美術總監;但一個400人的團隊,就可能需要80名資深員工,40名協調員,20名組長,8名資深組長,2名總監和1名高級美術總監。前者的比例是4:1,而後者的比例大約是4:1.5。因此,一個40名美術的團隊其實需要51個人,而一個400人的美術團隊則需要大約550人——是不是很夸張?
  • 繁多的會議——一個不到50人的團隊,可能都會被繁多的會議弄得苦不堪言,那想像一下協調一個150人的團隊吧?
  • R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

  • 個體可能會變得不再重要。舉個例子,如果你是團隊的2%(即一個50人的團隊),那你一定對項目很有參與感,很有主人翁精神,你和同事也都彼此認識;但如果你只是團隊的0.18%(即一個500多人的團隊),那你可能最多隻認識15%的同事,對項目可能也沒什麼熱情——這對於遊戲開發可不是什麼好事,而且就在我身邊真實發生過。
  • 臃腫的細節。龐大團隊的創造力太過剩了——這聽起來有點兒「凡爾賽」,但由於團隊規模過大,管理層不可能熟知每個員工的工作,更何況他們還處在不同的地點和時區。所以你們經常能看到一些出發點很好的小設計,它們有不錯的深度和細節,但從宏觀角度來看它們又不太必要。而每次發現這種設計的時候,團隊往往已經浪費了大量的時間和金錢。
  • 當然還有最重要的,高昂的成本。多個工作地點的開銷,巨額的工資,IT、HR和支持設施……它們的費用會非常驚人。
  • R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    所以回到前面那個問題:做3A是不是就一定要組建一支超大的團隊呢?我想答案是否定的,因為建立一支超大的團隊並不一定會增加成功的機率。遊戲開發的成功取決於創造力、控制力和執行力。特別是對於像我們一樣的新工作室,在短期內建設一個超大團隊,是很難構建出這些特質的。

    那如果沒有超大的團隊,我們該怎麼去做?

    在早期階段,我們只會在確實有需求的崗位增加人員,而不會分配不必要的人力——如果我有100名美術,那我就會確保他們人人都有活兒干。

    同時,我們還會不斷地挑戰現有的假設,不斷根據KPI和數據重新評估和制定計劃:明年我們是需要更多,還是更少的人?

    我們也會控制開發內容的規模——別被那些沙盒遊戲牽著鼻子走,人們真的想要一款能玩上好幾百個小時,擁有數不清的可收集要素的遊戲嗎?我想答案是否定的。那麼,就不要為了追求過多的內容而折騰你的團隊了。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    總而言之,不管是什麼類型的遊戲,只要你事先稍微多做一些分析,你就能更合理地利用資源,這會讓你對團隊規模有新的理解。

    團隊架構:如何保證「管理」與「製作」的平衡?

    那該怎麼設計團隊架構,才能實現效率和創造力的最大化?

    管理人員太少,你就有可能會面臨溝通困難的問題,或者只能讓創意人才去做瑣碎的管理工作,拖慢項目進度;而如果管理人員太多,又會顯得冗雜,不同部門之間也容易彼此隔閡分裂。

    舉個例子,這是一個最典型的3A遊戲團隊組織結構,我給不同的團隊加上了顏色,方便辨認。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    這種模式在8-10年前非常普遍,而且至今仍然存在於某些工作室當中:總製作人會先和各個製作人溝通,製作人們再與各個分支的總監溝通,讓他們把信息帶回各自的團隊。這是一個標準的瀑布型溝通體系。

    但層級結構越深,信息傳達的難度就越大。而且當信息需要更正的時候,大家還會沿著錯誤的方向繼續工作一段時間,直到收到新的信息為止。同時,這個信息向上反饋的效率也非常低下。

    那讓我們擦掉這個模型,重新建立一個更重視製作的管理架構:團隊希望通過添加部門人員以增加溝通渠道。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    現在,我們製作人的數量增加了2倍,還增加了同等數量的助理製作人,整個團隊傳遞信息的能力大大增強了。

    不過現在總製作人要和一個龐大的製作人團隊進行溝通,每個製作人還要用助理製作人和分支團隊進行溝通,越來越多的人為了同步信息而開各種小型會議,大家的信息反而非常分散。

    舉一個簡單的例子:助理製作人告訴大家,我們要做一個有三條胳膊的反派,而角色美術說,我們的骨骼系統根本做不來這樣的角色,必須打回去重新設計,或者更改骨骼系統的代碼。於是角色美術告訴總監,總監告訴助理製作人,助理製作人告訴製作人,製作人做決定再下達命令……等到信息沿著鏈條傳遞給所有相關人員,AI和動畫已經在錯誤的方向上耽誤太久了!

    讓我們再次把螢幕清空,看看我的建議。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    在這張圖的頂部,總製作人、製作人和總監們組成了一個創意委員會。而在圖片底部,我們也有一支助理團隊。

    在日常工作中,創意委員會先彼此溝通,由總監將信息傳遞給各個團隊。同時他們也會直接和自己的助理溝通,而這些助理們也會直接彼此溝通,並和各個團隊溝通。這樣我們就有了既能自上而下,又能自下而上,還能同級之間彼此溝通的組織架構。

    仍舊舉那個三條胳膊反派的例子。在總監們一起討論的時候,程序或者美術總監就能發現骨骼方面的問題;就算他們都沒發現,那角色美術發現問題之後,也會直接通知給美術助理。而美術助理既能通知美術總監,也能通知程序和動畫的助理。這就可以大量節省消耗在錯誤方向上的成本。

    另外關於團隊搭建還有一些小細節:

  • 可以組建一支跨部門的敏捷開發小組,在演示新的玩法特性Demo,或者新內容的第一部分時它特別有用。
  • 除了工作流程,開發環境也是影響開發效率的關鍵。為了節省一時的成本犧牲開發設備的配置或是降低網速,一定會導致巨大的效率損失——所以,千萬別在這種地方省錢;
  • 我們還應該挑戰組織架構。例如在功能測試和版本測試的時候,QA確實很重要;但如果要進行大規模的功能測試或者TRC測試,再等待QA團隊的反饋就沒那麼合適了。那我們是否還需要保留一支龐大的QA團隊?搭建一支獨立的團隊,讓QA助理與開發人員一起工作,單獨測試會不會更好?
  • 一些項目管理技巧,助你減少延期

    就和做很多其他事一樣,在遊戲開發中,也不可能存在完美的計劃,哪怕是執行得最好的項目也會延誤。但在擁抱變化的同時,我們也可以採用一些簡單的辦法來優化項目管理。

    如果一件任務需要超過一周才能完成,那就把它分解成子任務;我們還可以跟蹤任務推進的過程,以後再開發重復的內容,我們就可以給出更准確的估算。以建築或者建築內部的結構為例,我們可以估算每平方米的平均工期,建築做得越多,估算這個指標的方程式也就越完善。

    那如果是不相似的任務,比如寫一個新功能的代碼呢?我們可以先估算技術特性的風險,以及它在無法實現的情況下會對項目造成多大的影響。如果風險和影響都很大,那我們就要避免這類任務,或者嚴格控制它的數量。如果它對遊戲真的特別重要,那我們就要盡早開始這項任務。

    想讓進程安排得更加合理,我們還要面對需求漂移的挑戰。它會延長工期,增加成本,甚至需要削減內容才能趕上Deadline。

    很多製作人都說,想在Deadline之前完成項目,避免需求漂移非常關鍵。A級或者2A項目確實如此,但3A項目卻並不一定。某些情況下,不斷發展的創意確實能夠提升遊戲的體驗。

    如果想追求真正的3A品質,那很多事情都會挑戰我們既定的時間表。因此,我們還有一些方法能降低額外的成本。

    1. 讓內容計劃更具彈性。

    假設我們在做一款3A射擊遊戲,它的一大特色是多層高級協同AI,這個AI夥伴可以跟隨玩家戰鬥,跨越平台,甚至進行緊張的隱身潛行。而我們希望設計幾個任務來凸顯這項驚人的技術。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    但AI團隊卻很焦慮,他們還沒想好該怎麼讓AI夥伴擁有靠譜的隱身意識,這就讓遊戲研發的排期有太多的未知數。

    在這種情況下,很多人可能覺得給AI團隊留出足夠多的時間不就好了。但有些關鍵內容又非常依賴於AI技術的進展,可能給出足夠多的時間也不能完全保證功能的齊全。那我們就可以通過彈性的工作內容計劃來降低風險。

    比如還是AI夥伴的例子,我們可以調整任務對AI代碼的需求,比如讓故事解釋一下,為什麼做一些潛行任務的時候AI夥伴不在身邊。這樣我們可以提前准備很多解決方案,而非為了解決問題,一次又一次地延長開發時間。

    2. 劃分A、B、C內容。

    假設我們在做一款開放世界MMORPG,設計師需要讓可收集物品、任務和NPC散布在地圖的每個角落。在這種情況下,我們可以先劃分A、B和C三種量級的內容:A是最小值,C是最大值,B是性價比最高的中間值——它既能保證內容足夠豐富,又能兼顧開發成本。

    比如設計團隊的結論是,對於這款遊戲的可收集物品數量來說,最小值是150,最大值是500,而最合適的值是375。所以我們會把150項內容標記為A內容,另外225項標記為B內容,最後125項是C內容。在研發過程中,大家要首先完成A內容,之後再完成B內容,還有餘力的話再做C內容。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    這種方法可以避免一種非常常見的尷尬情況:遊戲開頭部分的內容過於飽和,而後續其他的區域卻比較荒涼。

    關於細節疊代

    你可能會發現,以上這些方法的共性在於,我總是先強調內容的質量和多樣性,並盡可能地保留之前的邏輯,最後只會在數量上做出犧牲。因為3A遊戲的設計和控制必須流暢,玩家必須覺得自己能精確控制螢幕上的一切細節——說實話,這是開發過程中最耗時,成本最高,也最難完善的因素。

    那該怎麼去處理這些細節呢?答案很簡單:疊代。我們要一遍又一遍地疊代所有的設計要素組合,直到它們的反饋、精細程度、視覺、聽覺和觸覺都能完美地結合起來。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    玩家和角色的聯系就來自於這些細節。在角色開始移動之前,玩家需要將搖杆推多遠,多長時間,又要多久才能變成慢跑?更改方向需要多長時間才能執行?瞄準和移動之間的界限是什麼?釋放搖杆多久之後,角色才會減速停下來?僅僅在平坦的地面上行走,就有這麼多微妙的細節。你的開發列表很快就會長得令人發指,這個疊代的過程需要無限的耐心,任務也非常容易延期。

    那該怎麼去安排這個過程呢?這就是敏捷開發的領域了:可以組建一支突擊小隊,劃分項目和計劃的結構,了解團隊身處何方,要前往何處,何時才能到達那里,誰是關鍵人員,他們工作的最佳環境是什麼,疊代的潛在阻礙和瓶頸又是什麼。

    舉個例子,對於角色控制型的遊戲,瓶頸往往會出現在動作捕捉上。我們之前往往只能靠推測來制定動作和動畫的錄制計劃,有些計劃看起來不錯,但到螢幕上就不對了。等到重新完善計劃,預約攝錄影棚重新拍攝,往往又要花費幾周甚至幾個月的時間。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    所以我們在加利福尼亞的工作室正在安裝小型的模擬動捕設備,它不會用來捕捉大型的敘事動作或特技,但可以用於角色動畫的疊代。突擊小隊可以在工作室內用它進行大量的動捕測試,廢掉不好用的想法,然後再去錄影棚拍攝。這樣我們就能向演員精確地列舉所需的動作,列出變化可能性的清單,並知道哪些動畫適合動捕。

    除了動捕,這種集成疊代的思路可以應用到每一個工種當中,它為團隊提供了一個允許失敗的安全區域。想讓團隊做出高質量的產品,你就必須降低他們的試錯成本。只有被鼓勵突破邊界,嘗試各種瘋狂的想法,創意團隊才算真正進入了3A遊戲的境界。

    希望今天的分享能讓你們覺得有趣和有用,謝謝大家。

    R星老兵開發者Steve Martin聊如何減少3A遊戲項目的翻車機率

    來源:機核