好久不见了！如果不是关注度越来越高，我可能都不知道还有人在关注这些知识，但毕竟还是看到有人对这些东西感兴趣，所以我觉得还是有必要打起精神来继续更新一些干货，希望大家喜欢。废话不多说，进入正题吧！
本文主要讲解动作游戏的底层构建，包括“动作名词定义”、“机制规则”、“指令（动作）层级”、“流程判断”，这些都是我自己的命名习惯，现在看不懂没关系游戏搭建，一会儿我会一一讲解。
动作名词的“定义”
上面小标题的意思可以理解为我们动作游戏中的每一个动作名词都必须由设计师亲自定义，并落实到正式的设计文档中，比如：行走、跑步、冲刺、跳跃、攻击等等。这是动作游戏最基本的框架工作。有些人可能会不同意，不明白为什么这很重要……不要怀疑，我一个非常优秀的策划朋友就曾经说过“底层是什么”，当时气得我差点没法做了。我们接下来就来看一下吧。
这时候有些人可能跟我的策划朋友一样，脑袋里有很多疑问，为什么我们需要在正式的文件中定义（描述）这些一目了然含义的名词？？
好的
让我举一个例子：
单看这个例子，大多数人不会理解为什么需要定义，因为它只表示需要说明动作的设定和制作方法。别担心，我们看下一个。
我们来看示例 B：
看到这里之后，如果将 A 和 B 进行对比，就会发现同样的动作可能会导致完全不同的操作（触发）方式；不仅如此，还可能导致完全不同的制作方式。再看跳跃的“定义”，就可以理解一个是单独完成的，一个是一起完成的。
有人会问这两种方式在跳转上看起来是不是差不多？其实区别很大，示例A中拆分动作可以按照优先级插入到其他动作中，而示例B中动作整体无法按照要求在不同动作前后插入详细动作（其实是可以的，但需要额外定义，具体视生产习惯和要求而定）。
现在我们来看看为什么我们需要在动作游戏中单独定义每一个动作。这是我们自己的动作游戏的字典，是字典告诉程序这些动作是什么，告诉动作设计者如何执行这些动作。这会影响操作的定义、设计和制作方法。如果没有在正式的设计文档中实现，当问题出现时，我们该从哪里找到答案？
我们需要对每一个动作进行单独的定义，从而建立起对游戏操作和实现方法的初步理解，但此刻，别忘了我之前文章中对动作游戏的理解，这是相辅相成的，比如我曾经说过，一个攻击动作可以分为“攻击动作”和“后摆动作”两个动作，就可以在这个“定义”阶段使用。
请花点时间完成以下定义工作。我们将继续讨论下一个问题。
机制规则
从字面上理解起来比较困难游戏搭建，所以需要在这里解释一下。如果我们需要描述一个连击连接是如何进行的，我们需要单独描述连击连接的规则。这个过程类似于“定义”。但为什么要单独拿出来呢？因为这是由玩家的“操作”生成的“动作规则”。
对于我的工作流来说，这是一个动作机制，这个机制会产生一系列的规则。因此，我会把它单独拿出来，避免和“定义”这个概念混淆。
我通常把“蓄力攻击”，“连击连接”，“剑斗/闪光”等概念描述为一种机制，并要求程序按照我所描述的规则来实现这些机制。
让我举一个例子：
组合连接：
按下一次，释放一次相应动作；
仅记录两次按键信息。如果按键被按了三次或更多次，则记录最后一次按键信息。
连续普攻动作连接示例：在一次普攻动作（不包括挥拳后的动作）结束前，如果有按键响应，则连续进行下一次普攻动作，并重复此操作，直到最后一次普攻完成后，此动作序列结束；
正常情况下，普通攻击动作（不包括挥舞后的动作）最后一帧后若无按键响应，则连击状态失效，恢复为该动作对应的待机恢复动作；atk1 → atkidle1 → idle
异常情况就是我们有表参数来控制关键响应时间，所以没有参数影响的情况就称为正常情况；
连续普通攻击动作流程示例：atk1 → atkidle1 → idle
在 atk1 中，关键响应是 atk2 → atkidle2 → idle
atk2 中的关键响应是 atk3 → atkidle3 → idle
atk3 中的关键响应是 atk4 → atkidle4 → idle
这个例子应该非常清楚，不会让人混淆。这是构成动作游戏基础的一套机制。如果你想描述“蓄力攻击”的概念，也是如此。
下面是另一个示例：
充电动作：
当玩家按住攻击键超过0.36秒时，角色将进入冲锋动作；
持续按住攻击键固定时间，例如1.5秒后，会进入蓄力阶段2，持续1.5秒后会进入下一个蓄力阶段；（可通过核心和道具加速）
蓄力阶段任何时候松开攻击按钮，都会释放蓄力攻击；
冲锋第一阶段：0.36-1.5秒；伤害100%-200%
冲锋第二阶段：1.5-2.7秒；伤害200%-400%
冲锋第三阶段：2.7-4秒；伤害400%-700%
你可以按照这个模型来描述你想要的功能。每个人想要的东西都不一样，所以你不必按照我写的来。
总结一下这里我们看到的，如果说“定义”是“积木”本身，那么“机制”就是构成整个动作游戏的“积木指南”。你在告诉程序这些动作机制是如何出现的，如何连接，如何区分，需要注意哪些问题。
另外！如果有角色动作项目文件同步说明就更好了，可以导出Gif图到程序里说明，也可以做我之前文章里的手绘动作效果阶段。有时候文字能描述出来的效果，并不能达到100%的传达效果。
指挥（行动）级别
输入命令的层级关系，字面上可以理解为按键输入命令，但在我搭建的系统中这是不正确的。这里的命令指的是每一个动作，因为同样的“按键输入”肯定会因为一些组合机制而形成不同的“动作”，所以“按键命令”是不可靠的。这里的命令代表的是“动作命令”。
其实关于动作层面我之前已经讲过了，这里就不再重复了。
需要区分各个动作之间的从属关系，以及动作之间的层级关系；因为表达起来很复杂，所以我会用“流程图”和文字来表达，因为有时候单靠文字有时候无法表达清楚。下图显示了从属关系：
【动作间的从属（递进）关系图不是状态机】
这种图片作为静态图片，能展示的信息有限，交给程序看，就有了动态的效果，通过“传递点”可以看到上下级关系，让程序更容易理解哪个动作可以进行到哪个动作。
动作的层级关系表需要额外的详细描述。你需要一份详细的清单，写下你的动作名称和英文名（动作软件中使用的英文名），以及它的层级关系；谁是最高级别（比如死亡），谁是最低级别（比如待命），一一列出，千万不要让角色在“死了”的时候“跑”了。
这不是一篇文章就能完全讲清楚的。尽管我之前写过那么多文章，也提供了一些图解，但光是这一段就能写满一篇大文章。我希望大家能通过这篇文章了解动作游戏的细节，然后在做自己的项目时避免陷阱，树立好概念，最后总结出自己的解决方案。
流程判断
流程判断指的是“伤害判断流程”、“各种效果计算流程”、“单元（匹配表）模块流程”。除了前两个流程，游戏行业策划都知道，很多策划的工作就是在前面的框架全部完成后，根据需求填写参数。但对于这些人来说，“流程判断”应该是很容易理解的。不过应该还有相当一部分人没有接触过游戏策划，所以这里我需要简单说明一下这部分主要讲的是什么。
简单来说，伤害判断流程就是我们需要告诉程序，如何产生伤害，如何判断产生的伤害，在什么条件下做出什么样的伤害判断，以及是否存在特殊情况等。请看下图：
（注意这些内容必须跟项目方当面沟通）
简单了解一下伤害计算流程，也就是伤害是怎么计算出来的，请看下面的例子，伤害计算流程（这个不是伤害判断流程！！注意）：
正常伤害计算流程：
效果框→是否闪避→物理伤害（是否暴击）→属性加成百分比→伤害减免（包含防御等所有减免）→是否格挡→最终伤害
若被躲避，则跳过所有步骤并直接显示“MISS”字样
伤害增益流程：
效果框→是否被抵抗→属性加成百分比→最终伤害
如果遭到抵抗，则跳过所有步骤，直接显示“抵抗”字样
这里要说一下，我给出的内容并不适合直接复制，仅供理解。
简单来说，效果计算过程就是把一系列的参数信息（性质相同）自定义成ID，做成一个个单元（表）；和程序约定好每个单元（表）的功能；然后使用程序按照你指定的规则调用各个单元的参数，通过参数之间的计算得到你想要的结果；每个单元负责的功能不一样，你需要和程序约定好从单元A到B，再从B到C到D……最后到G，得到你想要的结果。
请参阅下面的示例图：
（这个只代表了单元流程的一部分，千万别抄，如果不知道参数就抄，你会死得很惨。）
这些流程是底层框架的重要组成部分。如果做得好，将有很大的发展空间！你可以利用这个底层框架来实现以后想要的任何效果（当然，这也有界限），而不需要添加额外的单元（表）。单元太多可能会引起冲突，或者造成不必要的工作量。
也许以后我会讲如何让表格“精简”、“可扩展”和“易于理解”……但最好不要抱有希望。如果我讲得这么详细，我觉得我甚至可以开一门课程，赚点有偿的知识。
结论
本文已经讲完了动作游戏底层框架的要点，能把这些全部消化掉，并运用到自己的策划文档中就是很大的成功了。剩下的细节自然会在制作游戏时遇到，然后自己解决。我相信从第一篇文章读到这里的人都是高水平的。
如果后面再准备一篇文章的话，大概就不会讲策划了，因为那样会更具体一些，可能会直接转型到游戏动作美术表现，或者体验设计等方向。
很快再见，希望能与大家分享更多，但我太懒了（如果你们真的需要我，可以试着催我，反正我可能不会这么做）。目前一共有五篇文章，帮助大家入门理解和构建（2D）动作游戏。我暂时真的对 3D 一无所知，哈哈。
祝大家共同进步！
