好久没见到你了！ 如果不是关注度持续增长，我可能不会意识到还有人关注这些知识，但我仍然看到有人对这些东西感兴趣。 我觉得有必要打起精神，继续补充更多有用的信息。 我希望你能喜欢它。 废话不多说，咱们进入正题吧！
本文主要讲解动作游戏的底层构建，包括“动作名词的定义”和“机械规则”以及“指令（动作）级别”和“流程判断”。 这些都是我自己的习惯，现在不知道是什么了。 所以没关系，一会儿我会一一解释。
动作名词的“定义”
上面副标题的意思可以理解为，我们动作游戏中的每一个动作名词都必须由设计师亲自定义，并在正式的设计文档中实现，比如：行走、跑步、冲刺、跳跃、攻击等； 这是动作游戏中最低、最低水平的框架工作。 有些人可能不同意，不明白为什么这很重要……别怀疑，我的一个非常擅长规划的朋友曾经就“这到底是个什么样的底”发表过外行的评论。 我当时很生气，差点给了他，我就控制不住了，所以我就不多说了，接下来看。
这个时候游戏素材下载 免费，一定有人可能像我的策划朋友一样，充满了疑问。 为什么我们需要在正式文件中定义（描述）这些我们一目了然的名词？ ？
好的
让我举一个例子：
仅仅看这个例子并不能让大多数人理解为什么需要定义，因为它只是意味着需要解释动作设置和制作方法。 别急，我们看下一篇。
我们再举一个例子B：
读完本文后，如果你比较A和B，你会发现同样的动作可能会导致完全不同的操作（触发）方式； 不仅如此，还可能导致完全不同的制作方式。 只要看看跳跃的“定义”就知道了。 明白了，一个是单独制作的，另一个是一起制作的。
有人会说这两种方法跳转没有太大区别吗？ 事实上，差异是巨大的。 在示例A中，拆分动作可以将每个动作的优先级分别插入到其他动作中，而在示例B中，作为一个整体，无法根据需要插入详细的动作。 前后不同的动作（必要时可以做，但需要额外定义，具体取决于生产习惯和需求）。
现在我们来看看为什么我们需要单独定义动作游戏中的每个动作。 这是一本自己的动作游戏词典。 它是一本字典，您可以在其中告诉程序这些操作是什么游戏开发流程图，并告诉操作设计者如何执行这些操作。 这可以说，如果影响操作和设计生产方法的定义没有在正式的设计文件中得到落实，哪里会出现问题呢？
我们需要单独定义每个动作来初步建立我们对游戏操作和实现的理解，但此时不要忘记我在上一篇文章中对动作游戏的理解，它们是相辅相成的。 比如我曾经说过，将一个攻击动作分为“攻击动作”和“后摆动作”两个动作，就可以用在这个“定义”阶段。
每个人都花时间自己解决下一个定义工作，我们必须继续下一个问题。
该机制的规则
从字面上理解很难，所以我需要在这里解释一下。 如果我们需要描述组合连接是如何工作的，我们需要单独清楚地描述组合连接中的规则。 这个过程类似于“定义”。 但为什么要把它单独拿出来，是因为它属于玩家“操作”产生的“动作规则”。
这是我的工作流程的一个动作机制，这个机制生成了一系列的规则。 因此，单独提及是为了防止与“定义”的概念混淆。
我通常把“冲锋攻击”、“组合连线”、“剑斗/闪避”等概念视为一种机制描述，并要求程序按照我描述的规则来实现这些机制。
让我举一个例子：
组合连接：
按一次释放相应动作；
关键信息只记录两次。 如果某个按键被按下3次或3次以上，则记录最后一次按键信息；
连续普攻动作连接示例：在一次普攻动作结束前（不包括移动后摆），若有按键响应，则连续播放下一个普攻动作，重复操作直至最后一个编号基本攻击完成。 ，该动作序列结束；
正常情况下，如果基本攻击动作（不包括后摆动作）最后一帧后没有按键响应，则连击状态会失败，动作会恢复到对应的待机恢复动作； atk1 → atkidle1 → 空闲
异常情况是指我们会有表参数来控制按键响应时间。 因此，如果没有参数的影响游戏开发流程图，则称为正常情况；
连续基本攻击动作的连接过程示例：atk1→atkidle1→idle
atk1中的关键响应是atk2→atkidle2→idle
atk2中的关键响应是atk3→atkidle3→idle
atk3中的关键响应是atk4→atkidle4→idle
这个例子应该很清楚了，不太可能会出现什么混乱的情况。 这是构建动作游戏基础的一套机制。 同理，如果要描述“带电攻击”这个概念，也是一样的。
另一个例子：
充电动作：
当玩家按住攻击键超过0.36秒时，角色将进入冲锋动作；
连续按住攻击按钮超过固定时间。 例如，1.5秒后，您将进入充电阶段2，您将进入下一阶段的充电； （可以通过核心和道具加速）
蓄力阶段随时松开攻击按钮，蓄力攻击就会释放；
充电阶段1：0.36-1.5秒； 伤害100%-200%
充电阶段2：1.5-2.7秒； 伤害200%-400%
充电阶段3：2.7-4秒； 伤害400%-700%
你可以按照这个模型来描述你想要的功能。 每个人想要的东西都不一样，所以你不必遵循我写的。
综上所述，如果说“定义”是“积木”本身，那么“机制”则属于构成整个动作游戏的“积木搭建指南”。 你是在告诉程序这些动作机制是如何出现的，它们之间是如何联系的，又是如何区分的，需要注意哪些问题？
此外！ 如果有角色动作项目文件同步说明就更好了。 可以导出Gif图到程序中进行说明，或者像我上一篇文章那样手绘动作效果舞台也是可以的。 言语所能描述的有时并不能达到100%的沟通效果。
指令（动作）级别
输入指令的层次关系从字面上可以理解为通过按键输入的指令，但在我搭建的系统中这是不正确的。 这里的指令指的是每个动作，因为由于某些组合的机制，相同的“击键”“输入”肯定会形成不同的“动作”，所以“按键命令”是不可靠的。 这里的命令代表“动作命令”。
其实之前我已经讲过动作层面了，这里就不再赘述了。
需要明确区分单个动作与动作之间的从属关系，以及动作之间的层级关系； 因为表达的东西很复杂，我会用“流程图”和文字，因为有时候光靠文字是无法表达清楚的。 的。 下图展示了隶属关系：
【动作之间的依赖（渐进）关系图，不是状态机】
作为静态图片，这张图片所能表达的信息有限。 当交给程序时，这张图片就有了动态的效果。 通过“转接点”可以看出从属关系，方便程序了解哪个动作可以进展到哪个动作。 。
动作的层次关系表需要额外的详细描述。 你需要一份详细的列表，上面有你的动作的名称和英文名称（动作软件中使用的英文名称），以及它的层次关系； 谁的等级最高（比如死亡），哪个等级最低（比如待机）都被一一列出。 不要让角色“死”时“跑”。
这个主题无法在一篇文章中完整解释。 虽然我之前写了那么多文章，也给出了一些插图，但其实光这一段就可以写一篇大文章了。 我希望的是大家能够通过阅读这篇文章，清楚地了解动作游戏的细节，从而让自己在做项目的时候避免踩坑，树立一个好的概念，最后总结出自己的方案。
过程判断
流程判断是指“伤害判断流程”、“各种效果计算流程”、“单元（表匹配）模块流程”。 除了前两个流程之外，“单元（表匹配）模块流程”在游戏行业策划者都知道，很多策划工作就是在前面所有的框架都布置好之后，再按要求填写参数。 但对于某些人来说，“过程判断”方面应该很容易理解。 不过，应该有很大一部分人从来没有接触过游戏策划，所以这里我需要简单描述一下这个领域是什么。
简单理解损伤判断流程就是我们需要告诉程序如何产生损伤，如何判断产生的损伤，在什么条件下做出什么样的损伤判断，是否有特殊情况等。 请看下面的图例：
（注意这些内容一定要和程序面对面沟通）
伤害计算过程简单理解就是伤害是如何计算的。 请看下面的例子，伤害计算过程（这不是伤害判断过程！！注意）：
一般伤害计算流程：
效果框→是否闪避→物理伤害（是否暴击）→属性加成百分比→伤害减免（包括防御等所有减免）→是否格挡→最终伤害
如果被躲闪，就会跳过所有流程，直接装成“MISS”。
伤害BUFF流程：
效果框→是否被抵抗→属性加成百分比→最终伤害
如果遭到抵制，则跳过所有流程，直接写“抵制”
这里声明一下，我给出的不适合直接照搬，仅供理解。
简单理解效果计算过程，就是将一系列（性质相同的）参数信息定制成ID，做成一个单元（表格）； 同意该计划关于每个单位的作用（表）； 然后使用该程序来遵循您指定的规则。 调用各个单元的参数，通过参数之间的计算得到你想要的结果； 每个单位负责不同的角色。 你需要同意程序从A单元到B单元UI界面，再从B单元到C单元、D单元……····最后到G单元，最终得到您想要的结果。
请参见下面的示例图片：
（这仅代表部分单元流程，请勿照搬，不知道参数你会死得很惨）
这些流程是底层框架的重要组成部分。 如果做得好，会有很大的发展空间！ 以后你想创造什么效果都可以通过这组底层来完成（当然是有边界的）。 无需添加额外的单元（表）。 太多的单元可能会发生冲突或导致不必要的工作。 数量。
将来我们可能会谈论表如何“简化”、“可扩展”、“易于理解”……但最好不要抱希望。 如果我讲得这么详细，我想我可以开一个班，做一些知识付费。
结论
这篇文章就讲完了动作游戏底层框架的要点。 如果你把它们全部消化并应用到你自己的规划文件中，你就会取得巨大的成功。 剩下的细节自然会在制作游戏时遇到，然后自己解决。 。 能从第一篇文章读到这篇文章的人可能素质都很好，我相信你们。
如果以后我还准备文章的话，我可能不会讲规划，而是讲更具体的东西。 因此，我可能会直接转型到游戏动作艺术表演，或者体验设计等。
回头见。 希望可以和大家分享更多，但是我太懒了（如果你真的需要的话，可以尝试推我一下，但反正我也不一定会这么做）。 目前一共有五篇文章可以帮助你理解。 我刚刚开始制作（2D）动作游戏，但我真的没有太多与 3D 相关的事情可做，哈哈。
祝愿大家能够共同进步！
