曾经有一些人问过我，怎么去写一份系统设计文档。首先要理解系统文档的具体作用是什么，有哪些人会接触这一份文档，系统文档是否符合游戏开发的预期。
编写系统文档，一方面是将设计师自己的思路逻辑地整理一遍游戏开发设计文档，并且要达到毫无错漏的效果；另一方面，开发需求会以文档形式派发至团队其他开发人员游戏开发设计文档，包括：技术、测试、运营、UI设计部、甚至美术……而当中接触最为紧密，影响最大的是技术和测试，前者在于实现功能，后者落实检验逻辑。如果文档没写好，会为开发带来很大的障碍。
我接触过一些人，他们对开发文档的态度是：会认真写一份系统文档，当部分过于繁杂、零碎、简单的事情，或者开发团队人员有疑问时，会更偏向于口头交流，描述。我觉得这样从结果上或许能实现功能，但这绝对不是一个良好的习惯，口头交流会缺乏正常的工作流程，容易引起工作混乱，而且会阻碍你养成写严谨文档的习惯，你会依赖于口头交流。
不利于组建团队时的工作管理，尤其是作为就职者，哪天当你离开时，曾经口头交流过的内容没有留下笔录内容，是有很大隐患的。
鉴于此，我建议对系统文档要有两个基本的态度:
1.系统文档能够在让团队人员理解完整内容，不存在疑问而需要交流的情况（实际上需要在编写文档时考虑阅读者可能存在的疑问）；
2.即使哪天自己离职了，甚至是在功能未完成的情况下离开，系统文档的清晰程度足以让团队继续开发，无需与自己联系或询问任何功能疑问。
以上两个是非常苛刻的要求，目的在于提醒自己，时刻保持系统文档的质量。
怎么才算一份优秀的系统设计文档呢？
游戏系统设计文档是游戏设计师的基本功，逻辑严谨、内容齐全、阅读引导、图文并茂、格式规范、工作规程。
苛刻的自我要求，由始至终的良好习惯，能提高设计师的能力。
逻辑严谨
在具体讲述技巧之前，建议去了解一下语言编程基础（建议是C语言），重点不在于学会如何编程，而在于掌握编程的原理，进而掌握编程的思想，注意是思想。一方面能提高设计师的预见能力，使得自己对功能能否实现具有一定的判断力；另一方面系统文档会有更强的逻辑性并带有计算机语言的风格，与团队技术人员会有着更深入的磨合。
计算机语言是一门严谨而富有逻辑的语言！
主要功能和次要功能（思想参考：void main()、function（））（思想参考，意思是思维模式参考相应计算机语言的编程思想。）
游戏系统中有许许多多的功能系统，小系统在大系统的嵌套，大系统与大系统的交互，这种庞大、错综复杂的关系难免会让人看不清枝节，这时候我们需要一些方法，以便于更有效地设计文档。
1.始终为所有系统分清权重和优先权；
2.尽量保持系统树状结构。
多个小系统在一个大系统中嵌套时，要考虑哪个小系统权重更高，更符合大系统的特征，而小系统之间也需要分清次序，这里我建议采用排除法。当排除某个小系统或小功能后，大系统会出现特征缺失，或玩法无法进行的情况，则该小系统或小功能权重相对较高，在编写系统文档时需要优先考虑。
大功能或系统的集合也可以采用排除法，当排除某个大功能或系统时，游戏框架明显崩溃，或游戏无法运行时，则该功能或系统的权重相对较高（例如主角色系统和宠物系统，排除主角色系统后游戏明显无法继续）。
编写系统文档功能设定时，可以将权重较高的系统放置在文档的最重要段落。编写时尽量一个一个功能描述，避免功能间交叉描述，或者以最简洁的语言描述与本功能没有最直接关系的其他功能，目的在于在文档上做到功能之间的隔离。
系统与系统之间的结构，包括大系统里面的小系统，游戏框架里面的大系统，尽量保持树状结构，这也是编程思想影响下的结果。系统与系统之间存在影响，在树状结构中系统大部分保持着发散关系或者串联关系，当系统发生异常或需要调整时，能够比较有效地减少该系统的变动对其他系统的影响。假设系统结构以环状，或者网状等结构组建框架时，系统的变动会影响整个框架，影响范围难以控制甚至不可控制。
树状结构方便系统的创意、构思、搭建、嵌套。对系统功能进行权重区分，继而决定构思和开发顺序，将各个独立系统组建在一起。
条件情景与逻辑判断（思想参考：if、for、do……while、switch）
在设计文档时，常常会遇到条件判断的设置，什么条件下达成一个怎样的响应。首先最重要的是，我们必须找出所有存在的条件，不管是我们预期的还是我们所不希望但是可预见的。
条件可以复合，多个条件组成一个共同条件；可以嵌套，达成一个条件下，再进入下一个条件判断，与复合不同，复合条件具有相同的权重，而嵌套条件具有优先级的差异。如果符合条件和嵌套条件均可以解决问题时，我更建议使用嵌套条件，因为你会考虑条件之间优先级的区别，这是个良好的习惯。
条件判断的应用——循环。通过不断进行判断条件，直到达成条件后执行或不执行某个行为。需要注意的是如何让系统进入循环，如何让系统退出循环，在循环过程中一些行为在不断叠加的情况下是否合理。
参数与集合（思想参考：数组）
设定参数时需要考虑具体的参数类型性质，这是会与参数变化方式有关（例如等级，是一个正整数，而且是以+1递增不可逆的变化方式存在，而战斗力也是正整数，但是会以整数上下浮动），这样会对参数的变动有一个基本的预期。
参数具有一定的状态，参数在系统开启时、运行中、运行结束后、系统关闭再启动，都有可能有不同的状态，主要反映在数值上、逻辑符号上、是否生效……
参数的调用与改变，是系统与系统之间连接的重要途径，通过一个系统的参数输出，进入另一个系统中，并产生响应，参数不仅仅简单是个变量，更是系统之间关系的直接体现。通过整理参数信息，也可以大致了解系统的结构。
有时候参数会以一个集合的形式出现，里面包括不同类型的参数，而参数的调用和改变方式也可能不尽相同。对于这些参数，我建议还是适当做一些优先级的区别，其实参数在哪个系统起作用，由系统的权重很大因素能决定参数的优先级（我们都明白主角色的等级参数权重比主角色的战斗力参数高，是因为战斗力的系统体系是建立在等级系统体系之下）。
因此，编写逻辑严谨的系统设计案，更像是在用文字对功能进行编程实现。
内容齐全
内容齐全的系统设计文档能够在一定程度上提高游戏开发的效率，减少开发过程中的失误率（因为失误有可能已发生在设计师编写详细文档时，并立即作出处理）。当然，内容齐全是建立在相应的开发需求之上的，以下列出的是可能出现的内容。
系统概括性描述——对系统概括性总结，包括系统功能、满足需求的描述、玩家互动方式等。
系统功能描述——对系统功能进行完整详细的描述说明，是系统设计文档必备元素。
数据项配置表——整理该系统中出现的参数，以数组方式组合，并对出现参数加以意义解释。
游戏界面设计草图——对应功能在游戏画面中出现的界面，涉及所有元素的设计与布局。
游戏界面操作描述——对游戏界面的操作进行说明程序开发，包括界面操作方式、元素的显示与改变、玩家与界面交互方式等描述。
流程图——涉及系统功能实现的逻辑算法，或界面操作步骤的流程图。
当然，在一些场合下，设计文档中可能还包括：开发需求描述、美术资源配置表、关卡草图设计……因地制宜地编写内容是非常重要的。
需要注意的是，如果在某些方面的开发需要经常需要与别人口头交流，或者团队人员经常在某一方面向你询问，那很可能你的文档正缺乏该方面的内容。
如果能够符合上文要求的话，我相信已经可以编写一份基本能满足开发的设计文档了。接下来，将会是对文档更苛刻的要求，是一种更高的追求。把阅读者看作是自己的用户，关注他们的体验。
这是一种设计师的自我修行，我相信长期坚持，收获将不仅是文档质量的飞跃提高，而且将会形成一种时刻考虑用户体验的习惯，这种习惯会不断地潜移默化，我相信这是有着巨大的价值。
阅读引导
由于文档内容是设计师所构思并编写，往往容易使得设计师产生一种“阅读者应该能明白我的意思”的错觉，而且总是以“对方必定会把我的文档从头到尾阅读一遍”的前提下进行编写（当然，开发人员因为工作需要会适当阅读文档）。当然，设计师总不能揣摩阅读者的各种情景，这种考虑用户阅读体验的代价未免过高，但是有一点是确信的，要确保文档的易读性，这种易读性不仅仅是指开发人员能够看懂，而且更希望是连不相关的人也能看懂个大概，甚至能够完全理解，也就是所谓的“把用户当作完全的新手”。
阅读者总能理解已经阅读的部分，在这个过程是不会存在厌烦感或抵触心理，为此，循序渐进、由浅入深的文档内容会是很好的应对方法。从涉及面窄的到牵涉功能其他模块，甚至其他系统的；从底层靠近核心的内容到较为表层的内容（上一节中对内容权重的区分在这里得到了体现）；从一个模块的内容到另一个与之关系最为密切的模块的内容。
每个部分开头设置一些简短的总结性语句，是个很好的带入，通过概述接下来将要描述的内容，让阅读者有个总体的认知。而结尾处对上述内容的交代，对下文的适当提及也能带动阅读者的思维，为阅读理解带来一定的缓冲作用。
一些阅读障碍是需要被扫清的。当出现新单词或生僻词汇时，需要适当并且及时地加以解释；当有复杂逻辑功能的时候，则需要适当举出例子，甚至是反面例子。
总需要了解阅读者可能存在的理解误区，并及时地理清误会。
图文并茂
人对图片的理解能力和记忆力远远超于文字，这已让图片说明有充足的利用价值。
图片可以完成一些比较形象的说明，另一方面也需要设计师对表述内容的高度概括，对核心内容和关系清晰简约地表达。需要突出的核心内容或者观点、逻辑繁杂的关系、新概念内容……
图片往往会附带文字描述，而图文的编排不同，作用效果也不尽一样。如上文所说，阅读者对图片的理解能力和记忆力更好，假设是图片在前文字在后，那阅读时往往会快速在脑海中形成比较具体形象的图片，在接下来的阅读中，阅读者能够根据脑海的图片与阅读材料进行匹配理解，理解速度会更快，而假设是文字在前图片在后，那阅读文字后查看图片会有巩固记忆的效果，记忆时间会更长。
格式规范
尽管各个人的工作环境不同，编写文档使用的工具有所不同，文档风格也各有所异，但是总有一些可以遵循的基本原则。
以下举一个简单的例子：
1.装备一共有四件。
2.装备一共有4件。
3.装备一共有4件。
4.装备总件数：4。
单单是文字、符号、标点的运用，在阅读中有着不同的效果，这细节很容易会被忽视。
正确地使用标点符号；各部分内容分清章节并且设置目录书签；大段落与大段落开发学习，小段落与小段落之前分行清晰而有所区别；适当的文本链接设置；文体的合理利用……
格式规范不仅更加易于阅读，也易于设计师进行修改调整。
工作规程
有良好工作规程的文档，在开发过程中有着积极的作用。
对文档进行版本管理，包括文档版本号、修改日期、负责人、修改内容、特殊说明等，这些都很好地服务开发跟进工作。有些情况下，还要列出具体开发的配置，包括负责人员，工作分配，开发周期。甚者还有功能质量管理指标内容、资源需求列表、设计修改目的描述与修改流程……这一切工作，都是为了更科学地管理开发工作。当然，这些准备功夫也是根据具体工作的需要而定，画蛇添足将会为开发人员带来阅读不适。
我相信，对自我的苛刻，一切努力终究会带来成果，尽管游戏设计师修行之路是那么的艰苦。一种有价值的习惯，一旦潜移默化，那作用是巨大的，是无可衡量的。能写一篇严谨、优雅的游戏系统设计文档，是值得高兴的事情，但更希望是通过这么一种（或者其他种类）编写文档的习惯，带来更多的、不同领域的东西，这不再是一种技法、技巧，而是上升到一种思维习惯。
我们常常不是不知道怎么做，而是不知道应该去做什么（希望这一句能给你足够的思考空间）。
