[转]《How to Prototype a Game in Under 7 Days》：如何在七天內完成遊戲原型 >> 猴子靈藥 [Monkey Potion]

Menu Tags Categories



Home



RSS Feed



E-Mail

部落格事務 (14)

遊戲設計閱讀 (13)

遊戲開發閱讀 (13)

遊戲人生 (10)

進階技術 (9)

業界觀察 (8)

學習筆記 (8)

演講分享 (7)

入門概念 (6)

遊戲作品 (6)

生涯規劃 (6)

流程管理 (5)

遊戲程式閱讀 (5)

設計模式 (4)

觀念技巧 (4)

遊戲業界閱讀 (4)

案例分析 (3)

其他書籍 (3)

開發日誌 (3)

市場行銷 (2)

遊戲美術閱讀 (2)

遊戲程式書籍 (1)

遊戲開發書籍 (1)

活動事件 (1)


猴子靈藥 [Monkey Potion]

Search

Send a Message

This message will be pushed to the admin's iPhone instantly.

Name

E-Mail

《How to Prototype a Game in Under 7 Days》：如何在七天內完成遊戲原型
Nov 28th, 2008 @ 12:16 am › 半路
↓ Skip to comments



（圖片來源：www.refreshaustin.org）

原文出處：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 款遊戲原型作品這項近似於不可理喻且不可思議的目標，他們將自己鎖在房間內，遵循著以下三項規則進行開發工作：

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

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

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

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

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

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

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

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

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

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

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

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

Tower of Goo

一個偉大的點子或許能夠在須臾間誕生，然而等待那個被閃電擊中的時刻，卻會使人備受痛苦與折磨。各位應該都聽過「腦力激盪」(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》以及其他的經典機台遊戲，我們完全有可能使用基本的元素製造出豐富的遊戲樂趣。透鏡炫光、凹凸貼圖以及其他新技術很不錯，但它們並不能使遊戲變得更加有趣。請先向你自己證明，以一個簡單的遊戲原型來說，你的核心機制的確具有價值存在；當你確信之後，就可以更進一步地裝扮它，使它變得更加閃亮動人。



On A Rainy Day

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

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

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

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


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



Super Tummy Bubble

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

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

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

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

Categories: 遊戲開發閱讀



Del.icio.us



Digg



Technorati



Magnolia



Newsvine



Reddit

19 Responses

Ricky
38 mos, 1 wk ago

我是以撰寫程式為樂的人哩，但現身處的工作空間快容不下我這一類人。
那一句「每個人都會有種想要拯救所有東西的渴望」更好像是對我說一樣。

幸好有這篇文章激勵一番，感謝大大！



Milo Yip
38 mos, 1 wk ago

我現時做自家引擎/工具的目標也是快速 prototyping。看了這篇文章，更希望快點完成必要的部分，雖然很想做 Graphics ，但已被我拋於腦後了。fast prototyping~ core game mechanics~



EYE
38 mos, 1 wk ago

看完之後我也覺得我顧慮太多了，結果就是計畫一拖再拖。



Wxy
38 mos, 1 wk ago

>不僅要在極為緊迫的週期內，完成遊戲原型的開發工作，同時又要兼顧忙碌的研究所課業

其實對於CMU的Entertainment Technology Center（文中四人就讀的地方）來説，每學期只有兩門課，而其中一門就是Project——一學期製作50個原型，正是他們那個學期提出的Project
也正因爲可以全心全意投入自己喜歡的工作，才可以完成如此驚人的結果。



半路
38 mos, 1 wk ago

@Ricky:
以前我也同樣有過想拯救一切東西的渴望，而現在的我，則會以遊戲的核心機制與遊戲性，做為所有決定的最高指導原則。

請稱呼我半路就好，謝謝。 ^^

@Milo Yip:
我覺得「開發引擎」與「開發遊戲」的樂趣很不相同，不過兩者並沒有孰優孰劣的分別，只要能夠讓自己沈浸其中並且自得其樂，就很足夠了！

我自己是喜歡開發遊戲更勝於引擎～ ：D

@EYE:
你好，

妥善的計畫的確能夠幫助我們得到比較好的成果，但即使是再好的計畫，如果不去「執行」也只是徒勞無功而已。敏捷式原型開發，正是一項非常好的反思，提醒我們不要陷於「過度計畫」的泥沼中而忘記了最初設定的目標。

@Wxy:
原來如此，感謝你的詳細說明！

CMU ETC 真是一個令人非常嚮往的學習環境，讓我想起 Randy Pausch 也曾在 ETC 中任教哩。

感謝各位的迴響。 ：）



shark
38 mos ago

很棒的一篇文章…太久沒來逛啦!看來要常來挖寶.



半路
38 mos ago

@shark:
多謝啦！ XD
有任何意見或想法都歡迎提供～



Percy
38 mos ago

很讚的文章!

很同意
“當有限制存在的時候，反而會更易於產生創意”
“焦點”太多的話到最後就會失去所有”焦點”



半路
38 mos ago

@Percy:
我想只要是曾參與過遊戲專案的開發者，應該都很能認同這句話吧！毫無限制的自由發想，通常無法呈現出良好的創作成果，反之若能達到現實與理想之間的 Compromise，才是真正令人敬佩的遊戲開發者。

謝謝你的回應。 ：）



Eric
37 mos, 3 wks ago

好有趣的文章，真是有用的資訊，感謝唷!



半路
37 mos, 3 wks ago

@Eric:
你好，
這篇文章真的非常讚，謝謝你的迴響喔。 ^^



鮑魚
37 mos, 2 wks ago

開發游戲跟做其他的軟體一樣，都要求講究方法，軟體開發中有敏捷軟體開發方法，游戲開發也應該有它的軟件工程的內涵在里面，這樣做的目的很明確，就是要提高效率，降低成本，提高游戲的品質。



半路
37 mos, 2 wks ago

@鮑魚:
你好，

我想軟體開發的敏捷式開發方法，應該也能夠應用於遊戲開發的領域之中，畢竟遊戲也是軟體領域的分支之一。不論是什麼樣的方法理論，只要能夠提高效率、降低成本並且提高軟體的品質，就是個好方法。 ：D

感謝你的迴響。 ^^



ANdys
36 mos, 3 wks ago

想想過去自己的經驗，不管是程式美術，卻都著墨於技術層面，
希望所有功能都有個好表現，
沒有好好思考真正的遊戲性，
總之，感謝猴子的文章，只有｢受用無窮｣可以形容XD！



半路
36 mos, 3 wks ago

@ANdys:
你好，

我自己身為搞程式技術的人，也常會忽略遊戲性層面的考量。目前仍然在努力試著扭轉腦袋的思維方向。 = =+

感謝支持。 ：）



Btiger
21 mos, 3 wks ago

很好的文章，收藏了，今天才看到这么好的网站。



西瓜玩偶
6 mos, 4 wks ago

文章好棒，mark之，謝謝大大分享！！



半路
6 mos, 3 wks ago

@Btiger & 西瓜玩偶:
好文章總是歷久彌新，謝謝兩位。 ：）



diestr
6 mos, 3 wks ago

EGP 我的最爱~~~~~~~~~~~
老早就知道monkeypotion，不过一直没怎么来逛，惭愧惭愧~~~~~~~~~

Success! Comment added.

› Refresh the page to see your comment.
(If your comment requires moderation it will be added soon.)

Leave A Comment

Name *

Mail (unpublished) *

Website

There was an error posting your comment. Maybe it was too short?

訂閱本篇文章迴響（本文的新迴響將會寄至您的信箱）

Notify me of new posts by email.



Publishing...

Mobile Theme

All content Copyright 猴子靈藥 [Monkey Potion]

Powered by WordPress + WPtouch 1.9.37

通过 Wiz 发布