行業(yè)對下一代開發(fā)技術(shù)的恐懼隨處可見，它出現(xiàn)在飲水機上、出現(xiàn)在雜志中，人們在游戲開發(fā)者大會和《游戲開發(fā)者》雜志上討論這個話題。隨著硬件性能的不斷增強，游戲逐漸變得更加昂貴和擬真化，所有的東西都在增加：團隊大小、資產(chǎn)需求、時間投入和需要投資者提供的支持資金。用戶也期望能獲得更好的產(chǎn)品。他們想要更多有著更好功能和技術(shù)深度的機制，更密集的多邊形藝術(shù)，更高的分辨率紋理，更復(fù)雜的AI以及更多的測試和QA等。

這種對下一代的恐懼不僅限于行業(yè)從業(yè)者。這種壓力來源于用戶，也在用戶中蔓延。游戲站點FiringSquad.com說道：“行業(yè)內(nèi)眾多游戲發(fā)行商和開發(fā)商都在抱怨開發(fā)成本的攀升，主要原因在于需要大幅擴張美術(shù)團隊來制作出所有可行的內(nèi)容?！毙袠I(yè)面對的多數(shù)問題的本質(zhì)是他們采用了不當(dāng)?shù)漠a(chǎn)品方法論。近百人的團隊還在使用10人團隊的開發(fā)方法。我們其實可以更改和替換開發(fā)方法。

傳統(tǒng)游戲開發(fā)使用的產(chǎn)品方法論是，花大量前端時間來確定意向功能，通常會同時執(zhí)行機制和關(guān)卡等重要元素，最后進行潤色。這種通常稱為“瀑布”的方法論類似于生產(chǎn)線，前端負責(zé)將產(chǎn)品的各個部分拼接起來，后端等待對拼接完成的產(chǎn)品進行潤色。這種等待便會產(chǎn)生問題。設(shè)計師和發(fā)行商無法得知游戲的真正感覺，比如他們最初對機制的評估是否準(zhǔn)確，或者功能的執(zhí)行與原計劃是否存在偏差。這樣的因素會影響到產(chǎn)品質(zhì)量。

有個替代方案可以處理傳統(tǒng)游戲開發(fā)方法論帶來的這些問題。這種產(chǎn)品R&D過程和團隊管理方式稱為“敏捷方法論”。敏捷強調(diào)直接將游戲的可論證迭代融入制作過程中，將最關(guān)鍵的元素和功能的迭代優(yōu)化提前。這種方法還強調(diào)了團隊的組成和關(guān)系，以及團隊必須計劃和實現(xiàn)項目目標(biāo)的循環(huán)。游戲開發(fā)團隊會面對許多挑戰(zhàn)，美術(shù)、工程和設(shè)計等不同層面面對的挑戰(zhàn)也各不相同，他們需要合作。通向游戲項目完結(jié)的道路也非常漫長，較小的游戲需要開發(fā)1到2年時間，較大的游戲需要3年或更多的時間。

本文將分析敏捷方法和Scrum方法論，能夠直接處理這些問題，它們可能特別適合于面對下一代主機游戲開發(fā)的綜合性游戲開發(fā)者和設(shè)計師。

方法論

瀑布（Waterfall）

多數(shù)游戲設(shè)計或游戲開發(fā)書籍對方法論的敘述并不多。作者認為多數(shù)開發(fā)者使用的都是相同的方法，也就是所謂的“瀑布”。在瀑布方法中，工作持續(xù)朝一個方向發(fā)展，比如從項目需求或設(shè)計階段到制作和執(zhí)行階段。早期階段的迭代很少，評估的機會并不多。而且，就如同流水一般，但一旦展開工作，就難以顛倒。

在瀑布游戲開發(fā)中，游戲設(shè)計師或設(shè)計小組會先編寫游戲設(shè)計文件，陳述游戲的許多功能和機制。隨后，設(shè)計文件被分為許多部分，制作人從中找出所需的功能和資產(chǎn)。這些資產(chǎn)和功能元素的需求由參與項目的各個團隊來滿足。

因而，一旦展開瀑布方法，需求會流向動畫、編程、關(guān)卡藝術(shù)、角色美工、QA和FX等。隨后，每個個人或團隊完成一項功能，然后提交成品。比如，設(shè)計文件中的角色被遞交給制作人或項目主管。然后，它會被分解成各個成分：角色的紋理、動畫、被擊中時角色呈現(xiàn)出的效果以及攻擊或空閑時的模樣，最終用AI技術(shù)來強化角色。每個部門專注于完成屬于自己的成分，然后執(zhí)行，直到其完成。

然后，結(jié)果會回到設(shè)計師手中進行調(diào)整，遞交給QA完成測試，提交給關(guān)卡設(shè)計師放入關(guān)卡中，然后回到各部門手中完成漏洞調(diào)試工作。在這個角色的制作過程中，其他個人和團隊正致力于完成他們手中的機制。同一天的時間里，單個開發(fā)者可能需要處理多種不同的機制。這種方法論的本質(zhì)是逐漸滲透，游戲的許多機制從0開始，隨著時間漸漸完善。

敏捷

上世紀(jì)90年代末期，許多新的軟件開發(fā)方法論開始出現(xiàn)，這些方法論來源于從網(wǎng)頁applet開發(fā)到系統(tǒng)動力NASA航空等各種團隊。每種方法論都有其自身的優(yōu)點和缺點，盡管各有不同，但是多數(shù)方法論之間都存在許多共同點。

2001年，許多曾參與過這些方法論制作的人在猶他州召開大會。此次大會得出了一個中心思想體系和一則宣言：

1、一個可運行軟件的價值要高于陳述軟件功能的文件。

2、與客戶定期合作的價值要高于陳述產(chǎn)品功能的合約。

3、個人解決問題的價值要高于進程或工具。

4、最重要的是，它們的價值隨計劃的進展而改變。

執(zhí)行凌駕于文件記錄之上、利用客戶合作以及解決問題和改變的能力，這就是敏捷性。敏捷方法論的中心原則很簡單，但是卻有著豐富的內(nèi)涵，它可以用于任何復(fù)雜的產(chǎn)品開發(fā)系統(tǒng)中。

Scrum

隨著敏捷開發(fā)使用的普及，出現(xiàn)了各種不同的方法論。有些來源于敏捷，有些是已經(jīng)被人用過卻從未完全定義或運用到軟件開發(fā)中的系統(tǒng)。scrum便是此類方法，這種生產(chǎn)R&D的方法來源于日本汽車和消費電子制造業(yè)。從定義上來說，scrum指橄欖球比賽中的一種調(diào)遣方法，即隊伍中的每個人都參與到移動球的動作中。

作為一種方法論，這種精神也可以被運用到產(chǎn)品開發(fā)中，項目團隊被重新劃分組織成小團隊，這些小團隊密切配合，完成項目的某個具體成分。迭代開發(fā)受到重視，項目被劃分成可被呈現(xiàn)、測試和功能評估的“可運載”成分。

scrum的主要原則之一是，團隊中的每個人都參與到過程中。scrum將制作過程分解成短期工作循環(huán)，稱為sprint。在每個sprint開始時，這個項目團隊確定目標(biāo)，自我組織進入小scrum團隊。scrum團隊由不同類型的成員組成，包括美術(shù)設(shè)計師、設(shè)計師和程序員。每個團隊的目標(biāo)由項目管理者、制作人和發(fā)行人在計劃會議上確定，但團隊可以自行決定實現(xiàn)sprint目標(biāo)的方法和途徑。一旦進入sprint，團隊就可以完全自行管理他們的日常計劃和任務(wù)執(zhí)行。

熟悉scrum的人經(jīng)常會提到，項目會因這種方法也受到拖延。對于這種情況，sprint期間各scrum團隊召開每日會議便成了scrum方法的重要成分。會議可以短至5到10分鐘，其目的是確保工作朝著正確的方向、識別過程中遇到的各種障礙以及每日取得的進展能夠被參與項目的所有人所了解。這樣的做法會讓團隊成員產(chǎn)生歸屬感，項目進展的透明性也會讓團隊成員明白自己的義務(wù)，最終使制作效率得到提升。

因為團隊都是自發(fā)組成的，所以日常的評論能夠讓所有團隊鎖定正確的目標(biāo)，讓所有人都能夠了解產(chǎn)品最真實的現(xiàn)狀，包括外觀和表現(xiàn)。每個sprint完成后，團隊闡述其獲得的成就，他們的產(chǎn)品擁有者或“客戶”（游戲邦注：比如工作室管理者和發(fā)行商）可以對這個過程進行評估。隨后，客戶決定需要在下個sprint優(yōu)先完成的目標(biāo)。

visualization of Scrum(from gamasutra)

（圖1：scrum的簡單圖示。游戲功能被程序員、美術(shù)人員和設(shè)計師分解成獨立的任務(wù)，隨后他們在兩周到一個月的時間內(nèi)完成這些任務(wù)。他們既要為自己的任務(wù)負責(zé)，也要在日常會議中為其他人的任務(wù)提出看法。迭代完成后，對結(jié)果進行評述，項目總監(jiān)和發(fā)行商根據(jù)最新的工作情況決定下一個優(yōu)先迭代的目標(biāo)。）

在接受他們客戶的評論時，這些團隊的目標(biāo)是展示游戲的“垂直分片”（vertical slice），比如關(guān)卡集、完整的可玩機制或協(xié)調(diào)適當(dāng)?shù)墓δ?。盡管單次迭代無法完成所有機制，但是團隊可以專注于一項機制。比如，AI角色很難在單次srint內(nèi)完成。但是該AI角色的單個行為可以在單次sprint中編程、制作動畫、配音和添加到關(guān)卡中，最終得到可以被測試的產(chǎn)品。

記住這兩個元素，客戶可以查看產(chǎn)品，了解已經(jīng)完成的內(nèi)容、正在進展中的工作以及產(chǎn)品開發(fā)進展速度?？蛻舨恍枰聹y或盲目信任，他們能夠看到直接的成品，而且往往可以拿起控制器體驗游戲結(jié)果，而不是盯著數(shù)據(jù)表或線框圖。scrum還讓客戶可以更自由地處理多個迭代進程。

如果制作和評估的成品與預(yù)期效果有出入，客戶在sprint期間有空間改變項目目標(biāo)。因為scrum的迭代過程和sprint的短期工作循環(huán)，重新確定項目目標(biāo)幾乎不會導(dǎo)致大量工作和時間的浪費。

瀑布與scrum

瀑布開發(fā)給游戲設(shè)計師帶來的問題是，只有當(dāng)對象的所有元素都構(gòu)建完成并拼接起來時，他們才能從全局來衡量對象的效果和價值。比如，設(shè)計師或許需要構(gòu)建文件中描述的圍繞AI的關(guān)卡。參考設(shè)計文件，設(shè)計師發(fā)揮自己的想象和猜測，讓經(jīng)驗豐富的人給自己提建議和評估成果，最終將關(guān)卡提交給美術(shù)人員開始構(gòu)建各種元素。設(shè)計師及其主管知道沒有人真正體驗過角色，但是為了保證制作的流暢開展，設(shè)計師和關(guān)卡美術(shù)設(shè)計師必須假定AI能夠像預(yù)想的那樣發(fā)揮作用。但是，盡管工作繼續(xù)開展下去，問題依然存在。

假如負責(zé)制作角色的程序員發(fā)現(xiàn)，文件中陳述的AI機制無法實現(xiàn)，那又如何呢？如果AI運轉(zhuǎn)良好，但動畫無法讓機制恰當(dāng)?shù)爻尸F(xiàn)出來，那又如何呢？如果負責(zé)角色的設(shè)計師意識到，某個功能并不有趣，那又如何呢？對于這些問題，答案無疑是浪費共更能、浪費精力和時間、浪費開發(fā)預(yù)算甚至導(dǎo)致團隊成員對項目失去信心。從開發(fā)進程的角度來看，最可能出現(xiàn)的結(jié)果可總結(jié)為：產(chǎn)品質(zhì)量下降。

瀑布方法產(chǎn)生的另一個問題是，當(dāng)部門相互趕超，會出現(xiàn)“匆忙和等待”的情況。每個人都在盡可能快地完成自己的任務(wù)，然后等待下一個目標(biāo)?？梢韵胂笙拢@條裝配線上帶子的移動速度不時發(fā)生變化，有時完全停下來，有時以合理的速度和節(jié)奏運行，偶爾卻會顯得格外瘋狂。生產(chǎn)過程中這種不規(guī)律的節(jié)奏對制作人、財務(wù)負責(zé)人和所有項目參與者都不利。對于設(shè)計師來說，它會從根本上影響他們的工作。反復(fù)無常的流程會影響產(chǎn)品的功能和質(zhì)量，尤其是需要融合多種不同元素的功能。

比如，思考下游戲中的恐怖機制，玩家因忽然遭遇邪惡的BOSS而受到驚嚇。這樣的機制需要靠細微之處的設(shè)計才能獲得成功，設(shè)計團隊需要測試、評估、迭代并完善美術(shù)、音效和劇本。這些過程絕對不能在團隊對產(chǎn)品整體情況毫不知情的情況下完成。

瀑布方法總是會讓設(shè)計師處在不良的情境中，雖然游戲的篇幅和廣度在項目初期就已經(jīng)確立，但鏡頭、控制和AI等組成游戲最重要動態(tài)的深度卻滲透緩慢，只在接近項目末期時才呈現(xiàn)出完整的形態(tài)。在圖2中，我們可以看到某個范例項目，機制被提交到各個部門手中，他們分別處理屬于自己的片段，意圖在幾個月后呈現(xiàn)出完整的產(chǎn)品。

圖2：使用瀑布方法的范例項目的8個月開發(fā)進程(from gamasutra)

上述情景是項目的典型傳統(tǒng)做法。完成游戲的預(yù)制作后，他們投入到設(shè)計文件所列舉的機制和資產(chǎn)制作中。根本問題在于，所有人都以為這些機制最終的結(jié)果都將同設(shè)計文件保持一致。

描述瀑布項目進程的另一種方法是，用曲線來呈現(xiàn)產(chǎn)品已完成功能隨時間的進展情況，如圖3所示。項目時間線右側(cè)是提交給發(fā)行商的時間，它是固定的。隨著開發(fā)的進展，在項目進入至關(guān)重要的末期階段時，游戲機制開始呈現(xiàn)出最終的形態(tài)和功能。

圖3：完成功能隨時間變化圖(from gamaustra)

假如當(dāng)項目幾近結(jié)束，需要提交時，卻發(fā)現(xiàn)某些至關(guān)重要的成分無法發(fā)揮之前計劃的功能，那又怎么辦呢？因為提交時間是固定的，所以出現(xiàn)上述情況要么意味著需要加班加點，要么就是刪除項目中與這些功能相關(guān)的所有資產(chǎn)和內(nèi)容。最終導(dǎo)致的結(jié)果是，團隊浪費了資源、資產(chǎn)和經(jīng)歷，產(chǎn)品質(zhì)量也受到了影響。

scrum和瀑布的最根本性差別在于，scrum的交流層次是建立在日常協(xié)作的基礎(chǔ)上，項目期間各團隊都會開展交流和商討。在上述瀑布范例中，我們的設(shè)計師在圍繞AI構(gòu)建關(guān)卡時，使用的是描述角色樣式的文件和自身的想象力。如果在同樣的范例中使用scrum，設(shè)計師就能夠同團隊其他成員合作。比如，設(shè)計師說出了自己的目標(biāo)：我需要能夠讓我更容易進行導(dǎo)航迭代的AI。那么，下個階段就是直接通程序員合作實現(xiàn)目標(biāo)。

設(shè)計師和程序員配合，嘗試不同的做法，尋找最佳的技術(shù)，以使AI表現(xiàn)出意向行為。如果程序員遇到了障礙，因為設(shè)計師也參與到這個過程中，所以他可以直接更換其他解決方案。這種方法并不局限于設(shè)計師同程序員間的合作。同樣的方法還可以運用于，設(shè)計師同動畫師配合完成對角色移動的設(shè)計，或者同環(huán)境美術(shù)人員配合完成關(guān)卡布局工作。最終的結(jié)果是能夠得出較好的解決方案，因為scrum確保了所有任務(wù)參與者都能夠協(xié)調(diào)配合。

scrum的想法是，負責(zé)制作和執(zhí)行的人對目標(biāo)和可能遇到的障礙最為熟悉。對于角色移動所需的動畫的了解，誰能夠超越動畫師？對于如何讓AI移動到特定地點的了解，誰能夠超越程序員呢？

通過明確設(shè)計最終目標(biāo)，它讓設(shè)計師和執(zhí)行功能或關(guān)卡的人之間有了交流的機會，同時讓所有參與者都能夠有機會提出實現(xiàn)目標(biāo)的最佳方法。對于技術(shù)和美術(shù)的了解，設(shè)計師不及程序員和美術(shù)人員。我們能夠做的就是確定短期目標(biāo)，并在數(shù)周的時間里配合團隊完成制作，然后對最終結(jié)果進行評價，決定是否使用。這種對小片段快速迭代的強調(diào)使最終產(chǎn)品和設(shè)計師均獲益匪淺。

presubmission quality(from gamaustra)

通過快速迭代，設(shè)計師可以在短時間內(nèi)看到完整的機制。這讓設(shè)計師可以迅速發(fā)現(xiàn)機制的狀態(tài)以及游戲開發(fā)的前進方向。對于首席設(shè)計師和項目主管來說，他們每數(shù)周就能夠了解項目的進展情況，在每月與團隊的交流中就能夠發(fā)現(xiàn)他們的努力是否會滿足自己的最終目標(biāo)。

因為每個獨立的功能都由某個團隊來完成，所以如果被刪減不會影響到之前已經(jīng)制作完成的內(nèi)容。在獨立功能被融入整個開發(fā)流程之前，對其進行更改不會導(dǎo)致工作時間和精力的浪費。

對于關(guān)卡設(shè)計師來說，這也意味著他們可以圍繞已證實有效和有趣的機制來構(gòu)建關(guān)卡。設(shè)計師隨后可以回到某個關(guān)卡或區(qū)域，為其添加新功能，但在此之前游戲也可以先期推向市場。

finished functionality(from gamasutra)

專注于單個機制而不是分別制作并相互滲透，這種做法似乎會令人感到害怕。但是，應(yīng)當(dāng)注意到是，基礎(chǔ)機制和關(guān)卡構(gòu)建是游戲走出工作室必要條件。額外的功能能夠為游戲填色，但是并非如此至關(guān)重要。優(yōu)先構(gòu)建最重要的東西而不是將其放在項目末期，意味著內(nèi)容制作者（游戲邦注：比如設(shè)計師）能夠直接圍繞具體功能構(gòu)建關(guān)卡。

此外，在項目早期獲得功能性中心機制意味著，游戲無需依賴于那些可能被刪減的機制，這些內(nèi)容可以根據(jù)客戶的需要進行刪減或擴展。而且，產(chǎn)品擁有者和設(shè)計師可以決定哪些功能對游戲最有效，然后將其確定下來，包括更多用來呈現(xiàn)游戲中功能出眾之處的內(nèi)容。

隨著時間的不斷延長以及未嘗試技術(shù)和硬件等更多因素的出現(xiàn)，發(fā)行商和投資者面對復(fù)雜情況時的思維逐漸從“讓我們來嘗試下！”轉(zhuǎn)變?yōu)椤拔乙膊恢涝撛趺醋觥！毕乱淮螒蜷_發(fā)的成本會進一步增加，所以出現(xiàn)上述反應(yīng)是合理的。

如果使用scrum，產(chǎn)品擁有者和發(fā)行商可以通過多次迭代來規(guī)避風(fēng)險。如果未曾證實有效的功能或游戲概念確實無法發(fā)揮作用，那么團隊可以迅速進行重新評估并做出改變。如果那些功能有非凡的表現(xiàn)，團隊和產(chǎn)品擁有者可以決定專注于游戲的這些層面，甚至讓游戲開發(fā)朝全新的方向發(fā)展。

而且，隨著開發(fā)時間的增加，產(chǎn)品面向的市場也在不斷發(fā)生變化。新穎的想法會迅速變得稀松平常，因為其他同類產(chǎn)品會迅速在市場中出現(xiàn)。scrum讓發(fā)行商和設(shè)計師帶領(lǐng)產(chǎn)品遠離競爭，同時將轉(zhuǎn)變的風(fēng)險降到最低。如果產(chǎn)品功能需要發(fā)生改變，或者出現(xiàn)游戲項目需要完全取消這種最糟糕的情景，發(fā)行商失去的也就是兩周到兩個月的時間，而不是兩個季度或兩年。

總結(jié)

在scrum這樣的敏捷方法論中，游戲設(shè)計師能夠獲得眾多的好處。項目主管和首席設(shè)計師可以定期看到項目的整體進展情況，他們要面對的不是抽象的表格和數(shù)據(jù)，而是可以親身體驗。對于關(guān)卡設(shè)計師，他們可以專注于圍繞現(xiàn)有機制構(gòu)建關(guān)卡。如果使用scrum，關(guān)卡設(shè)計師可以使用完整的機制，也就不用進行無謂的猜想。

scrum可以讓游戲開發(fā)中的所有人受益，不只是設(shè)計師，因為它可以講“死亡競速”降到最小。發(fā)行商和項目主管可以審核每次迭代中的團隊表現(xiàn)，意味著他們可以安全的預(yù)測團隊未來的表現(xiàn)情況。

最重要的是，使用敏捷方法論和scrum讓設(shè)計師可以同執(zhí)行功能和技術(shù)的人協(xié)調(diào)配合。對話、提問和交流能夠使問題實現(xiàn)有機的跨部門解決。這樣團隊就可以事先排除可能導(dǎo)致浪費時間和精力的臆斷，通過協(xié)作讓游戲開發(fā)產(chǎn)生最佳結(jié)果。

游戲邦注：本文發(fā)稿于2006年6月28日，所涉時間、事件和數(shù)據(jù)均以此為準(zhǔn)。（本文為游戲邦/編譯，作者：Rory McGuire ）

Paper Burns: Game Design With Agile Methodologies

Rory McGuire

A fear of next generation development can be seen everywhere; it’s at the water cooler, it’s in magazines, it’s talked about at the Game Developers Conference and in Game Developer Magazine. With increased hardware capacity allowing for ever more expansive and immersive games, everything is growing: Team sizes, asset requirements, person hour investment, and of-course required capital from investors to support it all. Audiences are also expecting more. They want more mechanics with greater functional and technical depth, denser polygon art, higher resolution textures, more complex AI, more testing and quality assurance, and the list goes on.

This fear of the next generation is not confined to the industry. The press has caught, and with them the consumer. Game site FiringSquad.com said, “Game publishers and developers industry-wide are complaining of ballooning development costs, mostly due to art teams that have to grow exponentially to create all the content that’s possible.” A vast majority of the problems facing the industry are deep seated in the very production methodology that is employed. Teams of approximately 100 people are still using methodologies developed for a time when ten people were considered a bloated team. There are alternatives.

Traditional game development uses a production methodology that spends a lot of front-end time, defining intended functionality, often with implementation of important elements such as mechanics and levels waiting around until the mad scramble at the end. The traditional methodology, often called Waterfall, isn’t dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish. The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn’t end up to original specifications. Factors like these are what degrade product quality..

One alternative addresses exactly these problems with traditional game development methodology. It is, a product R&D process and team management style aptly referred to as Agile Methodology. Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives. The challenges faced by game development teams can be numerous and as varied as the divide between the discipline, such as art, engineering and design, that need to work together. The road to the end of game projects is also long; short games are in development for one to two years, bigger titles are running the gamut from a three years, and in exceptional cases up to five or more.

This paper will cover how the Agile method and a specific methodology, Scrum, can directly address these challenges, and perhaps are especially suitable for the complexity game developers, and explicitly designers, face with next-gen console development.

Methodologies

WATERFALL

Most game design or game development books contain very little about methodology. They assume the vast majority of developers use the exact same approach, a method often referred to as Waterfall. In the Waterfall approach work moves sequentially in one direction, such as from a project requirements or design phase to production and implementation. There is very little iteration in the early phases, leaving little opportunity for evaluation. What’s more, much like running water, once the sequence is in progress the process is not easily reversed.

In Waterfall game development, a game designer or group of game designers will first create the game design document, where they lay out many of the features and mechanics. The design document is then broken up into smaller chunks which producers use to extract required functionality and assets. The requirements for these assets and functionality elements span the spectrum of teams involved in the project.

Thus begins the sequence of the Waterfall method, as the requirements “flow down” to animation, programming, level art, character art, QA, FX, etc. This continues as once an individual or team is done with a piece of a feature, they then hand it to another. A character, for example, would begin with the design document and get handed to a producer or a project director. From there, it would be broken out into its components: The mesh and texture of the character, the animation, the effects the character plays when hit, attacking or idling and finally the AI technology which powers the character. Each department focuses on its component, then work to implement it until its bears some semblance of completion.

It’s then moved back to the designer for tuning, handed off to QA for testing, to the level designers to populate in levels, then bounced back to various departments for bug fixes. While this character is being worked on, other individuals and teams are working on their pieces of specific mechanics. In the same day, a single developer may work on pieces of several different mechanics. The nature of the methodology is a percolation, where the game’s many mechanics are brought from the ground up over time.

AGILE

In the late 1990s, a number of new software development methodologies began surfacing, derived from teams ranging from web applet development to systems powering NASA flights. Each methodology possessed its own do’s and don’ts, its own mantras and blasphemies, yet despite their variances, a majority of them had several fundamental things in common.

In 2001, several of the those who had helped spawned the half dozen or so methodologies in use organized a summit in Utah. The result was a central ideology, and a manifesto to go along with it:

A working piece of software had more value than a document that indicated what the software should do.

Regular collaboration with customers was valued more than extensive contracts that outlined the intended usage of a product up front.

Value individuals solving problems rather than processes or tools.

And most importantly, they valued responding to change over following a plan.

Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The central tenets to Agile Methodology were short, but they had large implications, and they were applicable to any complex product development system.

SCRUM

As use of Agile development grew, a number of different methodologies surfaced. Some were derived from Agile, others were systems that had been in use but never fully defined or applied to software development. One such method was Scrum, an approach to product R&D which had its roots in Japanese car and consumer electronics manufacture. By definition, scrum refers to a maneuver in rugby where everyone on the team is involved in an action to move the ball.

As a methodology, the same approach is applied to product development in spirit, where project teams are reorganized into small teams that work closely together on specific components of a project. Iterative development is stressed, with the project divided into components that are “shippable” pieces that can be demonstrated, tested and evaluated for functionality.

One of the principal tenets in Scrum is that everyone on the team is involved in the process. Scrum breaks down production into short work cycles called Sprints. At the beginning of each Sprint, the entire project team meets to create objectives and self-organize into small Scrum teams. The Scrum teams are interdisciplinary, with artists working alongside designers working alongside programmers. Though the goal of each team is determined by project managers, producers and publishers at the planning meetings, the teams ultimately decide the path they will use to achieve their goals for the Sprint. Once into the Sprint, the teams are completely self-managed in their daily planning and execution of tasks.

As recited often by those familiar with Scrum, projects become delayed one day at a time. For this reason, a critical component of Scrum is daily meetings among individual Scrum teams throughout the Sprint. The meetings can be as brief as 5-10 minutes, and are designed to ensure that objectives are on track, any impediments to progress are recognized, and daily accomplishments are seen by everyone involved. The process creates a sense of ownership among every member of the team, and its transparency is designed to create accountability among team members that ultimately boosts productivity.

With the team self organizing, regular reviews keep the team on target and give everyone a full diagnostic of the product in the purest form possible; how it looks and performs. At the completion of every Sprint, the teams conduct reviews that demonstrate their accomplishments, and allow their product owners or “customers,” such as studio managers and publishers, to evaluate progress. The customers can then determine what the priorities are for the next Sprint.

(Graphic01: A simple visualization of Scrum. Game features are broken down into individual tasks by programmers, artists and designers, they then work on these for an iteration of two weeks to a month, accounting for their tasks and to each other in a daily meeting. At the end of the iteration a product review occurs of all work done for that iteration where project directors and publishers can determine how to prioritize the next iteration based on the work done in the latest.)

The goal for these teams when reviewing with their customers is to demonstrate a “vertical slice” of the game, as in a piece of a game such as a single level hub or a completely playable mechanic or a tuned feature. While not all mechanics can be delivered in a single iteration, the individual pieces of them become the vertical slices that teams focus on. For example, an AI character is very difficult to deliver in a single Sprint. Yet a single behavior of that AI character can be fully programmed, animated, have sound attached to it, be deployed in a level, etc., resulting ultimately in something that can be tested.

With these two elements in mind, a customer can look at a product and see exactly what’s been achieved, where it’s going, how fast production is progressing, etc.. A customer does not need to guess or have faith, they can see a direct diagnostic, and often by picking up a controller rather than looking at spreadsheets or wireframes. Scrum also gives customers flexibility from iteration to iteration, just as it does product teams.

Customers have room to redirect project goals between Sprints if what’s been created and evaluated is not living up to expectations. And because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.

Waterfall vs. Scrum

Waterfall development creates a problem for game designers in that no object can be considered complete until all of the dependencies on that object have also been built and moved into the process. For example, a designer may build a level centering around AI which exists solely in documentation. Using the design document as reference, the designer makes a best guess, has it evaluated by seniors, and hands off the level to an artist to begin building the meshes. The designer and his managers know that no one has actually got to experience the character enough to design a level around it, but in order to keep production flowing the designer and level artist will have to assume the AI will work as promised. But while the work continues, the questions remain.

What if the programmer for the character determines that getting the AI mechanic to work as documented isn’t attainable? What if the AI works, but animation can’t get the mechanic to look right? What if the designer responsible for the character realizes that the functionality isn’t fun? Answers in the negative to these questions mean lost functionality, lost person-hours, some portion of the development budget wasted, even a psychological outcome such as loss of faith in the project. Whatever the drawback to the development process, it is best summed up in its most likely outcome: Degraded product quality.

Another substantial problem with Waterfall occurs when departments outpace each other, resulting in a “hurry up and wait” situation. Everyone is going as fast as they can when their piece of the Waterfall is in their lap, then waiting for the next piece when their portion is complete. Imagine an assembly line where the belts moved at variable speeds, sometimes completely stopped, other times moving at a comfortable pace and occasionally blazing. A chronically irregular pace during production has downsides for producers, financial officers and just about everyone involved. For designers it affects their job at a fundamental level. Inconsistent progress can substantially affect the functionality and quality of essentially any features that require different elements to come together.

For instance, consider a horror mechanic in a game, such as a moment when the player is surprised by a vicious boss encounter. A mechanic such as this relies on nuances for its success, and for a design team to test, evaluate and, as is nearly always needed, reiterate, they need finished art, sound and scripting. It certainly can’t be tested in a black box.

Waterfall will always put designers at a disadvantage, simply because while the breadth of a game is established at the project outset, the depth that makes up the game’s most important dynamics such as camera, tuned control, A.I., etc., “percolate” slowly and begin to take final shape only near the end of the project. In Graphic02 we can see a demonstration of this for a sample project, where mechanics have been handed off to various departments who are working on individual pieces, with the intention of delivering the finished product several months down the line.

(Graphic02: Progress at eight month mark on a sample project using Waterfall.)

The scenario is quite typical of a project at eight months. The team has moved out of pre-production and has laid the ground work for all the mechanics and assets outlined in the design document. The fundamental problem occurs in the assumption that all of these mechanics will be delivered and delivered well.

Another way to depict the progression of a Waterfall project is as a curve representing a product’s finished functionality over time, as depicted in Graphic03. Here, the right side of the timeline on the project is the delivery date -submission to a first party, handing over a master to the publisher, etc. It is immovable, the veritable brick wall. As development progresses, the game’s mechanics begin to take final form and function as promised during the critical final phases of the project.

(Graphic03: Finished functionality over time.)

What if as the team nears that brick wall, critical components do not function as promised? The inevitabilities are death marching, or cutting features late in the project along with the all the assets and content dependent on those features. The ultimate result is wasted resources, assets and person-hours, and quite likely, degraded product quality.

The most fundamental difference between Scrum and Waterfall is the level of communication Scrum establishes through daily collaboration towards goals approaching in a span of weeks instead of years. In the Waterfall example, our designer was building a level centering around A.I. using documentation and assumptions on how the character might be delivered. Applying Scrum to the same example, the designer works hand-in-hand with members of the team. For instance, the designer declares the goal: “I need AI to behave in a way that lets me easily iterate on its navigation.” The next step is working directly with programmers.

Together, the designers and programmers investigate options, coming to a consensus on what is the best technology to implement to get the desired behavior. Should the programmers run into impediments, the designer is imbedded in the process and able to have direct input on any alternative solution. The approach is not confined to how designers work with programmers. The same pipeline applies to, for instance, a designer iterating on how a character moves with animators, or how a level is laid out with environment artists. The end result is going to be better solutions, with Scrum ensuring that those who need to be part of the process have input.

Scrum presumes that the people creating and implementing the work are going the most knowledgeable on how to get to a goal and where the landmines are on the way there. Who would know more about the animations needed for a character to move than the animator? Who would know more about how the A.I. moves to a position than a programmer?

By simply declaring the spirit and end goal of the design it opens a dialogue between designers and the individuals implementing the feature or level, which in turn lets all parties involved figure out the best method to achieve the goal. Designers aren’t programmers or artists so presuming we know the best path in all methods of technology and art is foolish. What we can do is determine a short goal and work with the team over a couple of weeks, then review the product and determine if it’s up to snuff. An emphasis on rapid iterations in small pieces benefits the end product and designers immensely.

Through rapid iteration designers are able to watch whole complete mechanics come online in very short order. This lets designers immediately see the status of a mechanic and where the game is heading. For lead designers and project directors, this let’s them get a status check every few weeks on exactly the destination of the project and have a month to month diagnostic on a team’s progress and whether or not they should meet their end goals.

Because a team is delivering entire vertical slices features can be cut without immediate repercussions to previously made content. No dependent features have moved into development which means that scope can be reduced with a clear conscience and without wasted work.

For level designers this also means that their levels can be built around mechanics that are proven and fun in and of themselves. While a designer can return to a level or area at a later time to layer in new functionality as it comes online, the game can ship without them doing so. Moreover if the level is fun with the things the designer has, imagine how it’ll play when the designer get the things he doesn’t have.

It may seem scary to focus on individual mechanics instead of getting everything to bare bones functionally and then letting it percolate. Yet, note that the fundamental mechanics required to ship the game and build levels are the first out of the door, as determined by the product owner. Additional features which add spice to the game but are not critical can be layered in. Building the most important things first instead of receiving them at the very end means that content creators (such as designers) can directly build levels around a specific functionality.

Moreover, attaining functionality central mechanics early means there are no dependencies on mechanics that may need to be cut; scope can always be cut or expanded to suit the customer’s needs. Additionally, product owners and designers can determine what features are working best and then “hammer down” on them, including more content that uses the functionality to showcase it better in the game.

Rapid iterations also minimize an increasing trend in the industry: Risk aversion.

With bloated schedules, more investment and factors such as untried technology and hardware, publishers and investors face far more complications with a mentality of “Let’s try it!” to one of “I don’t know about that.” As costs rise for investors moving into the next generation, this is a perfectly reasonable and expected response.

Using Scrum, product owners and publishers can follow risky goals for a several iterations. If unproven features or game concepts don’t pan out, the team can easily re-evaluate and redirect. If those features are a hit out of the park, the team and the product owner can decide to concentrate on those aspects of the game, and even take the game in a completely new direction.

Also, as development time increases, the product can face a changing market. What may have been a fresh idea can rapidly become stale as competing titles beat your project to market. Scrum let’s publishers and designers separate their title from the competition with very little risk involved. If product features need to be changed, or in a worst case scenario a game has to be completely cancelled, the publisher loses two weeks to two months instead of two quarters to two years.

Conclusion

Within Agile methodologies such as Scrum, game designers gain a tremendous number of benefits. Individuals such as project directors and lead designers can see whole complete pieces at regular intervals, and instead of measuring progress by abstracts they can measure it by putting their thumbs on a controller. For level designers, they are able to build levels that focus around existing mechanics. Using Scrum, those mechanics are online and taken to their fullest extent so the levels the designers do create are part of a complete whole, with a better view of how the mechanic is going to look on disk.

One feature of Scrum that benefits everyone in game development, not just designers, is a minimization of “crunches” and “death marches.” Publishers and project leads are able to get diagnostics on the team’s performance every iteration, meaning they can safely predict how a team will perform. Within a methodology like Waterfall where features percolate, any aspect of the game that isn’t up to snuff has to be “crunched on” to ensure the game is shipped.

Most importantly, using Agile methodologies and Scrum puts designers at the table with the individuals implementing features and technology used to power the game. Conversations are initiated, questions are asked, dialogue and cross department problem solving occurs organically. Assumptions that lead to wasted time and effort are checked at the door, and a collaboration can be reached that gets the best game out in the most efficient way possible. (Source: Gamasutra)