游戏开发论坛

 找回密码
 立即注册
搜索
查看: 4445|回复: 1

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

[复制链接]

4万

主题

4万

帖子

8万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
82751
发表于 2021-8-11 13:28:50 | 显示全部楼层 |阅读模式
好久不见!如果不是还在持续增长的关注,我可能就意识不到还有人在关注这些知识,但总归还是看到了对这些东西感兴趣的人,我觉得还是有必要打起精神再继续更一些干货,希望你们能喜欢。废话不多说,进入正题!

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

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

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

动作名词的“定义”

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

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

好的。

我举个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%的沟通效果。

指令(动作)层级

所输入的指令的层级关系,字面意思上我们可以理解为按键输入的指令,但在我构建的这套系统里面这是不正确的,这里的指令指的是每一个动作,因为同样的“按键输入”绝对会因为一些连招的机制形成不同的“动作”,所以“按键指令”是不可靠的这里的指令代表的是“动作指令”。

其实动作层级我之前也讲过,这里不赘述。

需要分清楚单个动作与动作之间的从属关系,以及动作之间的层级关系;因为表达的东西很复杂,所以我会用到“流程图”和文字,因为有时候光文字是没有办法表述清楚的。如下图就是从属关系:

image001.png
【动作之间的从属(递进)关系图,并非状态机】

这张图片作为静态图能表现出来的信息有限,在给程序的时候这种图是有动态效果的,可以通过“传输点”看出从属关系,方便让程序理解哪个动作可以递进到哪个动作。

而动作的层级关系表,则需要额外的详细描述,你需要一个详细的列表,写上你的动作名称和英文名称(动作软件中使用的英文名称),以及它的层级关系;谁是最高的层级(比如死亡),谁是最低的层级(比如待机),一个个列好,不要让人物在“死亡”的时候还能“跑”。

这块可不是一篇文章就能完全讲的清楚的,哪怕我之前搞了那么多文章,又给了一些图例,其实光就这个段落就能讲一大篇文章,我希望的是大家能够通过这篇文章将动作游戏的细节理解清楚,然后自己在做项目的时候能够少踩点坑,并且建立一个良好的概念,最后自己总结出自己的方案。

流程判断

流程判断指的是“伤害判断流程”、“各种效果计算流程”、“单元(配表)模块流程”,除开前面两个流程,“单元(配表)模块流程”这块做过游戏行业的策划都知道,很多策划的工作就是在前面的所有框架全部打好之后,只管根据要求填参数。但对这部分人来说“流程判断”这块应该还是很好理解的。但是,没有接触过游戏策划的人应该也是大量存在的,所以这里我需要简单的讲述一下这块主要是什么。

简单理解伤害判断流程,就是我们需要告诉程序该怎样生成伤害,怎样判断生成伤害,什么条件下做什么伤害判断,有没有什么特殊情况。请看下面的图例:

image002.png
(注意这些内容一定要和程序面对面沟通)

简单理解伤害计算流程,就是伤害的计算方式,请看下面的示例,伤害计算流程(这不是伤害判断流程!!注意):

普通伤害计算流程:

效果帧 → 是否闪避 → 物理伤害(是否暴击) → 属性加成百分比 → 伤害减免(包括防御等所有减免) → 是否格挡 → 最终伤害


被闪避则跳过所有流程直接冒字"MISS"

伤害Buff流程:

效果帧 → 是否被抵抗 → 属性加成百分比 → 最终伤害


被抵抗则跳过所有流程直接冒字“抵抗”

这里说一句,我给出来的并不适合直接照搬,仅用作理解。

再简单理解效果计算流程,就是将一系列(相同性质的)参数信息定制成ID,做成一个单元(表格);通过和程序约定各个单元(表格)的作用;再通过程序按照你指定的规则调用各个单元的参数,通过参数与参数之间的计算获得你想要的结果;其中每个单元负责的作用不同,你需要和程序约定由单元A到B,再由B到C和D······最后到G,并最后得到你要的结果。

请看下面的示例图:

image003.png
(这仅代表了一部分的单元流程,别照搬,不知道参数就搬会死的很惨)

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

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

结语

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

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

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

祝大家共同进步!

文/无良印品
来源:机核
原文:https://www.gcores.com/articles/140154

0

主题

29

帖子

305

积分

中级会员

Rank: 3Rank: 3

积分
305
发表于 2021-8-11 14:13:08 | 显示全部楼层
马克,看标题挺大
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2024-3-28 17:13

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表