游戏设计文档该如何写？

分享一下我自己的系统设计文档习惯吧，抛个砖。

==工具==

我用得顺手的工具是微软的PowerPoint，算是策划群体中的异端。我看中的是其方便的制图功能，当然排版的随意跟修改的便利也是很重要的加分项。

==格式==

首先要声明的一点是：策划文档没有统一的格式。当然有些大厂为了沟通的便利，会有文档模板需要遵循。

我自己从业以来一直是在手游行业（非大厂），培养起来的文档制作习惯是按照游戏的系统来区分的，也就是一个系统对应一份文档。具体的内容是这样：

• 设计目标

简要阐述该系统的设计意图，例如希望玩家定时会来查看游戏，或是鼓励玩家之间更多的互动，亦或是粗暴直白的希望玩家花钱。

手游中跟ARM（Acquisition用户获取，Retention留存，Monetization付费）相关的系统会被重点对待，一般来说这些系统的设计目标会根据不同的玩家情景（例如，刚刚输掉一场PK，只想玩5分钟等）结合，以形成网状的覆盖结构。

另外，清晰的设计目标也能够一定程度激发程序及美术同学的创造力，说不定他们会针对你的设计方案提出优化甚至更好的建议。

• 系统的投入/产出

主流手游比较强调游戏中的经济循环，故在设计文档中也需要体现。程序同学也可能根据这部分提出一些疑问，例如资源有没有上限，没有资源时怎么处理等等。

• 玩家交互的流程

文档内容的重点，我自己的习惯写法是按照系统主要状态的切换流程来写，从初始界面UI开始，然后按照玩家的每一步操作来补充剩余的UI。当然，最好还能给美术及程序同学配图说明界面的不同状态（如下图）。

• 参考游戏的截图

当然这并不是说直接拿着别的游戏过来抄袭一下就完事，而是在弄清楚自己的这个系统的目标，经济循环以及体验后，方便跟美术及程序同学交流的工具。

基本上就是这样，当然最重要的还是能够和美术及程序同学无缝对接的沟通能力。

P.S.@LevelNINE‍ 同学也提到诸如流程图或是交互原型，这些是对沟通有帮助的素材，但更是策划自己整理思路以及自检的产物。我自己的经验是，如果能沟通好设计意图以及系统的操作流程，专业的程序跟美术同学是能帮你搞定问题的。

本人此处说的是游戏新功能/玩法的设计文档，也就是策划案。文档工具为word，流程图和UI示意图工具为axure。

1、文章开头做个表格，写好你创建文档的日期。之后每次进行修改，在这个表格当中都要记录日期。没准项目开发到一定地步，老大会让你来个各月进度汇总，记录日期就是那时候用的。

2、开头写明你自己的设计目的和针对设计目的而实施的各部分功能。这里不只是让别人看得明白，更主要的是给你自己看，要不然一个玩法你写着写着没准就写跑了。

3、UI部分画UI示意图，功能流程部分画流程图。方法其他几位都有介绍，不多言。（axure是个极好的东西，多学）

4、文字说明的地方分条说明，每一条尽量不要超过一行，以防程序和美术不认真读。提示性文字等特殊的地方要用特殊颜色字体标出。个人习惯在某部分由某职能人员负责的时候，后面单独加上，如//特效

5、写完之后要从头到尾检查下，确定前后没有逻辑矛盾——就像我说的，没准前面的思路写着写着就被推翻了然而前面还没有改。交上去的版本，至少在你的思维范围内，不要有被人问住的地方。

6、后续工作：说要修改的地方及时修改，美术出UI假图之后记得尽快把原文档当中的UI图替换掉。另外，不管你案子写得有多完善，美术和程序问你的时候，口头解释也一定要解释明白——毕竟有些人比起看文档，更喜欢直接问。

PS. 较长的功能还是做个目录较好。

总结：只有你自己脑子清晰了，你的策划案才能清晰，这是为自己行方便，也是为他人行方便。

设计文档，在说具体的写法之前，应该先明确一点：

这个文档是干嘛用的。

所谓的“设计文档”，我能想到的有以下几种用途：

写给投资人看的，用于拉投资

写给制作人看的，用于立项

写给主策划看的，用于讨论设计

写给程序看的，用于阐明需求

写给美术看的，提需求，确定资源格式

写给QA看的，checklist

写给自己看的，备忘整理思路。

每种文档的侧重点和写法都不一样，所以这是一个非常开放的问题……

还处在学习阶段的发行商产品人员强答一番。赞同@LevelNINE‍ 的答案，“文不如表，表不如图”，并且根据自己的工作经历和师长的教诲做一些补充。我觉得这几条很重要，尽管我并不能完全做到这些：

1、理解他人，用他人理解的方式把自己的创意与设计表达出来。

给程序看的，用数值表、用流程图、用伪代码甚至代码框架告诉他；给美术看的，用UI布局图、用有注释的草图、用网上找到的参考图甚至艺术领域的专有名词告诉他。

不会的话去学，国外（欧美）游戏公司没有不懂技术或者不懂美术的纯策划。

2、养成良好的文档习惯，形成简洁、易读、统一的文档结构。

这也是我组长最近教给我的东西。简洁意味着没有冗余信息去掉干扰，易读意味着每个人能够清晰地看自己的表就可以知道该如何实践工作，统一意味着任何时间都可以轻松调用之前的历史记录。而确定的文档习惯，将会大大提升沟通效率。

具体实施例子，策划案：

Excel表的Sheet 1重命名为版本，记录文档创建、修改的时间、地点、作者等基础信息，便于后期检索；

Sheet 2为总概，最好以概念图的形式阐述后面的模块与概念的逻辑关系，并且将设计目的、设计思路列清楚；

Sheet 3之后每个Sheet都是一个独立模块的具体设计方案，包括这一模块的目标与思路、需要实现的功能、UI与界面布局示意图或效果图等；

如果项目已经开始执行，需要与程序、美术对接的时候，还应单列出给他们自己的Sheet表，里面用图也好、纯数值表也好，达到一个程序或美术人员什么都不用了解，只需要看属于他自己的这一页，做出来的东西就跟你的想法差不多的情景。

3、自己不确定的东西，不要让他们做好之后再要求他人反复修改。

格斗游戏的打击感要精确到零点几秒，如果你不知道，就不要让程序全都做完了再在玩的时候发现好像有的地方不对要加速或者减速；

某个游戏需要做一个稀有道具，你能更清楚地站在玩家角度上告诉美术“金灿灿的感觉最酷炫”（这个本身不一定对），就不要在美术按照自己的“酷炫”理解做完了后，才告诉她不该这样画。

高的标准是，如果你不确定，那就自己写、调代码让零点几秒确定下来，自己选择怎样的色调与怎样的特效。如果做不到（我其实做不到，但国外一些一流游戏公司的策划能做到），至少清楚地告诉他们你想要什么、你想要的哪些东西你不确定需要设计参数、哪些感觉的重要性比艺术感更有价值。

——跑题的分割线——

下面的内容与答案本身无关了，讲一下为什么发行商的产品人员也需要写策划案；以及我是怎样意识到这个结论：好的文档结构对于沟通很重要。希望能给同样岗位的产品人员一点参考，对其他人算科普一下吧。

作为发行商的产品人员，我们与开发商（CP，Content Provider）相比多的是对于游戏见解的广度而非深度，因此我们的优势是能够跳出CP眼中的小众甚至不精准的“目标用户”，把相对更客观、更贴近玩家与市场需求的意见提给他们。

而这种意见往往是与CP一直坚持的东西会有矛盾。

这时候就需要沟通。

沟通的形式无非两种：线上线下的会议讨论，或文档直接传达。前者更准确、但更浪费时间，后者省时但双方经常有误解。

开始的时候我想的很简单，把信息尽可能详细地给到他们，把每个改动意见的来龙去脉讲得不能再详细就行了，具体执行CP的策划们去发挥他们的聪明才智就好了。在这个假设上，我每个文档都洋洋洒洒写了上千字就为了清楚地告诉他们这个改动是多么必要，要往哪个方向努力。结果……

CP说他们理解了我的意思，但做出来的完全与我想的不是一个东西！完全没有把最核心的内容表达出来！

后来反思为什么会是这样出力不讨好。有这样几个理由：

1、每个人的认知不同，文字表述极易造成信息失真。我用我的行文思路和表达习惯，自以为讲得再清楚不过，但别人从他的认知去理解的时候往往会得到另外的结论。

2、CP原有的方案是从多个可行方案中筛选出来的，并且已经在实施方案的时候不断告诉自己这样做是对的。这时候再让他去跳出这个圈子，任何人都不愿意接受。而这种惯性让策划很难基于别人的理解想出符合别人的实施方案。

3、从策划理解，到美术与程序理解还要经过一个信息传递过程。

而对应于这几个理由的改进措施就很明显了：

1、文不如表，表不如图。而文档形式要简洁、统一。

2、基于自己的理解而CP无法理解的情况下，哪怕再粗糙也要做出可行的方案。这样策划能够直接基于新的方案去构思游戏内具体实施，而不必强行改变自己的想法，让执行上受到阻力。

3、文档形式要易读。就是之前提到的那个标准，而不是只有策划案：“达到一个程序或美术人员什么都不用了解，只需要看属于他自己的这一页，做出来的东西就跟你的想法差不多的情景。”

文不如表，表不如图

开发喜欢流程图，你要是不画他们拿到需求也会画一个的

美术和开发还都喜欢原型，好好学Axure吧

坐等Adobe XD

“说人话！”

这个机灵抖得不太好，自我忏悔一下然后说两句吧。

“如何写才显得专业，才能让程序美术理解”这种问题在我看来和“医生怎么和病人家属沟通才能避免冲突，减少纠纷”，以及“出国不会说外语怎么才能与歪果仁进行正常交流”是一样的，都是一个“翻译”的问题。

在这种特殊的沟通环境中，交流的双方所处的信息地位和自身的需求、期望都是不一样、不对等的，当你越想要“专业”、“信达雅”地传递信息的时候，你可能造成的误解就有可能越多。因为你在对自身的想法进行“翻译”，转化成“你觉得”对方能够理解的语句的时候，这其中发生的信息二次加工就有可能加入过多的“主观臆测”，或者是信息的错漏，这样就会引起不必要的误解误判。

那么为了避免这种情况的发生，其实最简单最有效的方法就是……用最简单最通俗的方法来沟通。

你跟病人家属说，“你俩看起来一样，实际他肝儿比你惨多了，所以这药他遭得住，你吃就得死”，一般都不会再乱动别人的药了。

你跟老外比划“咯咯哒”再拍拍自己的大腿，对方也差不多能明白你要吃鸡腿。

话糙理不糙。

所以尽量简洁、直奔主题说你的“需求”，实现“什么目的”。

当然最好还是这两方向你都学点儿……

只说一点。

题主的问题：如何写才显的专业，才能让程序美术理解？    

后半句很好，前半句我不是很喜欢。

写文档的目的是让团队统一思路，知道前进的方向。

文档本身不是高大上的东西，你去翻网上大如GTA的文档，也是朴素充实。

小岛秀夫指挥工作室现在仍然使用纸笔的方式（以前纪录片里看的），一个人坐在隔间里打游戏，有什么想法或者要做的内容，就纸笔写一下，然后拿出去分下去做。感觉就和医院大夫写药方的感觉，那种感觉专业么？绝对不。

至于如何让程序美术理解，这就是比较偏执行的内容了。

和别人交流，本身就会有一些成本。

不管你说做图也好，画流程图也好，都不能解决问题。

不管你写文档写的多好，团队可能看你的文档只会了解30%，你开个会讲一讲，可能会好一些，了解60%。不要想着靠一份文档解决问题。

所以说，怎么处理？

其实也很简单，忘掉策划案这件事情，和团队一起做游戏。（当然，不是说不写，不要搞错我的意思）

融入到团队中去，和大家多交流，交流的多了，相互理解起来才会容易。

大家既然要一起做游戏，那交流就不应该只是文档。

可能是你们一起玩自己做的游戏，一起发现问题，一起创新改进。

但如果硬要说，如何做一份优雅地文档，让所有人都懂？

那我会写：这个设计抄的是XX游戏的XX，大家下了自己看。

以上

多一些  设计图，用图的方式阐述设计， 少一些含糊不清的文字描述

这个问题需要分开两个部分来回答。

第一是如何写才显得专业。

首先，程序员喜欢看原型图和原型图的跳转关系和了解原型图的逻辑细节，而美术喜欢看原型图，按着原型图来出效果图，除了同事还有你自己，基本上其他人很少会去关心游戏设计文档的具体内容，有不明白的地方直接问你不是更快吗？所以这个问题很简单，把游戏设计文档做成游戏功能的介绍和具体的需求解析(解释？)就可以了，让自己和同事可以有一份游戏功能和玩法参考，让后来加入的同事可以翻看，让自己忘记的时候可以翻看，排版上漂亮一些(这点很重要)，只要满足这些要求，那么就应该符合你”显得专业“的要求了。

第二是让程序和美术理解。

和第一点说的一样，程序和美术一般是不会去看设计文档的，除非你把刀架在他们脖子上，他们一般会要求你给他们提供原型图，他们要什么你就提供什么，他们不明白的地方你就给他们解释一遍，循环这个过程直到他们理解为止。你问我能不能在设计文档上面花点功夫让他们自己去看你就可以一边喝茶去？不存在的。就算你把设计文档写得再好，再差，给他们看，你依旧会回到我说的那个循环里头去，口头说明需求并且解释到他们理解为止，所以想让程序和美术理解你的意图，最好的办法是提升你的沟通能力。

不同的程序和美术有时候需求也是不同的，美术还好点，程序有些甚至会碰到对方不玩游戏或者就玩过一两个游戏的。

也有会很认真看一下文档的，做的时候再逐条去看，比如就一个背包系统物品怎么排序吧有默认→获取，整理后规则又要看品质啊数量啊名称类型什么什么的。之前一起开发的程序就是拿着文档一条条的对着，做完一条规则删一条酱紫。

原型图脑图什么的也很重要，先要让对方明白你要的到底是什么。一般系统UI图也是很容易让对方理解并且自己好说明的，还有表格一些需要策划后期配装的东西先列上，也让对方明白...之前碰到什么都想写死的真的是不知道怎么说了.....

我习惯系统文档是word，demo什么的excel，UI看时间用PS或者axure，脑图框架xmind，流程什么的visio.....

有人说终于的还是沟通能力我是认可的，但如果效率高真的建议写一个非常完善的文档比较好，因为开发流程整体还是很长的，后期维护文档以及可能大家觉得默认但也要说明的小东西都应该好好的呈现在文档上，有更详细的文档至少少争议是吧。

“数缺形时少直观,形少数时难入微,数形结合百般好,隔离分家万事休。”

我觉得这句话能很好的回答。

做原型图给美术，UI，前端展示，直观。

做流程图，规则逻辑给前端，后端展示，有细节。

最简单的指标：

显得专业：把你当成开发去写文档

看得懂：把你当成是小白去读文档