在這篇文章中，我將討論一種可在小型獨特項目中反復使用的游戲創(chuàng)造方法，并描述我們的工作室Mobile Pie在使用這種方法設計iPhone和iPod touch游戲《B-Boy Brawl: Breakin’ Fingers》過程中遇到的成功與失敗。

我會討論我們最初基于傳統(tǒng)線性電子游戲設計的方法及其演變過程，失敗讓我們看清了遇到的問題，知道如何制造出有趣且功能齊全的核心游戲機制，并將這個過程成功應用于其他游戲的開發(fā)中。

在討論電子游戲設計時，我將用上Ian Bogost的單元操作理論，這個理論指出，電子游戲由營造表達某種意圖的整體系統(tǒng)的單元操作構建而成。我們可以做出如下假設，我們用于構建完整系統(tǒng)或電子游戲的方法必須以徹底理解這些單元操作如何互相產生作用以實現(xiàn)預想結果為前提。

當然，將現(xiàn)有系統(tǒng)解構并重新構建較為容易也更為便捷。然而，如果我們想要構建與現(xiàn)有系統(tǒng)不盡相同的全新系統(tǒng)，那么我們就必須選擇能夠相互配合營造預想目標的正確的單元操作（注：以及設計元素），但是這些選擇有一定的技巧并且有時并不符合邏輯性。

我建議，開發(fā)者必須通過重復性開發(fā)過程來創(chuàng)造、測試和潤色獨特的系統(tǒng)，觀察系統(tǒng)的反饋，分離那些有礙于預想目標的元素，將它們替代成那些更為適合的元素，重復這個過程直到實現(xiàn)令人滿意的結局。

以上推薦的過程似乎已為許多老練的電子游戲設計從業(yè)者所熟知，尤其是那些經驗豐富的Agile方法使用者。但是，本篇文章將著重通過總結我們自身項目中的成功和失敗來得出每個階段的最佳做法和不同項目間方法使用的差別。

迭代開發(fā)的背景

長久以來，數字化內容傳播都被認為能夠將行業(yè)從巨額經費和實體零售瓶頸中解救出來。盡管游戲概念和開發(fā)硬件限制可能阻礙到某些開發(fā)行為，但PC和蘋果App Store二者都能夠讓小型開發(fā)團隊自由開發(fā)商業(yè)化的獨特游戲，涌現(xiàn)出類似于《Zen Bound》和《World of Goo》的有趣游戲體驗以及成千上萬個失敗作品。

隨著電子游戲生產成本增長并且收益逐漸減少，所有新游戲的開發(fā)都會面臨更大的金融風險。為使游戲市場規(guī)范發(fā)展，發(fā)行商和工作室已經很少再為不知是否有效的設計元素開綠燈。開發(fā)者的關注點從設計的創(chuàng)新性轉變?yōu)樽⒅赜螒蚴找妫@種做法正逐漸侵蝕電子游戲體驗并且會影響用戶對游戲的信心。

巨額預算和微薄利潤也帶來了一種嚴格的微管理文化，主要體現(xiàn)在緊湊的項目開發(fā)日程安排，以及對“計劃性設計”方式的高度依賴，它將市場營銷意圖和風險規(guī)避設計手法融為一體，使游戲創(chuàng)意性與商業(yè)性合二為一。

雖然大型游戲發(fā)行公司可能更喜歡采取上述方式，小型獨立開發(fā)商卻因發(fā)布某些吸引眼球但與商業(yè)化游戲差異過大的游戲而損失慘重。

這些失敗部分歸咎于開發(fā)方法，業(yè)界過于信賴大型工作室的產品開發(fā)思想體系。依我在Mobile Pie的經驗來看，將優(yōu)秀的游戲想法在設計初期便交由小型團隊負責會讓他們處于危險的境地，因為時間安排會讓游戲的質量大打折扣。

#p#

開發(fā)的演變

迭代設計開發(fā)方法起源于創(chuàng)造《B-Boy Brawl: Breaking Fingers》的設計過程。

《B-Boy Brawl》的靈感來源于一系列YouTube上的視頻，視頻中的人們把手指當做手臂和腿，在一塊小區(qū)域再現(xiàn)霹靂舞般的動作。視頻最初的目標在于教人們如何重現(xiàn)動作，但是當我們討論起這個概念時，我們形成了一個目標，并催生出了一款游戲。

通過這些早期的討論，我們決定游戲要保持某些非常獨特的設計想法：

1、傳授移動方式。用戶可以用來學習并記住每個獨特的移動方式。

2、炫麗的游戲玩法。游戲讓非游戲玩家看起來很有趣。

3、易用性。用戶可以簡單地學會游戲，無需過多的指導。

4、可適應性。允許用戶自由地以不同的方法來做出相同的移動。

這些想法并沒有記錄下來，但是已經成為游戲項目不可改變的必要元素。我們在執(zhí)行項目的開發(fā)中，這些想法限制了游戲的設計，但我們在無意間修改了設計以及開發(fā)手段。

在開發(fā)過程中，我發(fā)現(xiàn)這些想法中某些內容與其他想法有直接的沖突。從表面上來看，我們或許會發(fā)現(xiàn)易用性正與用戶需要學習移動方式之間有所沖突。而且，以上兩個想法和可適應性有著更深層次的沖突。某個相對合適的機制似乎能提高游戲的易用性，但在測試中我們發(fā)現(xiàn)與之相左的方法反而更好。

#p#

預想的模型

最早我規(guī)劃了兩個游戲原型的概念：其一以按鍵來顯示用戶手指應該放置的位置并以逐漸減少的圓圈來顯示時間；其二用HUD來顯示節(jié)拍以及當前、過去和即將到來的移動。

以上是兩個預想原型的模型，分別是按鍵方法和HUD設計(from gamasutra)

在這兩個原型的基礎上，我們猜想用戶會如何同這兩種方式互動。我們考慮到在游戲中添加按鍵的方法會讓游戲顯得約定俗成且單調，這會破壞炫麗游戲玩法和可適應性這兩個想法。

但是，更為重要的是我們沒有考慮以下問題：在向用戶傳播所需信息方面，這兩種方法的有效性如何以及用戶將會如何解讀這些信息。我們只顧著考慮用戶想要的東西，而忽視了用戶可以使用的東西。

#p#

《B-Boy Brawl》早期的樣式

我們通過討論和文件撰寫來修改設計想法，最終構建了游戲的最初原型，現(xiàn)有的兩個條狀物方向不同，一個顯示的是節(jié)拍，另一個顯示移動。玩過游戲原型之后，開發(fā)團隊對他們的勞動成果感到非常高興。游戲像我們預想和計劃的那樣發(fā)展，當時我們能夠斷言，盡管游戲還略顯粗糙，但是人們會喜歡這款游戲。

《B-Boy Brawl》早期的樣式，它有移動條和韻律條。(from gamasutra)

我們馬上將原型提交給我們的同行，以聽取他們的意見。我們知道游戲并不完美，但是肯定不會很差。看到游戲測試結果，我們感到很震驚。在這個階段，有些人能夠理解游戲機制并樂在其中，但有些用戶甚至都不能明白游戲基本架構，兩類用戶的反應差距懸殊。

公司團隊負責設計和執(zhí)行整個系統(tǒng)，因而能夠理解游戲的各項功能和機制、信息呈現(xiàn)的方式和形式、所呈現(xiàn)信息的內容，以及如何理解信息以做出正確的動作并獲得豐富的體驗。

我們從測試用戶處獲得各種反饋，有些用戶的意見還會有一定的沖突。有些人對游戲大加抱怨，因為他們無法理解游戲玩法。還有些人聲稱，應該制定教程，音樂拍子應該慢些，失敗的條件應該更寬松些，而且他們不知道下一步要把手指放在何處，拍子應該顯得更為形象化。

#p#

“潤色”后的游戲

我們收集眾人的反饋，包括他們口頭闡述的反饋和我們從他們的游戲過程中觀察到的內容。我們構建起全新的原型，再次將上述想法融入其中，讓新用戶來體驗并收集更多的可用反饋，不斷重復這個過程直到我們擁有精致的原型。完成這個過程后，多數用戶都能夠在教程的輔助下明白游戲機制。

經過潤色后的游戲原型，上面仍然有移動和韻律條。隨后，這兩者融合成一個。(from gamasutra)

現(xiàn)在回想起來，這個成功也預示著更大的失敗，在這些設計潤色的過程中，我們通過削弱某些內容來提高游戲的可用性。隨后，又有針對屏幕圖像的反饋意見，聲稱這會讓用戶感到眼花繚亂。我們沒有讓游戲變得更具易用性，反倒使它變得更為復雜。

我們將游戲提供給發(fā)行商或其他愿意與我們合作解決營銷和認證問題的人，我們發(fā)現(xiàn)在此等情況下游戲完全不具有易用性，我們創(chuàng)造出了個復雜的系統(tǒng)，只有通過超長的教程才能夠解釋清楚。

#p#

設計方案的最終版本

意識到這個問題后，我們召開會議討論項目未來的發(fā)展。在一個小時的時間里，我們就發(fā)現(xiàn)了問題的根源所在并制定出了解決方案。我們曲解了測試用戶的反饋，解決的只是游戲所存在問題的表象而不是原因。用戶想要的東西（注：即某些細微的改變）和他們真正需要的東西（注：更容易理解的核心機制）是完全不同的東西。

解決方案很簡單，即重新根據基于按鍵的原型來構建游戲，摒棄我們自己強加在游戲上的設計限制，也就是那些設計想法。

按鍵系統(tǒng)通過已經確立的按鍵圖解來向玩家傳達所需的動作，即按動或觸摸。同時，利用封閉式的圓圈來顯示時間。這些元素是讓電子游戲和用戶間產生預想互動的關鍵元素。

現(xiàn)在，用戶已經不需要學習他們在游戲中用到的移動，核心機制讓玩家跟隨游戲節(jié)奏即可。這種做法弱化了游戲體驗對旁觀者的影響，卻大大提升了產品的易用性和用戶獲得的游戲趣味性。

我們使用新引擎從頭開始創(chuàng)建全新的原型，盡量避免之前犯下的錯誤。現(xiàn)在，我們不將想法強加在產品之上，而是構建、測試、解釋上述解決方案，不斷測試和重新構建，根據用戶的反饋來進行游戲設計。

通過測試找到問題所在后，我們提出了一個解決方案并使用問題追蹤軟件進行記錄。隨后，我們將這種方法用于新的架構中，并對其進行測試。

《B-Boy Brawl》按鍵設計方案的最終版本。其特征包括分數、進度條和粒子效果。(from gamasutra)

在原型開發(fā)過程中，這個方案不斷演變并且變得更為精致，隨后便用來構建和改善內容，產生極具趣味性且易用性良好的產品。

對這些過程的理解使我細致分析了開發(fā)過程的行為，將它們進行分解并組織成設計方法，使得其他人也可以將優(yōu)秀的想法在有限的預算和時間框架內轉別成優(yōu)良的游戲體驗。

#p#

迭代設計開發(fā)方法的成型

這是種有著更為完整、精致并包容所有過程的框架，來源于Mobile Pie成員的經驗和工作方法，并結合了Agile方法論。但是，不可將其視為電子游戲設計的權威方法。

這種設計很大程度上由產品本身推動，而不是使產品受到限制。因而，設計師的目標會更為明確。這種獨特的效果使得這種方法適宜小團隊，如精品獨立工作室或學生團隊，在毫無外界壓力的情況下，他們可以在短期內制造出產品。

下圖顯示迭代設計開發(fā)的各個階段的流程。

迭代設計開發(fā)的各個階段(from gamasutra)

該過程起始是獨特的高層次概念，隨后團隊成員進行討論，羅列出原型中的功能。然后團隊密切配合制作出最初的原型，最好能夠使用游戲目標平臺上的目標技術。

我建議不必過于拘泥于開發(fā)文件，團隊成員間的口頭交流能夠更迅速地構建起原型，當然，這取決于團隊成員的投入程度、可信度和民主作風。

一旦最初的原型確立，迭代設計過程就可以進入“原型調整階段”。該階段的每個循環(huán)都可以視為類似SCRUM Sprint的方法。

該階段的測試過程和反饋的提煉是創(chuàng)造有效迭代的關鍵。你可以選擇將玩家分組測試產品，也可以選擇將游戲提供給同齡人或其他你偶遇的人進行測試。

重點在于，腦中不要有明確的精致度量，你應該觀察用戶及其行為以及他們所說的話。這是因為度量會讓你對系統(tǒng)的功能問題產生預設的想法，但依我的經驗來看，你作為系統(tǒng)的構建者，根本不可能預測到系統(tǒng)中的哪些元素會產生阻礙作用。

對測試中所得反饋的理解是種很高深的技能，其內容足以再寫一篇文章來闡述。但是從常識上來看，傾聽的能力以及對電子游戲功能的理解是非常寶貴的技能。

一旦整個團隊同意原型能夠發(fā)揮其功能時，就必須考慮設計和添加額外的內容了。這個階段時間的長短和復雜性取決于項目的類別。

內容設計并執(zhí)行之后，便進入了“內容調整階段”。根據項目類型的差異，這個階段與“原型調整階段”相比時間可能較長也可能較短，但是所使用的原則與上述相同，即考察內容在核心機制下的功能如何。除非確為必要之舉，否則不要對游戲玩法做過多的改變。

這個階段過后，產品就處于可供測試的狀態(tài)，應該進行QA來修補漏洞，隨后就可以發(fā)布了。

#p#

迭代設計過程中的項目管理

這個方法可用于開發(fā)高質量游戲，但是由于其獨特的效能，如果能夠對項目進行恰當的管理，開發(fā)時間和成本都可以得到控制。

使用這種方法的風險在于，每個調整階段所需的時間不確定。調整階段的每個循環(huán)所耗費的時長并不確定，而且迭代的次數也沒有限定。

但是，為對產品開發(fā)的時間和成本進行控制，就必須在項目開始前商定循環(huán)的次數和時間。

但是，包括內容開發(fā)等其他階段都可以使用傳統(tǒng)的模式進行控制。通過嚴格設定每個迭代階段的時間框架，項目主管可以牢牢把控項目的整體開發(fā)時間和成本。

迭代開發(fā)過程的適用范圍和適用性

盡管這種方法的目標用戶是開發(fā)獨特電子游戲的小型團隊，但也可以用來提升大型主流電子游戲的體驗的質量。在較為大型的項目中，重點可能會有所改變，可能應該更加關注內容。

這種方法還可以被小型團隊用來創(chuàng)造大型項目游戲概念的樣本，他們可以從內容迭代階段的測試中獲得反饋，改善未來內容的設計。

這種方法也可能用來改善多種產品的質量，但是需要根據團隊的類型和預想的結果進行些許改變。

結論

迭代設計開發(fā)可以讓小型但富有天賦的團隊找到正確的方法，以開發(fā)出獨特且富有創(chuàng)意的產品。

在開發(fā)循環(huán)中，它有著相對較大的自由度和靈活性。它還鼓勵團隊成員間在項目開始之處便開展合作，這意味著團隊成為整體，而不是成員獨立完成各個人物。

這個過程在Mobile Pie開發(fā)大量產品的過程中得到調整，還包含了學術性的設計理論和Agile項目管理理論。

我希望這種方法能夠對那些與我們情況相似的開發(fā)商有所幫助，他們可以調整并討論游戲內容，使這種方法進一步演變成為更有效的游戲開發(fā)方法。