>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

游戲數據：
發行商：Microsoft Game Studios
全職核心團隊：40人
全盛時期團隊大小(包括測試、授權、本地化以及其他支持資源)：102人
發布日期：2003年11月
平臺：Xbox
開發硬件環境: Pentium 600 MHz-2.4GHz、256-1024MB RAM、GeForce 2-4 Series、ATI Radeon 9700 Pro顯卡
開發軟件環境：Microsoft Visual Studio.NET、Microsoft SourceSafe、Alienbrain、built-in 3D Editor、Softimag XSI、Araxis Merge
2001、SoundForge
項目大小：37,174個文件，219,538行代碼，41GB數據
開發經驗
    Gotham Racing 2 是Xbox上銷售業績最好的賽車游戲的續集, 由Bizarre Creation(利物浦，英國)開發，Microsoft Game Studios提供了制作和發行方面的幫助。在2002年2月份完成了PGR的國際版本后，我們的兩只團隊直接啟動了續集的開發。我們極大地擴展了合并后團隊的規模和質量，招募了新的美工，程序員和測試員。這個項目的最終目的是在2003年假期推出一款基于PGR基本要素的AAA級游戲，并且在游戲中創新性地應用Xbox的在線游戲系統Xbox Live。最終游戲及時上市，并且在超過70個專業評論中得到了綜合92.4%的高分(參考自www.gameranking.com)，我們感覺到我們達到了我們的目標。
 

    我們把成功歸功于我們員工的努力和對挑戰的了解。聰明、高效、努力工作的員工是達到既定目標的關鍵。坦率的說, 我們的兩支團隊都具備那些素質。雖然在戰術方向我們存在一些爭執，在最后階段也做了一些改變，但團隊中的每個成員對項目的戰略方向十分明確并且為之努力。我們最后成功的一個關鍵因素就是開發商與發行商之間穩固的關系： Bizarre在設計、技術和美工的能力能夠很好地與微軟在測試、授權、可用性、創意寫作和制作管理方面的能力匹配起來。沒有相互之間的高度信任，我們將不可能去發揮每個團隊的最大潛力，而PGR2也不會如
此成功。

    我們的希望是：本制作案例能夠提供一些對我們如何一起工作開發PGR2的認識，比如我們做的比較成功的地方，還有我們做的不太成功的地方，如果我們有機會再做一遍這個游戲，我們將會有哪些改進。我們希望其他團隊能夠從這些經驗教訓中受益，從而改善他們的流程并且避免重犯我們的錯誤。

成功經驗：
1、很早就確定的強烈的創新意圖
    為了在PGR前作的市場成功之上更進一步，我們深知要保持并發揚前作的成功要素。我們已決定將汽車的種類從25種拓展至100種，并把城市的數量從最初的4個增加到11個。我們的藝術家投入了大量的時間去研究各個城市中的路線——那些有趣、容易辨識、并且有駕駛樂趣的路線。我們在增加汽車數量的同時，也增加了不同種類的汽車，比如老式汽車、強健型跑車、超級跑車、甚至SUV。設計者們同時增強了Kudos獎勵系統，增加了對良好駕駛技巧的獎勵，比如轉彎時轉得干凈利索，干凈的甩尾, 保持在跑道內部不壓線（不撞墻）等。

    不過作為一個新的PGR游戲，我們知道我們更應該體現一種創新精神。雖然Xbox Live在我們最初設計游戲的時候還是一項不為人所知的技術，我們仍努力推動PGR 2的聯網模式。我們預測游戲玩家會十分喜歡在網上和他們的朋友競爭賽車，因此決定為游戲中的每一次賽車提供Xbox Live排分榜。這些互動的高分排名讓每個擁有Xbox Live帳號的玩家能夠貼出游戲的結果，排名前十的玩家可以貼出他們游戲時的重放以供其他人下載并觀看（或者作為對手進行游戲）。

    每項決定都會帶來一些艱巨挑戰。為了創建新的汽車和城市，我們需要將原畫設計隊伍擴大一倍，但同時增加了團隊管理和交流的困難。

依靠外部團隊還未完成的技術也使開發進程遭遇瓶頸，因為我們不得不等待其他團隊完成他們的產品。然而，為了拓展整個游戲所包含的內容，我們選擇接受這些挑戰并不斷努力。

2、精簡全球管理
    Bizarre Creations團隊包括我們所有的核心開發人員、美工、游戲和音效設計師，以及產品人員。位于華盛頓州雷德蒙市的微軟團隊，包括許多產品和設計支持人員、授權經理、 一支完整的測試隊伍、以及市場推廣團隊。由于游戲要在全球范圍內發布，我們在日本、 韓國、臺灣和愛爾蘭全職工作的本地化人員。我們同樣在澳大利亞和英國雇傭了3D臨時美工，在法國雇傭了臨時翻譯工。  

    在制作期間，團隊成員訪問了世界各地來收集研究參考材料和記錄資料。我們在每個城市拍攝了上千張照片和上百小時的視頻。我們在莫斯科和東京錄下了真實的DJ。我們甚至去希望之地（Promised Land）作了個特別旅行，參觀了位于意大利Maranello市的法拉利工廠，拍下照片并錄下法拉利恩佐（Enzo）的引擎聲音（在法拉利恩佐向公眾開放之前）。借用一句古老的英國諺語: PGR2團隊上的太陽永不落。
 

    管理這樣一支全球性團隊，在溝通和進度管理方面導致了很多問題。 我們解決這些問題的措施實際是減少而不是增加管理。我們在所有的團隊成員中構建了強大的溝通渠道，去除了可能出現在游戲制作人級別的溝通瓶頸。微軟制作支持部門的全體職員被授權可以相互之間以及與Bizarre團隊的其他成員直接交流。雷德蒙的測試人員和利物浦的開發人員通過bug數據庫、e-mail和電話進行直接交流。利物浦美工組和雷德蒙的授權經理緊密合作，接受汽車制造商和其他外部授權者的批準和改變需求。我們國際本地化（international localization）團隊的所有
成員都直接與我們UI開發人員進行交流。

    正如大多數團隊那樣，在貫穿產品開發的整個過程中，我們為每個里程碑做出計劃目標和需要交付的工作成果（deliverables）。不過，讓我們有能力迅速解決問題并且能夠趕在假期前發售的，是我們在合適的位置上有合適的人，以及我們全團隊范圍的開放的溝通渠道。

3、盡早驗證在線游戲模式的穩定性
    對于任何游戲來說，在線多人功能經常是風險最高的區域，因為多人功能可能是最難實現的，并且需要重要的優化和調整。我們及早處理了這個問題。我們實現了大部分網絡代碼，針對汽車速度和軌跡的插值計算的物理優化，所有的Xbox Live功能后。這一切都是在2003年的四月，即距發布時間還有5個月的時候就完成了。這樣，我們整個的多人網絡游戲功能的實現是相對順利的，到最后的代碼優化階段只有一些性能和聲音方面的小問題需要解決。

    通過雇傭一個優秀的網絡程序員，讓他和Xbox Live團隊親密的合作去完全理解Xbox Live的新技術，并且協調我們的實現和測試過程，我們獲得了很好的效果。根據Xbox認證團隊的需求實現游戲中Xbox Live的主要功能集，需要立即教育我們的團隊。該項投資事半功倍，使得我們在Xbox Live 2.0的一些功能，如stats with attachment（支持ghost回放的上傳），沒有按時完成的情況下，能夠快速實現新的API來彌補。

    我們很早開始測試，找出了一些延遲和插值問題，這使得我們可以給新的Xbox Live功能糾錯，諸如friends、聲音和記分板等。這樣做，使得開發團隊能夠更早的提高新功能的穩定性。

    由于在早期就驗證了多人游戲的穩定性，因此我們能夠消除產品計劃的主要風險，并在項目的最后階段，把我們的精力放在其他諸如游戲性、性能微調和改善上。

4、將用戶反饋在產品設計中反映出來
    在巨大的時間壓力下設計一個游戲，通常會導致界面設計和游戲平衡性方面的近視。由于團隊在整個開發過程中距離游戲是如此近，對游戲內在的問題和可用性做出客觀評估變得非常困難，如果不是不可能的話。進度需求限制了有效的迭進修改時間（iteration time），開發團隊的成員也不能代表所有最終用戶所擁有的不同技巧。“一個用戶只會成為‘新用戶’一次”的理論，認為你的每個玩家將會樂于挑戰陌生的游戲界面和難度級別不均衡的關卡，并會很喜歡游戲的整體設想。

    雖然我們在處理PGR2這些挑戰上取得了成功，這部分歸因于在發布前的最后幾個月時間里，我們還是投入了巨大的人力和迭進修改時間。

我們實實在在地花費了幾百個小時手動微調每輛汽車，來平衡操作的易用性（ease of use）和駕駛的真實性。我們頻繁地使用Microsoft的可用性實驗室（usability lab）來得到賽車玩家的反饋，并觀察了解玩家在玩我們的游戲時的最初體驗，在界面瀏覽方面所遇到的問題，是否理解排名系統以及是否能完成每種競賽模式的小目標。

    除了查找和修改所有的功能和內容方面的bugs以外，我們在最后階段的最大部分精力放在了平衡我們游戲性的難度上。幾乎來自利物浦和雷德蒙兩只團隊中的每個人（還有許多不在PGR2團隊的其他人），都花費了時間提供了有關特別賽事和五個難度級別等方面的游戲平衡性反饋。

    考慮到游戲的大小，玩家的眾多，和我們所担心的在積分板和Xbox Live的排分榜上暴露得分中的“黃金路徑”（通過走捷徑得到高分的快捷方式）, 我們為我們在微調期間通過高強度協作所取得的結果而感到高興。

5、有效的授權管理
    追求現實世界真實性是PGR系列的一個核心優勢：真實的車、真實的城市、帶有真實DJ的真實廣播站、來自真實樂隊的真實音樂。和電影制作者不一樣，游戲制作者需要得到每個商標和物品的擁有者的合同批準，才能在游戲中使用它們的影像。

    11個城市（包括一個真實的賽道），超過100輛車，33個廣播站每個都有自己唯一的DJ，超過300首歌，這個工作量是難以想象的。 我們雇傭了由5個授權經理組成的團隊，在整個項目過程中全權負責這項任務，包括建立和維護與所有相關合作方的關系，幫助審核所有游戲中的資產，并且和律師一起合作來簽署下每個合同。

    授權團隊的貢獻是至關重要的。他們不僅僅使得我們的美工可以真實的再現每個城市，而且還獲得了相關的授權。沒有他們的話，我們將不能在PGR2中表現諸如法拉利、保時捷和寶馬等真實的車輛。
 

慘痛教訓

1、在全球范圍同步協調工作成果

    如前所述，管理協調我們在全世界各地的團隊的工作成果是一個很大的挑戰。我們覺得這個過程總體來說運行良好。但是，如果任何巨大的挑戰一樣，制作過程的核心部分總會有一些主要的問題突出出來。

    我們原來計劃通過分配工作給各團隊來利用我們的全球資源，對全球汽車名錄上的各種車的基本數據進行收錄、處理和實現。但最后這么做發現得不償失。因為車的記錄規格沒有統一，而且很多的車的數據很晚才拿到，我們不得不犧牲了游戲中每輛車的實現和調整的時間。

另外，音效設計小組的一個重要的成員在搬到加利福尼亞后，還試圖兼職工作，這更加搞亂了已經很薄弱的工作流程。相關問題也發生在DJ腳本方面。我們在各個城市錄制DJ，但冗長的合同和錄音計劃影響了我們的工作。

    這個失敗給我們上了兩課。首先，我們將來需要更好的協調內容創建（content creation）和執行。第二，所有和微軟合作的游戲開發團隊都要面臨的一個挑戰是：協調開發團隊和測試團隊。

    雖然所有Bizarre的程序員、美工和設計師，和微軟雷德蒙德的測試人員、授權經理和國際本地化團隊，都是使用一個bug數據庫實時工作，我們還是遇到了一些問題。在4GB的傳輸速度下，傳輸builds的時間是漫長的，我們不得不在發布之前三個月改變文件傳輸工具。在雷德蒙發現的一些明顯的錯誤很難在利物浦重現，因為測試的build版本落后于開發之后至少一整天的時間。

兩個團隊之間5,000英里的距離更增加了在項目最終階段任何文件更改所帶來的風險。

    雖然我們在更好的協調開發和測試方面邁進了很大一步，但我們將：（1）在功能性和內容的最終期限前更有效地完成任務（2）增強build流程的穩定性（3）在build發送到雷德蒙測試組之前，在利物浦的測試做得更周密些。

2、設計花費的時間太長了

    在我們整個項目的執行過程中，不完整的設計對各項工作的按時完成產生極為消極影響。雖然我們都理解和同意對于PGR系列游戲的總體設想，我們很晚才開始編寫PGR2設計文檔，而且我們在功能凍結（feature freeze）和E3展之后，因為新的想法出現成形，仍然在更新這個文檔。最后導致我們幾次大規模調整設計要素，象用戶界面、Kudos獎勵評價、甚至整個游戲的結構。

    很多重要的原因導致我們的設計階段被延長。我們的設計工作在早期攤得太開太淺，在具體計劃實施之前我們妄圖追求太多不同的路徑和游戲模式。在2003年初，Martyn Chudley，PGR系列游戲之父和Bizarre Creations公司的領導，不得不進場干預，為精簡游戲設計的規模起到非常重要的作用。

    反復調整修改每一個車輛的駕駛特性是一個超乎尋常的挑戰，而且在項目計劃時間表（schedule）中很晚才完成。對任何一款仿真賽車游戲來說，每一個車輛駕駛特性的任何改變都在可用性、AI的性能、每輛車的等級和競爭分類、和設定每次競賽的難度級別等方面都有重大影響。   

    從PGR到PGR2車輛的數量翻了四倍，而我們調整的時間絕對比前作超過四倍。因為更多的車型和內容，需要我們更加努力，進行測試，和在個體車型和類型之間調整。我們低估了這項工作的難度。

    為了解決這些問題，我們擴充了測試團隊的規模，從另外的項目調入了額外的設計師，而且雇傭了一支小團隊來專門負責游戲配平的任務。在將來的項目中，我們將采用其它的解決方案，比如在早期就充實設計文檔的關鍵部分，離線編譯新的游戲性原型，提前安排游戲平衡工作。迭進修改是一個游戲開發的自然組成部分，而且我們對于結果是基本滿意的，但是達到最好的效果卻不是一件容易的事情。

3、依賴外部團隊的新技術

    PGR2的設計是要求在游戲里的方方面面都具有完整的在線特性。這些特性需要的API函數仍然由Xbox Live小組開發中，這影響了我們項目的進展，使我們的開發遇到許多嚴重的障礙和時間上的約束。

    我們的計分牌是曾在2002年的Xbox Live初心會上展示的MotoGP演示版中所用系統的擴展。比之其它游戲，我們前所未有地應用和擴展了這套系統。加上新的Xbox Live功能，比如帶附件的統計（如ghost），和我們預期的大量在線用戶，我們知道我們做了一個很大的賭博，要把這些剛剛問世的技術變得穩定而且可用。如果任何一塊有問題，系統就會崩潰。作為這個領域的先行者，為上傳下載幽靈所編制的附件API（attachment API）帶給了我們很多無法預知的問題。Xbox ATG團隊給予了我們極大的支持，但是他們也很艱難，需要在期限內完成自己的任

務。

    舉例來說，我們應該避免的一個問題就是優化我們和在線記分牌的互動。根據在項目后期對Xbox Live的研究，他們發現我們的代碼對他們的記分牌服務器訪問過于頻繁，整個容量的問題在正式版發售后服務器將無法應付。雖然我們修復了這個問題，但還是對這個重大的制作問題感到后怕。

    依賴外部團隊的關鍵技術，我們深刻體會到要在計劃中給不可預料的問題分配足夠的緩沖時間（buffer）的重要性，要讓所有的部門之間保持交流的暢通，以及對技術要有深層次的理解。

4、ghost回放系統的穩定性

    為了支持全世界各地的Xbox Live用戶能夠上傳ghost 回放文件，我們必須能夠保證每個ghost是實際賽車結果的一份真實復制品。本功能的重要性使得我們從測試組那里得到了足夠的重視。

    回放子系統作為記錄ghost數據的底層框架使用。該遺留系統的長期調試是復雜和艱難的。距離驗證發布（RTC, release to certification）前兩天的一個深夜，我們的測試人員正沉浸于火熱的競賽中，在幾個小時的arcade cone競賽中挑戰各自的高分ghost。

    當時某項記錄變得很難被打破，某位測試人員注意到在ghost回放中出現的整個Kudos分數并不匹配積分榜上的值。盡管連續幾個月的不間斷測試，但該游戲在裝貨前僅僅幾個小時，仍然在回放系統上出現了非常嚴重的一個bug。

    競賽游戲模式在最后階段是測試過程中非常有價值的部分，因為這也是玩家將會如何玩我們的游戲！雖然我們修正了這個bug，但是我們本應該更早一點發現這個bug。在將來, 我們將為重要的領域進行自動測試，包括編寫特殊測試腳本的hooks、邊界和壓力條件。我們永遠也不能很完美的模擬出上百萬玩家的游戲體驗，但通過區分我們關注的事物的優先次序，擴展我們的自動操作套件，并且在最后階段擴大主要內部團隊“清掃bug”努力的規模和范圍，我們將能在發布前更好的尋找和修正所有的重量級bug。

5、構建流程和源碼控制

    在Bizarre Creations的內容創建（content creation）階段，我們有海量的資源需要管理，包括100多輛車的3D模型，物理動態和駕駛數據文件，11個不斷演化的城市模型，8000多個音頻內容文件。這導致了項目后期的極端混亂，因為我們最初計劃的流程并沒有考慮如何管理海量代碼和內容。在項目的起始階段，我們有多個團隊上傳到一個游戲鏡像。這導致了在構建build階段嚴重的內容不相容問題，例如汽車使用了不正確的引擎音頻、城市馬路沒有路邊障礙、以及把舊內容當成新的回寫的后舊bug再次重現。我們計劃解決這個問題的方法是：把原始的游戲鏡像分割成獨立的鏡像，其中分為城市數據、音頻和無線電內容、汽車內容和所有的源代碼。在游戲發布給雷德蒙的測試組前, 我們同樣計劃創建唯一的測試鏡像，這個鏡像則包括了所有的內容。

    不過，按照這種方法來分割流程，弊大于利。在最后階段，由于Bizarre團隊每隔幾天就要構建一次build，因此測試鏡像得要經常手動更新。為了確保一致性和速度，團隊創建了按部就班的流程和一組批處理文件，這些文件每次按照特定的順序運行。由于游戲是如此大，服務器空間捉襟見肘，使得我們不能使用Alienbrain或者其他文件管理包。我們不得不專門指派一個人用手動拖放來創建測試鏡像。

    當構建build過程開始花費更長時間時，厄運也開始襲來了。每個人工作很多小時，在build冒煙測試（smoke test）后才check-in自己的部件，添加額外的步驟用來管理多個游戲鏡像的資源獲取，所有這些導致構建build過程變得很復雜。測試鏡像經常被收集在一起并放到安全的FTP站點，而雷德蒙的測試組第二天早晨往往發現build無法運行，這就損失了一整天的測試時間。

注解：

    關于冒煙測試，應該是微軟首先提出來的一個概念，和微軟一直提倡的每日build有很密切的聯系。具體說冒煙測試就是在每日build建立后對系統的基本功能進行簡單的測試，這種測試強調功能的覆蓋率，而不對功能的正確性進行驗證。從這一點看和所謂的“接受性（驗收）測試（Acceptance Test）”非常相似。不同之處就在于他們執行的頻率和被測的版本不同。

    至于冒煙測試這個名稱的來歷，大概是從電路板測試得來的。因為當電路板做好以后，首先會加電測試，如果板子沒有冒煙在進行其它測試，否則就必須重新來過。類似的如果冒煙測試沒有通過，那么這個build也會返回給開發隊伍進行修正，測試人員測試的版本必須首先通過冒煙測試的考驗。
  
    在開發游戲上，Bizarre團隊將會堅持使用兩個游戲鏡像：一個用來提交所有的代碼和內容，另一個用來存貯所有測試完畢、可提交的內容。在減少改動部分的前提下，我們期望該流程能夠在未來的項目上使用得更平穩。

最后總結：

    最后，我們都對我們在PGR 2中的取得的成績感到驕傲，而且我們希望玩家也同樣如此。作為一個團隊，我們按照我們的預先設想和優先級別成功完成了這個游戲。我們在保持PGR游戲的傳統核心和引入如線上多人游戲和記分系統中等創新內容之間找到一個平衡。另外，我們也做到了準時把游戲獻給玩家。

    當然，沒有哪個項目是完美的。并且我們也有很多障礙要去克服，很多是我們自己的問題。在PGR和PGR 2之間有Bizarre Creations和Microsoft Game Studios的隊伍成長壯大。我們的挑戰在于我們要在未來繼續成長，要一同工作，并且要克服出現的困難。

    回顧昨天，我們成功的關鍵在于將游戲融入于生活中。PGR 2是由一群努力工作并且效率高的人所開發的——他們之間有相互的高度信任感、開放的溝通渠道、并且有一個清晰的遠景和目標。空談總是簡單的，執行才是關鍵，而且在可預見的將來都是這樣。

網載 2011-03-03 01:36:01