Design

[翻譯] 如何(以及為何)寫出一份優秀的遊戲設計文件


How (and Why) to Write a Great Game Design Document
[翻譯] 如何(以及為何)寫出一份優秀的遊戲設計文件

原文網址:
http://gamedevelopment.tutsplus.com/articles/how-and-why-to-write-a-great-game-design-document–cms-23545

作者:Alex Sayenko24
Apr 201516

Every indie developer or team has asked themselves how best to manage the development process. Is it obligatory to use detailed documentation, such as the legendary game design document (GDD)? What are the most common mistakes, and how can they be avoided?

For those who have searched for answers to these questions, I want to share our team’s experience of creating our GDD.
每個獨立開發者或是團隊都會問自己如何管理開發流程。一定要寫詳細的文件嗎?寫到像傳說中的遊戲設計文件(GDD)?最常犯的錯誤是甚麼?我們怎麼避開?
如果你正在尋找這些問題的答案,我可以分享我們團隊如何建立GDD的經驗。

Why You Need a GDD
為何需要一份遊戲設計文件

Good Documentation is a Must
遊戲設計文件是必要之務

Many game designers abstain from cultivating design documents and organizing ideas. I can’t imagine how these developers get through those times that they are hampered by malfunctioning code, placeholder art, and clashing mechanics, all while trying to remember why it was that they first subjected yourself to making a game in the first place.
很多開發者不想要精雕細琢遊戲設計文件及將點子組織起來。我無法想像這些開發者是怎麼在這樣的情形下開發,被有問題的程式碼,重複的素材,有問題的流程而阻礙。當我們在沒有文件的情形下想要回想到底發生了甚麼事,就像每次都把自己的記憶回溯到專案剛開始的時候一樣從頭開始。

Having a well thought out game design document can act as your crutch in these times. It will let you see the awesome ideas and concepts that kept you up all night long when you first started on your game, and, perhaps more importantly, which ones need to be cut from the game to make your life easier, or reworked to make your efforts worthwhile.
這些時候文件就會是及時雨。文件讓我們在開始專案的時候能瀏覽絕佳的點子與概念,更重要的是去除那些不需要的特點,減輕負擔,減少重工。

A GDD Aids Game Design and Development
遊戲設計文建會幫助設計與開發

A game design document acts as a nexus and hub to connect and list every aspect of a game. It consists of written descriptions, images, graphs, charts and lists of information pertinent to each segment of development, and is often organized by what features will be in the game, and clearly lays out how they will all fit together.
遊戲設計文件就像把遊戲的各個面向連在一起的工具。那包含文字描述,圖片,圖案,及每個開發流程的相關清單,通常也包含遊戲的特點,也說明那些特點是如何組織起來。

Creating a GDD will aid your team’s designer in understanding what the essence of the game is and the planned scope of its overarching world and gameplay. Plus, having all the game elements in one well-organized document will help the designer easily convey their vision to the rest of the team, while also helping to pinpoint weaknesses or missing components that the game may require.
建立一個GDD會讓團隊設計人員能夠了解遊戲的核心,同時規劃世界的範圍,遊戲玩法。更重要的是,有這樣列出遊戲要素的文件可以讓設計者的思維傳達給團隊其他人,也幫助指出遊戲的弱點或缺少的部分。

The GDD should serve as your master checklist. It will be the document you toss up in the air in celebration upon completing all its sections and finishing your game.
GDD應該視為開發首要之務,也應該是完成遊戲,大肆慶祝前的檢驗方法。

A GDD Helps in Other Areas, Too
在其他方面GDD也都能幫上忙

Since a GDD is full of descriptions, it is an ideal resource for all PR and marketing fronts, with concepts that convey the game’s aesthetic and appeal already written up and ready to copy and paste.
GDD是對遊戲的描述,所以他也是對於公眾關係與行銷面的好文件,它應該能傳達遊戲的美感。

Prospective employees’ skills can be quickly assessed as qualified or not by looking at their credentials alongside their positions’ corresponding sections in the document.
有潛力員工的技能也可以從的文件中相對應的部分而得知。

If fundraising is in the cards for your team, it will be crucial to have a well put together GDD for investors to look over and determine the risks of your development, as well as your ability to deliver on your promises.
假如團隊要進行群眾募資,將這份文件揭露給投資人讓他們能夠檢視團隊及開發風險,也是如承諾與技能同等重要。

A GDD Keeps Everyone on the Same Page
GDD可以將每個成員對遊戲的視野統一

Creating and adhering to a game design document is like planting a seed and watching it grow into a tree over the course of development. You have your initial preparation, cultivation, and ultimately the gruesome and backbreaking toil of the harvest.
創造一份遊戲開發文件就像是種下一個種子,試著在開發期看他長成一棵樹。你有一開始的準備,雕琢,最後辛苦地收割下來。

A common mistake is not handing all your team members the proper gardening tools to make your game a reality. The GDD will help make sure everyone is working together, so that you don’t find your programmer and artist cutting off the branch they are standing on.
一個常見的錯誤是沒有給予你的團隊成員適當的耕耘工具,所以遊戲才無法真正完成。GDD會協助每個人在一起合作,因此不會因為互相不知道對方的開發進度而扯後腿。

Common Mistakes
常見的錯誤

Trying to Describe Everything at Once
試著在一個地方描述所有的細節

It is not necessary to list every feature and mechanic in detail in the first draft. This is impossible when working on a complex game with a small team. Outlining the major nodes of gameplay and core elements will help give you perspective on what needs to get done, but you should expect to fill them in one by one, over time.
不需要在一開始的時候把所有的特點及運作機制寫得很詳細,對一個遊戲及小團隊來說那是不可能的。試著描繪遊戲玩法及核心要素的外觀描述出來,隨之也會明白該做的事情。試著一步一步隨著時間填滿這份文件。

Not Setting Deadlines
沒有設定完成時間

Setting game goals with deadlines may seem off-putting to some developers. Deadlines are a part of the boring 9-to-5 lifestyle, so many people have a natural aversion to them.
設定遊戲目標與完成時間讓有些開發人員厭煩,因為完成時間就像是每天朝九晚五的工作讓人自然地逃避。

However, setting deadlines is how you ensure that your game will get made and not sit forever unfinished in a folder on your desktop. These types of goals are milestones on the road to progress, and passing them one by one is a clear indication that you are doing something right. Each is a cause for celebration.
然而,設定完成時間是確保遊戲做完,而不是留在文件階段的方法。這樣的方法就是在開發中設定里程碑,一個接一個地完成也代表了專案朝向正確的方向。每個階段都值得舉杯慶祝。

Deadlines are a basic component of scheduling that helps you monitor the performance of your team and yourself. It aids in decision making that is rooted in reality, and eventually builds up a momentum and ethic that is healthy for the team as a whole and the individuals within it.
而完成時間則是排時程的基本要素,這會幫助我們了解團隊與自己的工作效能。同時會協助我們做出基於現實的決定,基於對團隊或其中每個成員的開發能量與工作倫理的了解。

Assuming Everyone Knows What to Add
讓每個人都知道要做甚麼

There is room in the GDD for basic descriptions that cover gameplay, storylines, and major coding tasks. As development progresses, you add more details to these sections. While creating and testing the game, you should add or update specific technical details every time a feature is implemented or changed. This way, you’ll never have a build with elements that you can’t trace back to the GDD, creating missing links of ideas, code or art. It can also be helpful to add information about the difficulty of implementing certain tasks, and whether they have been fully integrated into the game or may require further revision.
在GDD中對核心玩法,故事劇情,主要的功能都會有描述的章節。當開發進行的時候,就還會持續增加。當實作及測試遊戲,也會隨之增加或修改功能。因此遊戲中所有的元件都會在GDD中找得到。同時對工作的困難度,是否在本版本中要整合進來也可以註記在上面。

Throughout this process, your initial concepts should be trickling down into ever more detailed descriptions of each facet your features contain. This helps make concrete milestones that are easy to navigate and backtrack to see where they originated and where they need to go.
經過這個流程,初始點子應該已經變成一個詳細描述遊戲各個面向的文件了。這樣我們就可以知道里程碑應該要怎麼規劃,同時也知道該完成的項目。

As the GDD continues to grow and become more finalized it is still important to keep it up to date. This eliminates situations where team members do something without being able to justify why they spent time doing them, which is crucial come crunch time.
當GDD成長,持續更新的手續就開始變的重要。這還會減少團隊成員因為不明原因而去進行開發的狀況。

Printing the GDD
印出GDD

Personally, I have an unexplained primal fear of drowning in a heap of printed documentation. This would become a real nightmare if I had to keep all old versions of our GDD for every team member.
以我個人來說,我對於一堆印出的文件有種恐懼,尤其是那些舊的版本。

Why should we torture ourselves like this in the age of digital technology? There are plenty of free online services like Google Docs or Trello that let you save all changes and see all your team’s comments in real time.
在數位的時代我們已經不需要這樣折磨自己,有很多像Google Doc或Trello這樣的免費線上服務可以讓我們即時地儲存團隊的意見。

How to Write an Effective GDD
怎麼有效率的寫GDD

Write It in Stages
分階段寫

When starting the GDD, it is normal to get wrapped up in concepts. Backgrounds, introductions, and key descriptions help to flesh out the game and give it shape. As you begin to test and implement features, these concepts should become more refined, specified and detailed. Maintaining proper organization will become more and more critical as your GDD gains weight and density.
在開始寫GDD的時候,很正常會從概念,背景,介紹,關鍵描述開始,讓人能夠了解這個遊戲的外貌。當你在測試與開發的時候,概念就變的過於細節。當你的GDD開始變大時適當地維護他們就變得很重要。

Start in the concept phase, where you brainstorm your ideas and get them all down on paper. This should be exciting! It will also serve as a roadmap so you don’t lose track of your goals and vision along the way. When the appeal of certain game elements lose their lustre or lead you into a ditch, it may be time to rework your initial concept to make sure you reach a satisfying finish line.
從概念開始,那時是作腦力激盪,也是最刺激的時候。那時也會設定下長線的路線,讓團隊可以一路跟隨這些信標。當實作一些元件出現困難的時候,也不妨回頭從這些概念重新思考,設定比較可能的完成時間。

Towards the middle of development, once you have a gung-ho team on board, discussions and game builds will help sculpt and organize the document into an easy to use and hefty guide for everyone. There’s still room for experimenting with new concepts and ideas at this point, but they should be kept in check with some of your initial documentation.
在開發的中途,團隊開始成形,讓這份文件可以協助每一個人了解及使用。這時仍有一些對於概念的實驗空間,但修改時應該同時檢驗初始文件。

The home stretch of development is where your game design document will save you hours of frustration and heartache. As you close in on release your GDD should slowly start turning into a stone tablet, with features and mechanics set in more permanent game builds all held together by art that was surely crafted over multiple iterations to match the document’s specifications. The document should help keep all the team’s wheels on the ground, with a good line of sight on realistic expectations on delivering the game.
針對原始設計的探討會節省很多頭痛的時間。當專案接近釋出時,GDD就應該慢慢變成石板,特色與機制漸漸固定下來,遊戲的內容則由美術開始填滿,試著與文件描述的一致。文件會協助開發團隊固定在地面上,協助專案實際釋出到市場上。

It is not necessary to have an absolutely complete GDD before starting development. But the GDD must be complete for the next 10 days or two weeks beyond your team’s current work—and the relevant parts of the document must be as detailed as possible.
在開發之前,GDD不一定要很完整。但文件一定要能夠供應十天或兩個禮拜的開發。團隊開發進度的文件一定要描述得很完整。

Allow Changes During Your Game’s Development
在開發過程中允許改變

Parts of the GDD will have to be changed and modified throughout the entire development process, sometimes even in the final days before release. It can start to resemble a disaster zone if the content is not trimmed properly. If you are afraid of deleting text that is outdated, cut and paste it into an addendum or separate document. This will leave the main body of the GDD relevant to the current state of development, without all the distractions of previous iterations.
在開發時程時,部分GDD應該可以修改,有時甚至在釋出之前。那可以把一些內容縮減到不至於造成災難的地步。如果團隊害怕刪除文件,試著把過時的段落搬到一個補充文件中。讓目前開發的進度能與GDD一致,同時避免不相干的文件。

Don’t ever stop team members submitting new ideas. Idea creation is one of the most rewarding parts of development, and should be encouraged at all times. Your team members should head into development knowing that many of these concepts will be cut and never make it into the game, but this shouldn’t stop them from dreaming! No one knows what ideas will produce the best results at first, so generating new and innovative ideas should be a staple of your discussions and celebrated accordingly.
不要禁止團隊成員增加點子,點子也是開發的一部份,該一直被鼓勵,團隊會自己縮減那些放不進遊戲的部分,但不需要阻止開發者思考。也許這些點子將來都會有用,所以產生新點子應該隨著討論發生。

Put Just One Person in Control of It
只讓一個人控制文件

Supervision of the GDD must be performed only by one team member. They will identify the key ideas that must be focused on, and cut the less important ideas.
應該只派一個人來監控文件,標訂出關鍵需要關注的點子,削減不重要的部分。

Encouraging active feedback is important, then, because other team members do not have the chance to add their ideas to the document directly.
鼓勵正面回饋很重要,因為其他成員沒辦法直接把點子放到文件上。

Most development issues are comprised of a hard outer shell of miscommunication and a soft interior of not knowing how to compensate and correct them. These barriers can be eliminated with vigilant maintenance of the GDD and clear, concise documentation, and this can best be achieved if one person takes on that responsibility.
大多數開發的問題都來自於在外跟團隊難以溝通,在內不知道如何改變修正問題。這問題可以用小心的修正GDD以及清楚簡潔的文件來解決,特別是有專人來負責的話。

Focus on Readability
專注於可讀性

Be consistent with font styles and using uniform headers and indentations, punctuation, and formatting. Creating a legend or key to explain what specific colored highlights mean can go a long way toward reducing confusion and cutting down on the time it takes to convey the stages of different features’ implementation.
讓字型,標題,縮排,標點,格式維持一致。對於各種顏色的註解先做出定義,可以降低對文件的誤解與搞懂不同開發時程文件之間的時間。

Keep the Language Clear
使用簡單的語言

The simpler and clearer you keep the language in the GDD, the better your team will understand it.
在GDD中使用越簡單清楚的語言,團隊就更能理解它。

It’s important to keep the writing clear and concise, and your team should actively give you feedback about the presentation and clarity of the GDD. A back-and-forth dynamic will result in a more cohesive development experience, with overarching benefits including a defined art style, fewer communication errors, and less stressful documentation and office work.
讓撰文清楚簡潔是很重要的,團隊應該主動地給你有關GDD清楚程度的回饋。動態地一來一往修改可以讓風格固定,減少溝通錯誤,減少過分撰寫的文件,跟行政工作。

But most importantly, the GDD should be a reflection of your team culture, created in whatever format you find works best and is most appealing to you and those you work with.
但最重要的是,GDD會成為團隊文化的鏡子,團隊如何工作的縮影,了解自己與一起工作的團隊。

Use Visual Aids
使用視覺的工具

No one should ever be able to say that they haven’t understood something, or done something correctly, due to a lack of reference material in the GDD.
在GDD中,不該應為缺乏補充素材而讓人覺得看不懂或做不對。

Visual materials and references play a key role in the process of conveying ideas. Some difficult concepts can be explained in less time with visual aids like graphs and concept art. This will help ensure every team member understands the information that is conveyed to them, which in return will help them to complete development tasks faster.
視覺的素材與參考會是傳達資訊時的重要工具。有些複雜概念可以透過視覺素材或概念圖在很快的時間解釋清楚。幫助每個團隊成員了解這些資訊,也就是幫助他們能夠更快完成開發工作。

Put Some Passion Into It
在文件中加入熱情

You should not restrict yourself to dry text. (If you do, you’ll be waiting a long time for everyone to get engaged and understand the main ideas!) Try to describe the players’ emotions and the experiences that the game might cultivate.
你不應該把文件只視為文字而已。試著用玩過遊戲後的玩家感情與經驗來撰寫描述。

Keeping a GDD may sound technical, but you shouldn’t be afraid to tear your heart out and throw it at the document. Let your emotion and passion bleed into it. Imagine how you want to make the player feel, and write those aspirations down alongside the descriptions of your features. This helps to cultivate a collective consciousness in your team about what your game is trying to convey to the player—and, let’s face it, feelings should have enthusiasm behind them if you want them to be understood by anyone else.
GDD可能聽起來是很技術性的文件,但是你不應該害怕把情感放入。讓情感與熱情能夠融入其中,讓讀者覺得想要讓玩家感覺到甚麼,寫下那些鼓舞的字句。這會培育團隊的集體意識,讓他們試著把遊戲傳達給玩家,而這些是需要熱情在後面支援的。

Use It to Keep People on Track
使用GDD讓大家跟上腳步

Set the priorities of tasks and features, document their deadlines, and control their execution. You can’t develop absolutely all the ideas which your team and your mind will propose, so (after you’ve cut some of them), you need to set their priorities and at least approximate a schedule for their implementation.
設定那些工作與特點的優先度,註記完成時間,關心執行狀況。你沒辦法完成全部的細節,所以你必須設定優先度及時程表。

A well-groomed GDD makes for an excellent, prioritized list of tasks that need to be completed by your team. Not all the features in a GDD will make it into the final game. With this in mind, you must decide which features take precedence over others, and you should schedule them for implementation and testing before those others.
一個好的GDD會有搭配一份優秀,有優先度的須完成工作清單。並非所有的特點都匯完成。因此我們必須決定哪些特點必須先於其他的,排出完成的時程及優先測試。

Think hard about what is critical for your game, and what is possible given your team’s skill level, and use that information to guide your production.
認真思考對你的遊戲來說甚麼是至極重要的,甚麼是能夠由團隊的專業等級完成的。用這些資訊來引導開發。

A solid GDD can also help ease new team members into the project, and get them just as excited about it as you are.
紮實的GDD也能幫助協助新團隊成員進入專案,讓他們跟團隊成員一樣對專案有熱忱。

Since a fully outlined GDD may result in what seems like an excessively daunting game to make, it is good to remember that more than one person will be fleshing out its specifics. Assigning your team members tasks in the GDD will help it to become more robust while keeping everyone on the same page. Anyone can jump in to the document and see what has been completed, what tasks lay before them and the rest of the team, and why they are working on their current task.
一份完整的GDD可能就像一個複雜的遊戲,但記得這份文件是全部團隊都該注意的。指派文件內的工作給團隊成員,會讓文件更加通用,讓大家視野一致。任何人都應該能夠看到這份文件,同時知道甚麼已經被做完,甚麼工作正橫亙在眼前,以及現在工作的目的。

Continue Having Design Discussions
持續討論設計

Writing something in a shared GDD shouldn’t minimize or eliminate discussion with the team, it should serve to increase team discussion and improve your communication dynamics. It’s important that everyone clearly understands how you (and the other team members) imagine each feature of the game.
把東西寫進文件裡面與持續溝通討論並不互相衝突,文件應該是能提高團隊討論的頻率,增進溝通。讓每個人都能想像這個遊戲的特點。

Cutting ideas can be difficult and unnerving, but it is a process innate to creating games. Making sure that open, free discussion is a part of development will help ease the inherent tensions here, without dissuading members from being creative.
縮減規格是困難且不安的,但這是創作的一個部分。確保開放自由的討論是開發的一個部分,減少內部的壓力,不要因為創作而把成員擋在外面。

Play the Game In Your Mind
在腦海中試玩遊戲

I found many good ideas virtually playing the game in my mind, both before and during the game’s creation. Of course, this doesn’t give any guarantee that those ideas will take roots in the game during development and testing but, especially in the early stages, it’s a good method of brainstorming.
我在腦海中可以虛擬地試玩遊戲點子,不管在遊戲創造前或創造中。當然這不代表這個點子會真正實現,特別是在開發的早期。但這是一個很好的腦力激盪。

Set Realistic Goals
設定實際的目標

While it is good to foster an air of excitement within a team, it is equally important to keep your game goals embedded in reality. Mechanics and complex enemy and level behaviors always look great on paper, but reality has a way of corroding the grandeur of certain game elements, and this should be expected.
能夠培育團隊是一件令人興奮的事,但這與設定現實的團隊目標不相牴觸。遊戲機制,複雜的敵人與關卡行為在紙上的時候都令人驚艷,但實際常常會大相逕庭。

Consequences of updates and changes are almost impossible to foresee ahead of time in some situations, so just remember it is your job to try and limit the amount of remodelling that needs to be done when changes arise. If you make it common practice to play through new ideas in your mind before putting them down on paper, you stand a greater chance of keeping development goals rooted in realistic expectations.
一連串的更新與規格修改幾乎是無法事先預見,特別是預估時間與狀況,所以謹記你的工作就是試著在規格改變開始時限縮重構的次數。假如你能夠在真正實作之前就在腦海中想過一遍,那麼有很高的機率在實際的世界中也能一樣運作。

Make Use of Free Online Tools
使用線上工具

Our team is multinational. We live around the world, in different time-zones, and this makes it impossible to use print versions of documents for everyone, and difficult to have real-time conversations. Using tools such as Skype (for conversations), Google Drive (for sharing files), Google Docs (for collaborating on documents, and sharing the GDD), and FlockDraw (for digital drawings) can really help with explanations and discussions.
團隊是國際化的,我們住在世界各地,不同的時區,這讓我們無法用紙上文件來作業,也無法即時通話。透過Skype,Google Drive,Google Docs,及FlockDraw能夠實際幫助我們討論與解釋想法.

Conclusion
結論

If you find yourself on the fence about whether maintaining a GDD is necessary for your game’s production, you should take a good, hard look at how you envision development. There are almost certainly times where real life and full time jobs will get in the way of game making, or your implementation of features and mechanics simply does not work out.
假如你正在爭論是否要維護一份GDD的時候,你應該認真地看看你想要怎麼開發。工作與挑戰會持續出現,而常常實作的內容與機制都不管用。

On the stormy seas of game development, a healthy GDD can serve as a sturdy and solid vessel, and even a lifeboat at times. It is a detailed journal of your struggles and triumphs, a collection of thoughts and ideas for you to fall back on during hard times. You might find that improving the quality of the GDD trickles down into the rest of development as well, raising the bar across the board for your team. It should serve as a sturdy hub to facilitate team discussion and generate new, even greater ideas. At the same time, it can keep these concepts in realistic check.
在這個充滿挑戰的遊戲開發,一份健康的GDD會是一艘耐用且堅實的戰艦,甚至是一艘救生艇。那會是開發途中掙扎與喜悅的日記,想法與點子的工具箱。開發中,GDD品質就會不斷提升,提高團隊的能力。把他想成是支援團隊討論與產生新點子的堅實後盾,同時也是能夠把概念實際執行的紀錄。

The benefits of this type of efficiency may seem small when looked at individually, but over the long course of development, it builds up a wonderful kind of momentum. Ultimately, this type of document should propel, compel, and inspire you and your team to finish what you started. It should show you that your game has a plan that can be realized.
這種的優勢從一個個人的角度來看可能並不強烈,但在長時間開發中,它會建立一個完美的動量,驅策,啟發你與團隊完成工作。這份文件應該把遊戲以一個可被完成的計畫的形式來顯示。

And after you have finished your game, your GDD will stand as a testament to all of your hard work and efforts, the behind-the-scenes of an elaborate experience to be enjoyed by all.
在你完成遊戲之後,你的GDD會變成辛苦工作的鐵證,被幕後所有製作人員所享受的合作經驗。

廣告

5 thoughts on “[翻譯] 如何(以及為何)寫出一份優秀的遊戲設計文件

  1. 版主你好~我最近要開遊戲公司,想跟你請教一些問題方便跟你聯絡嗎?

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s