脑图

这是一篇关于撰写系统策划案的“套路”，一份优秀的系统策划案，我认为分为以下部分：

1.概述

阅读对象： 程序、美术、制作人

设计目的：阐述该系统、该玩法设计的目的。一方面用于让团队中其他的开发小伙伴理解需求的目的，另一方面则是策划对自己自圆其说的一个体现，如果开发这个系统或者功能连自己都不列出有理有据的理由说服自己，那还有什么意义呢。

需求类型：该需求是全新的功能还是对原先功能的改造。

预计产出：通过该需求文档希望能够得到什么样的产出。

框架图（结构图）：该系统的框架【Xmind】。

2.涉及的资源调配以及人员配合

并不是所有的开发人员都会关注通过该需求文档会实现什么效果，他们关注的往往是我要做些什么、我要和谁一起做、我要在什么时间点前完成。因此下列三点需要在文档的前言阐述清楚。

阅读对象：程序、美术、制作人

所需资源：完成开发需要哪些资源。

资源配合：完成工作需要的组内配合，资源如何配合来完成工作。

预计工期：各自工作的内容以及完成时间。

3.需求细化

阅读对象：程序、美术

详细阐述功能：但是注意语言精练、简洁，没有歧义。

分点罗列细节：适宜使用单句。

流程图：相关的逻辑流程 【VISIO】。

前端页面（界面）迁移图：使用表格或者流程图展示界面的关系，点击弹出或者是跳转哪个界面需要罗列清楚。

配置表（数据表）：设计好配置表的逻辑，包括提取需要使用的配置字段，字段的类型（整形还是浮点型，多少位小数，范围）。

美术需求清单：风格概念图以及原型图，包括原画、3D模型、3D动作、3D动画与特效、2D UI界面等，需要罗列清楚需要用到的美术资源，提供参考的风格概念图。

音效需求：如果有需要音效的部分，还需要描述音效需求。

测试工具：需要开发人员开发的GM或相关的测试工具

4.与其他功能的关联和影响

阅读对象：程序、数值策划、制作人

配合关联：本系统/玩法与原来的系统/玩法是否关联，如何配合，改动后是否造成影响，解决方案。

数值影响：分配原则，在分配比重是否需要调整。

投放原则：计划在哪个阶段投放该系统或者玩法。

5.其他需求

阅读对象：程序

数据打点：数据，是唯一能验证用户是否喜爱产品的指标。因此，当策划希望在游戏中通过得到玩家的哪些数据行为

断线重连、弱联网状态下的情况

防作弊：如果是一款联网游戏，还需要考虑如何做防作弊。防作弊通常会采用数据验证的方法，比方说前后端的某个数据值是否一致，前后端的时间戳或者计时时钟是否一致，某个值是否合理等等。

6.基本的测试用例

阅读对象：测试

整体流程：整体的运作流程可以跑通。

实现程度：将系统/玩法划分为条目，并标记是否已经全部完成，或者还差哪些，什么日期可以进行测试。

分布拆解：按照流程图，一步一步进行测试以及纠错。

表现是否正常（前端）：前端展示。

数据存储调用是否正确（后端）：数据是否正确，刷新是否及时。

与其他系统的关联性测试：对于可能会造成原来系统/玩法的部分，着重进行测试。

一份策划案应该包含以上的要点，但是并不是说所有的部分都需要详细写出来，这样效率也不高，而且洋洋洒洒写下一份几万字的文档，也不会有人去看。上文所提到的部分，全都是开发过程中可能会遇到的问题，在开发过程中可能并不是以策划案的形式写出来，比方说有的问题可能用口头沟通或以几行字就可以阐述清楚了。

我建议新人可以使用上述罗列的点完成几份策划案，一方面是可以了解游戏开发过程中设计的部分、提升工作的熟练度，另一方面则是能够更好地从多个角度去考虑自己负责开发的内容、提升全局感。

另外就是，策划案的方式有非常多样，用哪一种都可以，最重要的是需求能够成功传达给开发的小伙伴。具体用哪一种形式，这有赖于自己和团队中其他小伙伴的合作程度又或者是工作习惯的原因。比方说我见过一些老策划和一些经常搭档的程序提需求，需求就直接说几句话就可以完成了，因为他们的全局感已经建立，细节都已经了然于胸。也有一些年轻程序，他们所希望的是尽可能将逻辑更多的写清楚、写明白，这个时候一份详细的策划案可能对于你和他来说都能够提升工作的效率，这样就可以避免他自己想不懂而导致工作过程中过多花费时间的沟通又或者是完成的需求产生偏差。