[转]《How to Prototype a Game in Under 7 Days》:如何在七天內完成遊戲原型 >> 猴子靈藥 [Monkey Potion]
![prototype prototype](https://images.cnblogs.com/cnblogs_com/angelbean/201201/201201241000257974.jpg)
(圖片來源:www.refreshaustin.org)
本文是於 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 倍優秀的遊戲作品!」事實上,他們發現一般來說,任何遊戲性都能夠有效地在一週內完成原型建置;額外的投入時間,總是會傾向於產生功效遞減的結果。舉例來說,有些原型僅僅花費一個晚上的時間組裝完成,另外有些原型則使用了額外的一兩週時間,而令人意外的是,每個原型所花費的時間,與其最終獲得的成功程度,並沒有相互關連性存在。
在他們所製作出的成功遊戲原型中,多數都是出自於特定的主題,他們曾經探索過的主題包括了「重力」、「彈簧」、「演化」、「聲音」、「植物」與「平衡」等等。不知為何,當有限制存在的時候,反而會更易於產生創意。另外,與團隊成員同時進行某個特定主題的原型開發,某種程度上也能夠避免著力於太過顯而易見的遊戲性,迫使所有人都必須接受挑戰,探索在這個主題下的所有遊戲性的可能性。如果缺少了穩固明確的主題限制,遊戲將會花費更多的時間創造,同時也會減損團隊的方向目標,以及那種使他們能夠擠壓出最後一滴創造能力的友善競爭感。
每一位團隊成員都必須能夠獨立面對並且負責遊戲開發的所有面向,包含程式、美術、聲音以及其他所有將成為最終成品的必需品。但是個人的才能並不代表一切,團隊成員必須體認到對於這種形式的開發方式來說,「設計」才是至高無上的準則,而包括程式、美術與所有其他的東西在內,都只是為了服務最終的設計結果而存在。一位不具備這種思維的優秀工程師,將不會比完全瞭解這項關鍵要點的平庸工程師來得更為成功。
當團隊建立完成後,他們就開始停止與其他成員一起工作。「啥?這樣還算是團隊嗎?」聽起來或許有些奇怪,但是四個人分頭並進,同時開發四個遊戲原型的「不協同合作」方式有許多益處,像是減少風險(四個成品中至少會有一、二個成功的結果)、友善競爭感、更廣闊的主題探索(避免設計出與別人相同的遊戲性),以及相互分享彼此所習得的知識。在每個原型開發週期的起始和最終階段,團隊合作是最具有價值的期間,而當進入開發期之後,與其他成員一起工作只會造成分心,而無法產生良好的正面效應。
設計:創意以及腦力激盪之謎
A great idea takes a split second to happen, but waiting for that lightning to strike can be excruciating.
![tower-of-goo tower-of-goo](https://images.cnblogs.com/cnblogs_com/angelbean/201201/201201241000265616.jpg)
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 on-a-rainy-day](https://images.cnblogs.com/cnblogs_com/angelbean/201201/201201241000292844.jpg)
On A Rainy Day
在不斷發想、製作以及發表原型作品的過程中,他們發現具有最高可重複遊玩價值的遊戲,是那些擁有某種創造或客製化層面的遊戲,例如像是「用手和雨傘製造出一棵怪樹」、「畫出你的房子」、「建造你的高塔」或是「演化你的變異種族生物」等等遊戲目標。只要提供給玩家獨一無二的「所有權」感覺,就能夠使他們滿足而且想要獲得更多的樂趣。實驗並不意味著複雜。在這項計畫的早期,他們所製作出來的遊戲,往往遠超過這些遊戲應有的複雜度;不只是使用者介面令人困惑,而且按鍵對應至行動的方法也不夠自然直覺。
對於以撰寫程式為樂的人來說,請記得如果沒有遊戲性的目標,遊戲原型就只是個「玩具」,而不是個「遊戲」。所謂的遊戲性目標,可以是任何東西,例如:在 X 時間內蒐集 Y 個元件,或是保持系統的穩定度,或是通過這個空間並且不觸碰任何阻礙物體等等。而他們發現最佳的遊戲目標,是如同《Tower of Goo》中與生俱來的遊戲性,也就是不斷地向上建造高塔而已。
最後,請記得讓遊戲看起來很「多汁」(Juicy)!「多汁」所代表的意思,就是遊戲中接連不斷而且豐富的「使用者回應」(User Feedback) 設計。當你碰觸它的時候,多汁的遊戲會跳動、搖動、噴射並且發出一點聲響,讓玩家感覺它像是活生生的,而且會對於你所做的每件事情做出回應。使用者回應是遊戲中比較微小卻非常關鍵的要素,能夠讓玩家感覺自己是真正掌控著遊戲世界中的一舉一動,並且藉由每次的互動行為,訓練玩家逐漸熟悉遊戲所制訂的種種規則。
進行敏捷式的遊戲原型開發,就像是孕育自己的小孩一樣,或許未必每次都會有美好的結果,但你總是能夠從每次的經驗中學到些什麼新的東西。無論如何,這些過程與結果通常都非常好玩!整理以上四項內容,可以歸納出下列綱要:
準備:敏捷,是一種意向的狀態
- 擁抱失敗的可能性——它會鼓勵開創性的風險承擔
- 堅持實行極短的開發週期(更多的時間不等於更好的品質)
- 限制創意能夠使你渴求更多
- 召集優秀的團隊成員以及一位客觀的顧問——思維與才能同樣重要
- 平行開發以獲得最大化的成果
設計:創意以及腦力激盪之謎
- 正式的腦力激盪程序只有 0% 的成功率
- 聚集概念美術與音樂以創造情感化的目標
- 在你的腦袋中模擬——前置開發你的原型
開發:沒有人知道你如何達成,也沒有人會在乎
- 首先建立玩具
- 在可接受的情況下使用偽裝
- 終止你的損失並且學習如何斷然捨棄
- 著重於遊戲內容物無法救贖差勁的設計
- 整體美學仍然重要——運用有益的美術、聲音與音樂
- 沒有人會在乎你的偉大的工程技術
遊戲性:官能領域中的「多汁」樂趣
- 複雜未必代表樂趣
- 創造出所有權的感覺使玩家想要獲得更多
- 實驗並不意味著複雜
- 朝向具有良好定義的目標建置開發
- 讓它多汁!
在遊戲開發領域中,遊戲原型究竟具有什麼樣的重要性?在投入龐大的資源與人力之前,如果可以預先進行遊戲概念或者核心機制的原型開發,不僅能夠早期驗證遊戲設計的良窳與否,更有機會大幅降低專案開發時期的風險,避免到了專案中後期時才發現「這種玩法根本不有趣」的殘酷事實,而只能夠將已完成的遊戲機制整個砍掉,然後重新來過。由知名遊戲製作人 Will Wright 所主導的遊戲《Spore》,在開發時期中甚至製作了上百款遊戲原型,用以驗證遊戲中的各項設計機制與表現細節。他們也很大方地在遊戲的官方網站上公開其中數款遊戲原型,讓感興趣的玩家自行下載。
![super-tummy-bubble super-tummy-bubble](https://images.cnblogs.com/cnblogs_com/angelbean/201201/201201241000312264.jpg)
Super Tummy Bubble
之前偶然從 Gamasutra 的檔案庫裡翻出這篇數年前的好文章,我覺得自己實在是非常非常地幸運!由這四位作者共同發起的 Experimental Gameplay Project,竟然能夠在短短的一個學期內,完成超過 50 款遊戲原型。不僅要在極為緊迫的週期內,完成遊戲原型的開發工作,同時又要兼顧忙碌的研究所課業,一般人可能在製作出幾個作品後就會產生放棄的念頭,他們卻能夠保持紀律持之以恆地進行這項專案,絕對是一項相當難能可貴的成就。如果我是教授遊戲開發課程的教師,我一定也會很樂意依循著這樣的模式與原則,指導學生們進行如此具有樂趣與學習效果的遊戲原型開發專案!
對於身處程式設計領域的人來說,即使你不知道如何製作精美的圖片、不懂得如何譜出美妙的音樂,但只要你的腦袋裡裝滿了「做出來應該會很有趣」的遊戲點子,不妨大膽地放手一試吧!「左手只是輔助,工具也只是輔助。」不論你熟悉的開發工具是 OGRE、SDL、Torque 或者自己打造的引擎,條條大路通羅馬,這些工具全都能夠協助我們到達遊戲開發疆土中的美麗境界。而對於美術、設計或具有其他專業的人來說,即使你所擅長的技能並不是程式設計,但只要能夠學習使用 Flash 以及簡單的 ActionScript 語法,同樣能夠以簡單的工具創造出令人讚嘆的遊戲原型。
以前的我,總認為如果想要製作一款遊戲作品,必定要經過非常縝密的規劃與周全的設計,才能夠真正開始著手動工:「一定要有一個非常棒的遊戲引擎,一定要有一個前無古人後無來者的遊戲點子,一定要有一份超級詳盡的遊戲設計文件,一定要……」有許許多多的先決條件存在,一定要滿足了這些條件以後,才能真正開始動手撰寫遊戲。但是過度的顧慮與計畫,最後反而成為理想實踐道路上的最大阻礙。所以與其戒慎恐懼而遲遲不敢跨出一步,不如豪邁地向前跨出步伐,大方擁抱包括失敗在內的一切未知性與可能性吧!
閱讀完這篇文章以後,給了我很大的鼓舞與激勵,我也已經下定決心,準備要開始動手嘗試遊戲原型的實驗開發計畫。你呢?Happy Prototyping! :)
19 Responses
posted on 2012-01-24 10:01 Vision&Details 阅读(459) 评论(0) 编辑 收藏 举报
我是以撰寫程式為樂的人哩,但現身處的工作空間快容不下我這一類人。
那一句「每個人都會有種想要拯救所有東西的渴望」更好像是對我說一樣。
幸好有這篇文章激勵一番,感謝大大!
我現時做自家引擎/工具的目標也是快速 prototyping。看了這篇文章,更希望快點完成必要的部分,雖然很想做 Graphics ,但已被我拋於腦後了。fast prototyping~ core game mechanics~
看完之後我也覺得我顧慮太多了,結果就是計畫一拖再拖。
>不僅要在極為緊迫的週期內,完成遊戲原型的開發工作,同時又要兼顧忙碌的研究所課業
其實對於CMU的Entertainment Technology Center(文中四人就讀的地方)來説,每學期只有兩門課,而其中一門就是Project——一學期製作50個原型,正是他們那個學期提出的Project
也正因爲可以全心全意投入自己喜歡的工作,才可以完成如此驚人的結果。
@Ricky:
以前我也同樣有過想拯救一切東西的渴望,而現在的我,則會以遊戲的核心機制與遊戲性,做為所有決定的最高指導原則。
請稱呼我半路就好,謝謝。 ^^
@Milo Yip:
我覺得「開發引擎」與「開發遊戲」的樂趣很不相同,不過兩者並沒有孰優孰劣的分別,只要能夠讓自己沈浸其中並且自得其樂,就很足夠了!
我自己是喜歡開發遊戲更勝於引擎~ :D
@EYE:
你好,
妥善的計畫的確能夠幫助我們得到比較好的成果,但即使是再好的計畫,如果不去「執行」也只是徒勞無功而已。敏捷式原型開發,正是一項非常好的反思,提醒我們不要陷於「過度計畫」的泥沼中而忘記了最初設定的目標。
@Wxy:
原來如此,感謝你的詳細說明!
CMU ETC 真是一個令人非常嚮往的學習環境,讓我想起 Randy Pausch 也曾在 ETC 中任教哩。
感謝各位的迴響。 :)
很棒的一篇文章…太久沒來逛啦!看來要常來挖寶.
@shark:
多謝啦! XD
有任何意見或想法都歡迎提供~
很讚的文章!
很同意
“當有限制存在的時候,反而會更易於產生創意”
“焦點”太多的話到最後就會失去所有”焦點”
@Percy:
我想只要是曾參與過遊戲專案的開發者,應該都很能認同這句話吧!毫無限制的自由發想,通常無法呈現出良好的創作成果,反之若能達到現實與理想之間的 Compromise,才是真正令人敬佩的遊戲開發者。
謝謝你的回應。 :)
好有趣的文章,真是有用的資訊,感謝唷!
@Eric:
你好,
這篇文章真的非常讚,謝謝你的迴響喔。 ^^
開發游戲跟做其他的軟體一樣,都要求講究方法,軟體開發中有敏捷軟體開發方法,游戲開發也應該有它的軟件工程的內涵在里面,這樣做的目的很明確,就是要提高效率,降低成本,提高游戲的品質。
@鮑魚:
你好,
我想軟體開發的敏捷式開發方法,應該也能夠應用於遊戲開發的領域之中,畢竟遊戲也是軟體領域的分支之一。不論是什麼樣的方法理論,只要能夠提高效率、降低成本並且提高軟體的品質,就是個好方法。 :D
感謝你的迴響。 ^^
想想過去自己的經驗,不管是程式美術,卻都著墨於技術層面,
希望所有功能都有個好表現,
沒有好好思考真正的遊戲性,
總之,感謝猴子的文章,只有「受用無窮」可以形容XD!
@ANdys:
你好,
我自己身為搞程式技術的人,也常會忽略遊戲性層面的考量。目前仍然在努力試著扭轉腦袋的思維方向。 = =+
感謝支持。 :)
很好的文章,收藏了,今天才看到这么好的网站。
文章好棒,mark之,謝謝大大分享!!
@Btiger & 西瓜玩偶:
好文章總是歷久彌新,謝謝兩位。 :)
EGP 我的最爱~~~~~~~~~~~
老早就知道monkeypotion,不过一直没怎么来逛,惭愧惭愧~~~~~~~~~