top of page
  • 作家相片Junce Wang

我是如何开发《未堕天:觉醒》的

本文介绍了我从去年10月到今年5月期间,对学生项目《未堕天:觉醒》的开发过程。


《未堕天:觉醒》是一款专注于 BOSS 战的动作游戏。它也是我在犹他大学娱乐艺术工程硕士项目的毕业项目,我和 2 位在犹他大学的同学在半年的时间内共同完成了该作品。另外得到了两位伯克利音乐学院的同学在音频开发上的支持。该游戏已经在 Steam 上免费发布,截至目前,共获得了大约 50000 次下载,8000 次游玩,在 100 份玩家评价中得到了"特别好评"的好评率。对于学生项目来说,我觉得这是一个不错的成绩。


起源:战斗


最初这个项目的开发者只有我自己,那时候我对游戏体验的预想是一个具有优秀战斗手感的反应式动作游戏,因此所有的重点都在游戏的战斗体验上。我希望达到“3A的品质”但“小巧的体量”,作为一种概念验证demo。如我第零篇开发日志所说,我认为最容易达成我这个想法的内容范围,是一场类似战神2018女武神王的 BOSS 战。那时候我对这个项目的设计支柱只有两点:

  1. 优秀的操作手感

  2. 刺激的战斗体验

于是,我便以围绕 BOSS 战为核心的方向开始了我的开发。事实上,最终成品的确达到了这两点最初的目标。战斗设计上,最终以“围绕玩家攻击距离和BOSS动画节奏的反应式战斗”为主,达到了这两点。后续会详细说明具体是如何达到的。


并且,作为启发的女武神王战斗,对开发风险未知的学生项目来说,也有另一方面的启发——模块化的开发模式。在战神中,女武神王,是八位女武神小BOSS的首领。这八位女武神使用了一致的角色骨架,每个角色都有一部分相似的动作,以及另一部分作为自己特色的独特的动作。玩家在挑战完全部八位女武神之后,最终面对的女武神王,她的动作集合拥有所有其他女武神的独特动作。这样的开发方式,让开发内容非常“模块化”,从单一一位小BOSS的女武神的动作,到最终BOSS包含全部九位女武神的动作的范围内,开发到任意程度,都能提供一场不错的战斗体验。这样灵活的开发范围设置,对于未知性极大的学生项目来说,是非常合适的模式。我最初的规划是,我能制作出至少三种不同的小BOSS,并且轻易地制作一个整合了它们全部动作的最终BOSS。至于结果——剧透警告——实际上到毕业为止,我只完成了一个小 BOSS 的动作集的程度。但我仍然觉得它满足了我最开始想制作的战斗 DEMO


同时,游戏的美学主题,最早被设定为“死神 vs 不死异常”,因此主角被确定使用的武器是镰刀。这也是这个项目最早的开发代号 Code: Shinigami 的来源。关于初期的一些概念性的设计,可以参考我的第零篇开发日志。



开发:框架


最初的几个星期,我的主要时间花在搭建战斗系统的框架上。那时,我对具体的战斗机制的设计还没有深入思考,我想先从框架开发开始制作,根据我的实现能力决定后续进行怎样的设计。


我并没有选用任何已有的完整战斗框架或插件,而是选择跟随教学,从零开始完整搭建我的战斗框架代码。这么做主要出于以下几个原因——我希望完整地理解一个可行的战斗框架是如何构建起来的,以及所有的框架制作都经由我自己之手,可以确保我对后续的定制化修改是可行的,同时,这也可以锻炼我的蓝图脚本编程能力。


最开始的战斗框架非常简易,基本上就是教学中的内容:


武器功能:玩家可以获取武器,可以装备武器或收起武器

连招功能:玩家装备武器时,连续输入攻击按键可以进行连招

受击功能:玩家武器的碰撞体碰撞到敌人后,会造成打击效果

回避功能:玩家输入回避按键,可以进行回避功能


最初的战斗框架,并未采用特殊的设计模式。除了动画蓝图的 Locomotion 采用了状态机模式,其他功能,包括攻击动作、受击动作、回避动作,均采用基于事件驱动的代码逻辑手动管理状态,通过播放蒙太奇的方式完成。


但针对上述系统,我进行了一些改造。我希望我的战斗框架在各种细节上都有达到完美的潜力,并且在操作感上足够令人满意。


连招输入的优化:

首先,自然是加入了攻击动作对玩家方向输入的响应,在攻击动作的最初几帧,会根据玩家输入的方向旋转角色朝向对应的方向,对于连招中的攻击动作,每一招都可以进行这样的修正。我并没有希望像怪物猎人那样,让玩家刻意在意自己的攻击方向,因此采用了允许每一个连招中的动作进行方向修正的方案。

另外,还有一些关于连招打断取消动画的优化。默认情况下,玩家按下攻击按键会进行攻击动作,在攻击动作的动画播放中再按下攻击按键,如果不做任何处理,会立刻取消并打断上一个攻击动作,进行连招中的下一个攻击动作。这样会导致玩家的连招速度明显过快且动作不自然。

最初我采用的方法是,使用动画通知,对每个攻击动作,限制在相同的时间内不允许进行连招打断,这样玩家的输入最快有效间隔是一致的,确保了稳定的攻击动作节奏。

但这样做也有缺陷,玩家的有效输入只能慢于这个阈值,每次实际的有效输入时间,会比这个阈值慢上随机的几帧,无法通过 button smash 的方式达到最快的有效连招输入。我并不预期玩家能通过精准的帧输入来获取最快连招的优势,这显得在操作上太难了,因此,在后续开发中,我引入了指令系统的指令缓存功能,当玩家比允许进行连招打断的阈值更早地输入攻击指令时,我会记住这个指令,当动画播放到允许进行连招打断的阈值时,立刻执行这个攻击指令发生连招。如此一来,玩家可以通过简单的 button smash 达到最快连招的优势。

不过,其实在此之上还可以进行改进,目前我为了实现方便,对所有连招指令的缓存判定是“动画的第一帧~允许发生连招打断阈值”整个过程,这个过程显得太长了,导致了一些玩家过快的“双击输入”被视为了有效的连招输入,会发生两次攻击,但其实玩家后续有意地在连招打断阈值附近的时间停止了按键输入,意图只是进行一次攻击,当前的实现效果是对玩家意识的误读。从设计上来讲,对于允许进行指令缓存的时间,应该是“允许发生连招打断阈值的前 X 帧内”,这个 X 根据具体的动作和操作感进行微调配置,根据默认的 APM,X 大约在 5~6 帧左右。虽然有回避动作可以任意时刻打断攻击动作的设定,玩家额外用出的攻击动作其实不会造成额外的受击风险,但是从玩家反馈来看,玩家似乎并没有很好地意识到这一点。结论上来说,这个问题是需要修改的。

此外,目前还有一个我想修复但还没来得及修复的 bug:当玩家在攻击动作中被缓存了一次攻击指令,在这个指令被连招执行之前就用闪避打断了之前的攻击动作,这个闪避之后会执行这个被缓存的攻击指令。作为反应式战斗体验,反应操作的意图优先级是绝对大于主动攻击操作的,闪避指令执行成功时应该清空攻击指令的缓存。事实上这在设计时的确是预期外的行为,但是在程序上尚未 debug 完成。


打击的优化:

在这个阶段,对于玩家打击效果的优化,我添加了挥动武器时的 Trail VFX,来清晰地展示出武器的碰撞范围。命中任何敌人时,播放一个命中特效,作为命中的反馈。这个命中特效我使用的是 UE5 的 Lyra 工程模板中的特效作为占位符,但是在后面我寻找了其他资源进行更新。


受击的优化:

最初的框架,由于还没有敌人 AI,只制作了玩家攻击敌人,让敌人发生受击的功能。对于敌人的受击,我令敌人在受到玩家攻击的瞬间,首先瞬间转向玩家,然后播放向后退的受击动画。这是一个简单的受击反馈系统,但是对于我的游戏来说足够了。到最终成品为止,由于 AI 的设定, BOSS 绝大多数时候都是面向玩家,角度差异小于 ±45° 的情况,因此我也没有花时间制作例如背后受击等更复杂的受击反馈功能。但如果后续制作更多种类的敌人时,尤其是非 BOSS 的敌人时,这个功能我想应该是必要的。


回避的优化:

回避功能采用了这样的设定:在攻击动作的任何时刻都可以用回避取消攻击动作。这一点采用了战神中的设定。主要目的是希望玩家只需要在意敌人的动作进行反应即可,不需要在发动攻击前就思考这次攻击的风险——毕竟任何时刻都可以用回避来进行取消嘛。这个设定对玩家来说更友好,提升了玩家操作的下限。同时任意时刻允许闪避,也给了玩家更多见缝插针机进行攻击的机会,提升了游戏的操作上限。


动画、距离、速度:

在构建基础战斗框架时,我选用了 Twin Blades Bundle 作为主角的攻击动画来源,以满足镰刀武器的动作要求。这套动画资产包的绑定结构有些独特,武器骨骼被绑定在了 UE Mannequin 的 IK 骨骼上,这很不方便重定向。因此我便决定,不过多修改这套资产,直接将这些动画中的距离和速度作为我的“战斗 Metrics”。以这套动画的攻击距离,作为其他战斗中的空间和时间参数的参考基准。不过具体到速度和节奏,这些内容调整起来相对较便捷,我没有完全采用原动画中的设计,在未来,我详细制定了我自己的帧数表。

简单的来说,在初期制作框架期,刻意注意到的两点就是“攻击动作的前近距离和受击动作的后退距离相匹配”,“攻击动作的连招节奏间隔小于等于受击动作的硬直时间”。满足这两点,基本可以满足好的连招攻击手感。后续对资产的挑选和修改,都是基于这两条原则。


关于这个阶段,更详细的内容,可以参考我的<第零篇开发日志>。



角色创意设计:BOSS 概念设计文档


在初步完成框架之后,我对这个项目有了极大的信心,于是我开始着手进行创意设计的工作了。此时,概念艺术家王依宇加入了我的团队,我们决定从主角和 BOSS 角色开始进行设计。我和她进行了多次深入探讨,听取了她的建议,在世界观上保留死神vs不死异常的点子,但是除此以外不再做更多设定,而是交由她自由发挥。我仅从战斗的角度,提出了两点建议——双方角色拥有较多布料或动态材质,以展现战斗中的动态感;主角需要格外在意从背后看上去的样貌,因为游戏是第三人称视角,很大一部分时间是在看主角的背后。

最终,我利用 Pinterest一起寻找了大量的参考图,并且在和她沟通确认双方一致的想法后,在 Miro 上制作了一份美术角色设定的需求文档。

以下是当时我寻找的 Pinterest 图版参考图和角色美术需求文档。




没过几天,优秀的依宇就完成了第一版的 BOSS 概念设计草图,我对此感到十分惊喜。基于这个草图,我提出的建议是夸张化手部的臂刃,以此作为 BOSS 的主要战斗方式。依宇此后便在这张草图的基础上进一步细化概念设计。



最后,依宇也很快完成了正式版的 BOSS 概念设计,以及基于基础模式的三视图。这之后,技术美术陈泽世也加入了我们的团队,他开始基于此进行建模和绑定相关的工作,这些就都是后话了。




不过依宇此时很快忙于另外几个项目的工作了,主角的概念设计将会在很久之后才完成。不过这并不影响此时我在战斗框架和泽世在 BOSS 模型上的开发,因此在项目规划上,我们同意等待依宇直到她有时间再来进行主角的概念设计。这种开发成员时间上的不确定性,也是学生项目中比较有特色的一环吧。


战斗创意设计:BOSS 的模块化战斗设计


在依宇完成 BOSS 概念设计草图后,它立刻启发了我如何设计战斗以满足“模块化”开发模式。我想到的答案是——BOSS的手臂可以变形,不同的形状有不同的模式,每种模式有自己独特的动作,例如近战模式、远程模式、防御模式。对于小 BOSS 来说,它们的手臂各自只有一种模式,或者少数的两三种模式,最终 BOSS 则有全部模式的招式。BOSS 可以使用专门的动作主动在不同模式中进行切换,方便玩家分辨预测各种动作,记忆各种动作的处理方式。也可以没有专门的动作,直接切换手臂模式,发动变招,这样需要玩家关注并分辨 BOSS 的招式,让 BOSS 的招式可预测性进一步降低。技术上,可以使用 Blendshape 的方式来实现手臂形态切换。


而至于玩家的动作集合,因为我希望以反应式战斗体验为主,因此会反过来根据 BOSS 的动作来设定。按照完整的 BOSS 设计文档,玩家动作包括基础攻击 Combo、闪避、格挡、弹反。此外我也有考虑加入远程攻击和特殊招式攻击,以给玩家提供更丰富的攻击操作体验。


于是,在完整文档中,我设计了八种手臂战斗模式的概念,虽然一开始就预计肯定无法全部开发完成,但是作为战斗概念,我觉得这份设计文档还是很吸引人的。



上述文档内的几种模式,实际上最终实现的只有臂刃模式的动作和一部分三棱刺模式的动作。包括其中预想的玩家机制,也只实现了闪避,没实现格挡。其他更多模式的动作和功能,难以实现的主要原因,还是缺乏足够的动画资产。我们没有专门的动画师进行资产制作,只能使用商城购买的第三方资产,这些资产的限制还是过大了。


在依宇完成基础模式的设计之后,我把不同战斗模式的概念设计文档给她看了看,她觉得这十分有趣,并且完成了每个模式手臂的概念设计。(点击以下图片打开查看大图)





依宇制作的这些精彩的视觉概念设计,不论看多少次都觉得很吸引人。尽管我们现在还未能完全实现这些模式,但如果未来有机会我真的很想把全部这些概念做到可游玩的游戏里。


模型绑定


(待更新)


状态模式


(待更新)


战斗流程


(待更新)



更多内容:


待更新

37 次查看0 則留言

Comments


bottom of page