譯介丨Leandro Gonzalez:如何撰寫一份遊戲設計文檔


3樓貓 發佈時間:2023-05-16 14:52:25 作者:虎鴿咕咕 Language

譯文僅供參考,僅用於學習交流,請勿轉載,謝謝!
作者: Leandro Gonzalez
原文標題 : How to Write a Game Design Document
原文鏈接:點擊跳轉
譯註: 本文寫於2016年,距今也已有7年之久,一些觀點可能跟不上如今的發展,請僅供參考。 翻譯完成與2023.05.15,本來計劃在趕在BOOOM暴造開始之前翻譯完,但因為諸多原因進度緩慢……希望對大家有所幫助。

深入探討之前我想先解釋幾個觀點

我第一次分享這篇文章的時候(幾個月前的Reddit上),出現了很多非常有積極而熱烈的討論(因此我們都在遊戲設計師這條路上共同進步)。 其中有幾個比較重要的觀點我想在這裡解釋一下,如果你能閱讀全文,那麼就更容易理解這些內容:
  1. GDD(Game Design Document)的使用已經是過去式。
  2. 撰寫GDD時,需要直奔遊戲機制。
之後我可能會寫一篇完整的文章來討論每個觀點,不過現在:
譯註: 作者在這裡使用對應編號,對上述兩個觀點分開進行詳細的解釋說明。
1.—— 跟其他行業相似,遊戲行業也在不斷發展,使用的技術在不久的將來就會被淘汰,更何況它還是一個仍在發展其流程、指標的新興行業……所以不管想如何稱呼遊戲設計文檔(GDD、Wiki、Board……),更重要的是在全力開發之前,一定擁有了能夠描述遊戲項目(或任何其他項目)的東西。
譯註: Board:意為看板,可按自定義的順序放置各種內容的卡片。常見於軟件Trello,可用於項目管理等。
在Trick任職時我稱其為GDD,不過我們還用看板(Trello)組織任務,嘗試每兩週設立一個項目里程碑。(有點像Scrum)
譯註: Trick:遊戲開發工作室,和多家遊戲公司有合作。 Scrum:是迭代式增量軟件開發過程,通常用於敏捷軟件開發。
我們不使用隨開發過程推進而修改的單一GDD,而是使用加快團隊開發速度的文檔。然後,在遊戲設計階段,按照團隊的反饋和想法,做出修正。 一旦開始開發,我們就不再更新這份GDD。所有新想法都放在看板上,一些需要優先處理(權重1到3,1是一定做,2是可以做,3是還不錯),另一些放在“想法”欄,留著之後評估。 總之,無論是想用GDD還是別的什麼,我們一定會建議那些剛起步的遊戲設計師們——把想法寫進各式各樣文檔的時候,
請,請,請讓其他人能看、能懂。
2.—— 我的回答是“視情況而定”,這會在本文中詳細說明。如果你的遊戲像《俄羅斯方塊》(Teris)、《太空侵略者》(Space Invaders)或《爆破彗星》(Asteroids)一樣......(譯註:那你就可以在GDD直奔遊戲機制來描述)換句話說,遊戲中劇情如果不是特別的存在,那就對機制毫無影響,那你完全可以直接跳到第4章的模板。 剛才所舉例的這個遊戲,可以很自然地結合上下文描繪出角色、行為、動機(紐米(The Gnumies)可以轉化成特定的遊戲的機制,也可以衍生出遊戲中交戰的敵人——“細菌人”(German)“細菌先生”(The Germ))。
譯註: Gnumies,結合後文,應該是Numismatic(與錢幣相關的)與Gnome(侏儒)結合而成的詞。
說到底,一切都取決於遊戲和遊戲設計風格。可以考慮設置一個介紹部分,簡短地(一到兩段話)描述整個機制。這樣不管你是直接跳到遊戲的完整介紹,還是轉而先解釋背景故事,都能讓大家立刻理解遊戲的類型和核心機制。

所以,我該如何圍繞我想在遊戲中做的內容撰寫文檔呢?

這是我每次有個能一夜暴富的絕妙想法時,腦子裡蹦出來的第一個問題(開個玩笑,我還是很窮)。當時我甚至不知道我在做遊戲設計,也不知道我需要寫創建一份遊戲設計文檔(簡稱GDD)。 調查一番之後,我發現了這個術語,但似乎沒有讓我起步的一個行業標準或模板。 我找到很多遊戲設計書籍(我非常推薦Jesse Schell的一本關於透鏡的書),儘可能地在線閱讀之後,覺得是時候創建我的第一份GDD了。經過多年的迭代,它已演化成接下來的這個模板。我們在Trick每次製作新遊戲的時候都會使用。 本文是對這份GDD(你可以在這裡下載到後綴名為doc的模板文件=>Trick's GDD Template)中每個章節的描述。
譯註: Jesse Schell:《遊戲設計藝術:一本關於透鏡的書》(The Art of Game Design: A Book of Lenses)的作者。這本書確實非常推薦,即使不從事遊戲行業,也可以從這本書中得到創意上的啟發。 一本關於透鏡的書:《遊戲設計藝術》的副標題,本文作者都用副標題在稱呼這本書。 透鏡:《遊戲設計藝術》中一種分析遊戲、理解遊戲的視角。書中有一百多個透鏡(第一版有100個,第二版增加到了113個)。

GDD

項目說明

總結遊戲內容,不詳述遊戲機制,不漫談其它細節。項目描述要能夠讓人明白你想做的遊戲風格(大眾,休閒,硬核等)和遊戲類型(益智(Puzzle),角色扮演(RPG),第一人稱射擊(FPS)等)。當然,你可以增加任何與你遊戲相關的內容。 這一章節最好只寫1-2段,一定不能超過1頁。
例:
這份遊戲設計文檔詳細說明了一款跨平臺觸控的2D益智遊戲,以及其獨特機制、原創故事、原創角色。 該遊戲類似其他三消遊戲,但做出了一些創新。 名稱暫未定論,候選有……

1. 角色(Characters)

之所以從角色開始說明,是因為需要在劇情前介紹他們。假如你的遊戲沒有角色和/或劇情,可以直接跳到玩法章節並移去章節1-3(或留空)
角色說明的例子:
紐米(Gnumies)們是遊戲中的主要角色。這些生物開心而富有,卻毫不貪婪。他們之所以富有,是因為他們的祖先與金錢或錢幣(Numismatic)有關,他們因此得名:紐米(Gnumies)。 紅紐米(Red Gnumies)容易激動,有破壞衝動。黃紐米十分好動,常上躥下跳。綠紐米儒雅隨和,一顆平常心。藍紐米常感悲傷,有躁鬱傾向。 紐米們有很多隻手臂,從1到4只不等,而且都長有手。他們抓握有力,可以靠牽手連接成一體。紐米們行為粗暴,總會把一切迴歸混亂。
你可以把角色設定圖也放在這。

2. 劇情(Story)

“講故事藝術其中重要的一環,就是創造聽者容易共情的角色。因為角色讓聽者共情的點越多,角色身上發生的故事也就顯得越有趣。” ——Jesse Schell,一本關於透鏡的書
在介紹完角色之後,是時候講述事件是如何貫穿遊戲始終了。
例:
紐米們在城堡中愉快地玩耍,互相惡作劇。管家常常頭疼,不過大家還是其樂融融。樂子人造樂子。 細菌人正在家看電視,媽媽卻來打擾他。於是他來到外面,窺視紐米們。外面下著雨,細菌人透過窗戶露出羨慕的神情,全身卻被淋溼。 一位陌生的神秘人給了他一把鑰匙,可以用它打開後門。他帶著軍隊闖入,綁架並監禁了紐米們中的的女性和孩子,並把其他紐米都驅逐出了這個島嶼。
譯註: ……這個故事不知從何吐槽。

2.1. 主題(Theme)

“共鳴主題能把你的作品昇華為藝術。藝術家會引領你進入無法獨自到達的領域,而主題就是讓你前行的工具。” ——Jesse Schell,一本關於透鏡的書
別人看你的設計時,主題很重要。一般來說,主題說明了你想要講述什麼樣的故事:是喜劇,是現實生活,還是隻是幻想…… :)
例:
這是一個有關悲傷與困境的遊戲。遊戲中會有激動、快樂的時刻,但每一章劇情都在以確定的基調來推進,即紐米們因失去了家園而悲傷。 遊戲也必須存在幽默感,必須有趣。
如果你覺得這和你的遊戲不相關,你可以跳過這一章。

3. 劇情流程(Story Progression)

所以,你有了劇情,但遊戲該怎麼把玩家帶入劇情呢?
“遊戲世界是獨立存在的。你的遊戲是通往這個神奇之地的大門,是獨屬於你的玩家們的天馬行空。” ——Jesse Schell,一本關於透鏡的書
例:
遊戲開始於一個簡單介紹場景,紐米們在這被驅逐出了家園。隨後他們來到一座島上,第一章開始。 第一章是教程,可以跳過。關卡比較少,管家會給玩家介紹遊戲機制。 玩家通關教程時,就可以進入第一個世界森林世界。 玩家通關森林世界時,會得到一把鑰匙,可以選擇進入火山世界還是冰山世界。然後玩家通關這些世界時…… 最好不要讓這個世界只能容納一個劇情,而是能同時發生多線劇情。這會為續作、周邊提供空間。

4. 玩法(Gameplay)

“遊戲始於一個創意” ——Jesse Schell,一本關於透鏡的書
這是(可能對99%的遊戲來說)GDD中最重要的章節。在這裡需要說明你的遊戲玩法(沒錯,加粗了)會是什麼樣。
譯者注: 原文是將Gameplay的G大寫,表示非常重要。考慮到中文沒有大寫一說,所以加粗表示。
考慮到這章內容比較多,我們選擇了一些我們覺得有意義的部分作為子章節。當然,我們選擇的內容非常主觀,效果可能因人而異。

4.1. 目標(Goals)

很簡單,玩家為什麼要玩你的遊戲?最好的辦法就是把這部分內容單獨列成一章,不然你還得通讀整個GDD。
例:
總體(長期):幫助紐米們重返家園 遊戲玩法(短期):打敗敵人,提升等級,等等……

4.2. 玩家配置(User Skills)

這一章不太直觀,不過如果你需要考慮你的玩家應該掌握什麼樣的技能才能夠遊玩你的遊戲,你可以聚焦於此。相信我們,列出這份表能幫你發現遊戲設計中的問題。比如,你可能想開發一款面向兒童的遊戲,但你意識到他們可能需要做出超出年齡認知的操作,有些操作可能適合手機但並不適合帶搖桿控制器。再者,如果你想為遊戲自研硬件(Custom HW),列個表能搞清楚開發需要哪些功能。
例:
* 點按屏幕 * 拖放 * 記憶力 * 解謎 * 重組碎片 * 管理資源 * 制定策略

4.3. 遊戲機制(Game Mechanics)

這才是你該說明遊戲機制的地方。毋庸置疑,你的團隊在傳閱GDD的時候,應該保持對遊戲玩法的合理質疑。這是非常重要的一個部分,可以插入原畫、原型截圖(我們傾向於在投入資源之前製作原型,以測試遊戲玩法是否有趣)。 已經有完整的書籍、網站包含如何描述遊戲機制的資料,我們就不再舉例贅述。相關資源附在文章最後。

4.4. 道具、強化(Items and power-ups)

這一章用來闡述遊戲機制。為了避免腦子裡的想法塞爆了這一章,我們用上面那章描述核心機制,而這裡可以講講用來提高趣味、強化玩家的遊戲附加玩法。 所以,假如你的遊戲是三消類,那在上一章準確描述三消的機制原理(並在公式中增加變量)。 而在這一章,把玩家可使用/獲取/購買的每個強化、道具加進來,並介紹它們會如何影響核心玩法。
例:
每當通關一個世界,可以獲得該世界相關的強化。比如,通關火山世界後,可以獲得強化紅紐米力量的道具。它可以是圍巾或其它可穿戴的物品,而這些道具在之後的遊戲都會看到。可以使用遊戲貨幣升級道具,也可以氪金購買遊戲貨幣禮包……

4.5. 流程、挑戰(Progression and challenge)

這也是非常主觀的一章內容,可能因設計而異。我們想用這一章闡述遊戲難度是如何隨著遊戲流程上升的,好保證玩家跟得上步伐。
例:
難度以增強敵人的方式提高。 為了降低難度,玩家需要提高遊戲技藝、升級紐米、使用道具(也可以升級道具)。
對了,這裡我們要說玩家怎麼解鎖新關卡或新任務。
例:
每個BOSS會掉落一把鑰匙,顏色對應著當前世界。可以按任意順序通關世界。通關所有世界、擁有所有鑰匙之後,就可以衝擊最終世界。玩家可以自由選擇每個世界的通關順序,世界的最終BOSS會掉落鑰匙,可以解鎖其他世界。這樣一來,玩家必須在選擇下一個世界之前,通關當前的世界,同時難度也將隨之設定。

4.6. 失敗(Losing)

沒錯,失敗!失敗條件是什麼?時間,生命,還是都有?在這裡說明玩家怎麼樣才會看到“遊戲失敗”界面。
例:
失敗條件:超時、超步數、無可用連接(譯註:三消遊戲背景)。 玩家失敗時,需要展示紐米受傷/擦傷的圖像。可以是掉了些毛髮,露出了其下的皮膚。

5. 美術風格

這一章不用多說:介紹你的遊戲想要展現什麼模樣。一圖勝千言,快把概念圖放在這吧。
例:
這是一個2D等距(isometric)遊戲,使用高質量2D精靈(Sprites)。角色設計參考吉卜力工作室(Studio Ghibli)作品。 通過高度動畫化的場景和分層背景,將世界表現得多彩、生動。
譯註: 等距:指等距視角風格,也稱等軸測圖。該視角下,正方體的每邊長度相同、對邊平行,透視沒有視平線、滅點,且攝像機方向固定。使用等距視角的遊戲例有暗黑破壞神、紀念碑谷、陷陣之志等。 精靈:指遊戲引擎中的可展示圖片的一種遊戲元素。(並不是一種生物)。

6. 音樂、音效(Music and Sounds)

“音樂是靈魂的語言,正因如此它是在一個深層次對玩家傾訴。” ——Jesse Schell,一本關於透鏡的書
在這裡說明音樂和音效。如果你的遊戲音樂音效很重要的話,你可以把這章再分成若干個子章節。
例:
音樂是復古風(Retro),最好是高質量的8bit懷舊風。 當玩家表現活躍時,獎勵音效一定要給足,且擁有即時、積極的反饋。 時間不夠的時候,需要製造緊張感的音效。 悲傷的場景應該配有手風琴或小提琴的音樂伴奏,聽起來像是一曲悲傷的探戈。 至於遊戲內的音樂,用輕鬆的旋律,歡快的曲調,並隨著關卡推進提升節奏。山洞裡的音樂則需要壓低一些。

7. 技術說明(Technical Description)

在這裡說明你想運行的平臺、將在開發中使用或考慮使用的開發工具。這並不該是一份詳細的技術說明,你可能需要另起一份技術設計文檔(Technical Design Document、TDD)。這裡只涉及最表層的信息。
例:
最初,遊戲將會是跨平臺移動端: iOS 安卓(Android) Windows Phone後續會有PC獨佔和支持Facebook Canvas。 可能會增加Mac和/或控制器支持(通過e-stores) 考慮使用以下引擎:Marmalade,Unity 3D,虛幻4(Unreal Engine 4)。 用JIRA進行項目管理。用Perforce存儲代碼和資源。 待定於技術設計文檔。

8. 市場、資金(Marketing & Funding)

這是一個全部可選的章節,但現在你得寫下你的想法,以免之後忘記。即使在正式開發之前,也要考慮如何推銷你的遊戲,還要想好開發遊戲的資金從何獲取,這很重要。
“計劃是件現實的事。” ——Jesse Schell,一本關於透鏡的書
例:
將第一關原型化,然後啟動一個Kickstater(譯註:一個眾籌網站)項目展示這個關卡。 嘗試達成出版協議。 有任何我們可以申請的政府資金嗎? 撰寫新聞材料,發佈到遊戲新聞網站。 開啟一個YouTube頻道,上傳開發日記視頻。 等等……

8.1. 人口統計數據(Demographics)

瞭解你的目標用戶群體是很重要的,應該貫穿遊戲設計過程始終。如果你的目標是15到25歲的男性,那你的主角不該是一隻粉紅小馬(並不是說這有什麼問題)。
例:
年齡:12到50歲 性別:所有 休閒玩家為主

8.2. 發佈平臺、變現

可以增加一些細節,關於每個平臺上該如何發佈。
例:
最初:安卓app,免費版內置廣告,付費版無廣告。 iOS,免費版內置廣告,付費版無廣告。 遊戲內購。 待考慮:Windows 8,Windows Phone 8,XBOX live和Nintendo e-shop。

8.3. 本地化

你支持的語言。加你想做的就好,前期優先級並不高。
例:
最初英語和西班牙語。 之後更新:意大利語、法語、德語等。 考慮與亞洲的發行商合作,發展到亞洲市場,需要幫忙做本地化的人員。

9. 其他創意

這也是一個全部可選的章節。如果你有些拿不定的創意,考慮要不要加入遊戲,那就把他們都放在這當作備忘。
例:
* 關卡設計師 * 能夠為其他用戶創建的關卡評分 * 成就 * 排行榜 * 這遊戲應該有多人模式嗎?
“一般來說,製作一個多人在線遊戲花費的時間精力和金錢是製作一個類似的單人遊戲的4倍是比較合理的。” “有一個古老的經驗法則,即在你有一個完全可行的版本後,需要六個月的時間來平衡你的遊戲” ——Jesse Schell,一本關於透鏡的書

結語

我們希望其他遊戲開發者能認為這個模版有用。歡迎來討論這份文檔該如何修改和改進。 歡迎與我們聯繫:play@trickgs.com。如果想跟進我們正在進行的工作,可以再Twitter或Facebook上關注我們。感謝! 這裡有一些紐米,請收下!
the big list of game design
my 7 most valuable game design resources
模板鏈接:Trick's GDD Template

© 2022 3樓貓 下載APP 站點地圖 廣告合作:asmrly666@gmail.com