長篇綜述:Ensemble工作室之《帝國時代》反思報告

【在這份1998年由我們的姐妹出版商Game Developer magazine出版的開發反思報告中,Ensemble工作室爲我們揭示了在大型PC實時戰略遊戲《帝國時代》背後的故事】,譯者遊戲邦ciel chen

最近在一家當地的電腦商店裏,我遇到了一件讓我樂壞了的事。當時我正在沉浸在對排名最火PC遊戲前十名的欣賞當中,然後歐文無意中聽到了兩個年輕人下面的這段對話:

“你覺得這個《帝國時代》這個遊戲怎麼樣?”第一個人問道。

它的同伴回答說,“啊,這就是微軟把《魔獸》和《文明》結合起來用來賺錢的那些遊戲。”

由於我總是迫不及待地想要提高我們的銷售額,所以我藉此機會告訴年輕人,這些遊戲不是一家大公司的創意產品,而是一小羣有才華的人在他們自己的後院造出來的。

對於我們來說,《帝國時代》不僅僅是一個史詩般的遊戲大作,而且是我們一小羣人的一個史詩般的旅程,我們希望旅程的重點是能把我們的概念變成一個真正的遊戲。一路走來,我們笑過,我們哭過,我們點披薩喝咖啡熬夜,我們學會了很多遊戲開發的知識。

Age of Empires(from gamasutra.com)

Age of Empires(from gamasutra.com)

對“過去完成時”進行再設計

很明顯,《帝國時代》剛開始看上去並不像成品。儘管有人指指點點,但《人類的黎明》(AoE最初的名字)並沒有被創造成一個《魔獸爭霸2》的克隆版本。(事實上,《魔獸爭霸2》在發行之前,帝國的開發都已經順利進行到一半了。)

相反,最終設計是隨着時間的推移而不斷髮展和完善的,同時也會伴隨着一些重大的設計問題。在遊戲公司裏,我覺的最好的事情就是你能有玩各種不同遊戲的員工。

對Ensemble工作室來說確實需要這樣的員工,我們的開發人員Tim Deen購買遊戲的習慣以及他幾乎會去玩所有上新的PC遊戲給了我們很大的幫助。是Tim所購買的《魔獸爭霸2》讓工作室吸引了工作室其餘成員的注意。就是那個時候,《帝國時代》的很多遊戲內容,比如資源管理、帝國構建以及技術研究得以成型。

然而,我們並不真正瞭解戰鬥的內容要怎麼做。《魔獸世界2》就如同一股潑在臉上的冰水,讓我們清醒地意識到實時戰鬥是多麼有趣的玩法。工作室員工每週總有幾次會熬夜一起玩《魔獸世界》。這些即興的事情在《帝國》進展到成爲比《魔獸》還要好玩的遊戲之前一直都在發生。

另外一個重大的轉變是發生在開發一半的時候,那時候設計者正在研究《帝國》的本地化計劃。他們意識到《帝國時代》將會售往亞洲地區,然而亞洲地區存在着不止一種文化。

我們在全公司範圍舉行會議,決定講亞洲的早期文明加入到我們已經開發的歐洲、非洲和中東部落的文明當中。儘管這個添加的內容會爲美工和設計師製造更多的工作內容,但這個決定最終還是看到了這個遊戲在亞洲的可觀盈利前景而定下了。

這些所有的變動之所以能夠發生,都是因爲遊戲的設計師敢於採納工作室其他員工的想法意見。在Ensemble工作室,開發一款人人都爲之驕傲都想去玩的遊戲並不只是說說而已。也許體現這一核心價值觀的最好例子是遊戲中的奇蹟建築——玩家可以建造和使用來贏得比賽的倒數第二座建築。

在1997年早期,《帝國時代》在激烈的戰鬥上做的很好,但是每個人都覺得遊戲還應該再添加一點新玩法。在嘗試和否決了各種各樣的想法之後,Mark Terrano,我們的通信程序員,想到一個主意——構架一個“末日之鐘”來強制玩家放棄他們正在做的事情並對新的挑戰做出迴應。《帝國時代》充滿了美工和程序員想到的各種小點子和後期補充。這種參與度讓我們增加了我們對遊戲的歸屬感和自豪感。

在設計師的工作中,有一件事情是真正被低估的,那就是遊戲平衡。設計師要花上個把月的時間來調整成本、力量、速度和很多其他的統計數據,就爲了創造出一款好玩而沒有漏斗與作弊之機可趁的遊戲。

當我們不相信他的評價時,他會立即用這個漏洞在比賽中讓我們被“打臉”。在一年的大部分時間了,遊戲制衡都是首要任務,而且最近的即時戰略遊戲裏,它能比其他遊戲內容更能讓《帝國時代》獲得更多的持久力和更好的遊戲體驗。

令人激昂的多人遊戲之路

多玩家支持是早期設計中的重要組成部分,而《帝國時代》的構建就是這樣一種模式——和大部分遊戲一樣,它無法區分人類玩家和電腦玩家。當DirectX首次出現之時,DirectPlay似乎就成了在最廣泛連接類型當中提供通信的最佳選擇。

爲了支持大量的行動單位,我們使用了修行過的遊戲同步模型,通過它整個遊戲可以同時在多臺機器上運行。只有移動、更改和指令才能與其他機器通信。這種方法的優點是最小化了需要發送的數據量。

而使用這種模型的潛在危險就是它可能會造成遊戲在一臺機器上的運行和其他機器上的運行不同步的情況。這給《帝國時代》帶來了一些難以重現的bug。

負荷計量,確定遊戲更新所需的帶寬的過程,在完成計算機AI之前就已經做好了,該計量是基於人類玩家的數據流模型得出的。結果,我們一開始就忽略了電腦玩家有時會在短時間內發出大量指令的這個事實。

然而,我們用第一個補丁解決了這個疏忽。不過有一點——《帝國時代》通信能力在動態適應延遲的方面比預期的要好。當一個命令生效時,一個滑動窗口會延遲實際的遊戲時間,這樣所有的玩家都可以收到指令,並且在執行這個指令之前不必暫停遊戲。

解決玩家遊戲掉線的問題給Mark Terrano帶來了挑戰。因爲掉線是不可預判的,通常都沒法知道到底發生了什麼——可能是遊戲的邏輯出了問題,也可能是winsock、物理連接或者是ISP這些方面的問題,而且這個問題可能是發送者這邊的也有可能是接收方那邊的問題。因此無論什麼時候、什麼人,要想解決遊戲的掉線問題都是一個大工程。

我們從多人遊戲中學到的經驗就是要充分利用通信測試工具(例如自動日誌和校驗碼)。此外,我們發現了,創建一個簡單的通信數據流模擬器程序可以有很多的好處,還能將通信代碼與遊戲的其他部分分隔開來。

我們還發現DirectPlay也是存在問題的。難以重現的bug、古怪的行爲以及糟糕的文檔使這個過程變得更加困難。IPX(一種互聯網協議)的保證數據包交付是一個更值得注意的例子。在中國遊戲開發者大會(CGDC)上,微軟承諾將提供DirectX 5的功能,甚至這個功能可能會包括在測試版中。

遊戲畫面的製作

在《帝國時代》中所有的2D sprite都以3D模型的形式開始了生命。《帝國時代》包含了20兆的遊戲內置sprite圖片內容。即使所有的顯示都是2D形式的,我們還是早早地就決定了以3D模型來製作遊戲中所有的圖。我們使用的是3D Studio和3D Studio Max來進行美術製作。

由於3D渲染是非常耗時的,每個美工都要有兩臺機器,兩臺機器通常都是200MHz、128M內存的奔騰處理器,這在當時比程序員用的設備還要好。遊戲中的所有對象都使用的是3D模型,他們所包含的各種多變性數量從幾千到10萬不等。這然後這些模型會被添加紋理、被做成動態化並加之以渲染,最後輸出爲一個有着固定的256色調色板的.FLC(Autodesk Animator)動畫文件。

到目前爲止,我所描述的遊戲製作程序和許多其他遊戲是相同的。然而,在這一點上,美工們有多了一個耗時的步驟——這個.FLC動畫文件被交給了一個2D動畫專家,它把這個動畫用幀進行了分解,用photoshop“清理”了每一個圖片。

這個“清理”過程包括打磨細節並平滑不規則多邊形的邊緣。因爲《帝國時代》大部分的sprite的屏幕分辨率在每個方向上只有20到100個像素,所以我們有意識到提高畫質質量是相當重要的。於是當《帝國時代》在1997年的E3大展上展示的時候,我們的美工受到了許多其他公司同行的讚賞。

我們決定爲遊戲中所有對象使用3D模型的決定爲美術的其他方面提供了便利,因爲這些3D模型成爲了隨時可供使用的靜態背景圖像(出現在菜單、狀態畫面和各種動畫場景中)。其中包括了3分鐘的開場的動畫場景本身就是一個專項。

在《帝國時代》使用的256色調色板(實際上只有236色)是有些問題的。該調色板的選擇和設定是在項目一開始(大部分模型和紋理都還沒添加之前)就板上釘釘了。結果我們發現色彩頻譜中的一些某些部分——比如木紋理的褐色——幾乎沒有可用的顏色來呈現最佳的視覺效果。

在遊戲的開發過程中,調色板沒有被修改,因爲這會設計到重新劃分和修改遊戲中的每一個圖像——這裏的時間代價太大了。另一方面,由於調色板的顏色範圍比較寬、顏色也很均勻,這使得遊戲圖形看起來更明亮更令人愉悅。如果我們在做一個8位顏色的遊戲,我們會在開發過程進一步的時候再生成調色板。

運行速度的追求

性能是除了極其簡單遊戲外幾乎所有遊戲的一個問題,尤其是對《帝國時代》來說。當我加入Ensemble工作室,這款遊戲還在處在早期階段,進行得還很緩慢。這時候有兩個最大的問題就是圖形引擎(速度非常慢)和各種更新程序,這讓遊戲過程中偶爾會有一秒的停頓。

如果我們想要有一個最先進的系統,那麼一些優化就必不可少了。從這裏開始,故事的個人色彩會變重,因爲我在《帝國時代》該方面做了大量的工作。

我開始嘗試處理超過10W行C++代碼所做的事情(源代碼在完成之前會上升到超過22萬行)。在花了幾個星期的時間研究了我們手頭上所有的遊戲內容後,我提議對推行引擎解構進行一次重大的修改,包括在彙編中編寫一個主要部分。

當《帝國時代》的原設計組問我基準測試場景的幀率是否可以從當前的7-12幀/秒提高到20幀/秒的時候,我內心是汗顏不已的,不過終究還是希望能有更多的進步,於是我接下了這個要求。

我不能直接把就得圖像引擎撤掉,因爲這樣會牽扯到其他的所有人,於是我在接下來的五個月時間裏大多都在爲新引擎幹活。在這個過程裏,我取得了一些些進展,我將幀率提升到了10-14幀/秒,然而是在最後一個新設計被投入使用的時候,經過一個通宵達旦,這個巨大的突破得以實現。

令我吃驚的是,基準測試運行的速度現在達到了55幀/秒。所以在第二天能回到辦公室的時候,看到原來龜速的動畫流暢地運行時,我的內心是激動無比的。然而我的工作並不全部都在圖形引擎的改進上。

我還花了大量的時間來識別和優化遊戲中數不清的進程。由於這款遊戲是實時類型的,所以有很多要涉及到的改進來讓一個進程來在多個回合中展開,這樣就不用暫停遊戲到進程結束爲止了。最後,所做的優化得到了豐厚的彙報——我們得以將默認的分辨率從640×480提高到了800×600。

我從這次經歷中學習到了一個實踐經驗,那就是了解到——一款遊戲在接近完成時究竟還能有多燒錢多耗時。通常在一個遊戲項目的早期,引擎會顯示出很好地性能,但這樣的遊戲並不是最終版——當你將簡單的測試版本換成複雜的最終版本(添加了AI、UI等等各種各樣的內容)之後,你會在實際性能表現上看到一個完全不同的世界。這也確實是《帝國時代》身上發生的事。當我們接近完成時,所有的鬆散端都被綁緊了,許多性能上的提升都被換成了新特性。

我們在開發過程中做得好的方面

遊戲被分爲各個獨立的引擎和遊戲組件。有大概途中,有人擔心代碼庫的擴展在某些領域已經遠遠超出了最初設計預期,這樣會讓每個新的變更和添加內容看起來會變得像很醜的黑客。於是我們的首席程序員Angelo Laudon和Tim Deen用了兩個禮拜來把代碼庫分成兩個部分,一個是總引擎(Genie),以及遊戲本身(Tribe)。

這種轉換非常成功,並且讓《帝國時代》的程序員能夠保持良好的面向目標的設計。這樣做的好處是讓代碼更好修改和擴展,從而節省了程序員內大量的開發時間。

我們讓遊戲的數據庫有了驅動力。多虧了面向目標化的設計,《帝國時代》幾乎沒什麼對象的代碼是需要被硬編碼到程序中的。相反,巨大的信息表描述了遊戲中出現的每個對象的每個特徵;社記者們使用了一個超過40個悖論的表格來控制和塑造遊戲。因此,他們能夠不斷地更新和調整遊戲,然後在不需要程序員的情況下依舊能測試他們的改變。

我們保持和發行商的密切聯繫與協作。關於我們如何同我們的發行商微軟保持密切的聯繫我還沒法說出什麼是夠好的,不過我們的合作確實幫助了《帝國時代》的發展。通過讓他們保持對我們“開發內部消息”的悉知,當發生什麼事情的時候,微軟會協助我們而不是跟我們對着幹。

這種關係如何幫助我們開發進展的最好例子就是——我們處理日程推遲安排的方式。每次發生一些事情讓開發進程需要比預期更多的時間時;或者新的問題出現時,我們都會和微軟進行有效的溝通來延緩日程。

他們清楚地知道發生了什麼以及發生的原因,他們重申了他們無論花多少時間都要幫助我們開發一款高質量遊戲的承諾。因此,我們不感到驚慌失措和精疲力竭,而是保持專業的態度專注於我們自己的目標。

我們玩自己的遊戲

儘管這件事聽起來挺簡單,但它的重要性是非比尋常的。在整個開發的過程當中,每個公司的員工不僅僅玩遊戲來進行測試,而且會帶着享樂的目的去玩《帝國時代》。

Age of Empires(from gamasutra.com)

Age of Empires(from gamasutra.com)

於是,我們就非常瞭解遊戲的有趣之處以及人們可能從遊戲中得到些什麼。我們20個成員決定齊心協力讓遊戲玩法的樂趣不會被妥協或者被沖淡。

性能良好

如果你想讓你的遊戲具備廣泛的吸引力,那麼遊戲的性能表現就很重要了。 《帝國時代》能夠讓8個玩家在一個P120系統上以16兆的內存順溜地運行。而和《橫掃千軍》相比,32兆的內存、至少要200MHz的CPU來跑8個玩家的遊戲。《帝國時代》之所以能達到這種級別的性能是付出了大家辛勤的努力的。程序員把額外的精力用來控制內存消耗並識別程序瓶頸所在,而美工們則剔除了額外的動畫幀來重組圖形以使空閒內存最大化。

公司尊重自己的員工。關於Ensemble工作室對員工和他們的家庭的待遇,我確實得說點什麼。衆所周知,軟件開發,尤其是遊戲開發,都需要犧牲大量的時間,這讓他們在個人關係上猶如煉獄一般。

Ensemble公司貼心周到的管理讓員工的家庭成員可以加入公司舉辦的衆多晚宴和其他活動之中,這讓家庭成員們感到他們是隨時受到辦公室歡迎的。除此之外,在工作室達到一個里程碑之後,一定會讓員工休息幾天去和他們的家人聯絡感情。如果需要的話,他們可以有彈性地安排時間,另外還有鮮花或者其他表示感謝的禮物會定期送到家人家裏。

公司管理層的這種細緻做法的成果是顯而易見的;公司的士氣和忠誠度高出了我14年以來所見到所有軟件開發公司。這讓我的妻子熱愛我工作的程度都跟我一樣了。

本地化真的有效。從剛開始,我們知道微軟想要發行包括日語在內6個語言版本的《帝國時代》。在大概我們開發到一半的時候,我們更新了我們的代碼庫已提供全面的本地化支持。這就要求刪除和替換源代碼中的所有文本引用,並且只能從一個外部資源文件中來維護所欲的遊戲文本。

這還讓我們在文本的起草和表現上有了嚴格的限制。我們只能用Windows GDI——這是大多數遊戲都不樂意做的。這還意味着有一些比如按鈕之類的界面項目需要儘可能地擴大化好放下可能增長的譯後標題文本,這會限制了設計者在用戶界面上的創作。

但是我們還是屈服了,確切地按照指導方針去做了。而讓我們感到驚喜的是,這個轉換渡過得很迅速而且沒有什麼痛苦。並且當微軟的翻譯人員告訴我們本地化《帝國時代》是他們做過最流暢最不頭痛的項目之後,我們感覺就更好了。

本地化給了我們非常大的助益,因爲我們爲此有了一個可以用於所有遊戲譯後文本的單一可執行文件,這樣就可以避免避免在跟蹤BUG和發行多個版本的遊戲更新所帶來的巨大麻煩。

我們是一個尊重所有成員的團隊。《帝國時代》這個項目規模讓我們整個團隊需要在一起工作很長一段時間。我們會說我們僱傭新成員的一個標準是必須能夠互相尊重每一位團隊的成員。

有了這樣的互相尊重之後,加上公司對於員工的寬厚待遇,這讓每個成員在團隊裏有一種大家庭之感和團隊精神。我們避免了分成不同的羣組而讓大家對項目產生隔閡感,因此即使在嚴重的危機時刻,成員的態度和情緒依然高昂不氣餒。

如果我們的團隊脾氣暴躁,還充滿派系鬥爭,我真的不認爲《帝國時代》能在1997年取得那樣的成功。

那些出錯的或者本可以做的更好的方面

我們開發週期裏的beta測試進行的太晚了。在1997年8月份,我們對《帝國時代》進行了公開beta測試,但是我們卻沒能發揮出這次的測試的潛力。我們已經非常接近項目的尾聲了,以至於若非收到什麼非常有使用價值的反饋,我們並不想做出什麼遊戲上的變動。宣傳手冊已經做好印刷準備了,大部分的設計都已經板上釘釘了。我們當時所能做的就是修復所有被發現的bugs。而對於將來的任何項目,我們發誓,一定要在更早的時候的進行beta測試。

我們和微軟的QA人員(質檢人員)溝通不足。項目大部分的錯誤報告都是通過我們的數據庫來處理的,而我們的開發者並沒有直接和測試人員進行交流。結果很多錯誤解決的時間變得很長,新的特性也尚未經過測試。

單單靠中間數據是不足以讓測試人員和開發者知道別人在想什麼的。在未來的項目裏,我們想爲每個程序員指派一個測試人員,讓他們每隔幾天進行一次電話交流。

在接近開發尾聲的時候,我們還真的在一些成員身上施行了一下這樣的方法,他們在測試和bug解決方面的效率得到了巨大的提升。

我們有時不聽從指揮而沒能做好協作開發。另一個可以促進開發的人員交流方面是我們的團隊內交流。每個小組——編程組、美工組、遊戲設計組和音效組都有一個領頭人負責跟進自己小組每個成員的進度。當外部人員對開發內部人員提出新的要求時,這個領頭人就會成爲兩方的溝通的橋樑。

隨着《帝國時代》開發的日益發展以及壓力增大,當成員直接去滿足自己項目需求的時候,就破壞了這個系統的規則。我們就爲此付出了代價——成員們不知道變成上的變動或者美工給遊戲添加的新內容,於是混亂的程度日益增加,這導致了時間的消耗和分散。於是我們所有的人不得不停下來搞清楚到底發生了什麼事。

我們未能充分地測試多玩家遊戲和MODEM(調制解調器)之間的連接。我們開發環境上的一個問題就是它無法配上典型的用戶終端系統。在開發的過程中,《帝國時代》的多人遊戲部分有進行過廣泛的測試。

當我們在辦公室玩遊戲的時候,我們運行比較快的機器,在滿內存的情況下能在高速局域網中相互通信。當我們測試聯網遊戲玩法的時候,我們的通信是通過公司的T1線路進行的。在測試中我們沒有意識到的是——大多數玩家使用的會是MODEM(調制解調器)和商業互聯網服務供應商之間的網路。

出現這個錯誤的不只是我們,微軟的測試實驗室也出現了同樣的情況。結果,Modem連接的遊戲都沒能得到充分的測試。於是遊戲bug只有在網絡延遲時間較低時才比較少,這驅使網速慢的玩家都棄遊了。而我們的高速網絡掩蓋了這樣一個事實——在某些不尋常的情況下,《帝國時代》會要求達15K美秒的網絡寬帶——這甚至是56k的MODEM所能提供上傳速度的6倍速。

結果,當多人遊戲出現問題時,我們有點吃驚。儘管我們用第一個補丁包解決了這個問題,不過這樣的情況的出現是我們無法接受的。現在,我們每個開發者都有一個MODEM以及不同的ISP可以用,因爲Modem測試是我們測試流程的一個大項目。

開發部分內容依賴於沒有按時交付的產品(微軟的DirectX 5a)。這也是遊戲的MODEM沒能得到測試的第二個原因:微軟DirectPlay的交付與質量問題。之前承諾過的特性,甚至布包括beta版本的發行都沒能在遊戲的最終版本延遲發行時出現。

Direct X 5a直到遊戲發行前1個月才能夠使用。在此期間,我們的通信程序員通宵達旦寫的功能受到了期待卻沒能交付。等待被許諾的的驅動程序和SDK是開發人員必須面對的難題之一——即使作爲發行商的微軟也無法控制這樣的情況。

我們沒有制定做補丁的計劃。儘管版本1.0a的補丁包取得了成功,但對於我們沒有制定做這個補丁包的計劃這件事來說,還是有問題的。一般的關電視,如果你知道你需要發佈補丁,那麼你一開始就不應該把遊戲運轉起來。

儘管這個觀點有所道理,但是事實是這樣的——沒有遊戲開發者能測試出一款匹配上首批5萬的遊戲購買玩家電腦配置的遊戲;你的顧客會用各種你做夢都想不到的方式來嘗試各種玩法,以及在你從未聽說過的硬件和驅動程序上運行遊戲。環顧一下,今年幾乎每一款重大遊戲的發行都有補丁或者更新。

與其否認這一事實,我們更願意在未來調配資源與期望,這樣我們就可以在遊戲運行的幾天或者幾周後發佈一切必要的更新,而不是幾個月。

我們未能如常地處理好“意外”時間。在開發期間,我們經歷了幾起突發事件,這讓我們,作爲一家公司,竟然停止了我們手頭上正在做的事情。這些事件包括了遊戲的demo版本的製作以《帝國時代》素材的新聞報道。

雖然大部分的事件是有益於公司的,但我們並不是很擅長應對這些事件,而且這些事件也讓我們拋下了我們的日程安排。這些突發事件大多是在開發後期出現的,也是它們影響最大的時候。所以我們未來遊戲的目標之一就是儘可能地減少意外事件的影響,做到儘可能地提前告知,並且讓儘可能精簡的人員去應對這些事件以限制影響的範圍。

我們沒有充分利用自動化測試的優勢。在開發的最後幾個星期裏,我們開設了一款可以再9臺電腦上自動相互對抗的遊戲。除此之外,包含開發平臺和調試器的第二臺電腦可以監控每一臺參與遊戲的電腦。這些遊戲儘管是隨機生成的,還是會被記錄下來,這樣如果發生了什麼事,我們就可以不斷地重複這個遊戲直到我們找到問題所在爲止。

本身允許在加速條件下運行的遊戲會被留下徹夜運轉。這是個巨大的成功,讓我們得以在很大程度上把問題隔離出來。我們主要就失敗在沒能在早期開發中做到這點——這能節省我們大量的時間和精力。現今,我們未來所有產品計劃中都把從第一天開始的自動化測試列入到其中。

《帝國時代》的開發團隊,Matt Pritchard是在前排右數第二個

吸取所有的教訓

當《帝國時代》投入市場進行生產時,我們給自己開了一個大派對來發泄壓力。事實證明,我們狂歡得過早了。在《帝國時代》上架後,我們開始收到關於找不到路、單位AI行爲問題、人口限制問題以及多人遊戲問題的反饋。

除此之外還發現了一些漏洞,玩家可以利用這些漏洞在遊戲中得到不公平的優勢。Ensemble和微軟的管理層都採取了行動,決定爲《帝國時代》做一個補丁。

儘管時間是從別的項目中擠出來的,並且花了比預計還要長的時間,但最後的補丁還是相對成功的——它極大地提高了多人遊戲的遊戲質量,修正了漏洞,並且解決了所有之前提到的遊戲問題。這讓《帝國時代》得以發展到今日之勢——當然了我希望你們的硬盤上有裝這款遊戲。
【Matt Pritchard設計了《帝國時代》的圖形引擎,他還參與了《帝國時代2》、《神話時代》以及《黑暗地帶:51區》的製作。這篇文章最初發表於1998年三月的《遊戲開發者雜誌》上】

本文由遊戲邦編譯,轉載請註明來源,或諮詢微信zhengjintiao

I had an experience in a local computer store recently that caused me to burst out laughing. I had stopped to self-indulgently admire the top-ten PC games display when I overheard the following exchange between two young men:

“What do you think about this one, Age of Empires?” wondered the first.

His companion shot back, “Aww, the Borg at Microsoft just combined Warcraft and Civilization to cash in on these kind of games.”

Always eager to boost our sales, I took this opportunity to tell the young men how AoE wasn’t the creative product of a giant corporation, but of a small group of talented people living right in their own backyard.

For us, Age of Empires was not only a game of epic proportions, it was an epic journey for a small band of people determined to turn an idea into a real game company. Along the way, we laughed, we cried, we consumed pizza and caffeine, and we learned a great deal about making games.

age_of_empires_screen_1.jpg

Designing the Past Perfect

Obviously, Age of Empires didn’t start out looking like the final product. Despite some accusations, Dawn of Man (AoE’s original title) wasn’t created to be a Warcraft II clone. (In fact, Warcraft II wasn’t released until after AoE’s development was well underway).

Instead, the final design was evolved and refined over time, with a few significant design events along the way. One of the best things I think you can have in a game company is a staff that plays a lot of different games.

This was true of our staff at Ensemble, and was helped in no small part by programmer Tim Deen’s habit of buying and actually playing almost every new PC game as it came out. It was Tim who brought Warcraft II to the attention of the rest of the Ensemble staff. At that time, many of AoE’s game elements, such as resource management, empire building, and technology research, were taking clear shape.

However, we didn’t really know what to do about combat. Warcraft II was a splash of cold water in the face, waking us up to how much fun real-time combat could be. Several times a week, the staff would stay late to play multiplayer Warcraft. These impromptu events continued until AoE reached the point in development when it became more fun to play than Warcraft.

Another major shift occurred a little over halfway through development, when the designers were looking at AoE’s localization plans. They realized that AoE would be sold in Asia, but didn’t include a single culture from that region.

We held a company-wide meeting and decided to add early Asian civilizations to the early European, African, and Middle-Eastern tribes that we’d already developed. Though the addition would create more work for the artists and designers, the enhanced appeal that the game would have in Asia would make this a profitable decision.

All of these changes occurred because the game’s designers weren’t afraid of taking design input from the rest of the staff. Making a game that everyone would be proud of and would want to play was something that got more than just lip service at Ensemble. Perhaps the best example of this core value is the Wonder, the penultimate building that a player can build and use to win the game.

In early 1997, AoE was great for slugfests, but everyone felt that the game play needed to offer something more. Numerous ideas were tried and rejected. Then Mark Terrano, our communications programmer, hit upon the idea of building an “Armageddon Clock” that would force players to drop what they’re doing and respond to the new challenge. AoE is chock full of little ideas and touches that were thought up by the artists and programmers. This participation tangibly increased the sense of ownership and pride that we all took in the game.

One of things that is truly underappreciated about the designer’s job is play balancing. The designers spent months and months adjusting costs, strength, speed, and many other statistics in an effort to create a game that was fun to play and yet didn’t offer any loopholes or cheats.

At this point, I realized that Tim Deen was truly a gamer’s gamer. During development, if any of the various iterations of AoE’s design opened up a way for one player to take advantage of another player and thus make the game one-dimensional, Tim would find it.

And when we didn’t believe his assessments, he would promptly show us by using the loophole to kick our butts at the game. For the better part of a year, play balancing was a prominent task, and it paid off in giving AoE more staying power and better game play than many others in the recent crop of real-time strategy games.

Blazing the Multiplayer Path

Multiplayer support was an integral part of the early design, and AoE was structured in such a way that most of the game could not differentiate between human and computer players. When DirectX first came out, it appeared that DirectPlay would be the best choice for providing communications over the widest variety of connection types.

To support a high number of moving units, we went with a modified game synchronous model, where the entire game is simultaneously run on all machines. Only moves, changes, and commands are communicated to other machines. This approach has the advantage of minimizing the amount of data that has to be sent.

The unanticipated danger of using this model is that it can generate a condition where the game on one machine becomes out of sync with the game on other machines. This caused some very hard-to-reproduce bugs with AoE.

Load metering, the process of determining how much bandwidth the game updates required, was done before the computer AI was completed, and was based on the data flow model taken from human players. As a result, we initially missed the fact that computer players would sometimes issue large numbers of commands in quick bursts.

We did, however, address this oversight with the first patch. An area where AoE’s communications worked out better than expected was the game’s ability to dynamically adapt to latency. A sliding window delays the actual game time when a command takes effect, so that all players receive the command and do not have to pause before executing it.

The problem of handling players who have dropped from a game presented Mark Terrano with difficult challenges. Since drops are unpredictable, usually there is no way to know what happened. The problem could be the game logic, Winsock, the physical connection, or the ISP, and could exist on either the sender’s or receiver’s side. Getting the game to handle drops by anyone at anytime required a great deal of work.

One of the lessons learned from the multiplayer experience was to make full use of communications testing tools, such as automated logs and checksums. Also, we discovered that creating a simple communications data flow simulator program could provide great benefits and isolate the communications code from the rest of the game.

DirectPlay also turned out to be problematical. Difficult-to-reproduce bugs, quirky behavior, and poor documentation made the going more difficult. Guaranteed packet delivery for IPX was one of the more notable examples. At the CGDC, Microsoft promised to deliver this feature with DirectX 5 and even included in the beta.

However, when DirectX was actually released, this feature was nowhere to be found. The cost of that one missing item was the extra time we had to spend writing our own guaranteed delivery system and a bad packet generator program with which to test it.

Painting the Scene

All of the 2D sprites in AoE began life as 3D models. Age of Empires contains 20MB of in-game sprite graphics. Even though all of the displays are 2D, we decided early on that all of the graphics in the game would be taken from 3D models. We used 3D Studio and 3D Studio MAX for art production.

Because 3D rendering is so time-consuming, each artist was issued two machines each, both usually 200MHz Pentium Pros with 128MB of RAM, which at the time was better equipment than the programmers were using. The objects in the game were created as 3D models that had anywhere from a couple thousand to 100,000 polygons. The models were then textured, animated, and rendered out to a .FLC (Autodesk Animator) file with a fixed 256-color palette.

So far, the process I’ve described is identical to that of many other games. At this point, however, the artists added another time-consuming step. The .FLC files were handed off to a 2D specialist, who took the animation apart frame by frame and “cleaned up” each image with Photoshop.

The clean-up process involved sharpening detail and smoothing the edges of the irregular shapes. Since most of the sprites in AoE had screen dimensions of only 20 to 100 pixels in each direction, the visual quality improvement that we realized was significant. When AoE was shown at the 1997 E3, the artists received numerous compliments on their work from their peers at other companies.

The choice to go with 3D models for the in-game objects provided benefits for other art needs, as they were readily available for use in the static background scenes that appear on the menu, status screens, and the various cinematics. The cinematics, including the three-minute opener, were a fulltime project unto themselves.

The 256-color palette (actually 236) used in AoE was something of a problem. The palette was chosen and set in stone at the very beginning of the project, before most of the models and textures had been created. As a result, it turned out that some portions of the color spectrum, such as browns for wood textures, had too few available colors to get the best visual quality.

The palette wasn’t revised during the development process because that would have required rerendering and touching up every image in the game ‘ far too expensive time-wise. On the other hand, the palette did have a wide and balanced range of colors, which contributed to the overall bright and cheerful look of the game’s graphics. If we do another 8-bit color game, we’ll generate the palette at a point further along in the development process.

Going for Speed

Performance is an issue for all but the simplest of games, and it certainly was for AoE. When I joined Ensemble, the game was still in an early form and slow. The two biggest problems were the graphics engine (which was just plain slow) and various update procedures, which produced occasional pauses of up to a second in game play.

If we were going to sell to anything but the most cutting-edge systems, some serious optimization was in order. The story gets personal here, as I did a great deal of the work on this part of AoE.

I started by trying to get a handle on what the over 100,000 lines of C++ code did (the source would rise to over 220,000 lines before it was finished). After spending a few weeks studying what we had, I proposed a major overhaul of the graphics engine structure, including writing a major portion in assembly.

AoE’s original design team asked if the frame rate of a benchmark scenario could be raised from its current 7 – 12 fps to 20 fps. I told them yes. Inside I was sweating bullets, hoping that I could deliver that much improvement.

I couldn’t just go ahead and rip out the old graphics engine, as it would hold up everyone else, so I spent the next five months working mostly on the new engine. Along the way, I managed some incremental improvements that upped the frame rate to 10 – 14 fps, but the big breakthrough came during an all-nighter, when the last piece of the new design was put into place.

Much to my surprise, the benchmark scenario was now running at 55 fps. It was exciting to come back into the offices the next day and see the formerly sluggish animation running silky smooth. But my work was not all on the graphics engine.

I also spent a great deal of time identifying and optimizing myriad processes in the game. Since the game was real-time, many improvements involved spreading out a process over several turns rather than of stopping the game until it completed. In the end, the optimizations paid off handsomely and allowed us to raise the default resolution from 640×480 to 800×600.

A practical lesson that I learned from this experience was how much additional overhead and slowdown a game can acquire as it approaches completion. Often, early in a game project the engine will show great performance but the game’s not finished. When you replace the simple test levels with the complex final levels, add all the AI, UI, and bells and whistles, you can find a world of difference in actual performance. This was true for AoE as well. As we approached completion and all of the loose ends were tied off, many of the performance gains were traded in for new features.

Things That Worked Out (S)well

1. The Game was broken into separate engine and game components. About halfway through development, there was concern that the code base had expanded far enough beyond the initial design in some areas that every new change and addition would look like an ugly hack. Lead programmer Angelo Laudon and Tim Deen took two weeks and separated the code base into two separate sections, the general engine (Genie), and the game itself (Tribe).

The conversion was very successful and allowed the AoE programmers to retain a nicely object-oriented design. The benefit here was that it made the code much easier to modify and extend, saving the programmers a great amount of development time.

2. We made the game database driven. Thanks to the object-oriented design, almost nothing about any object in AoE is hard-coded into the program. Instead, huge tables of information describe every characteristic of every object that appears in the game. The designers used a system of over forty Paradox tables to control and shape the game. As a result, they were able to constantly update and tweak the game, and then test their changes without having to involve a programmer.

3. We stayed in close contact and working together with the publisher. I can’t say enough good things about how the close contact with our publisher, Microsoft, helped the development of AoE. By keeping them “in the loop” on our progress, they worked with us instead of against us as things happened.

The best example of how this relationship aided development is the way we handled schedule slippage. Each time something took longer than expected or new problems cropped up, we effectively communicated the delay to Microsoft.

With a clear understanding of what was happening and why, they reaffirmed their commitment to assist us in producing a quality game, whatever amount of time that would take. So instead of being panic-stricken and whacked out, we remained professional and focused on our goals.

4. We played our own game. While this may sound simple, it’s very important. Throughout the development process, every person in the company not only play tested, but played AoE with the purpose of having fun.

As a result, we were very in tune with why the game was fun, and what people were likely to get out of it. We had 20 guys who were determined not to let the game play be compromised or watered down.

5. Performance was good. Performance truly means a lot if you want your game to have broad appeal. Age of Empires can adequately run an eight-player game in 16MB of RAM on a P120 system. Contrast that with Total Annihilation, which requires 32MB and at least a 200MHz CPU for an eight-player game. Achieving this level of performance required a group effort. The programmers expended extra energy on keeping memory consumption in check and identifying bottlenecks, while the artists culled extra animation frames and reorganized the graphics to maximize free memory.

6.The company respected its employees. I have to say something about the way Ensemble Studios treated its employees and their families. It is well known that software development, especially game development, involves great sacrifices of time and can be hell on personal relationships.

Ensemble’s thoughtful management respected that by going out of their way to include families at numerous company dinners and other events, and to make them feel welcome to come by the offices at any time. Additionally, after crunching hard to meet a milestone, they would insist that employees take a couple of days off to catch up with their families. People were allowed flexible schedules if they needed them, and flowers or other tokens of appreciation were sent to the families periodically.

The result of this deliberate action by company management should be obvious; company morale and loyalty was higher than I have ever seen in fourteen years of software development. My wife loves my job as much as I do.

7. Localization really worked. From the beginning, we knew that Microsoft wanted to release AoE in six different languages, including Japanese. About halfway through development, we updated our code base to provide full localization support. This required stripping out and replacing all text references in the source code and maintaining all game text in an external resource file.

It also placed severe restrictions on how we could draw and display the text. We had to use the Windows GDI exclusively, something most games shun like the plague. It also meant that interface items such as buttons had to be sized to hold the largest possible translated form of their captions, limiting the clever things one could do with the design of the user interface.

But we buckled down and did it, following the guidelines exactly. And to our pleasant surprise, the conversion was swift and painless. We felt even better when the translators at Microsoft told us that localizing AoE was the smoothest and most pain-free project they had ever done.

The benefit to us was enormous in that we had a single executable program file that was the same for all translated versions of the game, thus avoiding the huge headache that comes with tracking bugs and releasing updates for multiple versions.

8. We worked as a team that respected all its members. A project of AoE’s size required that we all work together in close quarters for extended periods of time. One of our expressed criteria in hiring new people is that we must be able to respect each other.

This respect, complemented by the company’s actions towards its employees, fostered an excellent sense of family and team spirit among everyone. We avoided having different groups develop a sense of isolation from the project, and as a result, attitudes and spirits remained high even during the worst crunch time.

Had tempers flared and cliques developed, I honestly don’t believe that AoE could have made it out the door in 1997.

Things That Went Wrong Or We Could Have Done Better

1. We held the beta test too late in the development cycle. A public beta test of AoE was held in August 1997, but we didn’t come near to exploiting the full potential of it. We were too close to the end of the project to make any game play changes, despite the wealth of useful feedback we received. Manuals were already set to be printed, and most of the design had been set in stone. All we could really do was fix any bugs that were found. For any future projects, we vowed to hold the beta testing earlier.

2. There was inadequate communication with the QA people at Microsoft. For most of the project, bug reporting was handled through a database and developers didn’t directly communicate with the testers. As a result many bugs wound up taking much longer to resolve, and new features went untested.

An intermediate database was simply not enough to let testers and developers know what the other was really thinking. In future projects, we would like to assign a specific tester to each programmer and have them communicate by phone every couple of days.

Near the end of development, this did happen for a couple people, and for them productivity with testing and bug resolution was drastically improved.

3. We sometimes failed to coordinate development through the leads. Yet another area where personnel communication could have improved the development was among our own teams. Each team Programming, Art, Game Design, and Sound has a lead person who is responsible for keeping track of what each member of his or her team is doing. The lead is the go-to person when someone outside has new requests for the team.

As the development of AoE progressed and the pressures rose, adherence to this system broke down as people went direct to get their needs filled quickly. We paid a price for it. People didn’t know about programming changes or new art that was added to the game, and the level of confusion rose, creating a time drain and distraction. We all had to stop at times just to figure out what was going on.

4. We failed to adequately test multi-player games with modem connections. One problem with our development environment is that it isn’t comparable to the typical end user system. During the course of development, the multiplayer portions of AoE were tested extensively.

When we played a game in the office, our fast machines, stuffed full of RAM, communicated with each other on our high-speed LAN. When we tested Internet play, our communications were handled through the company’s T1 line. One thing that we failed to realize in our testing was the fact that most players would be using dial-up modem connections to commercial Internet service providers.

And it wasn’t just us; the same situation applied to the testing labs at Microsoft. As a result, modem connection games were under-tested. Bugs that were harmless when ping times were low resulted in dropped games for users on slower Internet connections. And our high-speed network masked the fact that under certain not-so-uncommon circumstances, AoE could require 15K of network bandwidth per second — six times what even a 56K modem can provide on the uplink side.

As a result, we were taken a bit by surprise when reports of multiplayer game problems rolled in. Though our first patch fixed this problem, the situation was unacceptable. Now, each developer has a modem and several different ISPs are used, as modem testing is a big part of our testing process.

5. Portions of development relied on products that were not delivered on time. There was a second reason that modem games were under-tested; problems with the delivery and quality of DirectPlay from Microsoft. Features that were promised, and even included in beta releases, weren’t present when the delayed final release was delivered.

Direct X 5a wasn’t available to us until a month before the game shipped. In the meantime, our communications programmer was burning the midnight oil writing the functionality that was expected but not delivered. Waiting on promised drivers and SDKs is one of the harder things that developers have to deal with; even those with Microsoft as a publisher have no control over them.

6. We did not plan for a patch. The version 1.0a patch, even though it was a success, was problematic in that as a company we had not planned for it. The general argument is that if you know you are going to need to release a patch, then you shouldn’t be shipping the game in the first place.

While one can take that stand, it’s also a fact that no game developer’s testing can match that of the first 50,000 people who buy and play the game. Your customers will do and try things that you never dreamed of, while running on hardware and drivers that you never heard of. Looking around, nearly every significant game released this year has had a patch or update released for it.

Rather than deny this reality, we would like to allocate resources and expectations in the future so that we can release any necessary updates days or weeks after our games ship, rather than months.

7. We didn’t manage “surprise” events as well as we could have. During the development period, we experienced several sudden events that caused us, as a company, to stop what we were doing. These events included the creation of a demo version of the game and materials for press coverage of AoE.

While most of the events were beneficial to the company, we weren’t very good at handling them, and they threw off our schedules. These disruptions mostly came late in development, when their impact was felt the most. One of our goals for future games is to minimize the impact of unplanned events by giving advance notice when possible and restricting them by minimizing the number of people that have to respond to them.

8. We didn’t take enough advantage of automated testing. In the final weeks of development, we set up the game to automatically play up to eight computers against each other. Additionally, a second computer containing the development platform and debugger could monitor each computer that took part. These games, while randomly generated, were logged so that if anything happened, we could reproduce the exact game over and over until we isolated the problem.

The games themselves were allowed to run at an accelerated speed and were left running overnight. This was a great success and helped us in isolating very hard to reproduce problems. Our failure was in not doing this earlier in development; it could have saved us a great deal of time and effort. All of our future production plans now include automated testing from Day One.

The Age of Empires development team. Matt Pritchard is front row, second from right.

Patching It All Up

Once AoE was shipped off to production, we threw ourselves a big party to let off some stress. It turns out we were a bit premature in our revelry. Shortly after AoE arrived on store shelves we began receiving feedback on problems with the path finding, unit AI behaviors, population limits, and multiplayer play.

Additionally, some bugs were found that a player could exploit to gain an unfair advantage in the game. Management was stirred to action at both Ensemble and Microsoft, and the decision to do a patch for AoE was made.

Although time was taken away from other projects, and it took longer than desired, the patch was a success; it vastly improved the quality of multiplayer games, fixed the bugs, and addressed the game play concerns that had been raised. And that brings the development of AoE to where it is today, which I hope is somewhere on your hard drive…(source:gamasutra.com