Day06 - 根据需求画出 Flowchart 或是 State Diagram

今天尝试将 2D RPG 角色移动模组根据规格画出 Flowchart 和 State Diagram

规格

• 按下 ⇦、⇨ 可控制玩家移动
  
• 按下 B 是跳跃
  
• 长按 ⇩ 是匍匐前进 → 放开 ⇩ 是起身
  

Flowchart

首先我们先尝试使用 Flowchart ，假设从最开始的需求，只有跳跃而已（下图一），

图一

到最後除了跳跃，还要有匍匐、前进、後退等，随着功能增加，添加了许多 flag 储存不同状态，以及为了使角色功能正常运作的防呆检查，最後会像是非常惊人的图（下图二），

图二

不要问我花多久时间画出来的 QwQ，怕～（说不定还有画错？！等待广大网友们帮我除错ＸＤＤ）
（更新：发现我好像有哪里漏思考画错，但没保留原档，不愿意面对，以後有时间再回去重画吧）

假设今天有人很认真开发、也很注意每个 if, else 的小细节，也细心思考过每个状态下的防卫(Guard)跟防呆(Fallback)，而且还愿意多花自己的时间补齐文件（加班？！），最後画出一张详细的流程图在上方...。

我感到敬佩跟尊重，但不晓得一般人，不管工程师或 PM ，到底愿意花多少心力细看上图二。

假设真的遇到错误、bug，不管有没有这张图，应该也会迷失在茫茫 bug 海吧？

而且图中，显现太多逻辑判断的细节，其实不需要为外人所知，这些逻辑判断，也只不过是为了达成规格书要求所产生的。

State Diagram

假设我们今天尝试采取比较高抽象层次的观点来着手，还记得昨天提到的

• 他们都有一个初始状态
• 整个实体、物件或是对象，都有一系列不同的状态们
• 还有一系列不同的事件，可能会导致状态转移
• 还有一张纪录着什麽事件配什麽状态会发生转移的地图、对应表
• 有限数量的结束状态( 0 - n 个 )

我们先从一个实体对象(entity, object)的观点出发，假设我们今天实体对象就是玩家操纵的角色，

我们的商业需求，目前有跳跃、俯卧、前後移动，3种主要的大动作，我们可以来细细思考，我们可能需要怎样的状态及事件。

先想想，玩家一开始抵达我们的系统会是什麽样子，应该可以有一个静止的站姿吧（初始状态）？

接着先对应到跳跃(Jump)

1. 按下 B 是跳跃

我们可能有跳跃前、跳跃後...，跳跃是个动作、动词，所以我们姑且先将他视为一种事件，那这个事件的前後应该是什麽状态呢？

跳跃依照规格「可能」只能从静止时开始，所以跳跃前的状态应该为静止站姿，进行跳跃时，就要转换到跳跃中的状态，跳跃结束时，应该会回到地面静止站姿的状态，所以可能应该要有个降落的事件，让玩家回去。

如果对上述的整理已经产生不肯定、疑惑时，这就是一个去跟 PM 厘清规格很好的时机，不用等到开发下去才再回去改。

再来我们看移动

2. 按下 ⇦、⇨ 可控制玩家移动

移动同样是个动词、动作，我们应该可以视为一种事件，那移动这个事件应该从什麽状态开始什麽结束呢？

常理（或照规格）应该是从静止开始吧？所以站姿静止状态经过一个开始移动的事件後，应该要转移到一个状态，我们姑且称这个状态为站姿移动中，而这个移动中，应该要有个停止，才有办法回到静止的状态，所以我们也应该实作一个停止移动的事件（即放开 ⇦、⇨ ）。

一样，如果对上述的整理已经产生不肯定、疑惑时，这就是一个去跟 PM 厘清规格很好的时机。

最後来看俯卧与匍匐前进

3. 长按 ⇩ 是匍匐前进 → 放开 ⇩ 是起身

如何匍匐前进、後退？
假设从站立到卧倒，我们可能要一个卧倒的动作及俯卧中的状态，以及对应回去的起身的动作。

而同上的站姿移动，卧倒中要移动，可能也必须要仰赖开始移动的事件来到匍匐移动中，而停止移动，则可返回静止卧倒状态。

如此我们便完成了一张状态图

假设今天不管这张图是从工程师这边画出来或从 PM 那边拿到，是不是比较能轻易理解？

接着明天会将 Flowchart 、 State Diagram 做一个比较

参考文献

• Wiki: State Diagram

图片引用

• 2D GAME POLICE CHARACTER FREE SPRITE SHEETS
• Game Kits Adventure (Character Sprite Soldier Police)