企划案要怎么写（如何撰写优秀的策划案）

很多策划会说：“策划写文档浪费时间，还是过去直接沟通”、“老板不会浪费时间看我的文档拉”、“程序员自己觉得看文档就是浪费时间，要你跑过去直接口述”。然而这只能证明你的文档有问题，并不能证明所有人写的文档都存在以上的问题。

好的文档要求具有下面的一些特点：

1、在设计中抓住广泛理念。

2、为所有部门或者特定部门提供可操作、可视化的方法和过程。很多人写文档，自己都看不懂了...更何谈给程序员。

3、能够为计划安排提供帮助，并提高开发工作效率。

4、给出重点。

5、在设计上，系统相互依存关系和矛盾的点要有可预见性。比如某些数值，某些逻辑冲突。

为什么好的文档比较稀少呢，我想主要在以下几个方面：

1、 设计者综合实力不强，导致很多表述不清楚，或者和基本理念相冲突。设计者基本知识不够，或者知识模糊不清。其实设计者不但要懂策划数值，甚至要懂程序、美术以及沟通等等。

2、设计者对项目本身理解不强，对于设计本身的逻辑理解不到位。设计者本身逻辑思路不行。

3、系统多而杂，同时互相系统交叉，使得设计者难以把握其中关系。

4、设计者总是进行过度的表述和设计。系统设计文档时间要比构筑少，避免方案成为一部“愚蠢的人写的冗长的书”

5、他们不太理解迭代开发

6，设计者不跟紧项目和团队的节奏。设计者很少进行沟通，导致自己陷入自己的想法世界里面去了。

7、设计者不清楚一些文档撰写基本要求。导致文档甚至在阅读方面都很有问题。

其他开发者会说： “给我最短、有目标的、最新的”、“简单精确的”、“列一张表告诉我做啥就行了”等（其他人员对方案要求）。

那么要怎么做，才能写好文档呢？接下来写文档的旅途开始了。

首先我们总是要以一场会议开始，你和主策划一起讨论，阐明以下三个问题：1、系统设计的目的是什么 2、这文档需要回答什么问题 3、这个系统要多复杂。同时我们弄清楚各个系统设计的依据和理论，还要处理设计上的障碍。如果系统设计没有预定的目标，其实很多方案都是可以做的，然而这样最终会导致设计臃肿或者矛盾。比如你可以设计为锻造是一个副业，玩家用来打发时间，可以考虑做。或者说喜欢锻造的玩家可以拥有自己锻造屋和铁铺，通过这个来获得他们财富和声望。显然第二个有目标的方案是我们要的。如果没有目标，就是可做可不做，做了也白做感觉，而且没有目的方案很可能会混乱其他系统，导致系统各种矛盾（没有想清楚目的后果）。

另外要懂得如何划分，在开始会议上，帮你老大理清以下事情：当所有文档都关联起来，要明白哪个系统放到末尾。要明白无误的安排文档设计的先后顺序，避免设计顺序混乱，导致设计断层。要迅速列出第一阶段的设计的特色和特点。

认真地决定特色功能，要重点突出，我们要把我们特色表现的极尽完美。要让特色具有竞争力，但是避免大而空，我们想要让产品在市场中有所区分，但是避免过于冒险，不顾一切的创新（毕竟你不是出钱的，很多策划完全从自己想法出发了）。要和竞品有所区分，创新点要能一击致命，让产品在市场中脱颖而出。

接下来就要调查研究了 。研究之前游戏，特别要研究他们为什么失败。研究非游戏的相关资料，比如你要做一款关于二战的游戏，回去看看历史，看看二战的军械图等等。简单来讲，就是可以从其他领域找到权威资料和灵感。咨询专家，咨询公司的同事，甚至于家里的老奶奶，比如你要一款非常简单的游戏，问老奶奶或者小侄子意见是非常OK的。

灵感来源于头脑风暴，如何头脑风暴呢，比如集合5个以上10个以下的有意思的人，跳出固有思维的怪圈，注意没有想法是最糟糕想法，另外头脑风暴最好要有发散性思路，抓住能够共鸣想法。可以运用思维发散导向的一些软件来辅助发散。要剔除一些糟糕的想法，比如不可实现的（基于现实和团队的能力），完全超越现实，和目标或者其他事项冲突的，怪异的想法。最终想法通过会议来筛选，当然可以保留自己的一些好奇想法，以便在日后加以补充。记住可以用进化论的观点来筛选想法。就是适用当前市场的玩法，可以优先考虑。比如随着技术程序进步，现在可以做到人脸识别，你可以把这个想法提出来了加以运用。

无论文档还是想法，都要简单明了。至少你在最开始写文案或者想法时候，是简单的。毕竟如果开始都是复杂的，后面就会越来越复杂，一发不可收拾。尽量注重本质的玩法，强调可玩的地方。设计应该在反馈和迭代基础上变得复杂，而不是一开始。有些人怕别人看自己的文档，可能就是因为自己的文档写的稀里糊涂的一大堆，或者说写的文档太无逻辑，废话多，怪异的念头也多。

注重迭代开发，注意完全和现实一样的游戏是不可能存活的。对于游戏设计的方方面面不要带入太多的情感，一旦程序员开始代码开发，要反复修正文档。

同时文档要注意目标，毕竟是给人看的。在一份设计文档上面，人们通常对于以下方面感兴趣（也就是达到以下目的）：1、策划设计（设计人员） 2、程序构建 3、计划安排和盈利（制作人关注） 4、测试计划 （QA部门）5、整体目标（股东老板关注的）。但是实际上，并不是所有文档都包含这些目标，要具体问题具体分析。大部分情况是只包含设计和计划部分。具体要看你需要给哪些人看。

程序构建是最重要目标，因为他是游戏制作出来核心部分。但是不同人想法不一样，比如美术认为游戏美术风格很重要。要问程序员等人员，需要什么样的文档或者写法，如果他们要求策划忽略自己的一些不是很必要守则（注意不是核心守则），那就按照他们的意思去做吧。

注意简明,表现为易读、易写、易维护，尽可能的减少相互抵触的部分。如何做到呢？比如剔除缺陷，剔除无用部分，剔除无意义剪切和复制部分，剔除非必要的系统。记住程序员总是希望逻辑清楚，简单明了。那如何做到呢，举例如下：

{确认建立公会UI：玩家创建公会时候，会收到一个确认UI，会弹出对话框：“你真的想建立公会吗”，有一个确认和取消按钮。

确认按钮：确认UI有一个确认按钮，用来确认相应动作。

取消：取消UI上有一个取消按钮，用来确认取消动作。

关闭按钮：左上UI有个关闭按钮，用来关闭对话框。

退出：直接按ESC，跟关闭按钮一样效果。}

{实际上，我们可以这样写.确认建立公会UI：当玩家要求建立公会时，玩家会收到一个对话框（确认相关细节）（查看通用对话框说明）}

文档要注意设计的优先级，然后分阶段完成设计。确认文档是有步骤的，分步骤设计系统特色。

举例：

装备的系统表述

玩家在包裹栏上装备物品

装备物品后可以改变战斗属性。

装备物品后外观可以显示

玩家装备物品可以被附魔

玩家盾牌上可以有公会纹章

这大概把很多装备的特性表述混一起了，实际上要分阶段：

基础装备（原型）

玩家在包裹栏上装备物品，装备物品改变人的战斗属性。

加强装备（升级）

当玩家装备物品后，装备可以显示。装备可以被附魔。

公会纹章装备（特殊）

玩家盾牌上有公会纹章。

以上是对单个系统，对于整个系统文档来说，可以罗列以下分类

1、基础功能 2.核心功能3、扩展和未来构想

好文档要以图示文，一张图胜过千言万语。比如一张简单的逻辑思路图，一张类似功能的其他游戏截图，VISIO或者其他思维导图等。下图说明图案是如何解释游戏流程的，但是在撰写文档时候，下图显得太过于草稿了。很多流程用一大堆文字，并不能很好和程序员说明，所以图片变得异常重要。同时图片要附上简单摘要或者说明。

图片是如何清楚解释复杂流程

你需要给你的UI设计功能，但是请让美术决定UI的风格。不要尝试告诉别人如何做好他的本质工作，除非你比他专业。我举个例子，比如（从这个例子中你知道谁设计的好了吧，让美术把握美术专业事情）：

策划自行设定UI风格

美术设定的UI风格

比如你在任务文档设计时候，不需要告诉程序角色对象数据是以何种形式存储，这是程序决定的问题。但是你必须告诉程序员哪些需要存储，存储数量，存储时间段等等信息。

在书写时候，最好以非常清晰逻辑思路书写，比如可以用以下格式书写：

结果：A不可以在和平区域PK

问题： 为什么不可以（注意这里黑体表明问题）

答案：因为.......

而不是采用这种非常混乱写法，A不可以在和平区域PK，如果PK了，A会怎么样....而采用上面这种文档表示方法，很容易找到造成这种问题的答案。说明为什么要这样设计的时候，尤其是大项目，成员有时候忘记当初为什么要这样设计。那么这样写的好处，就能一眼找到原因了。

不要用一堆文字来表述一些条件，试着用表格来表述吧！同时要善于总结一些通用条件或者通用结果，而不要逐项都文字说明同一个条件或者结果。比如如果所有的制作工具都会磨损，你不需要每个工具都说一句“使用会磨损“。你只需要在制作工具总览哪里说明即可。很多物体特性，也可以用表格，比如用是和否来表述是否具有相应特性。

注意不要让别人苦苦寻找他想要的信息，细分好内容和章节目录，做好总结。所以在格式上面要注意了：用团队确认的文档模板、改变字体、用水平线、多用编号、用表格和表单。最后说一句要做模板的主人，不要成为模板的奴隶。

用清楚专业术语，不要假设读者知道它的含义。特别是一些文档让新人看的时候，不利于传承。同时有一些专业术语可能有多重含义，最好注明。总之用简单语言，避免歧义语言。避免用公司内部形成词汇，时刻更新行业内新的词汇。不用晦涩难懂词汇。