游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

如何以及为何要编写一份游戏设计文件

发布时间:2016-01-12 16:38:20 Tags:,,,,

作者:Alex Sayenko

每个独立开发者或团队都会问自己如何最有效地管理开发过程。使用详尽的文件是否必要,如传说中的游戏设计文件(GDD)?最常见的问题是什么?该如何避免这些问题?

对于那些已经寻找过这些问题的答案的人,我想要在此分享我们团队在创造自己的GDD的经验。

为什么你需要一份GDD?

优秀的文件是必须的

许多游戏设计师都忽视了创造设计文件与组织理念的过程。我不能想象当这些设计师在面对故障代码,占位符图像和破损的机制的同时还要努力回忆为什么会出现这些情况时的情形。

通常在这种情况下出色的游戏设计文件总是能够成为你的支柱。它将帮助你看清楚那些推动自己在开始创造游戏时夜以继日坚持下去的出色理念,或者更重要的是帮助你看到那些需要从游戏中删除从而让自己的工作变得更简单的内容,再或者是帮你决定是否需要重新创造某些内容以对得起自己之前的努力。

GDD能够帮助游戏设计与开发

一份游戏设计文件能够作为连接游戏每一面的中心点。它将包含书面描述,图像,图表以及与开发每个部分相关的信息,并且它总是由游戏中的功能以及这些功能之间的联系所构成。

创造一份GDD能够帮助你的团队设计师更好地理解游戏中的必要元素并规划其主导游戏世界和游戏玩法的范围。再加上拥有一份包含所有游戏元素的文件还能够帮助设计师更轻松地向其余团队成员传达自己的看法,并更有效地找出游戏的缺陷或者遗漏的组件。

我们应该将GDD当成主要清单。它将是你在完成游戏的所有部分的庆祝空挡所创造出的文件。

document(from frbiz)

document(from frbiz)

GDD将在其它领域提供帮助

创造并跟随游戏设计文件就像播撒种子并看着它在开发过程中成长成一棵苍天大树一样。你将拥有从初步准备,成长阶段到最终的辛苦收获的过程。

这里的一个常见问题是并未提供给所有团队成员适当的“园艺工具”去创造你的游戏。GDD能够帮助你确保所有人的相互协作,但也因此当你的程序员和美术师切断了他们所站立的树枝时你将全然不知。

常见的问题

尝试着马上描述出所有内容

在初稿中详细列出所有功能和机制是不必要的。这对于在一支小团队中致力于一款复杂游戏来说是不可能的事。列出游戏玩法和核心元素的主要节点能够帮助你明确需要完成什么,同时你也需要一步一步去实现它们,不可操之过急。

没有设定截止期限

似乎有些开发者都不愿为游戏目标设定截止期限。截止期限是无聊的朝九晚五生活方式中的一部分,所以很多人都不喜欢它。

然而设定截止期限能够帮你确保游戏是否完成了并避免你的计算机里永远都会躺着一份未完成的文件夹。这类型目标便是你在前进道路上的里程碑,而通过它们也预示着你完成了某些事。这些都是值得庆祝的事。

截止期限是能够帮助你判断团队和自己绩效的基本排程。它能够帮助你判断决策的制定是否现实,并最终创造出对团队整体以及里面的个体有益的势头。

假设每个人都知道该添加什么

GDD中存在一个包含游戏玩法,故事线和主要编程任务的基本描述。在开发过程中你将添加更多细节到这些部分中。而在创造并测试游戏的同时,你也会在每次执行或改变一个功能时添加或更新一些特定的技术细节。基于这种方式,你可以在GDD中找到各种之前的元素,并且能够创造一些遗漏的理念,代码或图像链接。这对于添加有关执行特定任务的难度,它们是否能够完全整合到游戏中或者是否需要额外调整等信息也很有帮助。

经过这一过程,你最初的理念将逐渐延伸到你的功能所包含的每一面的细节描述中。这将帮助你更轻松地了解所有特定里程碑的起源与终点。

因为GDD将继续发展并不断完善,所以保持更新也非常重要。这能够解决团队成员不知道自己为什么要花大把时间去做某事的情况。

打印GDD

就我个人来讲,我非常厌恶被一大堆印刷文件所淹没。如果我将之前每支团队成员的GDD都保留着的话这对我来说将是一场真实的噩梦。

为什么在数字科技时代我们还要如此折磨自己?现在的我们拥有许多像谷歌Docs或Trellp等免费的在线服务能够帮助你保存所有改变并实时检查所有团队成员的评价。

如何编写一份有效的GDD

按阶段进行编写

当开始编写GDD时,我们通常都会埋头于概念中。像背景,介绍以及关键描述都能够帮助我们具体呈现出游戏轮廓。当你开始测试并执行功能时,这些概念将变得更加完善,具体。当你的GDD变得更加重要且完整时,维持适当的结构便变得更加重要。

从概念阶段开始,这时候你们可以使用头脑风暴会议去讨论理念并将其记在纸上。这是非常让人兴奋的事!这将变成你的路标并避免你在发展过程中忘记最初的目标与观点。当一些特定游戏元素失去魅力或将你带向下坡路时,你便需要调整最初的理念并确保自己能够到达一个让人满意的终点线上。

在开发的冲刺阶段,你的游戏设计文件将保存一些让你受挫与心痛的时刻。当你接近发行阶段时,你的GDD将慢慢变成碑碣一般的存在,即更加可靠的游戏架构带有功能,机制,图像以及多个迭代去满足文件的规格。这份文件应该能够确保整支团队以现实的眼光去交付游戏,

接受游戏开发期间的改变

在整个开发过程中你将不得不改变部分GDD内容,有时候甚至是在发行前最后几天需要做出调整。如果你的内容不能达到平衡的话它将变成一个灾难区。如果你不想删除一些过时的文本,那就将其剪切黏贴到一个附录文件中。这能够保持你的GDD主题与当前的开发状态相匹配,而不存在一些不相干的内容。

不要阻止团队成员继续提出新理念。理念创造是开发中最有益的部分之一,这是我们应该一直倡导的部分。你的团队成员应该深入开发过程并了解各种将被删除并且永远不会被带进游戏中的概念,但前提是这不会阻止他们继续幻想!一开始没人会知道哪个理念能够创造出最棒的效果,所以你应该将创造全新且具有创造性的理念当成是讨论与庆祝的主要对象。

只安排一个人去管理它

你最好只安排一名团队成员去管理GDD。他们将审查需要关注的关键理念并删减不那么重要的理念。

鼓励积极反馈非常重要,因为其他团队成员往往没什么机会直接将自己的理念添加到文件中。

大多数开发问题都是由带有坚硬外壳的误解与不了解如何纠正它们的本质所组成。而如何能够有效维护GDD并保持文件的清晰整洁, 你便能够有效缓解这些障碍,而如果有一个人能够担负起这项责任,你们便能够更有效地做到这点。

专注于可读性

确保语言足够清晰

保持GDD中的语言更简单且更清晰的话,你的团队便能够更轻松地理解它。

你必须确保编写内容足够清楚且简单,你的团队也需要积极地提供给你有关GDD表达的反馈。如此来回的动态交流将帮助你们创造出更具有凝结力的开发体验,即包含了明确的美术风格,较少的交流问题以及较轻松的文件制定与工作任务。

但是最重要的还是,GDD应该反应出你的团队文化,即基于你们能够最有效工作且最能够吸引你与团队成员的工作模式。

使用视觉帮助

没有人会说因为GDD中缺少参考对象而导致自己不理解某些内容或者未能正确做好某事。

视觉材料与参考内容在传达理念的过程中扮演着一个关键角色。即基于像图表和概念艺术等视觉帮助,我们可以使用更少时间去解释一些复杂的理念。这也能够保证每位团队成员能够更轻松地理解那些自己所接收到的信息,并帮助他们更快速地完成开发任务。

投入一些热情

你不应该只局限于这些干巴巴的文本内容。(如此你便需要等待很长时间才能让所有人真正理解你的主要理念!)你可以尝试着描述游戏可能集大发玩家情感以及玩家体验。

确保你的GDD听起来够专业,并且你应该真正倾注自己的心血于其中。将你的情感与激情投入于此。想象自己希望玩家有什么感受,并在描述功能的过程中记录下所有的这些灵感。这能够培养你们团队有关游戏想要传达给玩家的内容的集体意识—-我们必须牢记,如果你希望所有人能够理解你想要传达的某种情感,那么这种情感便必须具有热情!

使用它去引导别人

设定任务和功能的优先顺序,记下它们的截止期限,并控制它们的执行。你不可能去开发你和团队想开发的所有理念,所以你便需要为它们设定先后顺序,至少需要规划它们的执行时间。

一份整洁的GDD有助于你罗列出团队需要执行的任务先后列表。并非GDD中的所有功能都能被添加到最终游戏中。牢记这点后你便需要决定哪些功能先于其它功能执行,并制定它们的执行与测试时间。

仔细思考什么内容对你的游戏最重要,并且是否能够提供给你的团队相关技能,然后使用这一信息去引导生产过程。

一份有效的GDD同时也能够吸引全新团队成员加入项目中,并让他们对你所做的事感兴趣。

在GDD中分配你的团队成员任务将使得这份文件变得更强大并确保所有人都处于同样的节奏上。任何进入该文件的人都能看到你们团队完成了什么内容,他们以及团队面对着怎样的任务以及为什么他们要致力于当前的任务中。

持续进行设计讨论

在分享性的GDD中编写某些内容并不等于减少与团队间的对话,它将进一步推动团队间的讨论并完善你的交流方式。你必须确保所有人都能够理解你对于游戏中每个功能的设想。

删减理念是很困难的事,但这却是创造游戏的特定过程。保证开放自由的讨论是开发的组成部分,并且能够缓解一些内在的紧张感且推动团队成员更大地发挥创造性。

在脑子里玩游戏

在创造游戏之前或创造游戏过程中我都会在脑子里尝试着设想一些不错的想法。当然了这并不能保证这些理念在开发和测试过程中便会扎根于游戏中,特别是在早前阶段,这其实是一种有效的头脑风暴方式。

树立一些现实的目标

尽管培养团队间的兴奋氛围很重要,但是你也必须确保你们的游戏目标始终具有现实性。在书面上,机制,复杂的敌人和关卡行为总是看起来很不错,但现实总是会基于某种方式去吞噬特定的游戏元素,你应该想到这点。

利用免费在线工具

我们的团队成员来自不同国家。我们生活在不同国家,不同时区,所以我们不可能使用印刷版本的文件,并且我们也很难进行实时会议。所以使用像Skye,Google Drive,Google Docs和FlockDraw等免费工具能够帮助我们更好地进行解释与讨论。

结论

如果你发现自己对维护一份GDD对于游戏制作是否必要保持中立态度,你便可以仔细着眼于自己的想象开发过程。当然了。现实生活和自己的全职工作有可能阻碍到你的游戏创造,或者你会遇到功能和机制未能如期有效运行等情况。

在波涛汹涌的游戏开发过程中,一份有效的GDD就是一艘坚实可靠的船只,有时候甚至能够充当救生艇的角色。这是关于你的努力和胜利的详细记录,这是你在艰难时期能够回顾的所有想法集合。你可能会发现对于GDD的完善将影响到剩下的开发过程。这是推动团队讨论并生成全新且更出色理念的坚实核心。同时它也能够确保这些理念足够现实。

也许从个体看来这些效能的好处并不大,但在整个开发过程中它们将逐渐创造出一个巨大的势头。最终,这类型文件将推动你和团队去完成你们在一开始所决定创造的内容。你也将看到你的游戏拥有一个能够实现的规划。

当你完成游戏时,你的GDD将作为你的所有付出与努力的证明,这也是所有人所体验到的内容的幕后花絮。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转发,如需转载请联系:游戏邦

How (and Why) to Write a Great Game Design Document

by Alex Sayenko

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.

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.

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.

A GDD Helps in Other Areas, Too

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.

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

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.

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.

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.

Printing the 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.

How to Write an Effective 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Use It to Keep People on Track

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.

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.

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.

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.

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.

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.

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.(source:gamedevelopment

 


上一篇:

下一篇: