功能执行案的撰写

一、 文档的基本格式
交由技术美术的开发文档是根据设计需要拆分成的功能执行案。
功能执行案的最小单位是功能模块；功能模块是开发的最小单位。包含：功能模块标题、先决条件、操作步骤、结果、冲突与联系、程序意见六部分的表格。表格的形式见下：
功能模块标题
先决条件 
操作步骤 
结果 
冲突与联系 
程序意见 

1、 设计方面
“功能模块描述的是一次完整的用户操作过程。”
“先决条件、操作步骤、结果”三部分很适合用于描述用户的一次操作过程。由功能模块组成的功能执行案，能覆盖用户在游戏中的操作过程。我们知道用户的游戏体验就是由一系列的操作组成和实现；按照这种描述方式，能保证开发结果在用户感受的层面是唯一的。
    “帮助设计者关注细节。”
同时，“先决条件、操作步骤、结果、冲突与联系”是一个简单的“if……then……else”逻辑语句。按照这种方式撰写文档能保证策划关注到每个逻辑判断如何处理。从而在执行的过程中更多的关注细节，换言之可以作为一种帮助策划完善设计的工具。从而提高产品的品质。
“可继承。”
功能执行案在设计上的完整，能使在项目中后期进入的策划；能通过阅读文档的方式了解之前的设计内容。且在设计上发生争执时，之前的文档也能作为一个参考。

2、 技术方面
“文档可阅读，进度控制。”
功能模块作为游戏开发的最小单位，包含逻辑判定过程。技术不需要进行分析，直接按照文档就可以编写代码。同时逻辑层面上的开发就是由一个个逻辑判断组成。功能执行案的拆分，也能作为项目进度控制、工作安排的一个依据和参照。
“在设计上减少BUG，降低沟通成本。”
“冲突与联系”用于描述当前功能模块和其他功能模块发生关联或逻辑判断时，如何在逻辑节点上各种可能情况如何处理。该部分能在设计的过程中解决可能出现的BUG，也能降低技术与策划之间的沟通成本。

3、 其他方面
     “QA作为测试的基础。”
另外，功能模块也能作为QA进行游戏流程测试的参考。因为功能执行案在设计上的完整性，QA能直接通过功能执行案和实际开发结果进行比较。这能作为评估游戏设计开发实现程度的一个标准。
“策划出现人事变动时不影响开发。”
如上，由于功能执行案能保证设计的完整性；在策划部门出现人事变动时，技术依然可以按照文档继续开发。而不会因为缺少与策划的沟通而无法继续开发。
“培训方式”
功能执行案的直接接口是负责功能模块开发的技术。功能执行案的撰写也要求尽量采用技术能够理解的语言。这意味着，功能执行案的撰写能使策划获得基本的技术常识。这能提高策划在技术实现可能性和成本等方面的认识。

二、 文档的其他内容

1、 文档修改记录
文档修改记录
修改日期 修改人 修改原因
  
在文档标题正下方首先是“文档修改记录”，在第一次创建文档时建立；在每一次文档修改时，均需要填写。填写内容包括三项：修改时间、修改人、修改原因。对修改人的记录是当文档对应的功能开发出现问题时；便于找到撰写人，了解文档相关情况。而修改时间的记录是可以进行开发中预期进度和实际进度的比较。修改原因的作用在于，进行设计调整时，便于技术了解文档的修改部分。

2、 定义
当文档中出现反复使用的非一般约定成俗的词汇时，需要就词语的含义进行一个详细的定义。使策划内部及各个部门之间对某一词语的理解是统一的，同时在开发的沟通中成员对同一意义的表达使用的词语是一致的。

3、 流程图&界面规划
流程图用于描述功能的基本工作流程，目的是使技术对功能模块的工作方式首先有一个整体的认识。界面规划：1、用于拆分完成美术需求。2、连接美术和技术。

4、 美术需求表
美术需求列表
名称 功能说明 风格简述 位置 大小 数量
     
   一般放在功能执行案的最后，从功能文档中提取界面相关的美术需求。位置和大小的单位是像素，用于确定图形元素的位置。当按钮需要多种状态图片时，需要记录数量；一般包括：普通、悬停、点击、死灰四种状态。

5、 文档执行人员
记录文档的执行人员，便于执行人员之间就细节的沟通交流调整。
文档执行人
策划 ×××
技术 ×××
美术 ×××

6、 功能执行案主要负责人员签字
包括：主策划、主程序、项目经理；分别从三个角度：设计是否合理、技术是否可行、功能实现的时间需求是否合适；评估该文档是否可交由技术美术执行。