网站策划案标准格式和内容(为什么好的文档比较稀少？（不限于游戏）写好方案文档要求)

　　网站策划案标准格式和内容(为什么好的文档比较稀少？（不限于游戏）写好方案文档要求)

　　本文档是为那些想在游戏行业，或（包括但不限于游戏）写一个好的解决方案文档，并希望在游戏开发上有一些野心的人准备的。

　　很多规划者会说：“规划写文档是浪费时间，还是直接沟通过去”、“老板不会浪费时间读我的文档拉”、“程序员觉得看文档是浪费时间，他们要你跑过去直接发号施令。” 但是，这只能证明你的文档有问题，并不能证明大家写的文档都有上述问题。

　　好的文档需要以下一些特征：

　　1、在您的设计中捕捉广泛的想法。

　　2、为所有部门或特定部门提供可操作的可视化方法和流程。许多人编写他们无法理解的文档……更不用说程序员了。

　　3、可以帮助调度和提高开发效率。

　　4、强调一下。

　　5、系统的相互依赖和不一致应该可以通过设计来预测。例如，一些价值观，一些逻辑冲突。

　　为什么好的文档很少见，我觉得主要有以下几个方面：

　　1、 设计师整体实力不强，导致很多表达不清楚或与基本概念有冲突。设计师基础知识不够，或者知识模糊。事实上，设计师不仅要了解规划价值，还要了解方案、艺术和沟通等。

　　2、设计师对项目本身的理解不是很透彻，对设计本身的逻辑也不是很了解。设计者自己的逻辑是不够的。

　　3、系统众多且复杂，同时又相互交叉，设计者很难把握它们之间的关系。

　　4、设计师倾向于夸大和设计。系统设计文档比构建耗时少，避免解决方案成为“笨人写的笨书”

　　5、他们不太了解迭*敏*感*词*发

　　6、设计师跟不上项目和团队的节奏。设计师很少交流，导致自己陷入自己的想法世界。

　　7、设计者不了解文档编写的一些基本要求。导致文档即使阅读也有问题。

　　其他开发者会说：“给我最短的、有针对性的、最新的”、“简单而精确”、“只要列个清单，告诉我该怎么做”等（别人要求的）。

　　那么你需要做什么来写一个好的文档呢？然后开始编写文档的旅程。

　　首先，我们总是从与首席规划师讨论的会议开始，并明确以下三个问题：1、系统设计的目的是什么2、本文档需要回答哪些问题3、 这个系统有多复杂。同时，我们阐明了每个系统设计的基础和理论，并处理了设计障碍。如果系统设计没有预定目标，可以做很多解决方案，但这最终会导致设计臃肿或矛盾。比如你可以把锻造设计成副业，玩家可以用它来打发时间，你可以考虑去做。或者喜欢锻造的玩家可以拥有自己的锻造屋和铁器铺，从中获得财富和声望。显然，第二个有针对性的解决方案正是我们想要的。

　　另外，知道如何划分。在开会时，帮助你的老板理清以下事情： 当所有文件都相关时，要了解到底是哪个系统。需要明确安排文档设计的顺序，避免设计顺序混乱，导致设计错误。快速列出设计第一阶段的特点和特点。

　　认真决定特性和功能，聚焦关键点，我们必须使我们的特性表现尽可能完美。让功能有竞争力，但避免大而空，我们要让产品在市场上差异化，但避免风险太大，拼命创新（毕竟你不买单，很多规划完全是基于你自己的想法）。要与竞品区别开来，创新点必须一击致命，让产品在市场上脱颖而出。

　　下一步是调查。研究以前的游戏，尤其是它们失败的原因。研究非游戏相关的资料，比如如果你想做一个关于二战的游戏，回去看看历史，看看二战的军械图等等。简单地说，权威信息和灵感可以在其他领域找到。咨询专家，咨询公司的同事，甚至是家里的奶奶。例如，如果您想要一个非常简单的游戏，可以向奶奶或侄子征求意见。

　　灵感来自头脑风暴。如何进行头脑风暴，例如，聚集5个以上但少于10个有趣的人，跳出固有思维的恶性循环，注意没有想法是最坏的想法，头脑风暴最好有分歧的想法，抓住Live to be能够引起想法的共鸣。可以使用面向分歧的软件来协助分歧。剔除不好的想法，如无法实现（基于现实和团队能力）、完全超出现实、与目标或其他问题相冲突、奇怪的想法。最终的想法是通过会议筛选出来的，当然你也可以保留一些自己好奇的想法，以备日后补充。请记住，您可以从进化的角度筛选想法。是适用于当前市场的玩法，可以优先考虑。例如，

　　无论是文档还是想法，都要保持简单明了。至少当你开始写文案或想法时，这很简单。毕竟，如果一开始复杂，以后会越来越复杂，一发不可收拾。尝试专注于基本的游戏玩法并强调可玩的地方。设计应该基于反馈和迭代而变得复杂，而不是一开始就变得复杂。有些人害怕别人看他们的文件，可能是因为他们的文件写的很混乱，也可能是因为他们写的文件太不合逻辑，胡说八道，思想怪诞。

　　注重迭*敏*感*词*发，注意一个和现实一模一样的游戏是无法生存的。不要在游戏设计的各个方面都带入过多的情感，一旦程序员开始代码开发，就该修改文档了。

　　同时，文件要注意对象，毕竟是给人看的。在一份设计文件上，人们通常对以下几个方面感兴趣（即达到以下目的）： 1、规划与设计（设计师）2、方案建设3、规划与盈利（有关生产者）4、测试计划（QA 部门）5、总体目标（有关股东老板）。但实际上，并不是所有的文件都收录这些目标，具体问题还需要详细分析。在大多数情况下，只包括设计和规划部分。取决于你需要见谁。

　　程序构建是最重要的目标，因为它是制作游戏的核心部分。但是不同的人有不同的想法。例如，艺术家认为游戏美术风格非常重要。询问程序员和其他人员他们需要什么样的文档或写作方法。如果他们要求规划者忽略他们的一些不必要的规则（注意它们不是核心规则），那就做他们想做的事。

　　注意简洁，易读、易写、易维护，尽量减少冲突部分。怎么做？如去除缺陷，去除无用的部分，去除无意义的剪切和复制部分，去除不必要的系统。请记住，程序员总是希望逻辑清晰简单。怎么做，例如：

　　{确认公会创建界面：玩家创建公会时，会收到确认界面，并弹出对话框：“你真的要创建公会吗？” 有确认和取消按钮。

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

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

　　关闭按钮：用户界面左上方有一个关闭按钮，用于关闭对话框。

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

　　{实际上，我们可以这样写。确认公会创建界面：当玩家要求创建公会时，玩家会收到一个对话框（确认相关细节）（见一般对话框说明）}

　　文档关注设计的优先级，然后分阶段完成设计。确认文档是按部就班的，按部就班地设计系统功能。

　　例子：

　　设备系统说明

　　玩家在包裹槽上装备物品

　　战斗属性可以通过装备物品来改变。

　　装备物品后可以显示外观

　　玩家装备物品可以附魔

　　玩家盾牌可以有公会徽章

　　这可能混淆了很多设备的特性。其实需要分成几个阶段：

　　基本设备（原型）

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

　　强化装备（升级）

　　当玩家装备一件物品时，可以展示该装备。装备可以附魔。

　　公会徽章装备（特殊）

　　玩家的盾牌上有公会徽章。

　　以上针对单个系统，针对整个系统文档，可以列出以下几类

　　1、基本功能2.核心功能3、扩展和未来思路

　　一个好的文档应该是用图片来写的，一张图片胜过千言万语。比如简单的逻辑思路图，其他类似功能的游戏截图，VISIO或者其他思维导图等太通风了。许多流程使用大量的文字，无法很好地向程序员解释，因此图片变得极为重要。同时，图片应附有简短的总结或说明。

　　图片如何清楚地解释复杂的过程

　　您需要为您的 UI 设计功能，但让艺术家决定 UI 的样式。不要试图告诉别人如何做他的基本工作，除非你比他更专业。我举个例子，比如（从这个例子你就知道谁设计的好，让美术主修美术专业）：

　　计划设置自己的 UI 风格

　　美术设定的UI风格

　　例如，当你设计一个任务文档时，你不需要告诉程序角色对象数据是以何种形式存储的。这是程序决定的问题。但是你必须告诉程序员要存储什么，存储多少，存储多长时间，等等。

　　写的时候，最好写的很清晰，逻辑性强，比如可以写成如下格式：

　　结果：A无法在和平地区PK

　　问题：为什么不（注意这里的粗体问题）

　　答：因为...

　　而不是使用这种非常混乱的写作方法，A不能在和平地区被PK。如果PKed，A会怎么样。。通过上面的文档表示方法，很容易找到这个问题的答案。在解释为什么要这样设计时，特别是对于大型项目，成员有时会忘记为什么要这样设计。那么这样写的好处就一目了然了。

　　与其用一堆单词来表达某些条件，不如用表格来表达它们！同时，要善于总结一些一般条件或一般结果，而不是逐条解释相同的条件或结果。例如，如果所有的制作工具都磨损了，你就不需要在每个工具上都说“随用随用”。您只需要说明创作工具概述的位置。很多对象特征也可以用在表格中，比如yes和no来表示是否有对应的特征。

　　注意不要让别人费力找到自己想要的信息，细分内容和章节目录，做好总结。所以要注意格式：使用团队确认的文档模板，更改字体，使用横线，使用多个数字，使用表格和表格。最后，说做模板的主人，不要成为模板的奴隶。

　　使用清晰的术语，不要假设读者知道它的意思。尤其是有些文档是给新人看的时候，不利于继承。同时，有些专业术语可能有多重含义，最好注明。总之，使用简单的语言，避免使用模棱两可的语言。避免使用公司内部形成的词汇，随时更新行业新词汇。没有晦涩的词汇。

　　如何编写计划文件的第一部分首先在这里。有兴趣的话，有时间再继续写第二部分。以后有时间会制作视频讨论游戏开发的方方面面。希望大家支持我的文章。您可以喜欢和订阅并关注我。如果大家有任何游戏相关的问题想讨论，可以关注后私信我。希望对从事游戏行业或想从事游戏行业的朋友有所帮助。这篇文章为我辛苦了原创，未经允许，任何人不得转载。