行業對下一代開發技術的恐懼隨處可見，它出現在飲水機上、出現在雜志中，人們在游戲開發者大會和《游戲開發者》雜志上討論這個話題。隨著硬件性能的不斷增強，游戲逐漸變得更加昂貴和擬真化，所有的東西都在增加：團隊大小、資產需求、時間投入和需要投資者提供的支持資金。用戶也期望能獲得更好的產品。他們想要更多有著更好功能和技術深度的機制，更密集的多邊形藝術，更高的分辨率紋理，更復雜的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優先完成的目標。
在接受他們客戶的評論時，這些團隊的目標是展示游戲的“垂直分片”(vertical slice)，比如關卡集、完整的可玩機制或協調適當的功能。盡管單次迭代無法完成所有機制，但是團隊可以專注于一項機制。比如，AI角色很難在單次srint內完成。但是該AI角色的單個行為可以在單次sprint中編程、制作動畫、配音和添加到關卡中，最終得到可以被測試的產品。
記住這兩個元素，客戶可以查看產品，了解已經完成的內容、正在進展中的工作以及產品開發進展速度。客戶不需要猜測或盲目信任，他們能夠看到直接的成品，而且往往可以拿起控制器體驗游戲結果，而不是盯著數據表或線框圖。scrum還讓客戶可以更自由地處理多個迭代進程。
如果制作和評估的成品與預期效果有出入，客戶在sprint期間有空間改變項目目標。因為scrum的迭代過程和sprint的短期工作循環，重新確定項目目標幾乎不會導致大量工作和時間的浪費。
瀑布與scrum
瀑布開發給游戲設計師帶來的問題是，只有當對象的所有元素都構建完成并拼接起來時，他們才能從全局來衡量對象的效果和價值。比如，設計師或許需要構建文件中描述的圍繞AI的關卡。參考設計文件，設計師發揮自己的想象和猜測，讓經驗豐富的人給自己提建議和評估成果，最終將關卡提交給美術人員開始構建各種元素。設計師及其主管知道沒有人真正體驗過角色，但是為了保證制作的流暢開展，設計師和關卡美術設計師必須假定AI能夠像預想的那樣發揮作用。但是，盡管工作繼續開展下去，問題依然存在。
假如負責制作角色的程序員發現，文件中陳述的AI機制無法實現，那又如何呢？如果AI運轉良好，但動畫無法讓機制恰當地呈現出來，那又如何呢？如果負責角色的設計師意識到，某個功能并不有趣，那又如何呢？對于這些問題，答案無疑是浪費共更能、浪費精力和時間、浪費開發預算甚至導致團隊成員對項目失去信心。從開發進程的角度來看，最可能出現的結果可總結為：產品質量下降。
瀑布方法產生的另一個問題是，當部門相互趕超，會出現“匆忙和等待”的情況。每個人都在盡可能快地完成自己的任務，然后等待下一個目標。可以想象下，這條裝配線上帶子的移動速度不時發生變化，有時完全停下來，有時以合理的速度和節奏運行，偶爾卻會顯得格外瘋狂。生產過程中這種不規律的節奏對制作人、財務負責人和所有項目參與者都不利。對于設計師來說，它會從根本上影響他們的工作。反復無常的流程會影響產品的功能和質量，尤其是需要融合多種不同元素的功能。
比如，思考下游戲中的恐怖機制，玩家因忽然遭遇邪惡的BOSS而受到驚嚇。這樣的機制需要靠細微之處的設計才能獲得成功，設計團隊需要測試、評估、迭代并完善美術、音效和劇本。這些過程絕對不能在團隊對產品整體情況毫不知情的情況下完成。
瀑布方法總是會讓設計師處在不良的情境中，雖然游戲的篇幅和廣度在項目初期就已經確立，但鏡頭、控制和AI等組成游戲最重要動態的深度卻滲透緩慢，只在接近項目末期時才呈現出完整的形態。
上述情景是項目的典型傳統做法。完成游戲的預制作后，他們投入到設計文件所列舉的機制和資產制作中。根本問題在于，所有人都以為這些機制最終的結果都將同設計文件保持一致。
描述瀑布項目進程的另一種方法是，用曲線來呈現產品已完成功能隨時間的進展情況，如圖3所示。項目時間線右側是提交給發行商的時間，它是固定的。隨著開發的進展，在項目進入至關重要的末期階段時，游戲機制開始呈現出最終的形態和功能。
假如當項目幾近結束，需要提交時，卻發現某些至關重要的成分無法發揮之前計劃的功能，那又怎么辦呢？因為提交時間是固定的，所以出現上述情況要么意味著需要加班加點，要么就是刪除項目中與這些功能相關的所有資產和內容。最終導致的結果是，團隊浪費了資源、資產和經歷，產品質量也受到了影響。
scrum和瀑布的最根本性差別在于，scrum的交流層次是建立在日常協作的基礎上，項目期間各團隊都會開展交流和商討。在上述瀑布范例中，我們的設計師在圍繞AI構建關卡時，使用的是描述角色樣式的文件和自身的想象力。如果在同樣的范例中使用scrum，設計師就能夠同團隊其他成員合作。比如，設計師說出了自己的目標：我需要能夠讓我更容易進行導航迭代的AI。那么，下個階段就是直接通程序員合作實現目標。
設計師和程序員配合，嘗試不同的做法，尋找最佳的技術，以使AI表現出意向行為。如果程序員遇到了障礙，因為設計師也參與到這個過程中，所以他可以直接更換其他解決方案。這種方法并不局限于設計師同程序員間的合作。同樣的方法還可以運用于，設計師同動畫師配合完成對角色移動的設計，或者同環境美術人員配合完成關卡布局工作。最終的結果是能夠得出較好的解決方案，因為scrum確保了所有任務參與者都能夠協調配合。
scrum的想法是，負責制作和執行的人對目標和可能遇到的障礙最為熟悉。對于角色移動所需的動畫的了解，誰能夠超越動畫師？對于如何讓AI移動到特定地點的了解，誰能夠超越程序員呢？
通過明確設計最終目標，它讓設計師和執行功能或關卡的人之間有了交流的機會，同時讓所有參與者都能夠有機會提出實現目標的最佳方法。對于技術和美術的了解，設計師不及程序員和美術人員。我們能夠做的就是確定短期目標，并在數周的時間里配合團隊完成制作，然后對最終結果進行評價，決定是否使用。這種對小片段快速迭代的強調使最終產品和設計師均獲益匪淺。
presubmission quality(from gamaustra)
通過快速迭代，設計師可以在短時間內看到完整的機制。這讓設計師可以迅速發現機制的狀態以及游戲開發的前進方向。對于首席設計師和項目主管來說，他們每數周就能夠了解項目的進展情況，在每月與團隊的交流中就能夠發現他們的努力是否會滿足自己的最終目標。
因為每個獨立的功能都由某個團隊來完成，所以如果被刪減不會影響到之前已經制作完成的內容。在獨立功能被融入整個開發流程之前，對其進行更改不會導致工作時間和精力的浪費。
對于關卡設計師來說，這也意味著他們可以圍繞已證實有效和有趣的機制來構建關卡。設計師隨后可以回到某個關卡或區域，為其添加新功能，但在此之前游戲也可以先期推向市場。
finished functionality(from gamasutra)
專注于單個機制而不是分別制作并相互滲透，這種做法似乎會令人感到害怕。但是，應當注意到是，基礎機制和關卡構建是游戲走出工作室必要條件。額外的功能能夠為游戲填色，但是并非如此至關重要。優先構建最重要的東西而不是將其放在項目末期，意味著內容制作者(游戲邦注：比如設計師)能夠直接圍繞具體功能構建關卡。
此外，在項目早期獲得功能性中心機制意味著，游戲無需依賴于那些可能被刪減的機制，這些內容可以根據客戶的需要進行刪減或擴展。而且，產品擁有者和設計師可以決定哪些功能對游戲最有效，然后將其確定下來，包括更多用來呈現游戲中功能出眾之處的內容。
隨著時間的不斷延長以及未嘗試技術和硬件等更多因素的出現，發行商和投資者面對復雜情況時的思維逐漸從“讓我們來嘗試下!”轉變為“我也不知道該怎么做。”下一代游戲開發的成本會進一步增加，所以出現上述反應是合理的。
如果使用scrum，產品擁有者和發行商可以通過多次迭代來規避風險。如果未曾證實有效的功能或游戲概念確實無法發揮作用，那么團隊可以迅速進行重新評估并做出改變。如果那些功能有非凡的表現，團隊和產品擁有者可以決定專注于游戲的這些層面，甚至讓游戲開發朝全新的方向發展。
而且，隨著開發時間的增加，產品面向的市場也在不斷發生變化。新穎的想法會迅速變得稀松平常，因為其他同類產品會迅速在市場中出現。scrum讓發行商和設計師帶領產品遠離競爭，同時將轉變的風險降到最低。如果產品功能需要發生改變，或者出現游戲項目需要完全取消這種最糟糕的情景，發行商失去的也就是兩周到兩個月的時間，而不是兩個季度或兩年。
總結
在scrum這樣的敏捷方法論中，游戲設計師能夠獲得眾多的好處。項目主管和首席設計師可以定期看到項目的整體進展情況，他們要面對的不是抽象的表格和數據，而是可以親身體驗。對于關卡設計師，他們可以專注于圍繞現有機制構建關卡。如果使用scrum，關卡設計師可以使用完整的機制，也就不用進行無謂的猜想。
scrum可以讓游戲開發中的所有人受益，不只是設計師，因為它可以講“死亡競速”降到最小。發行商和項目主管可以審核每次迭代中的團隊表現，意味著他們可以安全的預測團隊未來的表現情況。
最重要的是，使用敏捷方法論和scrum讓設計師可以同執行功能和技術的人協調配合。對話、提問和交流能夠使問題實現有機的跨部門解決。這樣團隊就可以事先排除可能導致浪費時間和精力的臆斷，通過協作讓游戲開發產生最佳結果。
通過快速迭代，設計師可以在短時間內看到完整的機制。這讓設計師可以迅速發現機制的狀態以及游戲開發的前進方向。對于首席設計師和項目主管來說，他們每數周就能夠了解項目的進展情況，在每月與團隊的交流中就能夠發現他們的努力是否會滿足自己的最終目標。
因為每個獨立的功能都由某個團隊來完成，所以如果被刪減不會影響到之前已經制作完成的內容。在獨立功能被融入整個開發流程之前，對其進行更改不會導致工作時間和精力的浪費。
對于關卡設計師來說，這也意味著他們可以圍繞已證實有效和有趣的機制來構建關卡。設計師隨后可以回到某個關卡或區域，為其添加新功能，但在此之前游戲也可以先期推向市場。
finished functionality(from gamasutra)
專注于單個機制而不是分別制作并相互滲透，這種做法似乎會令人感到害怕。但是，應當注意到是，基礎機制和關卡構建是游戲走出工作室必要條件。額外的功能能夠為游戲填色，但是并非如此至關重要。優先構建最重要的東西而不是將其放在項目末期，意味著內容制作者(游戲邦注：比如設計師)能夠直接圍繞具體功能構建關卡。
此外，在項目早期獲得功能性中心機制意味著，游戲無需依賴于那些可能被刪減的機制，這些內容可以根據客戶的需要進行刪減或擴展。而且，產品擁有者和設計師可以決定哪些功能對游戲最有效，然后將其確定下來，包括更多用來呈現游戲中功能出眾之處的內容。
隨著時間的不斷延長以及未嘗試技術和硬件等更多因素的出現，發行商和投資者面對復雜情況時的思維逐漸從“讓我們來嘗試下!”轉變為“我也不知道該怎么做。”下一代游戲開發的成本會進一步增加，所以出現上述反應是合理的。
如果使用scrum，產品擁有者和發行商可以通過多次迭代來規避風險。如果未曾證實有效的功能或游戲概念確實無法發揮作用，那么團隊可以迅速進行重新評估并做出改變。如果那些功能有非凡的表現，團隊和產品擁有者可以決定專注于游戲的這些層面，甚至讓游戲開發朝全新的方向發展。
而且，隨著開發時間的增加，產品面向的市場也在不斷發生變化。新穎的想法會迅速變得稀松平常，因為其他同類產品會迅速在市場中出現。scrum讓發行商和設計師帶領產品遠離競爭，同時將轉變的風險降到最低。如果產品功能需要發生改變，或者出現游戲項目需要完全取消這種最糟糕的情景，發行商失去的也就是兩周到兩個月的時間，而不是兩個季度或兩年。
總結
在scrum這樣的敏捷方法論中，游戲設計師能夠獲得眾多的好處。項目主管和首席設計師可以定期看到項目的整體進展情況，他們要面對的不是抽象的表格和數據，而是可以親身體驗。對于關卡設計師，他們可以專注于圍繞現有機制構建關卡。如果使用scrum，關卡設計師可以使用完整的機制，也就不用進行無謂的猜想。
scrum可以讓游戲開發中的所有人受益，不只是設計師，因為它可以講“死亡競速”降到最小。發行商和項目主管可以審核每次迭代中的團隊表現，意味著他們可以安全的預測團隊未來的表現情況。
最重要的是，使用敏捷方法論和scrum讓設計師可以同執行功能和技術的人協調配合。對話、提問和交流能夠使問題實現有機的跨部門解決。這樣團隊就可以事先排除可能導致浪費時間和精力的臆斷，通過協作讓游戲開發產生最佳結果。（以上由長沙軟件開發編輯整理于網絡，如想獲知相關信息請訪問www.sjin.cn ）
武漢SEO www.quliangwen.org.cn