【游戏力量资料站】撰写功能执行案方法

尛蟲蟲 · 发表于 2008-9-19 15:36:17

第一部分拆分功能模块

一个完整的功能模块包含“先决条件、操作、结果、冲突与联系”四个部分。在拆分功能执行案之前，首先会拿到一个框架案。试开发流程的不同，他有可能来自项目内某人的口述、框架案文档或撰写功能执行案的人自己设定。
那么，我们首先来看一段框架案：
①
商城分充值与消费两大部分，充值通过页面操作进行，消费在游戏内进行。
②
点券的获得：用户通过账号充值获得点券。
③
点券的消耗：购买商城内的道具消耗点券。
④
有新品和热销商品的标示。
⑤
商城购买的道具不可出售给系统。
⑥
商城的道具分类沿用商店的设定。

好的，现在我们已经拿到框架案了，接下来让我们看看该做些什么。首先，这份框架案并不是按照用户操作流程撰写的，而只是将框架案的关键信息写出来了。而我么拆分功能模块的依据是用户的操作流程，那么让我们将上面的框架案转换成一个用户使用商城的操作流程。
①
商城的主要功能是购买道具，这是在一个游戏窗口上完成的。那么用户使用商城的第一个操作步骤是：打开商城。
②
相对于打开商城，一定有一个关闭商城的操作。因为用户需要退出商城进行其他的游戏内容。
③
获得点券是在网页上完成的，那么可以不放到功能模块中。
④
因为有道具分类，那么可查看之前的设定，因为之前不同分类的道具是在不同的标签之下。为了保证游戏内容统一，在我们这里也沿用标签的设计。所以需要一个切换标签页的功能模块。
⑤
商城的主要功能是进行虚拟道具的购买，那么我们需要一个购买道具的功能模块。
⑥
商城购买的道具不可出售给系统：商城购买的道具将存储到用户仓库内，而不可出售给系统的操作是在用户仓库内完成，不属于商城系统。所以不需要在该功能执行案内列出单独的模块。
⑦
新品和热销商品的标示，首先新品和热销商品的显示不是用户操作的结果，而属于打开商城后，商品的显示规则。那么我们可以单独列出一个模块，我们称为商品排列规则。
⑧
另外，为了帮助用户挑选商品，我们需要提供商品信息的显示。所以可以单独列出一个功能模块查看商品信息。
⑨
商品的数量可能大于一页，那么我们还需要一个功能模块：翻页。

到此为止，我们已经列出了商城系统的完整功能，并且可以得到下面一个描述商品系统功能的简图（图例1）。虽然这个系统相对简陋，但至少是完整的。实际上，我们可以至少往里面加入如下的功能：赠送商品、试穿商品、购买试穿、快速充值。

在我们看完了操作实例后，我们开始需要一些具有适用于所有功能的理论基础了。这将有助于功能执行案的撰写者，搭建合适的功能模块。那么满足什么样的条件可以独立为功能模块呢？归总起来就是以下几句话：
1.
用户的一次操作是一个独立的功能模块。
2.
系统处于某种状态（不需要用户操作）后的结果可以是一个独立的功能模块。
3.
特殊的需要程序注意的内容（只包含冲突与联系），可以是一个独立的功能模块。

图例1 商品系统功能简图

依次解释以上几句话。
用户的一次操作是一个独立的功能模块。

用户的操作可能是如下几种：
①
鼠标左键单击某按钮/角色/图标/窗口某位置，扩展一下，还包括鼠标右键、鼠标中键、双击、长按、拖动。
②
按下键盘某按键，扩展一下，还包括按住、按击数次。
如果是PC游戏就是键鼠操作了，没有其他。那么以上，每需要用户一次单独操作的功能模块都应该是独立的功能模块。
有的时候会出现这样的情况，完成一个功能需要依次完成两次操作。例如上例在商城中购买商品，有这样的实现方式：1.鼠标左键单击商品图标，选中商品；2.鼠标左键单击购买商品按钮，完成商品购买。类似这样的情况，建议拆分成两个不同的功能模块，因为他们可能有不同的冲突与联系，拆分成不同的功能模块，单个框的内容较少、且冲突与联系的归属清晰，易于程序阅读。
系统处于某种状态（不需要用户操作）后的结果可以是一个独立的功能模块。

有些结果并不是用户操作的直接结果，而是当系统处于某种状态后的结果。这需要单独列出一个功能模块。理由是：单个框的内容较少、且冲突与联系的归属清晰，易于程序阅读。并且他们可能具有相同的特点，这也是让功能执行案易于阅读的方法。

例如：商城打开后，商品的排列规则、商业页面上按钮的状态、标签的排列规则。当然，你也可以把他们写在同一个框内，但你将让程序阅读到一个长达2页，内容排布杂乱的功能模块。你有考虑过程序的心情吗？

特殊的需要程序注意的内容（只包含冲突与联系），可以是一个独立的功能模块。

这部分内容可能没有先决条件、操作、结果；而只属于冲突与联系。例如窗口中文字的大小、最大数量、图标大小、一页显示数量、标签分类等等属于约定性的内容。如果他们数量足够多，并且重要。你完全可以把他们列出来作为一个单独的功能模块。

到这里，如何拆分功能模块已经介绍完了；但还有两点需要额外注意的：

第一，功能模块的标题必须是对该功能模块作用的描述；有的人写的功能模块标题，甚至让人看了后完全不知道这是一个什么样的功能。这是多么糟糕的一件事情，如果我要在写末份功能执行案，需要查找之前功能执行案中的相关内容，却发现我不能通过标题去判断，坦白说，这一刻我想拿板凳砸人。

第二，拆分功能模块并不是严格遵循框架案的内容；框架案只是约定和协助的作用。如果发现框架案的在设计上有不合理或冗余的地方，功能执行案的撰写者有必要提出异议。

尛蟲蟲 · 发表于 2008-9-19 15:36:46

第二部分撰写功能模块(先决条件)

拆分好功能模块后，首先需要将功能模块的框架搭建好。依次把操作、结果、先决条件塞到对应的功能模块中去。功能模块是如下图（图例2）所示的一个表格。

功能模块标题
先决条件
操作步骤
结果
冲突与联系
程序意见

图例2 功能模块框

下面是一个功能模块框架的举例（图例3）：

打开商城
先决条件
操作步骤	左键单击商城按钮。
结果	打开商城窗口。
冲突与联系
程序意见

图例3 功能模块框架

撰写先决条件

当你把所有功能模块的框架搭建完成了，就可以开始丰富单个功能模块了。还是继续使用上面的例子，首先写先决条件。问自己这样几个问题：在该项目中什么条件下，该操作不能进行？在该项目中什么条件下该操作有不同的结果？自己问自己，问完了把所有结果列在先决条件中即可。试项目的不同，先决条件会截然不同。

举个例子，商城界面是在仓库中打开，那么先决条件需要包括仓库已打开。如果是在游戏主界面上，则先决条件是用户角色已登陆游戏。如果游戏中，用户在某些场景无法打开商城界面，例如在城镇中可以打开，其他任何场景中都不能打开。那么先决条件需要包含用户在城镇中。或者我们要求，商城是额外赋予用户的功能，是对用户游戏时间的奖励，那么我们先决条件将包含用户达到某等级。

以下一些先决条件，是经常出现在游戏中的：
①
某属性大于或小于某数值。
②
用户处于某种状态。
③
某游戏窗口已打开。
④
达到倒计时时间。
某功能到底包含哪种先决条件，具体功能具体分析。

尛蟲蟲 · 发表于 2008-9-19 15:37:03

第二部分撰写功能模块（结果、冲突与联系）

撰写结果

在写结果的时候，最常遇到的是以下几种问题：
①
对实现方式不了解，导致功能拆分不够细致。
②
对设计细节不了解，导致功能拆分不够细致。
对实现方式不了解

以使用技能为例，可能有些人结果会写：该技能生效。但实际上这远不完整，视觉表现、听觉表现和底层数据变化只是恰好被调整成一致的，实际上在程序上他们都是单独处理的。如果你不写，那么他们甚至永远不会出现在你的游戏中。结果至少需要包含：
1.
技能图标的变化显示。
2.
播放角色使用该技能的动作。
3.
播放角色使用该技能的特效。
4.
播放角色使用改技能的音效。
5.
角色属性根据使用该技能的成本对应减少。
6.
如果技能有CD时间，还有有技能进入CD时间的描述。
7.
判定技能是否命中（这里需要将完整的判定规则列出来），如果技能命中还需要以下的处理。
8.
命中方属性对应技能减少。
9.
命中方获得技能对应状态。
10.
命中方播放命中该技能的动作。
11.
命中方播放命中该技能的特效。
12.
命中方播放命中该技能的音效。
对设计细节不了解

以商城为例，打开商城窗口并不完整。打开商城后显示什么？在哪显示？按什么顺序显示？如果是按钮，还需要指明按什么状态显示？如果有即时读取的数据，需要指明数据从哪读取？如果有角色虚拟形象的显示，那么还需要写出角色的朝向、动作、穿着什么装备。并且需要给出准确的界面布局图。列出我写的一个打开商城窗口的结果，参考参考：

打开商城窗口。布局见图例4，需要显示的内容如下：

1.
分层标签：若用户能到达的最高层为A，则分层A标签呈点击状态。

2.
商店分类标签、商品分类标签：默认武器店（商店分类）标签下的刀剑（商品分类）标签呈点击状态。
3.
商店的商品列表：显示满足层数及商品类型条件的第一页商品。从数据表中读取以下数据对应显示在商品列表：

商品名称、商品图标、商品类型、商品价格。
4.
上翻页按钮、下翻页按钮、当前页数/最大页数；最大页数根据商品数据表中商品的数量和一页能显示的商品数量计算得到。
5.
购买、赠送、购买试穿、取消试穿按钮；按钮的状态见《按钮状态规则》功能模块。
6.
用户账号、点券数量根据用户对应信息显示。
7.
人物框及角色名称根据用户对应信息显示。
①
人物框默认显示角色当前装备的武器和防具。
②
人物角色默认正面朝向用户。
③
人物动作默认大厅待机动作。

图例4 商城窗口

如何写好结果？没有什么特殊的诀窍，多听多看多问多想，多经历一些事情如此而已。

撰写冲突与联系

撰写冲突与联系记住如下几句话，就足够了：
1.
所有需要约定的内容。
2.
一条先决条件对应一条冲突与联系。
3.
当用户处于结果时，是否有某种异常处理。

所有需要约定的内容

例如：窗口大小、字体、字号、字色、角色动作、图标大小、输入的字符是明码还是暗码、一页显示数量、等等……每一个细节都是需要被约定的。

一条先决条件对应一条冲突与联系

还记得最开始我们怎么定先决条件的吗？写先决条件时问自己这样几个问题：在该项目中什么条件下，该操作不能进行？在该项目中什么条件下该操作有不同的结果？

换句话说，在冲突与联系中，需要写的是：当该条件不被满足时，会有什么样的结果。

当用户处于结果时，是否有某种异常处理

例如：当某个窗口打开的时候，会有什么样的异常状况关闭该窗口？

尛蟲蟲 · 发表于 2008-9-19 15:42:26

撰写功能执行案需要注意的其他事项
1.
保证用词的唯一性：以项目中命名的词为唯一标准。保证项目内每个相关成员都能看的懂。例如：穿着在角色身上的道具，我们可以称之为防具，也可以称之为装备。但如果我们约定了，他就叫防具。那么之后在任何一份相关的功能执行案中提及到他的时候，我们都应该称之为防具；而不是装备。这需要策划组中每一组员的自觉性。否则我们将在这一点上浪费不必要的时间去进行沟通。
2.
保证界面风格的统一：例如：我们约定所有的弹出窗口右上角都没有关闭按钮，那么之后每一份涉及到弹出窗口的功能执行案左上角都不应该有关闭按钮。我们约定了聊天窗口提示信息文字的字体、字号、字色；那么任何一份涉及聊天窗口提示信息都应该沿用该规则。再比如，我们约定了功能按钮都应该放在界面窗口的右下角，那么任何一份涉及功能按钮的功能执行案，都不应该把功能按钮放在左下角。
3.
用词应该简练：功能执行案应该像代码一样简练，如果五个字能说清楚的，绝对不用六个字。并且必须是说明性的文字，而决定不应该在功能执行案中出现描述性的文字。例如：游戏窗口播放特效。那么关于特效的描述是不需要写在功能执行案中的。这部分应该出现在美术需求中，而只在美术完成特效后，由策划将特效ID提供给程序，告诉程序这个时候在这个位置播放这个特效。功能执行案中几种常用的句型是：
①
A处于B状态（……已……）。
②
左键单击A按钮。
③
显示A。
④
播放A。
⑤
A做出B动作。
⑥
若……则……
⑦
满足条件A。
⑧
A保持更新。
⑨
……≥……（……≤……）。
另外，如果一个功能模块中，需要描述多个角色或多个道具的结果，则依次按A、B命名。以图例5的切换分层标签页为例。
切换分层标签页
先决条件
1.
商城已打开。
2.
分层标签B呈点击状态。
操作步骤
左键单击分层标签A。
结果
1.
标签状态处理：
①
分层标签B呈普通状态。
②
分层标签A呈点击状态。
2.
若商品标签为B；则商品列表显示分层A内商品标签B下的第一页商品。
冲突与联系
若分层标签A = B，则左键单击分层标签A无任何效果。
程序意见
图例5 切换分层标签页
4.
每一条都单独列出：不要将多个先决条件、多个结果或多个冲突与联系写在一起。而应该尽量将每一条都单独列出。如果每一条都不超过1行那将是最好的。原因是：这样最适合阅读，并且他们在代码中也是单独的一行（能尽量减少程序遗漏功能）。 6
游戏力量
游戏力量·撰写功能执行案的方法简介
三．
确认实现方式
不同的实现方式，功能执行案的撰写方式不同。
撰写功能执行案的时候，向程序和美术确认实现方式是必不可少的内容。无论功能执行案本身已经把游戏描述的多么准确了。请别忘记，在程序实现逻辑、美术给出资源之前。功能执行案也只不过是YY。难道你想让你写的功能埋藏在VSS的最深处发霉吗？如果不是，那么就带上你的功能执行案走到程序美术前面，“我想这样，可以实现吗？”
这部分工作可能是撰写功能执行案的过程中去确认、也可能是在撰写完成后去确认。不过我认为，作为策划必须在撰写的过程中就确认实现方式；因为不同的实现方式，功能执行案的撰写方式可能完全不同。
举个例子，在设计上，我希望有一种叫称号的东西，可以被用户收集。称号的数量可能有上千个，并且我希望用户在未获得该称号时也可以看到称号的名字介绍等等。因为在网络游戏中，角色数据必须在服务器上有所保存。那么，如果要让用户看到每个称号的名字和介绍，就需要角色数据表中保存每个称号的状态。也就是至少要保存1000项。这个时候我就需要找程序确认，这在程序上是否能实现了？
如果程序对我说，能实现；那么在功能执行案中，我会写：“当用户未获得该称号时，称号名字及相关信息显示为灰色。”如果程序对我说，不能实现；那么在功能执行案中，我可能会用替代的方式，“当用户未获得该称号时，称号名字及相关信息显示为问号。”
这也是我之前建议在写某个不确定实现方式的功能之前，必须优先找程序美术确认实现方式的原因。这可以减少返工次数。如果你写了，之后才确认需要用其他替代的方式实现，这可能会比你当初直接确认再写多花一倍的时间。并且有可能造成他人对策划产生负面的看法：“什么烂策划，实现方式都不知道就瞎写。不会干别干……”记住，游戏策划不是上帝，游戏策划是引擎。
如何针对程序美术的反馈，做出调整。
无论如何，确认的结果大致可以分为以下几种：
1.
能实现，没有任何问题。
2.
能实现，但可能占用过多的客户端或服务器端资源。
3.
能实现，但需要美术更多的工作量。
4.
能实现，但需要程序更多的工作量。
5.
对用户而言相同的表现下，有工作量更少的实现方式。
对于策划而言，首先要根据程序和美术的反馈进行分类，看需要实现的方式是以下哪一种。之后你需要对这个设计进行分类：
1.
必须的，如果不这么做，这个游戏就不用做了。
2.
必须的，但时间不允许的话也没办法。
3.
可以有其他的方式替代。
如果该设计属性需要占用额外的工作量、有其他的方式可替代。那么就用替代方案。如果该设计属于第2种，那么你需要和项目经理确认时间，将该部分功能的实现调整到上线后完成。如果该设计属于第1种，那么，你可以，举起左手猛拍桌子，大喊一声“老子不干了！”（呵呵，玩笑），不管怎么样，找替代的解决方法都是在不能实现的情况下的最优解。
7
游戏力量
游戏力量·撰写功能执行案的方法简介
哪些实现方式需要被确认?
实现方式需要被确认，但这并不意味这每一点都需要被确认。就像，你不可能找程序确认如下的内容是否能实现：
1.
我可以让按钮禁用吗？
2.
我可以渲染某个窗口吗？
3.
我能轮询检测，然后选择第一个道具使用吗？
4.
我可以改变某个角色的状态吗？
如果程序和你说实现不了……汗……请鄙视他……话说回来，我还真见过对我说“轮询检测，然后选择第一个道具使用实现不了”的程序。这是社会主义初级阶段（持续跑题中）……
一般而言当遇到如下情况，你需要确认：
1.
该功能需要存储过多的角色数据。
2.
该功能需要向其他用户传输额外的数据。
3.
该功能需要占用额外的显存。
4.
该功能需要程序做出动态判断。
5.
该功能需要美术额外的工作量。
可能还有其他的需要确认的内容，不过现在能想到的就这么多了。一个内容是否需要确认，需要做策划的你平时多积累各种功能的实现方式。当看到某个功能，请问自己：“这是怎么实现的？有几种实现方式？”下面会就每一种需要确认的类型举一个例子，帮助读者理解其中的内容。
该功能需要存储过多的角色数据。用户有一个任务列表，其中记录了所有用户曾经做过的任务，供用户在任何时间查阅。
该功能需要向其他用户传输额外的数据。用户可以在场景的任意地方建造建筑、并且也可拆除建筑、建筑细节可由用户设计。当其他用户在该建筑旁边时，可看到该建筑的所有细节。
该功能需要占用额外的显存。用户界面有画中画的功能，可以观察选中用户实时的行为；用户一次最多打开三个画中画。
该功能需要程序做出动态判断。小地图由程序根据场景模型自动生成。
该功能需要美术额外的工作量。2D旋转视角的游戏。
除了实现方式以外，还有一些是必须要三方约定的内容；例如：1.美术资源如何编号？如何让程序知道该资源对应该功能？资源的数量？ 2. 哪些资源由美术提供？哪些资源由程序根据逻辑调用，而无需额外的资源？3.各种界面的规格。4.各种资源的提交格式？尺寸？
四．
复杂度易用性
关于易用性，有很多书都有介绍到，比如：《AboutFace》、《设计心理学》等等。有兴趣的话，可以阅读一下。在这里不打算说什么是易用性，相比较我认为更重要的是，策划要学会在复杂度和易用性上做一个平衡。
在这一点上，策划的立场处于一个很尴尬的位置。当你设计了一个复杂的逻辑，对于程序而言，也许过于复杂，实现起来很麻烦。但对于用户而言，也许很好用。这个时候，你需要决定，你的立场是什么？满足程序的需求，抑或是满足用户的需求？
举个例子，我家楼下有个饮水机。每次只能投币5角或一元。但我的壶可以装下8角的
8
游戏力量
游戏力量·撰写功能执行案的方法简介
水。问题就来了，我希望每次都可以打满水，但我又不希望浪费那2角钱。出于用户的角度，我对此很不满，难道他妈的要让我换个壶吗？我就喜欢这个！作为用户的“我”发怒了！
但当我站在设计者的角度我想到了，如果我希望实现退币的功能，我需要做如下处理：
1.要有相应的逻辑设计（判断当前出了多少水、之前投了多少钱）。2.我需要在饮水机内准备足够的1、2、5分币、1角币；供程序判定出币。3.我需要有停止出水、退币的按钮；我需要有退币槽。一切看来很好，能够实现；但问题来了：现在的最小单位是角币，很难再找到分币了！机器上没有额外的地方安装退币槽了！可能还有一个问题是，造水设施已经占满了内部布局，没有额外的地方存放货币了。另外一个是，也可以通过卡购水，如果用卡购水将不能退币。
以下问题都会让事情变的复杂起来了……那么，我们为什么不把这个问题交给用自己解决？反对的声音是“可能有些追求无瑕疵的用户会觉得不高兴！”，“让他去死吧，这种凤毛麟角的无聊用户，我们提供了最廉价的水，他不高兴可以不喝！”
“如无必要，勿增实体！”
五．
如何提高撰写功能执行案的能力？
对于我个人，对功能执行案的理解，经历了如下几个阶段：
1.
功能执行案这种格式非常棒、化腐朽为神奇，让策划提供的需求提高一个档次。
2.
功能执行案的用词应该简练如代码。
3.
糟糕的功能执行案，相比其他的格式更让程序头痛。
4.
功能执行案只是工具，案子好不好，还是由撰写人决定的。
5.
如无必要，勿增实体。
6.
写功能执行案，其中写只占整个过程的50%。
7.
功能执行案只适合于特定的开发流程。
希望我的体会能帮上忙。写到这里，关于功能执行案撰写的介绍可以告一个段落了！如何提高功能执行案的撰写能力？坦白说，和任何一种技能的提高没有区别，多练习多思考，如此而已。