《神話時代》制作大揭密

簡體傳統

制作第一代的Age of Empires游戲非常難。由于沒有經驗，很多不熟悉的東西都要去嘗試一下才知道行不行。要經歷很多挫折，甚至放棄最初美好的設想。會犯不少錯誤，也會有很多經驗教訓。由于沒有過去的成功（或者哪怕是失敗）做參照物，你的游戲設計只能跟著感覺走。開發團隊沒有經驗，則計劃和實際相差甚遠，進度亦無法掌控。各項任務之間協調不周，有時候一個重大的任務沒有完成，妨礙其他相關任務，只能見機行事、見縫插針。這些因素交織在一起，形成一個游戲公司在草創階段的常見的混沌狀態。對第一次開發游戲的人們來說，他們所需要克服的問題，僅僅用“挑戰”這個詞來形容也許是太輕描淡寫了。

      到了第二代（Age of Empires II : The Age of Kings），就容易多了，雖然你當時也許并沒有意識到。當你的第一個游戲發售后，你可以得到寶貴的反饋信息，籍此了解自己在什么地方做對了，什么地方做錯了。你對自己的團隊更加熟悉和了解。你也有了一個成熟的引擎，還有一些內部開發的工具，你知道公司的技術實力和局限。特別是從設計師的角度看，你知道在續集里要加上哪些設計要素——那些由于時間和技術原因在第一作中沒能體現出來的原始設想。

      游戲的第三代標志著一個時代的終結。經過前面兩個游戲（如果它們都是很成功的話），你對玩家的口味一清二楚了。不幸的是，很多玩家已經玩過了這兩個游戲，和其增強版或者擴充版，有點膩了，想要一些新鮮口味了。但是如果你膽敢刪除或者修改一些固有的游戲設定，你就會收到另一群玩家的鋪天蓋地的EMAIL抗議，還有在BBS上發動的請愿。所以，到這個時候，原作的任何一個設定，都是拋舍不下的。到了第三作的時候，你的引擎和工具已經漸呈老態，急需開發新的內部引擎或者購買學習新的商用引擎。
這就是我們設計組在《神話時代》項目伊始所面臨的狀況。最令我們捏著一把汗的問題就是：“我們怎么才能超越《帝國時代》？”

      Ensemble Studios的游戲項目從來都是野心勃勃的，而且我們的雄心壯志隨著每個游戲的完成都不斷增長。項目的野心不斷擴張，團隊的規模逐漸壯大。而且我們是在同時多面出擊：我們在開發一個全新的引擎，一個全新的多用戶網上功能，與此同時，我們要開發一個全新的可以超越《帝國時代》的游戲。在這個游戲中，我們將引入新的設計要素，包括神力（God powers）和神獸部隊（myth units），還有更強的單機戰役設定。
在這里我不想老生常談。不斷膨脹的項目野心和有限的資源之間必然的矛盾，市場部對游戲內容的干預，還有人力資源等問題，都不在本文討論范圍之內。我要著重介紹的，是《神話時代》的設計。雖然設計師是Ensemble Studios的靈魂，是由他們掌舵來決定一個游戲的方向，但他們不會把自己的意志強加給其他人。設計師們需要把項目組的勃勃野心控制在可控范圍內，并協調和編程和美工之間的關系。他們需要保證信息反饋的暢通，同時又要小心不能陷入無休止的爭論。

【標題】成功經驗

1、采用復進式設計（Iteration）
Ensemble的基本游戲設計流程是這樣的：早點把可玩的游戲做出來，然后不斷測試調整各項游戲設計要素直到達到最優狀態。幾乎所有的游戲設計要素都經過這個過程。有的設計要素被修改了無數次。而且我們勇于拋棄那些怎么調整也不合適的要素。

《神話時代》中的神力（God Power）是一個很好的例子。在我們紙上作業做出原始設計時，神力和英雄（Hero）是這么設定的：在用戶界面上有一個按鈕，只要隨時一按，英雄就可以在其當前所在地點使用威力強大的神力。這個設定簡單明了！

可是，當我們把這個設計要素在游戲中實現，并開始測試后，我們馬上發現：這個設定實在是太差了！由于神力的威力極為強大，而且只能發生在英雄所在的地點，這就迫使對方集中全部兵力，不惜一切代價在最開始的時候先將英雄干掉，否則后果不堪設想。在這種情況下，英雄成了眾矢之的，每每最先犧牲，反倒像是最弱的。測試的時候這么玩下來，大家最后都嘟嘟囔囔的：“怎么一點英雄的感覺都找不到？”而且，神力是在英雄所在地點發生的，如果是隕石之類，好像英雄自己被砸，形象實在十分不堪。

我們隨即嘗試了幾種改進辦法。一種新的設定是閃電柱（lightning rods），英雄必須使用它來釋放神力。這樣做可以使得英雄不再是眾矢之的，而且神力所作用的地方也不一定是英雄的所在地。但經過測試，人們覺得這個設定沒意思。另一種設定是可以用資源來購買神力，就像在游戲中購買其他武器一樣。經過測試，這個設定也被否決。我們總共試驗了大概10多種不同的設定。

最后，在多次嘗試之后，我們才找到最終的解決方案，也就是玩家最后玩到的設計。英雄和神力脫離關系。英雄被用來消滅神獸部隊（這才能顯示英雄的獨特威力），而神力被轉移到主游戲界面上，且只能一次性使用。這樣神力的重要性和特殊性得到突出。

因為神力是游戲中最重要的游戲要素之一，所以我們在嘗試過六七個不成功的設定后，并不氣餒，還得繼續嘗試下去，直到尋找出合適的設定。每一次新的設定，都需要編寫新的代碼和制作新的美工素材，才能把效果展現出來并測試之。多次拋棄不成功的設定，意味著我們做了很多無用功，很多代碼和美工作品都被拋棄了。但不管怎么說最終我們實現了既定目標：找到了令我們比較滿意的設定。值得強調的是：我們的游戲設計流程也許并不是效率最高的，但它起碼是一種有效的方法。
2、讓每個人都參與游戲性測試（play-test，又稱測玩）
游戲開發界一個令人驚詫的現象是：有多少游戲開發人員是完全依賴外部的游戲測試人員來告訴他們游戲是否好玩，而他們自己是不玩游戲的！來自玩家和專門測試人員的外部反饋信息是十分重要的——特別是在游戲設計的中后階段。但如果僅僅依賴各種外部反饋來設計游戲的話，那么這個游戲將沒有自己的靈魂和個性，成為一團漿糊。在Ensemble，每個開發團隊成員每周至少親自測玩（play-test）游戲一次。這種策略使得游戲開發者和他們所開發的游戲距離更近——如果這個游戲連他們自己都覺得沒有意思，那怎么能夠指望它來征服廣大的玩家呢？公司特為此作出了強制性的規定：規定每天早上和下午或者晚上的多個時間段被是專門的測玩游戲時間。

我們發現這種大規模的組員內部測玩制度有以下幾點好處：測玩使得游戲開發組的每一個成員都對游戲的目前狀態心中有數，使他們感到自己是游戲（和游戲設計過程）的真正主人，有利于找到Bug，并可以幫助確認游戲何時才能令人滿意可以發售了。像前面所提到的神力的設定問題，就是被我們的組員最先發現的。他們經過測玩發現了這個缺陷，然后成群結伙地跑到設計師的辦公室來抗議。如果我們沒有讓組員們測玩，《神話時代》很有可能就包含著這個有缺陷的設定發售了。

3、使設計研討會小型化
在開發《帝國時代》和《帝王時代》（The Age of Kings）的時候，我們曾經讓開發團隊的全體成員都參與游戲設計（起碼是在初始設計階段）。在《帝王時代》的一次漫長的會議中，我們試圖為游戲中的獸群作出一個設定。會上一般是讓每個與會者都發言。一圈下來后再討論。可是幾個發言之后，討論已經自發地變得無法控制，連一圈都輪不下來了。在這種情況下，我們不得不放棄讓所有組員與會的制度，而是只邀請部門頭目（department lead）來開會討論游戲設計。這些部門頭目把各自部門中員工的意見匯總反饋給我們，并代表那些員工在會上討論，最后他們把會上討論的內容向各部門的員工傳達并獲取新的意見和反饋。到了開發《神話時代》時，這種方法也不靈了。因為《神話時代》光部門頭目就有12個左右。這么多人來開會，效率也是很低的。

最后我們將部門頭目列席會議的重點放在了開發任務管理和進度監控上，而不再討論游戲設計的問題。針對游戲設計，我們專門組織了一系列的小型會議。這種會議由4-5個核心人員所參與，其中有一半是游戲設計師。會議專門用來對游戲設計進行自由討論（brainstorming）。游戲中的各種要素，如各文明的特色和優勢、神獸部隊的能力設定、和神力等，都是在這種會議上討論出來的。我們總是盡量把這些設計研討會安排在公司以外的地點，這樣就不會被打擾。由于每個人的日程表都是緊緊的，我們必須很早就預先安排好這些研討會的日期。這樣所有與會者才能有準備，并準時到場。為了避免張揚，我們把這種會議叫成“小寵物會議”（small pets）。這個命名的由來是這樣的：我們把會議上提出的設計要素稱為恩寵[YSHA1]的要素（pet features），使得它們聽起來不那么嚴肅。這樣沒能參加會議的組員們不會太敏感。

雖然不是所有人都能親自參與研討會，但我們力求做到組里每個人都有機會發表自己的看法。為此，我們在會后會將討論的問題和結論向全公司公布。公司里面的每個人都可以向我們提出意見或者建議，我們評估這些反饋，對設計做出必要的修改。這樣，既保證了每個人都有參與權，又能保證我們高效高速地完成游戲設計。
4、利用基于數據的開發工具（Data-driven tools）
我們在《神話時代》設計過程的最初階段就制作了各種基于數據的工具（data-driven tools）。這是一件事半功倍的事情。在最初階段，程序員們費了很多時間和精力去編制這些輔助工具。在那個時候游戲設計師們在焦急地等待著游戲達到可試玩的程度。表面上看，編制這些工具耽誤了游戲的開發進度。但一旦開始測玩，各種工具的威力開始顯現。利用它們，游戲設計師可以直接修改調整游戲內容而無需每次都麻煩程序員了。這樣省卻了大量的時間。舉一個例子：雖然從表面上看《神話時代》有36種神力，但實際上某些神力的內在機制是類似的。程序員只需要編寫一段通用的代碼，通過輸入不同的數據我們就可以實現并測試幾種貌似不同的神力。比如說有一種神力可以用來轉換部隊（switch units）。程序員編寫好代碼后，通過操縱數據，我們設計師就可以毫不費力地把敵人的部隊轉換成一群豬，或者把友方的法老轉換成埃及冥神（Osiris）之子。

當然，在工具上花費太多時間和精力也有其不利的一面。因為首先這些東西是玩家看不到的，你的努力也許并不為人所感激。其次，你可能是在為了設計而犧牲編程。也就是說你占用了寶貴的編程時間，去給設計師提供工具。在《神話時代》開發的最后階段，設計師有他們所需要的一切工具，但一些設計要素卻沒有時間去實現了（沒有編程時間了）。

5、注重戰役（campaign）設計
注：所謂戰役，是指在單機模式下，由故事主線所連接起來的一系列戰役。每一個戰役有不同的場景和目的。戰役之間用過場動畫來描述故事情節。

《帝國時代》和《帝王時代》中的諸多戰役（campaigns）雖然有些樂趣但卻沒有太多閃光的地方，它們是由1到2個設計師獨立完成的，比較單薄。在《神話時代》的計劃階段，我們就決定給單機模式下的戰役設計以足夠的重視，使其成為游戲的招牌賣點。我們新招了幾個員工，并為游戲中的動畫和鏡頭使用著實花費了一些心血。我們還特地跑到好萊塢去使用了一些專業的配音演員。

我們以前從未嘗試過這種史詩性的、著重人物性格刻畫的劇本。我們為此做出了巨大的努力。我們指定了一個故事委員會（story committee）來審核劇本。在游戲開發的最后階段，負責戰役設計的游戲設計師和負責過場動畫的動畫師每天都得進行數次溝通，以保證協調一致。這些努力沒有白費，最終我們完成了一個廣受好評的單機模式下的戰役設計。

1、過于重視設計，設計主導（design driven）的程度太深
由于整個項目是圍繞著設計師們展開的，設計師們是明星，程序員為設計師提供他們想要的工具。最終，設計師們如愿以償地獲得了各種工具（基于數據的工具，如前所述），并利用這些工具來進行設計和調試。但到最后我們意識到：設計師做了很多程序員可以做得更好更快的工作。如果讓程序員來做，可能要比專門編制這些工具更省時省力。

在設計規格書（design specs，又稱設計綱要，是描述游戲設計的文檔）方面，由于我們在以前的項目中，規格書做得過于籠統，導致程序員沒有完全掌握設計師的意圖并實現其設想。我們這次不惜矯枉過正，事無巨細都放到了設計規格書中，導致設計規格書龐大而駁雜，有些內容寫上去之后就從來沒有人閱讀了。我們的設計規格書精確到了什么程度呢？精確到了對scenario editor中各種圖標（icon）的樣式，按鈕（button）的各種狀態和位置等，都做出了詳細的描述。
這么做的后果，就是新進的設計人員只是在很低的層面從事沒有創造性的工作，即完善一本已經很龐大駁雜的設計規格書。他們花費時間精力，去撰寫如“當你按下這個按鈕（button），它應該陷下，直至你松開鼠標，它應該恢復正常的狀態。當按下按鈕時，應該發出一種音效，就像樹枝折斷的聲音……”這樣繁瑣而枯燥的內容。這可真要令他們發瘋！在下一個項目中，我們還會一如既往地重視游戲設計，但我們將把設計提高到一個比較高的層次，不再搞這么復雜的設計規格書了。我們將要充分信賴程序員和美工，讓他們有一定自主性，去補充完成細節。
2、劇本過于宏大
在開發伊始，我們就希望《神話時代》能夠有一個如伊里亞特（荷馬史詩）般宏大感人的劇本。我們也希望游戲中的人物有血有肉，并且能夠相互之間進行交互。一句話，我們需要一個宏大的劇本和海量的對話。雖然Ensemble的設計師們有一些零星的寫作經驗，但沒有任何人有完成如此宏大的劇本的把握。而且我們對過場動畫（用來表現故事主線）的機理也是心中無數。

雖然如此，事情終究是要做的，我們也只好硬著頭皮上陣。劇本經過千辛萬苦編出來了，然后是在全組范圍內征求修改意見。大家紛紛提建議。這個人喜歡這個角色，那個人喜歡那個角色。這劇本修改起來可就困難了。刪改任何一個角色，馬上有人提出抗議。隨便改動一點情節，就會牽一發動全身，對劇本的主線造成損害。最后，我們不得不放棄在全組尋求劇本修改意見的作法，指定了一個2人小組專門負責修改潤色劇本。在將來，我們會在一開始就限定劇本在小范圍之內尋求反饋和修改意見，這樣才能保證我們及時把劇本的各項內容敲定，包括故事的長度、角色數量、情節細節等。

編制這樣宏大的劇本，制作如此眾多的素材，并且按質按量完成，是需要切實的熬出來的經驗的。如果你也正準備開發一個這么大的游戲，并且沒有經驗的話，那我的建議是：把項目各項工作的所需時間乘2，而把項目的預期內容削減一半（角色數量、對話行數、scenario數量等）。

3、大的制作組內部很難達成一致意見
在Ensemble Studios，我們曾力求讓所有組員對游戲設計達成共識。這是我們公司創立之時的指導思想，也是我們的游戲設計流程的根本。當公司只有十幾個人的時候，它曾經十分有效。即使當我們擴張到20多人的時候，把大家聚集起來（我們一般都在一起吃午飯，所以可以利用午飯時間召集會議）討論問題，仍然是行之有效的方法。但當公司繼續擴張，把所有組員聚集起來開會就不是一個很有效的方法了。更為嚴重的是，在很多問題上人一多，意見一多，就形成僵局。很多設計決定，都是各方妥協的結果。這種妥協，產生的是各方都不太滿意但又都湊合同意這平庸化的設計。用我們的話來說，就是“和稀泥式設計”。

我們不得不改變了策略。設計部門就游戲設計向所有組員收集反饋，然后分析整理，做出決策。但是，在項目中途改變人們的既成習慣是不容易的。很多人抗議，說他們提供的反饋意見沒有得到重視，被黑洞吞噬掉了！這迫使我們制定新的制度，我們要將反饋信息的分析和決策過程整個記載下來，并將其用Email傳達給所有組員。但是我們馬上又陷入另一個怪圈：當你在Email里為一項設計決定做出解釋后，馬上收到5封Email不同意你的邏輯和結論，并要求回復。

最終我們忍無可忍了！設計師們只能有兩個選擇：做他們應該做的事情——完成游戲設計；或者陷入永無休止的爭論中，解釋并捍衛每一項設計決策。

雖然如此，我們現在仍然認為：項目組的大小是一個變量。它的變化將影響到如何在組員中達成共識。項目組大的，達成共識比較困難。但設計部門還是應該最大程度上和所有組員交流并獲得共識。在《神話時代》開發后期所采用的“小型設計研討會”（前面介紹過），比較有效，我們將把它更正規化制度化起來，應用到我們以后的項目中。

4、標新立異，多新多異？
開發續作，挑戰很多。其中一個人所共知的困難是：你必須保留前作中受到好評的要素，同時還必須提供一些新的要素，使得新游戲有別于舊游戲（否則玩家為什么要買新的游戲？）。《神話時代》的前作《帝國時代》系列是非常復雜的游戲。我們知道我們不能簡單地把《帝國時代》拿來，在它上面簡單附加一些新的功能。我們得有所取舍，進行深層次的改動和改進，這樣《神話時代》才能脫穎而出。對這個問題，大家有足夠的認識。但每個人對“改動”的理解，卻又是不一樣的。有的人主張只進行小的改動，比如把《帝國時代》中的騎士改成牛頭馬面。有的人則主張進行傷筋動骨的大改動。理解的不一致，導致后面設計工作中的爭論。

比如，我們對游戲中的人口模型進行了數次改動。最初的設計中，我們去除了《帝國時代》中的房子的功能。一些組員認為這個改動太大了，《帝國時代》的玩家們會不滿意。而另一些人則認為改動還太小，僅僅去除房子還不夠，他們提議做更多的改動。

當然，所有這些改動，玩家們最后的反應都是很強烈。他們一方面為新的游戲設計要素鼓掌稱快，另一方面又對哪怕是最微小的刪改提出抗議。例如，在《神話時代》中你不能選擇你方的色彩。雖然是一個和游戲性無關的功能，但很多玩家對此極為不滿。

對于如何使得一個游戲（特別是續作）標新立異卓然不群，并沒有理想的解決方案。現在的游戲都非常復雜，無法在項目一開始的vision statement（游戲總設計目標）中清楚地定義這個游戲是如何“新”和“異”的！我們在今后的項目中，將試圖更早地對這個問題進行探討并達成共識，避免這次出現的這么多不同意見和爭論。
5、未完成的工具
因為我們要采用一種新的引擎，并且沒有任何前作的代碼可以重用，所以我們一開始就很明智地安排了很多時間來開發各種工具。可惜的是，因為這些工具是內部使用的，當其他方面出了問題急需人手時，編寫工具的程序員經常被抽走幫忙。有些工具到最后也沒有完成，而需要使用這些工具的游戲設計師一直無奈地等待到了項目最后。在漫長的等待中，我們覺得與其坐等不如繞過工具做點什么，很多內容就是這樣非常規地被塞到游戲中。我們真是有點象黑客了！一個很好的例子就是scenario中的計算機方的AI。這個部件很晚才完成。當它完成時，游戲設計師們早已在游戲中用scenario triggers制作了模仿計算機方AI的腳本。這種方式不值得提倡，因為使用非常規的方法放入的內容很難修改，不利于我們調整游戲設計（前面提到的復進式設計）。

在未來的項目中，我們（和游戲開發業所有人一樣）需要明確認識到這些工具的重要性和價值，要給予工具足夠的開發時間。另外，我們也應給予那些最終將要和游戲一起推出的，面向玩家的工具以足夠的重視。象這次《神話時代》的scenario編輯器，就很令我們不滿意！