[轉]如何在七天內完成遊戲原型

本文是於 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 款遊戲原型做品這項近似於不可理喻且難以想象的目標,他們將本身鎖在房間內,遵循着如下三項規則進行開發工做:php

  1. 每一個遊戲必須在 7 天之內完成。
  2. 每一個遊戲必須從頭至尾以 1 人之力完成。
  3. 每一個遊戲必須立基於通常常見的主題,例如「重力」、「植物」或「羣聚生物」等等。

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

準備:敏捷,是一種意向的狀態
敏捷式原型開發 (Rapid Prototyping),不僅是前置開發時期的有用工具,同時也能夠是一種生活方式。從思惟層面出發,首先要使本身的心理狀態合乎「敏捷」的原則,纔可以真正成爲一位敏捷式的原型開發者。首先,第一步就是要樂於擁抱失敗的可能性。
優秀的原型開發者可以瞭解,失敗是一件能夠接受的事情!而那也正是創建原型的目標,因此請大膽地放手去作吧!萬一最終真的失敗了,也可以從其中的過程學習到某些具備價值的經驗,而且惟有藉由擁抱失敗的可能性,纔有可能獲得有所回報的實驗結果。在 Gray 所製做的《Mime After Mime》與《A Mime to Kill》中,很大膽地只使用位置性音源 (Positional Audio) 作爲遊戲性 (Gameplay) 的來源;雖然這兩個遊戲是全然失敗的做品,但也充分證實了僅有音源遊戲性的遊戲設計概念,是一項不可行的做法。
堅持實行極短的開發週期,是另一項快速開發的訣竅。開發者們彷佛會很天然地說:「嘿,既然咱們在 1 週內完成了一個很棒的遊戲,那麼若是咱們花費 2 週的時間進行開發,咱們將會獲得一個 2 倍優秀的遊戲做品!」事實上,他們發現通常來講,任何遊戲性都可以有效地在一週內完成原型建置;額外的投入時間,老是會傾向於產生功效遞減的結果。舉例來講,有些原型僅僅花費一個晚上的時間組裝完成,另外有些原型則使用了額外的一兩週時間,而使人意外的是,每一個原型所花費的時間,與其最終得到的成功程度,並無相互關連性存在。
在他們所製做出的成功遊戲原型中,多數都是出自於特定的主題,他們曾經探索過的主題包括了「重力」、「彈簧」、「演化」、「聲音」、「植物」與「平衡」等等。不知爲什麼,當有限制存在的時候,反而會更易於產生創意。另外,與團隊成員同時進行某個特定主題的原型開發,某種程度上也可以避免着力於太過顯而易見的遊戲性,迫使全部人都必須接受挑戰,探索在這個主題下的全部遊戲性的可能性。若是缺乏了穩固明確的主題限制,遊戲將會花費更多的時間創造,同時也會減損團隊的方向目標,以及那種使他們可以擠壓出最後一滴創造能力的友善競爭感。
每一位團隊成員都必須可以獨立面對而且負責遊戲開發的全部面向,包含程式、美術、聲音以及其餘全部將成爲最終成品的必需品。可是我的的才能並不表明一切,團隊成員必須體認到對於這種形式的開發方式來講,「設計」纔是至高無上的準則,而包括程式、美術與全部其餘的東西在內,都只是爲了服務最終的設計結果而存在。一位不具有這種思惟的優秀工程師,將不會比徹底瞭解這項關鍵要點的平庸工程師來得更爲成功。
當團隊創建完成後,他們就開始中止與其餘成員一塊兒工做。「啥?這樣還算是團隊嗎?」聽起來或許有些奇怪,可是四我的分頭並進,同時開發四個遊戲原型的「不協同合做」方式有許多益處,像是減小風險(四個成品中至少會有1、二個成功的結果)、友善競爭感、更廣闊的主題探索(避免設計出與別人相同的遊戲性),以及相互分享彼此所習得的知識。在每一個原型開發週期的起始和最終階段,團隊合做是最具備價值的期間,而當進入開發期以後,與其餘成員一塊兒工做只會形成分心,而沒法產生良好的正面效應。
設計:創意以及腦力激盪之謎app

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

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) 設計。當你碰觸它的時候,多汁的遊戲會跳動、搖動、噴射而且發出一點聲響,讓玩家感受它像是活生生的,並且會對於你所作的每件事情作出迴應。使用者回應是遊戲中比較微小卻很是關鍵的要素,可以讓玩家感受本身是真正掌控着遊戲世界中的一舉一動,而且藉由每次的互動行爲,訓練玩家逐漸熟悉遊戲所制訂的種種規則。
進行敏捷式的遊戲原型開發,就像是孕育本身的小孩同樣,或許未必每次都會有美好的結果,但你老是可以從每次的經驗中學到些什麼新的東西。不管如何,這些過程與結果一般都很是好玩!整理以上四項內容,能夠概括出下列綱要:工具

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

  • 擁抱失敗的可能性——它會鼓勵開創性的風險承擔
  • 堅持實行極短的開發週期(更多的時間不等於更好的品質)
  • 限制創意可以使你渴求更多
  • 召集優秀的團隊成員以及一位客觀的顧問——思惟與才能一樣重要
  • 平行開發以得到最大化的成果

設計:創意以及腦力激盪之謎開發工具

  • 正式的腦力激盪程序只有 0% 的成功率
  • 彙集概念美術與音樂以創造情感化的目標
  • 在你的腦殼中模擬——前置開發你的原型

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

  • 首先創建玩具
  • 在可接受的狀況下使用假裝
  • 終止你的損失而且學習如何斷然捨棄
  • 着重於遊戲內容物沒法救贖差勁的設計
  • 總體美學仍然重要——運用有益的美術、聲音與音樂
  • 沒有人會在意你的偉大的工程技術

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

  • 複雜未必表明樂趣
  • 創造出全部權的感受使玩家想要得到更多
  • 實驗並不意味着複雜
  • 朝向具備良好定義的目標建置開發
  • 讓它多汁!

在遊戲開發領域中,遊戲原型究竟具備什麼樣的重要性?在投入龐大的資源與人力以前,若是能夠預先進行遊戲概念或者核心機制的原型開發,不只可以早期驗證遊戲設計的良窳與否,更有機會大幅下降專案開發時期的風險,避免到了專案中後期時才發現「這種玩法根本不有趣」的殘酷事實,而只可以將已完成的遊戲機制整個砍掉,而後從新來過。由知名遊戲製做人 Will Wright 所主導的遊戲《Spore》,在開發時期中甚至製做了上百款遊戲原型,用以驗證遊戲中的各項設計機制與表現細節。他們也很大方地在遊戲的官方網站上公開其中數款遊戲原型,讓感興趣的玩家自行下載。
Super Tummy Bubble
以前偶然從 Gamasutra 的檔案庫裏翻出這篇數年前的好文章,我以爲本身實在是很是很是地幸運!由這四位做者共同發起的 Experimental Gameplay Project,居然可以在短短的一個學期內,完成超過 50 款遊戲原型。不只要在極爲緊迫的週期內,完成遊戲原型的開發工做,同時又要兼顧忙碌的研究所課業,通常人可能在製做出幾個做品後就會產生放棄的念頭,他們卻可以保持紀律持之以恆地進行這項專案,絕對是一項至關難能難得的成就。若是我是教授遊戲開發課程的教師,我必定也會很樂意依循着這樣的模式與原則,指導學生們進行如此具備樂趣與學習效果的遊戲原型開發專案!
對於身處程式設計領域的人來講,即便你不知道如何製做精美的圖片、不懂得如何譜出美妙的音樂,但只要你的腦殼裏裝滿了「作出來應該會頗有趣」的遊戲點子,不妨大膽地放手一試吧!「左手只是輔助,工具也只是輔助。」不論你熟悉的開發工具是 OGRE、SDL、Torque 或者本身打造的引擎,條條大路通羅馬,這些工具全都可以協助咱們到達遊戲開發疆土中的美麗境界。而對於美術、設計或具備其餘專業的人來講,即便你所擅長的技能並非程式設計,但只要可以學習使用 Flash 以及簡單的 ActionScript 語法,一樣可以以簡單的工具創造出使人贊嘆的遊戲原型。
之前的我,總認爲若是想要製做一款遊戲做品,一定要通過很是縝密的規劃與周全的設計,纔可以真正開始着手動工:「必定要有一個很是棒的遊戲引擎,必定要有一個前無古人後無來者的遊戲點子,必定要有一份超級詳盡的遊戲設計文件,必定要……」有許許多多的先決條件存在,必定要知足了這些條件之後,才能真正開始動手撰寫遊戲。可是過分的顧慮與計畫,最後反而成爲理想實踐道路上的最大阻礙。因此與其戒慎恐懼而遲遲不敢跨出一步,不如豪邁地向前跨出步伐,大方擁抱包括失敗在內的一切未知性與可能性吧!
閱讀完這篇文章之後,給了我很大的鼓舞與激勵,我也已經下定決心,準備要開始動手嘗試遊戲原型的實驗開發計畫。你呢?Happy Prototyping! :)url

相關文章
相關標籤/搜索