行業對下一代開發技術的恐懼隨處可見，它出現在飲水機上、出現在雜誌中，人們在遊戲開發者大會和《遊戲開發者》雜誌上討論這個話題。隨著硬體效能的不斷增強，遊戲逐漸變得更加昂貴和擬真化，所有的東西都在增加：團隊大小、資產需求、時間投入和需要投資者提供的支援資金。使用者也期望能獲得更好的產品。他們想要更多有著更好功能和技術深度的機制，更密集的多邊形藝術，更高的解析度紋理，更復雜的AI以及更多的測試和QA等。
這種對下一代的恐懼不僅限於行業從業者。這種壓力來源於使用者，也在使用者中蔓延。遊戲站點FiringSquad.com說道：“行業內眾多遊戲發行商和開發商都在抱怨開發成本的攀升，主要原因在於需要大幅擴張美術團隊來製作出所有可行的內容。”行業面對的多數問題的本質是他們採用了不當的產品方法論。近百人的團隊還在使用10人團隊的開發方法。我們其實可以更改和替換開發方法。
傳統遊戲開發使用的產品方法論是，花大量前端時間來確定意向功能，通常會同時執行機制和關卡等重要元素，最後進行潤色。這種通常稱為“瀑布”的方法論類似於生產線，前端負責將產品的各個部分拼接起來，後端等待對拼接完成的產品進行潤色。這種等待便會產生問題。設計師和發行商無法得知遊戲的真正感覺，比如他們最初對機制的評估是否準確，或者功能的執行與原計劃是否存在偏差。這樣的因素會影響到產品質量。
有個替代方案可以處理傳統遊戲開發方法論帶來的這些問題。這種產品R&D過程和團隊管理方式稱為“敏捷方法論”。敏捷強調直接將遊戲的可論證迭代融入製作過程中，將最關鍵的元素和功能的迭代優化提前。這種方法還強調了團隊的組成和關係，以及團隊必須計劃和實現專案目標的迴圈。遊戲開發團隊會面對許多挑戰，美術、工程和設計等不同層面面對的挑戰也各不相同，他們需要合作。通向遊戲專案完結的道路也非常漫長，較小的遊戲需要開發1到2年時間，較大的遊戲需要3年或更多的時間。
本文將分析敏捷方法和Scrum方法論，能夠直接處理這些問題，它們可能特別適合於面對下一代主機遊戲開發的綜合性遊戲開發者和設計師。
方法論
瀑布（Waterfall）
多數遊戲設計或遊戲開發書籍對方法論的敘述並不多。作者認為多數開發者使用的都是相同的方法，也就是所謂的“瀑布”。在瀑布方法中，工作持續朝一個方向發展，比如從專案需求或設計階段到製作和執行階段。早期階段的迭代很少，評估的機會並不多。而且，就如同流水一般，但一旦展開工作，就難以顛倒。
在瀑布遊戲開發中，遊戲設計師或設計小組會先編寫遊戲設計檔案，陳述遊戲的許多功能和機制。隨後，設計檔案被分為許多部分，製作人從中找出所需的功能和資產。這些資產和功能元素的需求由參與專案的各個團隊來滿足。
因而，一旦展開瀑布方法，需求會流向動畫、程式設計、關卡藝術、角色美工、QA和FX等。隨後，每個個人或團隊完成一項功能，然後提交成品。比如，設計檔案中的角色被遞交給製作人或專案主管。然後，它會被分解成各個成分：角色的紋理、動畫、被擊中時角色呈現出的效果以及攻擊或空閒時的模樣，最終用AI技術來強化角色。每個部門專注於完成屬於自己的成分，然後執行，直到其完成。
然後，結果會回到設計師手中進行調整，遞交給QA完成測試，提交給關卡設計師放入關卡中，然後回到各部門手中完成漏洞除錯工作。在這個角色的製作過程中，其他個人和團隊正致力於完成他們手中的機制。同一天的時間裡，單個開發者可能需要處理多種不同的機制。這種方法論的本質是逐漸滲透，遊戲的許多機制從0開始，隨著時間漸漸完善。
敏捷
上世紀90年代末期，許多新的軟體開發方法論開始出現，這些方法論來源於從網頁applet開發到系統動力NASA航空等各種團隊。每種方法論都有其自身的優點和缺點，儘管各有不同，但是多數方法論之間都存在許多共同點。
2001年，許多曾參與過這些方法論製作的人在猶他州召開大會。此次大會得出了一箇中心思想體系和一則宣言：
1、一個可執行軟體的價值要高於陳述軟體功能的檔案。
2、與客戶定期合作的價值要高於陳述產品功能的合約。
3、個人解決問題的價值要高於程式或工具。
4、最重要的是，它們的價值隨計劃的進展而改變。
執行凌駕於檔案記錄之上、利用客戶合作以及解決問題和改變的能力，這就是敏捷性。敏捷方法論的中心原則很簡單，但是卻有著豐富的內涵，它可以用於任何複雜的產品開發系統中。
Scrum
隨著敏捷開發使用的普及，出現了各種不同的方法論。有些來源於敏捷，有些是已經被人用過卻從未完全定義或運用到軟體開發中的系統。scrum便是此類方法，這種生產R&D的方法來源於日本汽車和消費電子製造業。從定義上來說，scrum指橄欖球比賽中的一種調遣方法，即隊伍中的每個人都參與到移動球的動作中。
作為一種方法論，這種精神也可以被運用到產品開發中，專案團隊被重新劃分組織成小團隊，這些小團隊密切配合，完成專案的某個具體成分。迭代開發受到重視，專案被劃分成可被呈現、測試和功能評估的“可運載”成分。
scrum的主要原則之一是，團隊中的每個人都參與到過程中。scrum將製作過程分解成短期工作迴圈，稱為sprint。在每個sprint開始時，這個專案團隊確定目標，自我組織進入小scrum團隊。scrum團隊由不同型別的成員組成，包括美術設計師、設計師和程式設計師。每個團隊的目標由專案管理者、製作人和發行人在計劃會議上確定，但團隊可以自行決定實現sprint目標的方法和途徑。一旦進入sprint，團隊就可以完全自行管理他們的日常計劃和任務執行。
熟悉scrum的人經常會提到，專案會因這種方法也受到拖延。對於這種情況，sprint期間各scrum團隊召開每日會議便成了scrum方法的重要成分。會議可以短至5到10分鐘，其目的是確保工作朝著正確的方向、識別過程中遇到的各種障礙以及每日取得的進展能夠被參與專案的所有人所瞭解。這樣的做法會讓團隊成員產生歸屬感，專案進展的透明性也會讓團隊成員明白自己的義務，最終使製作效率得到提升。
因為團隊都是自發組成的，所以日常的評論能夠讓所有團隊鎖定正確的目標，讓所有人都能夠了解產品最真實的現狀，包括外觀和表現。每個sprint完成後，團隊闡述其獲得的成就，他們的產品擁有者或“客戶”（遊戲邦注：比如工作室管理者和發行商）可以對這個過程進行評估。隨後，客戶決定需要在下個sprint優先完成的目標。
visualization of Scrum(from gamasutra)
（圖1：scrum的簡單圖示。遊戲功能被程式設計師、美術人員和設計師分解成獨立的任務，隨後他們在兩週到一個月的時間內完成這些任務。他們既要為自己的任務負責，也要在日常會議中為其他人的任務提出看法。迭代完成後，對結果進行評述，專案總監和發行商根據最新的工作情況決定下一個優先迭代的目標。）
在接受他們客戶的評論時，這些團隊的目標是展示遊戲的“垂直分片”（vertical slice），比如關卡集、完整的可玩機制或協調適當的功能。儘管單次迭代無法完成所有機制，但是團隊可以專注於一項機制。比如，AI角色很難在單次srint內完成。但是該AI角色的單個行為可以在單次sprint中程式設計、製作動畫、配音和新增到關卡中，最終得到可以被測試的產品。
記住這兩個元素，客戶可以檢視產品，瞭解已經完成的內容、正在進展中的工作以及產品開發進展速度。客戶不需要猜測或盲目信任，他們能夠看到直接的成品，而且往往可以拿起控制器體驗遊戲結果，而不是盯著資料表或線框圖。scrum還讓客戶可以更自由地處理多個迭代程式。
如果製作和評估的成品與預期效果有出入，客戶在sprint期間有空間改變專案目標。因為scrum的迭代過程和sprint的短期工作迴圈，重新確定專案目標幾乎不會導致大量工作和時間的浪費。
瀑布與scrum
瀑布開發給遊戲設計師帶來的問題是，只有當物件的所有元素都構建完成並拼接起來時，他們才能從全域性來衡量物件的效果和價值。比如，設計師或許需要構建檔案中描述的圍繞AI的關卡。參考設計檔案，設計師發揮自己的想象和猜測，讓經驗豐富的人給自己提建議和評估成果，最終將關卡提交給美術人員開始構建各種元素。設計師及其主管知道沒有人真正體驗過角色，但是為了保證製作的流暢開展，設計師和關卡美術設計師必須假定AI能夠像預想的那樣發揮作用。但是，儘管工作繼續開展下去，問題依然存在。
假如負責製作角色的程式設計師發現，檔案中陳述的AI機制無法實現，那又如何呢？如果AI運轉良好，但動畫無法讓機制恰當地呈現出來，那又如何呢？如果負責角色的設計師意識到，某個功能並不有趣，那又如何呢？對於這些問題，答案無疑是浪費共更能、浪費精力和時間、浪費開發預算甚至導致團隊成員對專案失去信心。從開發程式的角度來看，最可能出現的結果可總結為：產品質量下降。
瀑布方法產生的另一個問題是，當部門相互趕超，會出現“匆忙和等待”的情況。每個人都在儘可能快地完成自己的任務，然後等待下一個目標。可以想象下，這條裝配線上帶子的移動速度不時發生變化，有時完全停下來，有時以合理的速度和節奏執行，偶爾卻會顯得格外瘋狂。生產過程中這種不規律的節奏對製作人、財務負責人和所有專案參與者都不利。對於設計師來說，它會從根本上影響他們的工作。反覆無常的流程會影響產品的功能和質量，尤其是需要融合多種不同元素的功能。
比如，思考下游戲中的恐怖機制，玩家因忽然遭遇邪惡的BOSS而受到驚嚇。這樣的機制需要靠細微之處的設計才能獲得成功，設計團隊需要測試、評估、迭代並完善美術、音效和劇本。這些過程絕對不能在團隊對產品整體情況毫不知情的情況下完成。
瀑布方法總是會讓設計師處在不良的情境中，雖然遊戲的篇幅和廣度在專案初期就已經確立，但鏡頭、控制和AI等組成遊戲最重要動態的深度卻滲透緩慢，只在接近專案末期時才呈現出完整的形態。在圖2中，我們可以看到某個範例專案，機制被提交到各個部門手中，他們分別處理屬於自己的片段，意圖在幾個月後呈現出完整的產品。
圖2：使用瀑布方法的範例專案的8個月開發程式(from gamasutra)
上述情景是專案的典型傳統做法。完成遊戲的預製作後，他們投入到設計檔案所列舉的機制和資產製作中。根本問題在於，所有人都以為這些機制最終的結果都將同設計檔案保持一致。
描述瀑布專案程式的另一種方法是，用曲線來呈現產品已完成功能隨時間的進展情況，如圖3所示。專案時間線右側是提交給發行商的時間，它是固定的。隨著開發的進展，在專案進入至關重要的末期階段時，遊戲機制開始呈現出最終的形態和功能。
圖3：完成功能隨時間變化圖(from gamaustra)
假如當專案幾近結束，需要提交時，卻發現某些至關重要的成分無法發揮之前計劃的功能，那又怎麼辦呢？因為提交時間是固定的，所以出現上述情況要麼意味著需要加班加點，要麼就是刪除專案中與這些功能相關的所有資產和內容。最終導致的結果是，團隊浪費了資源、資產和經歷，產品質量也受到了影響。
scrum和瀑布的最根本性差別在於，scrum的交流層次是建立在日常協作的基礎上，專案期間各團隊都會開展交流和商討。在上述瀑布範例中，我們的設計師在圍繞AI構建關卡時，使用的是描述角色樣式的檔案和自身的想象力。如果在同樣的範例中使用scrum，設計師就能夠同團隊其他成員合作。比如，設計師說出了自己的目標：我需要能夠讓我更容易進行導航迭代的AI。那麼，下個階段就是直接通程式設計師合作實現目標。
設計師和程式設計師配合，嘗試不同的做法，尋找最佳的技術，以使AI表現出意向行為。如果程式設計師遇到了障礙，因為設計師也參與到這個過程中，所以他可以直接更換其他解決方案。這種方法並不侷限於設計師同程式設計師間的合作。同樣的方法還可以運用於，設計師同動畫師配合完成對角色移動的設計，或者同環境美術人員配合完成關卡布局工作。最終的結果是能夠得出較好的解決方案，因為scrum確保了所有任務參與者都能夠協調配合。
scrum的想法是，負責製作和執行的人對目標和可能遇到的障礙最為熟悉。對於角色移動所需的動畫的瞭解，誰能夠超越動畫師？對於如何讓AI移動到特定地點的瞭解，誰能夠超越程式設計師呢？
通過明確設計最終目標，它讓設計師和執行功能或關卡的人之間有了交流的機會，同時讓所有參與者都能夠有機會提出實現目標的最佳方法。對於技術和美術的瞭解，設計師不及程式設計師和美術人員。我們能夠做的就是確定短期目標，並在數週的時間裡配合團隊完成製作，然後對最終結果進行評價，決定是否使用。這種對小片段快速迭代的強調使最終產品和設計師均獲益匪淺。
presubmission quality(from gamaustra)
通過快速迭代，設計師可以在短時間內看到完整的機制。這讓設計師可以迅速發現機制的狀態以及遊戲開發的前進方向。對於首席設計師和專案主管來說，他們每數週就能夠了解專案的進展情況，在每月與團隊的交流中就能夠發現他們的努力是否會滿足自己的最終目標。
因為每個獨立的功能都由某個團隊來完成，所以如果被刪減不會影響到之前已經制作完成的內容。在獨立功能被融入整個開發流程之前，對其進行更改不會導致工作時間和精力的浪費。
對於關卡設計師來說，這也意味著他們可以圍繞已證實有效和有趣的機制來構建關卡。設計師隨後可以回到某個關卡或區域，為其新增新功能，但在此之前遊戲也可以先期推向市場。
finished functionality(from gamasutra)
專注於單個機制而不是分別製作並相互滲透，這種做法似乎會令人感到害怕。但是，應當注意到是，基礎機制和關卡構建是遊戲走出工作室必要條件。額外的功能能夠為遊戲填色，但是並非如此至關重要。優先構建最重要的東西而不是將其放在專案末期，意味著內容製作者（遊戲邦注：比如設計師）能夠直接圍繞具體功能構建關卡。
此外，在專案早期獲得功能性中心機制意味著，遊戲無需依賴於那些可能被刪減的機制，這些內容可以根據客戶的需要進行刪減或擴充套件。而且，產品擁有者和設計師可以決定哪些功能對遊戲最有效，然後將其確定下來，包括更多用來呈現遊戲中功能出眾之處的內容。
隨著時間的不斷延長以及未嘗試技術和硬體等更多因素的出現，發行商和投資者面對複雜情況時的思維逐漸從“讓我們來嘗試下！”轉變為“我也不知道該怎麼做。”下一代遊戲開發的成本會進一步增加，所以出現上述反應是合理的。
如果使用scrum，產品擁有者和發行商可以通過多次迭代來規避風險。如果未曾證實有效的功能或遊戲概念確實無法發揮作用，那麼團隊可以迅速進行重新評估並做出改變。如果那些功能有非凡的表現，團隊和產品擁有者可以決定專注於遊戲的這些層面，甚至讓遊戲開發朝全新的方向發展。
而且，隨著開發時間的增加，產品面向的市場也在不斷髮生變化。新穎的想法會迅速變得稀鬆平常，因為其他同類產品會迅速在市場中出現。scrum讓發行商和設計師帶領產品遠離競爭，同時將轉變的風險降到最低。如果產品功能需要發生改變，或者出現遊戲專案需要完全取消這種最糟糕的情景，發行商失去的也就是兩週到兩個月的時間，而不是兩個季度或兩年。
總結
在scrum這樣的敏捷方法論中，遊戲設計師能夠獲得眾多的好處。專案主管和首席設計師可以定期看到專案的整體進展情況，他們要面對的不是抽象的表格和資料，而是可以親身體驗。對於關卡設計師，他們可以專注於圍繞現有機制構建關卡。如果使用scrum，關卡設計師可以使用完整的機制，也就不用進行無謂的猜想。
scrum可以讓遊戲開發中的所有人受益，不只是設計師，因為它可以講“死亡競速”降到最小。發行商和專案主管可以稽核每次迭代中的團隊表現，意味著他們可以安全的預測團隊未來的表現情況。
最重要的是，使用敏捷方法論和scrum讓設計師可以同執行功能和技術的人協調配合。對話、提問和交流能夠使問題實現有機的跨部門解決。這樣團隊就可以事先排除可能導致浪費時間和精力的臆斷，通過協作讓遊戲開發產生最佳結果。
遊戲邦注：本文發稿於2006年6月28日，所涉時間、事件和資料均以此為準。
via：（gamerboom.com