開發者談合格遊戲文檔的基本構成要素

本文原作者:Dylan Moran 本文譯者:Ciel Chen

一個概念性遊戲設計文案,其理想狀態是能夠在着手開發前概括出整個遊戲的開發過程。

一旦這個遊戲項目被通過,開發者就會爲開發團隊把這個概括文案具體化。因爲遊戲開發是一個非常動態的過程,有時一個遊戲設計文案會在開發過程中被反覆多次地修訂更改而變得更加完善,同時項目範圍和方向也會不時地變化。

正因爲遊戲設計文案有這個會不斷變化的性質,它常常又被稱作動態文案。剛開始它可能只是一個很基礎的大綱,然後慢慢地變成了一個對整個遊戲開發過程的每個階段都有詳盡描述的框架。

successful Game Design Document(from gamasutra)

successful Game Design Document(from gamasutra)

格式確切、對所有不同類型遊戲都適用的遊戲設計文案終稿是不存在的。每份遊戲設計文案終稿所涵蓋的信息量都是獨一無二的,因爲這取決於不同的公司目標,項目規模,團隊技術以及作者認知。但相同的是,在初期,一份好的遊戲設計文案會包含所有的遊戲組成部分和遊戲機制,也就是以下部分:

項目說明

一份遊戲設計說明必須有一個簡潔的關於遊戲的說明。沒必要把遊戲機制和技術方面的內容一一列出。只要把這個說明把控在兩三段左右,應提到的有遊戲性質(社交、冒險等),遊戲類型(益智類、設計類、戰鬥類)還有你所知道的任何遊戲參考。

角色、故事、時間、主題

在一開始把遊戲的角色、故事、時間和主題介紹出來很重要。如果你的遊戲沒有任何特定的角色或故事,你可以簡單地描述遊戲的主題進入下一步就好。因爲就像簡單的射擊遊戲未必需要像拯救平民的士兵這樣的角色。它可以僅僅是讓兩個玩家切磋射擊技巧的簡易遊戲。

遊戲可玩性

在這部分,你必須特別指出玩家會選擇玩這款遊戲的理由以及他們會怎麼玩。比如可以提到遊戲設計的目標、角色/玩家在玩這個遊戲需要用到的技巧、遊戲的機制、可強化的選項(爲了讓遊戲更有趣好玩)、遊戲難度以及玩家怎樣算輸。

美術風格

就像標題說的那樣,美術風格的定位決定了整個遊戲的畫風。遊戲畫風也就是說這款遊戲看上去會是什麼樣。舉個例子,像《精靈寶可夢》(Pokemon Go)、《糖果粉碎傳奇》(Candy Crush)和《憤怒的小鳥》(Angry Bird)就有非常吸引人的美術風格。獨一無二的畫風元素在這些遊戲的成功道路中功不可沒。富有創造性的色彩融合、設計、主題加上有新意的角色讓這些遊戲脫穎而出流行起來,而且還爲遊戲增添了自然/免費的營銷渠道。比如不同的製造商發行的各種周邊,就像憤怒的小鳥腕錶/文具;還有以遊戲相同名字註冊的不同服務,比如Rebel Penguin網絡服務,精靈寶可夢兒童日託服務。

技術說明

在這個部分,你必須明確遊戲發行所面向的平臺,比如是手遊平臺(安卓系統或者蘋果系統)、單機、聯網/Facebook平臺或其他更多。還有就是這個新遊戲所用到的工具、軟件或者遊戲引擎,比如說虛幻引擎4(Unity 3D)、Unity 3D等。因爲詳細的技術細節會在技術設計文案中一一例舉出來(TTD),所以在這裏你只要把最基本的細節明確下來就好。

營銷與資金

此處應列舉出你對於這款遊戲的所有營銷想法,比如遊戲所面向的目標用戶或者目標地區,要從哪裏弄來資金等等內容。在動手開始設計遊戲之前,把這些細節搞定是非常重要的。比如說,如果你的目標用戶是年輕男性(15到25歲),那比起粉嫩的洋娃娃或者小兔子,把主要角色設定成士兵、賽車或者足球運動員總要合適得多吧。還有如果瞭解遊戲面向的地區你就知道遊戲要採用那裏的語言,比如法語,西班牙語,英語,意大利語等等。還有最重要的是,你必須明確你打算怎麼通過這款遊戲賺錢,是通過植入遊戲的廣告還是通過賣出該遊戲的完整版。

總而言之,一份遊戲設計文案不用把你遊戲每個技術部分都描述得非常詳細。它只需要概括出你對這個遊戲的設計計劃,這個計劃得讓人讀得下去,看得明白。 擁有一份詳細的遊戲設計文檔肯定不是件壞事,因爲它能讓開發團隊在回顧分析一些小細節時,能預判到潛在問題,這些都是那些過於簡短的文案辦不到的。

本文由遊戲邦編譯,譯者爲Ciel Chen 轉載請註明來源,或諮詢遊戲邦,微信zhengjintiao

How to write a successful Game Design Document

by Dylan Moran on 02/21/17 09:08:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

A conceptual Game Design Document (GDD) is ideally created before a pitch, which outlines the complete game development process.

Once the project is approved, the document is then expanded by the developer into a detailed guide for the development team. And because the game development is so dynamic, sometimes a GDD is revised and changed multiple times during the development phase. It is continuously improved upon as the development processes. Project scope and direction is also changed at times.

For this frequently changing nature of a game design document, it is also often referred to as a living document. It may start with only a basic outline and become a detailed framework for each phase of the complete game development process.

There is no definite format of a final Game Design Document that suits all different variations of games. The amount of information contained in the final GDD is always unique, depending on the company goals, project size, skills of the team and knowledge of the author. However, to begin with, a good GDD contains a description of all the components of the game and the game mechanics as below:

Project Description

A GDD must start with a brief description of what the game is about. Not necessarily listing the game mechanics or other technical aspects. Just keep it to 2-3 paragraphs and mention the nature of game (like, social, adventure), genre of game (like, puzzle, shooter, combat) and any reference games you know of.

Characters, Story, Events and Theme

It is important to introduce the characters, story and theme of the game at the beginning. In case your game does not have any particular characters or a story, you may simply describe the theme of the game and move ahead. Like a simple shooting game may not necessarily have a character like a soldier rescuing civilians. It can be simply game where two players compete for better shooting skills.

Gameplay

In this section, you must specify why the player would be playing the game and how he would play. For example, mention the goals of the game, skills needed by the character/player to play the game, the mechanics of the game, power up options (to make the game more fun), game difficulties/challenges and how a player loses.

Art Style

As the name suggests, defining an art style means deciding on the visuals of the game. How the game would look like. For example, games like pokemon go, candy crush and angry birds, had very attractive art style. Their unique visual elements were equally responsible for the success of these games. Their creative blend of colors, design, theme along with innovative characters makes these games highly popular among masses and increase the natural/free marketing channels. Like, various accessories are launched by different manufacturers with the game theme, like angry birds wrist watches/stationeries, and different sort of services being registered under same title name like Rebel Penguin web services, pokemon go day care for kids.

Technical Description

In this section, you must specify the platforms on which you would launch the game, like Mobile Phones (android, iOS), PC, Social Networks/Facebook or more. The tools, softwares or game engines you would employ to create your new game, like Unreal Engine 4, Unity 3D and more. The detailed technicalities would need to be listed in a Technical Design Document (TDD), so here you just need to specify only most basic details.

Marketing and Funding

Here you need to list all your ideas about how you intend to market your game, which is the targeted user or location, where to get funds from and more. It is important to have all these details in hand before starting to design a game. For example, if you are targeting young adult men (from 15-25 years), it might not be appropriate to have the main character as a pink colored doll/bunny, rather a soldier, a racer, a football player could make a better choice. Knowing the location of the game would allow you to use regional language within the game, like, French, Spanish, English, Italian and more. And most importantly, you must specify how you plan to monetize on the game, whether it is through in-game ads, or by offering a paid full version of the game.

In short, a GDD does not need to be a detailed document that specifies each technical aspect of your game. It simply needs to outline your plan for the game design, which is readable and easily comprehensible by anyone who reads the document. Having a detailed GDD can never be a bad thing either, as it would allow the development team to review several smaller points analyse them and address potential problems in advance which could not be possible through a very brief document. (source:gamasutra.com )