找回密码
 立即注册
查看: 917|回复: 13

Unity2D格斗游戏开发问题?

[复制链接]
发表于 2021-11-11 10:43 | 显示全部楼层 |阅读模式


题主来填坑,两个月前在知乎发了这个问题大家的帮助,参考大家的建议后自己就在Unity里开干了,断断续续做到现在要求功能已经完成,说一下大体思路吧:
直接说最核心的问题,战斗系统:
A.碰撞检测: 我在每个角色对象身上放了3类碰撞盒:
1.攻击(子物体)。
2.防御(子物体)。
3.伤害判定(自身)。





B.攻击判定: 在攻击动画中调整碰撞盒是否激活:例如普攻中的第一击,其他攻击判定类似。(某些技能还可巧用帧事件)




C.防御判定:当播放防御动画的时候,防御碰撞盒出现,注意在敌方后面攻击时防御无效(这个我是根据人物朝向来写的)


D.被击后的反应:
1.根据受到攻击的技能播放不同的特效动画.
2.轮流播放被击动画(僵直)。
3.掉血。
4.增加气槽量(每个气槽释放一次大招)。
大概也就以上这些,编程方面的东西就不赘述了,主要还是思路,下面大家可以欣赏一下美术:











PS:最近也一直在忙自己的游戏项目《灵》,是一款解谜游戏,目前团队5个人,虽然都不是很专业,但是大家都有十足的热情和毅力这是非常难得的,有兴趣的朋友可以关注我的
公众微信:黑客画家
个人网站:http://anchorart9.com
大家一起在学习交流。
原文链接:Unity制作格斗游戏核心思路总结

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-11-11 10:51 | 显示全部楼层


题主来填坑,两个月前在知乎发了这个问题大家的帮助,参考大家的建议后自己就在Unity里开干了,断断续续做到现在要求功能已经完成,说一下大体思路吧:
直接说最核心的问题,战斗系统:
A.碰撞检测: 我在每个角色对象身上放了3类碰撞盒:
1.攻击(子物体)。
2.防御(子物体)。
3.伤害判定(自身)。





B.攻击判定: 在攻击动画中调整碰撞盒是否激活:例如普攻中的第一击,其他攻击判定类似。(某些技能还可巧用帧事件)




C.防御判定:当播放防御动画的时候,防御碰撞盒出现,注意在敌方后面攻击时防御无效(这个我是根据人物朝向来写的)


D.被击后的反应:
1.根据受到攻击的技能播放不同的特效动画.
2.轮流播放被击动画(僵直)。
3.掉血。
4.增加气槽量(每个气槽释放一次大招)。
大概也就以上这些,编程方面的东西就不赘述了,主要还是思路,下面大家可以欣赏一下美术:











PS:最近也一直在忙自己的游戏项目《灵》,是一款解谜游戏,目前团队5个人,虽然都不是很专业,但是大家都有十足的热情和毅力这是非常难得的,有兴趣的朋友可以关注我的
公众微信:黑客画家
个人网站:http://anchorart9.com
大家一起在学习交流。
原文链接:Unity制作格斗游戏核心思路总结

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-11-11 10:54 | 显示全部楼层
谢邀。
//============================突然兴起写了个关于移动的=====================
提示信息 -  GameRes游资网
这里所说的横版动作游戏,包含且不限于2D横版动作游戏、横版跑酷游戏、横版格斗游戏,只要逻辑层是横板的,且对于判定需要及高精度的(比如在动作游戏中就是拳头命中身体才算中,而不是WoW中,虽然近战攻击有时候看起来还有点距离,但是服务器计算命中就算命中了)就属于“横版动作游戏”范畴。

1,逻辑的世界



在一个横版动作游戏中,我们就讨论这个移动问题,把世界拆散成三个,他们互相之间是并行的,由这些并行的世界,组成了玩家最后看到的游戏,事实上不同的游戏中并行的世界可能会有更多个。
在这篇里,我主要说的就是移动世界,一个逻辑世界。在开发游戏的时候,当开发者处于这个世界时,会抛开一切攻防判定世界和贴图世界的信息。

2,地形
地形的定义我就不作出解释了,仅仅要说明的,地形并不仅仅是踩在脚下的。在横版动作游戏中,地形可以有以下一些信息:
1)坐标点
地形在这个世界上的点位置,一切地形相关的控制由这个点的变化来决定他的位置,坐标点不是一个2维的x,y,它还包含了一维inWorld,我们暂且这么称呼,表示他是否在世界上存在。坐标点(x,y)的作用大家肯定第一时间可以抽象的出来——就是在一些横版动作游戏中,有些会移动的岛屿,FC的冒险岛、超级马里奥开始就有。



这个很熟悉吧, 屏幕中间那两根会带着你往上或者往下走的地形,有时候角色踩上去还会自动往下掉。这就是(x,y)坐标在这里的作用。而会消失的地形,其实很多横版动作游戏也是有的,你接触的第一个这样的游戏可能就是……



FC的经典大作魂斗罗,我们这一代游戏人都是玩这个长大的,不少人人生第一个游戏就是他,在刚开场没多久,你就能遇到一座桥,走过去的时候会爆炸,原本可以踩的地形inWorld变成false了,当然对于这个桥,更高效的处理是去掉这个地形信息,但是在另外一些动作游戏中,他会出现那种若隐若现的地形,出现的时候可以踩,但是消失了就会掉下去



FC的赤影战士里面有很多这样的地形,另外也有成龙之龙等都会有这样的地形。

2)天花板、充实体、墙壁
这两个都是可选属性,且都是boolean的,天花板的概念很好理解,就是当角色起跳的时候,会因为顶到天花板而终止跳跃开始下落,这是最常见的,天花板其实还是限制版子边缘的东西,也就是角色无法往上走了。
最古老的天花板之一:



超级马里奥开始的时候那些问号、砖头、顶掉问号后的铁块,都是天花板=true的,而魂斗罗中,大多地形天花板都是False的, 因此角色可以自下而上的跳跃。
充实体则是角色往下跳的障碍,这个真不好找图(因为无法说明问题),但是相信每个人的游戏经历里面都会遇到:
充实体=false的时候,角色按下和跳是会往下跳一层的。
充实体=true的时候,角色按下跳,要么就是蹲着,要么就是原地跳起(根据游戏设定的按键反馈不同)。
至于墙壁,就太好理解了,通常版子边缘,或者一些横向不让走过去的都是Wall=true的,比如上图玛丽奥里面的绿色水管就是个典型。

3)体型
这是地形最重要的属性,这决定了这块地形的大小。
老式的游戏中,采用二维数组作为地图,依然是Tile Based,如超级马里奥系列,所以都是正方形。但是随着游戏精度要求越来越高,也出现了多边形的地形,并且世界不再是tile based。



早在MD时代,索尼克已经采用了特殊形状的地形(可怜国游的跑酷还做不出来)。体型的作用是什么我这里就不多说了,核心在于不是矩形的体型与点的碰撞算法,是要数学功底的,这里我就不提供算法了,自己百度很容易搜到,都是初中、高中教程了。
体型当然不是一个简单的polygon就了事而得,他还有一个offset坐标,这个坐标的x,y是与坐标属性的x,y产生关系的,已决定这个地形出现在哪儿。我们刚说了移动地形。

4)强制位移、溜滑、弹性。
严格的来说,溜滑、弹性是强制位移的一种,但是概念上来说还是要把它们分开。
强制位移,是指当角色处于这个地形的时候,会收到一个外力(forceMoveX, forceMoveY),这些外力会导致角色的移动在x,y方向上受到力的作用:



最常见到的是传送带,但是松鼠大战中著名的强制移动地形不仅仅是传送带,还有电风扇。核心在于你往一个方向走会很慢,但是往另一个方向走却会很快。这里要特别注意的是,一些游戏中实现Y方向的强制移动可能是增加角色的重力或者跳跃力。
溜滑属性(通常是float)他的作用是让角色在停止移动的时候,还会逐渐保持一个减速的ForceMoveX效果:



早在FC的冒险岛1代,我们就遇到过这种溜滑的地形。
而弹跳属性(通常也是float),则是给角色强加一个jump的力度,最常见的是:



注意到屏幕中间那个弹簧了么,就是他!

5)位移轨迹node,可携带性。
一些地形有自移动的能力,他们通常会跟随一定的轨迹移动,而这些地形通常也会需要设定一个可携带性,可携带性决定了角色在地形上是否会跟随地形的位移而位移。而地形位移的信息,除了坐标的移动轨迹、每两个轨迹间的tick长度外(这时候inWorld属性也就起作用了,你可以设计一个地形移动到一个地方突然没有了),还要设定一个可携带性,因为并不是所有的地形都要带着上面的角色走的(这个自开脑洞吧)。



松鼠大战里面的小板车是“最不标准”的位移地形(可携带)。当可携带为true的时候,我这个地形这一帧的位移,也会成为ForceMove传递给角色(所以通常循环里面地形的位移在前,别问我为啥这么不严谨,因为大家都喜欢偷懒)。

6)其他属性
之所以归纳为其他属性,是因为根据游戏的不同,你还可以给地形带上一些其他的属性来丰富他,但是这些属性通常与现在正在讨论的位移这件事情没什么大关系。比如你给地形带来一个烧伤力,角色走上去会受伤,并且受到吹飞力等影响,的确这个吹飞力会影响到角色的移动,但这个逻辑并不属于这一层,而是属于攻防判断层带来的影响。



比如洛克人的钉板就会让角色直接挂了(至于图里面为啥没挂,你懂得)

3,角色
在位移这件事情上,角色又有哪些属性呢?
1)坐标与体型
早期的游戏中,也包括现在很多比较粗糙的游戏中,角色移动是一个矩形,通过这个矩形与地形(通常也都是矩形,既然这么做了肯定是效率优先,自然都用矩形)之间的关系来实现位移的每一个细节。
而好一点的游戏,却采用了点阵和法线:



一个角色通常有若干个点来组成,这是在地形(位移)判定的时候用的,而不是攻击框,这些点共同组成了一个多边形,这个多边形,决定了角色与地形的碰撞关系,而在角色中心会有一条法线(视觉上也是这个,但别跟法线贴图搞混了,完全没任何关系的),这跟法线是在角色ScaleX(左右反转)的时候使用的,让这些逻辑点的坐标也发生Scale,通常法线只是一个概念(并不存在实体数据),因为我们在设定角色的每一个动作的点阵(这个点阵是跟动作而非动作的每一帧的,有些游戏是跟角色的,都不分布道动作)的每一个点的坐标的时候,会把发现当做Y轴。而作为角色坐标的那个点,通常也是脚下那个X=0的点。

2)移动相关参数
角色本身(请一定注意“本身”)在一帧内移动相关的参数包括:
玩家期望位移(x, jump):这个是根据操作传过来的x,y方向的唯一,y方向的位移通常为跳跃力(一些游戏中根据你按跳的时间长度不同,跳跃力是不同的,超级马里奥就是一个代表,对于玩家来说甚至是一个技巧活)。一些游戏中,角色在空中可以受到按键影响改变跳跃的方向,也就是因为“角色腾空后”依然接受x方向处理。
来自动作的强制位移(forceMoveX, forceMoveY, ignoreFloor):强制位移主要是x,y方向上的,通常来说,会多一个ignoreFloor,但不会有ignoreWall或者ignoreRoof这种,当然成为ignoreFloor也不太科学,他的本意是——当我强制位移中,是否还受到正常的重力影响,典型的是侍魂中的不意打,这是一个非跳跃动作,但他有真的起跳了。还有DNF一些角色的后跳技能。

3)角色在这一帧的位置变化一审(李狗海看多了)
角色的位移,分为2个:X方向和Y方向。
X方向的位移距离=玩家期望X(通常这里是经过buff等计算的最终X方向的速度)+自身动作forceMoveX+地形ForceMoveX+游戏其他因素ForceMoveX。
Y方向的位移距离=-起跳力(这里有2个做法都不能说错,一些游戏中先运算了起跳力-重力,而一些则是在下一步运算,这两个都OK,看coder和designer的想法了)+本身ForceMoveY(如果是Jump变化则为-)+地形ForceMoveY+游戏设定ForceMoveY。

4)角色的位移定案
当我们知道了角色在2个方向上的移动距离以后,我们就要进行碰撞判断,决策是否最终能够去到那个点。
一些老的游戏的做法,现在可能并不是最合适,但是也是比较好用的是:直接判断这个点是否能放角色(马里奥做法),如果可以就过去,否则这次位移的目标点变成角色当前所在点。
更好的做法(恶魔城GBA开始的做法)则是:



我们来看图1,好的做法(也是适合与任何角度地形的)是将角色的碰撞点当前位置与目标位置相连,并计算这些直线与阻挡的关系。我们在图2中可以看到,蓝色的阻挡横向的如果是一个天花板,那正确的做法,角色还是应该继续向上,顶到天花板后才开始下落,但如果采用马里奥的做法,就会定不到天花板(正巧马里奥是tile的,大多时候避免了这个问题);而另一些游戏则是角色的头顶会超出天花板一点(其实这也完全可以接受)。但是如果做一条线段去判断,则可以返回出顶端的点(这里所有的具体算法都是高中数学水平的,我就不写了自行百度吧,或者找你家数值策划去),当然这不是唯一的好处。
我们再仔细看图2,假如世界上有2中地行,他是橙色的线条,而且她的宽度恰好是橙色线条这么宽,按照马里奥的算法,在速度够快(移动距离够大)的时候,我们会穿过这条线,形成“穿墙”,所以我们必须做出这样一条射线(其实还是线段,毕竟两头都知道了,但我们还是需要方向的),以保证不发生这样的bug,而不是无端的把墙壁变粗,关卡设计毕竟有她的巧妙性,而且你也没法保证角色的速度不会这么快对吧?尤其是跑酷游戏。

关于角色位移,这么小的一件事情,背后就是这么复杂的东西,有太多需要思考的东西,太多太多了。而且要注意的是,这里并没有说的是,角色之间还有碰撞,当角色之间还有碰撞的时候,其他角色的碰撞框对“我”来说就是地形(墙壁为True,至于充实体和天花板就看你游戏多么恶搞了)。所以,真不要小看了动作游戏里面的角色移动,跟回合制游戏的概念是完全不同的!

//===============================之前的回答==============================
这些问题并不是Unity才有的,所以其实问题可以去掉Unity的限制,所有2D格斗游戏开发思路是一样的。
其实这个问题回答起来太长了,我之前写过一些动作(格斗)游戏的相关的东西就已经很多了,但那些要帮你开发一个动作游戏是不可能的,先给你几个链接:
格斗游戏的招式指令判断
[经验心得]动作游戏中连招的实现
[项目经验]动作游戏设计中极容易犯的设计错误

一个动作游戏或者格斗游戏,每一个Tick(你必须理解他的时间单位是tick,而不是秒,其实就是计时器每一跳)会发生的事情:


1,所谓的位移信息就是当前角色正要做的动作、动作的第几帧、这一帧动作的强制位移信息决定的,所有角色、子弹、地形在这个世界上的位移(在逻辑层,世界是方块组成的)。
2,你需要for 攻击框 {for 挨打框 for 防御框}进行遍历,并且告诉下一环节,谁碰到了谁。
3,执行碰撞的逻辑,通常伤害、改变动作等都是在这里执行的,这里我不的不拐开说一句——在另外一个帖子里,居然有人认为动作游戏是可以在这一帧预判下一帧你会移动到那儿的,我就呵呵了(具有位移的技能是否应该支持被悬崖打断? - 游戏)最高赞的说的头头是道,还有这么多外行点了赞,我就笑了,你在这个tick的第一个事件,要去判断下一个Tick的第一个事件的情况,首先你就要演算出这个tick后面的2步,而言算出以后,你要回到第1步之前重新决策?这种逻辑思维怎么做游戏呢?

至于碰撞盒怎么加,加在每一个角色->每一个动作->每一帧下面的,所以是海量的工作,比如KOF早期的10个队伍(含boss),每队3人就是30个角色,每个角色平均20个动作,每个动作平均10帧长度,你就要去做6000个单位的判定盒,而且每一个单位里面都可能有攻击、防御、挨打3种,且每一种都可以超过1个,所以格斗游戏、动作游戏,没有积累是没法做的。不建议新手去做。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-11-11 10:55 | 显示全部楼层
我做过一套完整的2D格斗游戏的开发工具,或许可以给你一点帮助。打击体验要做的好,都是逐帧计算,命中、抵抗用多层碰撞盒子。会涵盖的变量因子下面有截图。



本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-11-11 11:05 | 显示全部楼层
不好意思哈,笔者现在还不够专业来回答这个问题,相信后面会有更多的开发者给出他们更专业的答案。不过我想给你提供一个思路:
就是MUGEN
当然你可以直接去看这个程序的代码。/*我并没有看过*/
我给你的建议是,找一个Mugen的角色包,用修改工具/*比如FighterFactory*/打开,看看格斗游戏的数据是如何组织的。我这里已经给你准备好了工具和一个角色包。http://pan.baidu.com/s/1bgjNFS
/*多上手玩一玩,自己也做一个角色包尝试下,会对开发有启发的*/
这是使用时的截图:



本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-11-11 11:05 | 显示全部楼层
不请自来。
之前自己动手写了一个2D动作游戏,类似鬼泣,可惜要画的东西实在太多,而我掌握不来,因此半途而废。写这篇答案既是总结开发过程中的种种心得,也可能给题主带来一些并不专业的经验。


以上是运行的时候的截图。

在这个半成品中,我为主角画了23帧,为怪物(也就是右边那位断臂屠夫)画了10帧。在试运行的时候,我唯一的感想是,动作帧一定要多,才流畅!



我为跑步动作画了6帧,然而根本于事无补,不调速度运行起来就跟抽风一样,调了速度运行又有一种令人难以忍受的黏着感。


第二个攻击动作“跨步拔刀”,我花了3+1+2帧,真正的攻击判定帧为hero 1_27那一帧,在游戏运行的时候,真正可谓刀如闪电……
因此,我觉得很重要的一点是:2D格斗,美术要到位。因为2D格斗游戏少有60帧的流畅速率,每一帧的延迟都会在人眼中放大,因此任何一帧的偷工减料都非常的明显。

其次,关于连招,由于我才写了两招,因此当时的思路并未完整写成。
游戏中我使用的是WASD(四方向)+JKLI(攻击跳跃特殊攻击使用物品)+空格键位(闪避),可以见鬼泣3SE对我的影响233。
这里我写了一个InputManager,在每一帧的Update函数中监控输入,然后把最近的若干次输入在Switch语句中查询一次,若找到对应的招数列表则调用HeroAnimation.cs的函数,改变动画状态机的状态,使动画发生改变,同时再调用PhysicalPrinciple.cs的函数,确定其状态和位置的改变。
这就是我架构的问题了,最开始写的时候,我使用了刚体来实现【重力】,后来发现有了刚体就做不到碰撞体相交的问题,大笔一挥就写了个PhysicalPrinciple来控制角色的位置,导致人物动作的实现被肢解成动画和物理两个完全单独的方面,写的时候很是精分不提,经常出现动画和位置无法匹配的问题——譬如人落地了还保持空中出刀的姿势。
因此,我得到的教训是:动作和技能的实现最好是一体的

第三点关于判定,我的办法是给角色加上六个用于出招判定的碰撞体,还有六个用于被击判定的碰撞体,全部设成trigger,对应正前方上中下盘、后方上中下盘。
每个碰撞盒上挂着hit或者behit脚本,脚本中有个enable变量控制碰撞盒是否有效。剩下的就是花大量时间针对每一帧微调碰撞盒的位置,作为动画播放了。
至于技能和物品,由于没写,我也不好大放厥词。
恩……大致就这样,AI就写了一个每0.1秒判定一次距离,远则靠近,近则怒跳泰山压顶的辣鸡东西。果然很差劲啦。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-11-11 11:12 | 显示全部楼层
题主可以去youku搜一个叫SpookMash的游戏。如果你所说的动作游戏是那样的,那么我大概知道。

逐一回答。
首先,策划设计一个完整角色,比如怎么攻击,拥有几段攻击,有什么技能。
然后美术根据策划的设计再设计动作。
然后程序根据美术提供的动画,来拆分状态并找策划商议。动作游戏会经常有打断,硬直,有效无效的切换,这需要根据Gameplay先做一个大体的初版,之后根据测试反馈调整。需要注意的是,一段攻击或者技能,往往不止一个状态,需要多个状态协同工作。
状态之间如何切换,需要策划详细设计,并给出文档。然后程序来实现这个切换即可。因为需要多次修改,最好要求程序实现的灵活些比较好。
碰撞盒一般有两种做法:
1.状态中动态产生。及进入攻击,临时产生攻击碰撞盒,进入技能,临时产生技能碰撞盒。以此类推。
2.预先保存一个人物的所有可能的碰撞盒并让它们失效,在需要的时候让它们有效即可。
请根据效率和实现难度自行选择方案。或许还有别的更好的办法。

答得简单,有具体制作的问题再问吧。以上。
发表于 2021-11-11 11:13 | 显示全部楼层
即使你之前从未写过一行代码  也能在学完本课程后达到一个入门的水平  资料和源码+v:15035157318领取~
发表于 2021-11-11 11:19 | 显示全部楼层
上面的贴那么多酷炫的图,但我想问你们到底有没有分析过格斗游戏。

格斗游戏的重点之一是指令输入的处理,需要根据设计需求模糊处理指令输入,比如236手236手可以读成236236手,而不读成236手或者23623手等等。这是一个重要的环节需要小心翼翼的处理。

然后就是各种动作的状态机融合处理。用格斗术语就是目押或者取消,一个动作未结束,在适当时机按下对应键位可以直接连招到另一个攻击动作。这需要程序上处理好各种动作的状态机融合。

这只是举了两个例子,还有很多细节需要处理比如有利帧,确认等等

这些都没有,上面的你们是在格斗游戏还是在玩名为格斗的过家家游戏?
发表于 2021-11-11 11:26 | 显示全部楼层
角色图形帧的各种判定(碰撞、伤害、防御、投技被投、飞行道具),硬直或受创动作里的帧冻结帧延迟;
不同动作互相之间的打断、覆盖、优先级等等;
输入指令的识别,包括提前预输入;
这些东西和游戏引擎一毛钱关系没有,都得靠开发者反复调校>_<

动作游戏要做好更多的是整个动作系统设计好,引擎只是在画面上能提供一定助力
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-9-23 06:32 , Processed in 0.101481 second(s), 26 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

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