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

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

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

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

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

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

迭代開發的背景

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

隨著電子游戲生產成本增長并且收益逐漸減少，所有新游戲的開發都會面臨更大的金融風險。為使游戲市場規范發展，發行商和工作室已經很少再為不知是否有效的設計元素開綠燈。開發者的關注點從設計的創新性轉變為注重游戲收益，這種做法正逐漸侵蝕電子游戲體驗并且會影響用戶對游戲的信心。

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

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

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

#p#

開發的演變

迭代設計開發方法起源于創造《B-Boy Brawl: Breaking Fingers》的設計過程。

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

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

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

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

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

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

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

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

#p#

預想的模型

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

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

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

#p#

《B-Boy Brawl》早期的樣式

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

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

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

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

#p#

“潤色”后的游戲

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

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

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

#p#

設計方案的最終版本

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

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

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

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

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

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

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

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

#p#

迭代設計開發方法的成型

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

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

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

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

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

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

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

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

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

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

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

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

#p#

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

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

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

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

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

迭代開發過程的適用范圍和適用性

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

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

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

結論

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

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

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

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