底层搭建：踏入动作游戏的制作阶段

时间：2021-08-11 13:32:03 来源：作者：网络转载

制作动作游戏吧

大小：18.09MB更新：2019-07-03

分类：动作射击

好久不见！如果不是还在持续增长的关注，我可能就意识不到还有人在关注这些知识，但总归还是看到了对这些东西感兴趣的人，我觉得还是有必要打起精神再继续更一些干货，希望你们能喜欢。废话不多说，进入正题！

新选手和忘了以往内容的的老选手，以下是往期内容传送门：

硬直与反馈初始篇
连招系统篇
硬直系统篇

这篇文章主要讲解动作游戏的底层搭建，包括了“动作名词的定义”和“机制的规则”和“指令（动作）层级”以及“流程判断”，这是些称谓我自己的习惯，现在不明所以没有关系，一会儿就一一解释。

动作名词的“定义”

上面的小标题的意思可以理解为，我们动作游戏中每一个动作名词必须由设计师亲自定义，落实到正式的设计文档，比如：走路，跑步，冲刺，跳跃，攻击等等；这是动作游戏最底层最底层的框架工作。有人可能会不同意，也不明白这有什么重要的……不要怀疑，我的一位很要好的策划朋友就提出过“这算什么底层”的门外汉言论，我当时给气乐了，差点给我整不会了，不多说接下来就来看。

这个时候一定有人可能和我那个策划朋友一样，满脑子问号，为啥需要在正式文档定义（描述）这些一看就知道什么意思的名词？？

好的。

我举个A例子：

跑步：当角色走路超过3秒之后由走路切换到跑步动作；
跳跃：拥有三个动作，起跳（Jump1）、持续下落（Jump2）、下落恢复（Jump_idle）；起跳使用第一部分，当角色root点离“地面”Y轴距离1像素高度的时候，处于“浮空状态”，持续Jump2动作；离“地面”Y轴距离-1像素的时候，播放Jump3；

光看这个例子，还不能让大部分人理解为什么要定义，因为这只是代表了需要解释动作设定和制作方式，不急我们再看下一个。

再举个B例子：

跑步：仅双击方向键，角色立刻由走路切换跑步动作；
跳跃：该动作使用工具或者事件帧拆分，将Jump动作划分为三个部分，起跳使用第一部分，当角色root点离“地面”Y轴距离1像素高度的时候，处于“浮空状态”，持续循环第二部分；离“地面”Y轴距离-1像素的时候，播放第三部分；

看了这个之后对比一下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阶段： 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，再由B到C和D······最后到G，并最后得到你要的结果。

请看下面的示例图：

（这仅代表了一部分的单元流程，别照搬，不知道参数就搬会死的很惨）

这些流程是底层框架组成的重要一部分，如果做的好，就会有很大的开发空间！你后面想要做什么样的效果都可以利用这套底层来完成（当然这也是有边界的），不用额外加单元（表格），单元多了还有可能会冲突，或者造成本没必要的工作量。

以后可能也许大概会讲到表格怎样“精简”、“可扩充”、“易于理解”……但是最好还是不要抱希望，说那么细，我觉得自己都可以开课了，搞点知识付费。

结语

这篇文章讲完了动作游戏底层框架的主要几个点，把这些全部消化掉再运用到自己的策划文档里面就是大成功，剩下的一些细节做游戏的时候自然会碰到然后自己解决掉的。能够从第一篇一直看到这里的大伙估计都是有水准的，相信大伙。

之后我如果还要准备文章的话可能不会讲策划方面的了，再讲就是更具体的东西了，所以，我可能会直接过渡到游戏动作美术表现，或者体验设计等等方向。

过段时间再见吧，希望能够和大家分享更多，但是我太懒了（如果你们真的需要你们可以试着催一催，反正我也不一定做），目前总共五篇文章帮助大伙在理解和搭建（2D）动作游戏上入个门，3D我就暂时真的没什么办法了，哈哈。

祝大家共同进步！

来源：机核
原文：https://www.gcores.com/articles/140154

资源转载网络，如有侵权联系删除。