​TGDC | Evolving AAA Game Development

2020年12月8日，由騰訊遊戲學院舉辦的第四屆騰訊遊戲開發者大會（Tencent Game Developers Conference，簡稱TGDC）進入了第二天的議程。來自騰訊互動娛樂光子工作室群的Steve Martin，分享了他多年的遊戲從業經驗，以下是分享視訊和文字實錄：


大家好，我是Steve Martin。今天我想聊聊如何建設3A遊戲的開發能力，以及Lightspeed LA是如何搭建的。

為什麼我們要從零開始搭建一個3A遊戲工作室？先來介紹一下我自己。我從1996年開始為索尼PlayStation主機開發遊戲，在接下來的24年裡，我先後在全球各地的多家工作室任職，曾參與《極品飛車：地下狂飈》、《馬克思·佩恩》、《俠盜獵車手》和《荒野大鏢客：救贖》等系列遊戲的開發。

2019年，在R星（Rockstar Games）工作了14年之後，我渴望新的挑戰和機會。於是我開始和光子接觸。我們希望把光子最好的工作方法和對卓越的追求，與西方最好的經驗、知識和人才結合起來，切入3A遊戲市場。於是就有了我們在加利福尼亞州新開設的，面向全球的3A工作室。

接下來我們討論一些關鍵問題，比如團隊規模和團隊建設。

團隊規模：做3A需要一支超大的團隊嗎？

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

那麼我們一定要打造一個多地協作的超大團隊嗎？我們可以先看看超大團隊的利弊。


超大團隊有如下幾個好處：

1. 擁有大量的開發資源；

2. 能夠在全球範圍內挑選頂尖人才；

3. 擁有7x24小時工作的潛力——比如研發團隊和QA團隊可以放在兩個時區，形成接力式的開發流程；

4. 可以把一些技術要求不高的崗位放在成本比較低的地方，以此降低支出。

但它也有一些弊端：

1. 容易增加人員數量，而不是縮減規模；

2. 人才資源庫雖然龐大，卻無法提升流程的效率——如果公司人員充足，何苦花時間優化系統？

3. 人才稀釋。找到40個3A標準的美術是一回事，但組建一支400人的團隊又是另一回事。除非你用多年來鍛鍊團隊，否則不可能保持相同的人才標準；

4. 更高的管理成本。中層管理人員的數量和團隊人數可並不是一個線性的關係。一個40個人的美術團隊，可能需要8名資深員工，2個組長和1名美術總監；但一個400人的團隊，可能需要80名資深員工，40名協調員，20名組長，8名資深組長，2名總監和1名高階美術總監。前者的比例是4:1，而後者的比例大約是4:1.5。因此，一個40名美術的團隊其實需要51個人，而一個400人的美術團隊則需要大約550人。

5. 繁多的會議——想象一下協調一個150人的團隊要開多少會吧。

6. 個體不再重要。為了維持人情味，團隊要耗費巨大的成本。舉個例子，如果你是團隊的2%（即一個50人的團隊），那你一定對專案很有參與感，很有主人翁精神，你和同事也都彼此認識；但如果你只是團隊的0.18%（即一個500多人的團隊），那你可能最多隻認識15%的同事，對專案可能也沒什麼熱情——這是在我身邊真實發生的故事。

7. 臃腫的細節。龐大團隊的創造力太過剩了，這聽起來有點兒凡爾賽……但由於大家都處在不同的地點和時區，管理層不可能檢測到員工的所有工作，更何況他們還處在不同的地點和時區。

所以你們經常能看到一些出發點很好的小設計，它們有不錯的深度和細節，但從巨集觀角度來看它們又不太必要。而每次發現這種設計的時候，團隊往往已經浪費了大量的資源和金錢。

8. 高額的成本。多個工作地點的開銷，鉅額的工資，IT、HR和支援設施……一支1500人的團隊，做6-7年的費用非常驚人。

所以我們要不要建設一支超大的團隊？我認為答案是否定的。因為建立一支超大的團隊並不會增加成功的概率。遊戲開發的成功取決於創造力、控制力和執行力。在短期之內建設一個超大的團隊，我們很難構建起一套擁有這些特質的系統，這個風險太大了。

那如果沒有超大的團隊，我們該怎麼做事？

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

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

我們也會控制開發內容的規模——別被那些沙盒遊戲牽著鼻子走。人們真的想要一款能玩上200個小時，擁有成千上萬可收集要素的遊戲嗎？我猜不是。那就不要為了追求過多的內容而折騰你的團隊。

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

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

那該怎麼設計團隊架構，才能實現效率和創造力的最大化？關鍵在於「管理」和「製作」的平衡。

管理人員太少，你就有面臨溝通問題的風險，或者只能讓創意人才去做瑣碎的管理工作，跟進專案進度；而如果管理人員太多，每個部門都會依賴自己人來負責溝通，那不同的部門之間就容易彼此分裂。

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


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

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

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


很明顯，現在我們製作人的數量增加了2倍，還增加了同等數量的助理製作人，整個團隊傳遞資訊的能力大大增強了。

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

舉一個簡化的例子：助理製作人告訴大家，我們要做一個有三條胳膊的反派角色，而角色美術說，我們的骨骼系統無法處理多餘的肢體，需要重新設計角色，或者更改骨骼系統的程式碼。

於是角色美術告訴總監，總監告訴助理製作人，助理製作人告訴製作人，製作人做決定再下達命令……等到資訊沿著鏈條傳遞給所有相關人員，AI和動畫已經在錯誤的方向上耽誤太久了。

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


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

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

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

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

1. 可以組建一支跨部門的敏捷開發小組，在演示新的玩法特性Demo，或者新內容的第一部分時它特別有用。

2. 除了工作流程，開發環境也是影響開發效率的關鍵。為了節省一時的成本犧牲開發裝置的配置或是降低網速，一定會導致巨大的效率損失；同理，犧牲版本搭建、編譯和載入的時間也會導致類似的後果。

3. 我們還應該挑戰組織架構。例如在功能測試和版本測試的時候，QA確實很重要；但如果要進行大規模的功能測試或者TRC測試，再等待QA團隊的反饋就沒那麼合適了。那我們是不是還有保留一支龐大的QA團隊？搭建一支獨立的團隊，讓QA助理與開發人員一起工作，單獨測試會不會更好？

一些專案管理技巧：

在遊戲開發中，不可能存在完美的計劃。執行得最好的專案也會延誤。但在擁抱變化的同時，我們也可以採用一些簡單的辦法來優化專案管理。


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

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

還有一點非常重要：收集實時資料。

有的團隊想延長後續同類內容的開發時間，結果相關領導說：「這次花的時間是很長，但我們也有很多收穫，下次的時間肯定可以更短。」這種錯誤觀念非常常見，因為他們拿到的是錯誤的資料。

這個時候，團隊有三種解決問題的思路：

思路一，保留之前的計劃排期，但會根據之後三次類似工作內容的資料，重新調整平均值；

思路二，立即調整計劃排期，並根據之後新的資料調整平均值；

思路三，在評估任務和實際工作的過程中，根據更多資料調整平均值。


思路二的效果似乎更好，因為如果按照原始計劃排期計算平均值，資料的增量肯定有限。但這個思路也並不萬能，大家還是要根據資料，和專家進行討論，再決定最合適的方法。

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

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

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

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

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

但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內容。


這種方法可以避免一種尷尬的局面：遊戲一個區域的內容過於飽和，但其他區域卻比較荒涼，這樣玩家就會覺得，開局的體驗為什麼比結尾豐富了那麼多。

關於細節迭代：

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

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


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

那麼問題來了，如何安排這個過程？這就是敏捷開發的領域了：可以組建一支突擊小隊，劃分專案和計劃的結構，瞭解團隊身處何方，要前往何處，何時才能到達那裡，誰是關鍵人員，他們工作的最佳環境是什麼，迭代的潛在阻礙和瓶頸又是什麼。

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

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

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

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

來源：騰訊遊戲學院
原文：https://mp.weixin.qq.com/s/oFl297-OkOYyRV4Qxnz8bA