《How to Prototype a Game in Under 7 Days》:如何在七天內完成遊戲原型

>>>  創業先鋒 眾人拾柴火焰高  >>> 簡體     傳統

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

  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.

tower-of-goo
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

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

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

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

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

準備:敏捷,是一種意向的狀態

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

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

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

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

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

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

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

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

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

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

  • 首先建立玩具

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

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

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

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

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

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

  • 複雜未必代表樂趣

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

  • 實驗並不意味著複雜

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

  • 讓它多汁!

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

super-tummy-bubble
Super Tummy Bubble

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

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

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

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


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

[新一篇] 《World of Goo》:歡迎來到「咕」世界!

[舊一篇] 遊戲產業新門派(一):Casual Game
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表