>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

原文出處：How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester

本文是於 2005 年時發表的文章，雖然距今已有三年以上的歷史，但絕對無損這篇文章的價值。同時，本文也與極具創意的優秀獨立遊戲作品《World of Goo》，有非常深的淵源以及關連性存在。

Kyle Gabler、Kyle Gray、Matt Kucic 與 Shalin Shodhan 是四位就讀於卡內基美隆大學 (Carnegie Mellon University) 研究所的學生。在 1 個學期的時間內，他們僅僅憑藉著 4 個人的力量，完成了超過 50 個遊戲的原型 (Prototype)！同時他們也設置了一個名為 Experimental Gameplay Project 的網站發表他們所製作的各款遊戲原型；其中最受歡迎的遊戲之一，就是由 Kyle Gabler 所製作的《Tower of Goo》，而這個遊戲原型也正是《World of Goo》的前身作品！

為了達到 1 個學期之內完成 50 款遊戲原型作品這項近似於不可理喻且不可思議的目標，他們將自己鎖在房間內，遵循著以下三項規則進行開發工作：

1. 每個遊戲必須在 7 天以內完成。

2. 每個遊戲必須從頭到尾以 1 人之力完成。

3. 每個遊戲必須立基於一般常見的主題，例如「重力」、「植物」或「群聚生物」等等。

7 天，1 人，以及 1 個主題，製作成為一個遊戲原型作品。許多人好奇他們是如何在這麼短的時間內完成一款遊戲原型作品？又是如何能夠維持上述規則與紀律，長達一整個學期之久？在此，四位作者共同將這段過程中所學習到的各種寶貴知識，包括正確以及不可行的嘗試經驗沈澱整理之後，分為準備、設計、開發以及遊戲性四個項目，一一闡述如下：

準備：敏捷，是一種意向的狀態

敏捷式原型開發 (Rapid Prototyping)，不只是前置開發時期的有用工具，同時也可以是一種生活方式。從思維層面出發，首先要使自己的心理狀態合乎「敏捷」的原則，才能夠真正成為一位敏捷式的原型開發者。首先，第一步就是要樂於擁抱失敗的可能性。

優秀的原型開發者能夠瞭解，失敗是一件可以接受的事情！而那也正是建立原型的目標，所以請大膽地放手去做吧！萬一最終真的失敗了，也能夠從其中的過程學習到某些具有價值的經驗，並且唯有藉由擁抱失敗的可能性，才有可能得到有所回報的實驗結果。在 Gray 所製作的《Mime After Mime》與《A Mime to Kill》中，很大膽地只使用位置性音源 (Positional Audio) 做為遊戲性 (Gameplay) 的來源；雖然這兩個遊戲是全然失敗的作品，但也充分證明了僅有音源遊戲性的遊戲設計概念，是一項不可行的作法。

堅持實行極短的開發週期，是另外一項快速開發的訣竅。開發者們似乎會很自然地說：「嘿，既然我們在 1 週內完成了一個很棒的遊戲，那麼如果我們花費 2 週的時間進行開發，我們將會得到一個 2 倍優秀的遊戲作品！」事實上，他們發現一般來說，任何遊戲性都能夠有效地在一週內完成原型建置；額外的投入時間，總是會傾向於產生功效遞減的結果。舉例來說，有些原型僅僅花費一個晚上的時間組裝完成，另外有些原型則使用了額外的一兩週時間，而令人意外的是，每個原型所花費的時間，與其最終獲得的成功程度，並沒有相互關連性存在。

在他們所製作出的成功遊戲原型中，多數都是出自於特定的主題，他們曾經探索過的主題包括了「重力」、「彈簧」、「演化」、「聲音」、「植物」與「平衡」等等。不知為何，當有限制存在的時候，反而會更易於產生創意。另外，與團隊成員同時進行某個特定主題的原型開發，某種程度上也能夠避免著力於太過顯而易見的遊戲性，迫使所有人都必須接受挑戰，探索在這個主題下的所有遊戲性的可能性。如果缺少了穩固明確的主題限制，遊戲將會花費更多的時間創造，同時也會減損團隊的方向目標，以及那種使他們能夠擠壓出最後一滴創造能力的友善競爭感。

每一位團隊成員都必須能夠獨立面對並且負責遊戲開發的所有面向，包含程式、美術、聲音以及其他所有將成為最終成品的必需品。但是個人的才能並不代表一切，團隊成員必須體認到對於這種形式的開發方式來說，「設計」才是至高無上的準則，而包括程式、美術與所有其他的東西在內，都只是為了服務最終的設計結果而存在。一位不具備這種思維的優秀工程師，將不會比完全瞭解這項關鍵要點的平庸工程師來得更為成功。

當團隊建立完成後，他們就開始停止與其他成員一起工作。「啥？這樣還算是團隊嗎？」聽起來或許有些奇怪，但是四個人分頭並進，同時開發四個遊戲原型的「不協同合作」方式有許多益處，像是減少風險（四個成品中至少會有一、二個成功的結果）、友善競爭感、更廣闊的主題探索（避免設計出與別人相同的遊戲性），以及相互分享彼此所習得的知識。在每個原型開發週期的起始和最終階段，團隊合作是最具有價值的期間，而當進入開發期之後，與其他成員一起工作只會造成分心，而無法產生良好的正面效應。

設計：創意以及腦力激盪之謎

A great idea takes a split second to happen, but waiting for that lightning to strike can be excruciating.

一個偉大的點子或許能夠在須臾間誕生，然而等待那個被閃電擊中的時刻，卻會使人備受痛苦與折磨。各位應該都聽過「腦力激盪」(Brainstorming) 這項引導創意思考的團體活動吧！他們曾排定腦力激盪的會議，嘗試過各種不同的創意發想方法，最後在他們開發出來的全部遊戲裡，沒有任何一個作品是出自於團體腦力激盪議程所得出的成果，這實在是一項相當令人挫敗且震驚的結論。經過許多次的研究後，他們終於發現了一個事實：「你就是無法為創意安排時程。」(You just cannot schedule creativity.) 你不能夠說：「嘿，我們的計畫是在 4:15 時開始腦力激盪，然後到了 5:00 我們就能得到 4 個超殺的絕妙點子，然後就可以開始動手了！」不過，腦力激盪至少能夠使團隊開始進行思考。

做為腦力激盪方式的替代方案，他們發現蒐集美術與音樂材料，特別有助於創造出具有情感的目標。以《Tower of Goo》為例，這個遊戲背後的想法，源自於當 Gabler 聽完了《Tango Apasionado》（電影《春光乍現》的主題曲）曲目後，在回家的路上，想像在某一個小鎮裡，當太陽下山時，鎮上的每個人都扛起他們的桌子椅子或其他東西走出房子，為了某個神秘的理由，試圖堆疊建立起一座高聳入雲的巨塔，毫不停歇地向上攀升；然而這些居民並不是很稱職的工程師，所以玩家必須協助他們建造這座高塔。

為了製作出令人喜愛的遊戲，你必須先在腦海中想像玩家們會如何發出「哇！」的讚嘆聲，然後依循此目標由後向前進行各項設計與開發。對於他們多數充滿樂趣且獲得成功的遊戲作品，其實並不是令人感到意外的結果。在最佳的狀況下，甚至在動手開始寫任何一行程式碼之前，就已經能夠明確知道遊戲點子是否穩固，因為他們已經事先在自己的腦袋中運行了模擬與實驗的程序。沒有任何遊戲是偶然或者意外成功的；在見到成品之前，最終的成果早已昭然若揭。

開發：沒有人知道你如何達成，也沒有人會在乎

當你想出了絕妙的遊戲點子後，接下來就是要在很短的時間內開發出遊戲原型。首先，必須從核心機制 (Core Mechanic) 開始著手動工，建造出一個「玩具」；所謂的玩具，應該是核心機制減去任何遊戲層面的實質目標或決定。不論該原型的核心機制是彈簧系統、生物群聚行為、重力機制或者其他系統，最多只會花費幾個小時的時間就能夠建構完畢。玩具並不存在贏或輸的狀態，只是一個有趣且可供玩耍的小玩意兒。先打造出玩具，能夠讓開發者及早確認核心遊戲性的穩固性，並且找出設計層面的潛在問題。

在專案的進行過程中，他們所學到最重要的一課就是：「正確」的解決方案，通常不是最佳的解決方案。策略性地使用偽裝的方法，能夠節省你的時間與金錢，使你能夠更快速地製作遊戲。當你能夠使用可預先製作的貼圖，就不要設置複雜的光影系統；當你能夠使用同樣的效果蒙混過去時，就不要設置樣式辨識系統以分析圖畫；當你能夠延展點陣圖達到相同且快速的效果時，就不要畫出 Spline 曲線或者製作向量圖形函式庫。請大方而且經常性地進行偽裝吧！

剛開始進行遊戲原型開發時，每個人都會有種想要拯救所有東西的渴望：「只要再多花一點點時間與努力，一定能夠把一個本來很糟糕的遊戲，轉變成一個很棒的遊戲成品！」然而事實並非如此。以「彈簧」主題的遊戲原型為例，起先是以一個非常精巧的彈簧系統做為出發點，結果到最後反而無法使這個核心機制轉化成為一個優秀的遊戲。對於原型開發者來說，必須要能夠迅速辨認出已走入死路的遊戲點子，然後斷然地終止花費於其中的損失，繼續朝著下個目標前進。比起花費時間試圖拯救既存的程式碼，保持開發時程的紀律與自發性更為珍貴。

如果原型的遊戲性差勁透頂，就不會有復原的方法，即使放入了許多精美而豐富的內容物，也無法使遊戲獲得救贖。所有的美術、音樂以及衍生物內容，都無法使糟糕的遊戲性最終轉變成一個優秀的遊戲，玩家很快就會發現在精美的圖像與動人的旋律中，其實遊戲本身並沒有深厚的內涵，而不過是虛有其表而已。雖然如此，但遊戲的整體美學仍然很重要；一個經過仔細琢磨的遊戲，的確能夠使一個好遊戲變得更具可玩性，提供給玩家更好的遊戲體驗。

需要再次提醒的是，一位優秀的工程師未必能夠成為一位優秀的敏捷原型開發者。「正確性」或「復用性」的解決方案通常不是敏捷原型開發者所追求的目標。面對每個問題與挑戰，敏捷原型開發者必須要能夠想出一堆解決方案，並且從中選擇最快的方法。如果陷入了過度工程 (Over-Engineering) 的迷思當中，最終成果很容易產出一般性的工具或是技術展示程式，而非一個真正可玩的遊戲。請記得：對於遊戲原型的最終使用者們來說，他們從不會看見你的偉大工程技術，而且他們也不會在乎。

遊戲性：官能領域中的「多汁」樂趣

複雜的東西未必具有樂趣。如果人類能夠在幾千年來，以各種不同的「球與平面」發展成各種球類運動來娛樂我們自己，那麼遊戲開發者或許在遊戲樂趣的嘗試上太過於努力了。想想《Tetris》、《Pac Man》以及其他的經典機臺遊戲，我們完全有可能使用基本的元素製造出豐富的遊戲樂趣。透鏡炫光、凹凸貼圖以及其他新技術很不錯，但它們並不能使遊戲變得更加有趣。請先向你自己證明，以一個簡單的遊戲原型來說，你的核心機制的確具有價值存在；當你確信之後，就可以更進一步地裝扮它，使它變得更加閃亮動人。

在不斷發想、製作以及發表原型作品的過程中，他們發現具有最高可重複遊玩價值的遊戲，是那些擁有某種創造或客製化層面的遊戲，例如像是「用手和雨傘製造出一棵怪樹」、「畫出你的房子」、「建造你的高塔」或是「演化你的變異種族生物」等等遊戲目標。只要提供給玩家獨一無二的「所有權」感覺，就能夠使他們滿足而且想要獲得更多的樂趣。實驗並不意味著複雜。在這項計畫的早期，他們所製作出來的遊戲，往往遠超過這些遊戲應有的複雜度；不只是使用者介面令人困惑，而且按鍵對應至行動的方法也不夠自然直覺。

對於以撰寫程式為樂的人來說，請記得如果沒有遊戲性的目標，遊戲原型就只是個「玩具」，而不是個「遊戲」。所謂的遊戲性目標，可以是任何東西，例如：在 X 時間內蒐集 Y 個元件，或是保持系統的穩定度，或是通過這個空間並且不觸碰任何阻礙物體等等。而他們發現最佳的遊戲目標，是如同《Tower of Goo》中與生俱來的遊戲性，也就是不斷地向上建造高塔而已。

最後，請記得讓遊戲看起來很「多汁」(Juicy)！「多汁」所代表的意思，就是遊戲中接連不斷而且豐富的「使用者回應」(User Feedback) 設計。當你碰觸它的時候，多汁的遊戲會跳動、搖動、噴射並且發出一點聲響，讓玩家感覺它像是活生生的，而且會對於你所做的每件事情做出回應。使用者回應是遊戲中比較微小卻非常關鍵的要素，能夠讓玩家感覺自己是真正掌控著遊戲世界中的一舉一動，並且藉由每次的互動行為，訓練玩家逐漸熟悉遊戲所制訂的種種規則。

進行敏捷式的遊戲原型開發，就像是孕育自己的小孩一樣，或許未必每次都會有美好的結果，但你總是能夠從每次的經驗中學到些什麼新的東西。無論如何，這些過程與結果通常都非常好玩！整理以上四項內容，可以歸納出下列綱要：

準備：敏捷，是一種意向的狀態

• 擁抱失敗的可能性——它會鼓勵開創性的風險承擔

• 堅持實行極短的開發週期（更多的時間不等於更好的品質）

• 限制創意能夠使你渴求更多

• 召集優秀的團隊成員以及一位客觀的顧問——思維與才能同樣重要

• 平行開發以獲得最大化的成果

設計：創意以及腦力激盪之謎

• 正式的腦力激盪程序只有 0% 的成功率

• 聚集概念美術與音樂以創造情感化的目標

• 在你的腦袋中模擬——前置開發你的原型

開發：沒有人知道你如何達成，也沒有人會在乎

• 首先建立玩具

• 在可接受的情況下使用偽裝

• 終止你的損失並且學習如何斷然捨棄

• 著重於遊戲內容物無法救贖差勁的設計

• 整體美學仍然重要——運用有益的美術、聲音與音樂

• 沒有人會在乎你的偉大的工程技術

遊戲性：官能領域中的「多汁」樂趣

• 複雜未必代表樂趣

• 創造出所有權的感覺使玩家想要獲得更多

• 實驗並不意味著複雜

• 朝向具有良好定義的目標建置開發

• 讓它多汁！

在遊戲開發領域中，遊戲原型究竟具有什麼樣的重要性？在投入龐大的資源與人力之前，如果可以預先進行遊戲概念或者核心機制的原型開發，不僅能夠早期驗證遊戲設計的良窳與否，更有機會大幅降低專案開發時期的風險，避免到了專案中後期時才發現「這種玩法根本不有趣」的殘酷事實，而只能夠將已完成的遊戲機制整個砍掉，然後重新來過。由知名遊戲製作人 Will Wright 所主導的遊戲《Spore》，在開發時期中甚至製作了上百款遊戲原型，用以驗證遊戲中的各項設計機制與表現細節。他們也很大方地在遊戲的官方網站上公開其中數款遊戲原型，讓感興趣的玩家自行下載。

之前偶然從 Gamasutra 的檔案庫裡翻出這篇數年前的好文章，我覺得自己實在是非常非常地幸運！由這四位作者共同發起的 Experimental Gameplay Project，竟然能夠在短短的一個學期內，完成超過 50 款遊戲原型。不僅要在極為緊迫的週期內，完成遊戲原型的開發工作，同時又要兼顧忙碌的研究所課業，一般人可能在製作出幾個作品後就會產生放棄的念頭，他們卻能夠保持紀律持之以恆地進行這項專案，絕對是一項相當難能可貴的成就。如果我是教授遊戲開發課程的教師，我一定也會很樂意依循著這樣的模式與原則，指導學生們進行如此具有樂趣與學習效果的遊戲原型開發專案！

對於身處程式設計領域的人來說，即使你不知道如何製作精美的圖片、不懂得如何譜出美妙的音樂，但只要你的腦袋裡裝滿了「做出來應該會很有趣」的遊戲點子，不妨大膽地放手一試吧！「左手只是輔助，工具也只是輔助。」不論你熟悉的開發工具是 OGRE、SDL、Torque 或者自己打造的引擎，條條大路通羅馬，這些工具全都能夠協助我們到達遊戲開發疆土中的美麗境界。而對於美術、設計或具有其他專業的人來說，即使你所擅長的技能並不是程式設計，但只要能夠學習使用 Flash 以及簡單的 ActionScript 語法，同樣能夠以簡單的工具創造出令人讚嘆的遊戲原型。

以前的我，總認為如果想要製作一款遊戲作品，必定要經過非常縝密的規劃與周全的設計，才能夠真正開始著手動工：「一定要有一個非常棒的遊戲引擎，一定要有一個前無古人後無來者的遊戲點子，一定要有一份超級詳盡的遊戲設計文件，一定要……」有許許多多的先決條件存在，一定要滿足了這些條件以後，才能真正開始動手撰寫遊戲。但是過度的顧慮與計畫，最後反而成為理想實踐道路上的最大阻礙。所以與其戒慎恐懼而遲遲不敢跨出一步，不如豪邁地向前跨出步伐，大方擁抱包括失敗在內的一切未知性與可能性吧！

閱讀完這篇文章以後，給了我很大的鼓舞與激勵，我也已經下定決心，準備要開始動手嘗試遊戲原型的實驗開發計畫。你呢？Happy Prototyping！ ：）

猴子靈藥 [Monkey Potion] 2015-08-25 16:41:49