什么是“动作状态机”？跟你聊聊怎么设计真正的动作游戏

　　从业好几年，有幸能参与到几款动作游戏的开发。今天跟大家分享一些设计心得。一篇文章难以涵盖所有，准备分篇发布。本文谈及的所有，都会反映出本人及同事们的偏好。条条大路通罗马，不同的开发者会有不同解决方案。这里所提供的绝非唯一解。希望能通过这篇文章与各路大神交流。

　　本文谈及的设计思路主要体现在下面两款游戏中：

　　这俩游戏是同一拨人做的，你敢信？

　　事先声明：

　　1）本文讨论的“动作游戏”比较接近Capcom的游戏，而不是《蝙蝠侠：阿卡姆系列》那样的动作游戏。

　　2）本文会提及“打击感”，但是会先论述一些基础知识，请耐心阅读。

　　3）本文中提及的所有机制，目的都是“让角色的动作令人信服”。

　　让游戏角色的动作让人信服，一方面要参考真实生活，但是这不意味着越拟真越好，有时候我们会选择贴近玩家的想象，或者说是捕获他们的心思，而不是贴近现实生活。这就要求设计者有对幻想类作品有大量的观影体验并且有一定审美能力。这是一门很神奇的手艺。

　　让我们思考一个问题

　　假设A和B是两个角色。两人都想出拳攻击对方。

　　你就想象两个隆用这个动作打对方

　　两人的招式完全一样，但是A出拳早，B出拳晚。正处于前摇阶段的B被A的拳头命中。

　　问：这个时候应该发生什么结果？

　　这个情况我们在很多游戏里面体验过无数遍了，相信你的答案必定是脱口而出的。

　　答：A命中B的瞬间，B的出拳动作被打断，B立即放受伤动作。

　　真正的问题是：怎样在游戏中实现以上效果？请现在先闭上眼睛思考一下这个问题。思考完我们继续。

　　动作状态机

　　【例一】

　　【图例】

　　1）图中的每一个方框称为一个“动作片段”。

　　2）每一个箭头称为一个“中断”，即“此动作片段中断至另一个动作片段”之意。

　　3）箭头上的文字代表这个中断的必要条件。如果箭头上无文字，代表无需条件。本动作结束就沿箭头方向发生中断。

　　*注意：所有箭头都是单向的。如果两个动作可以双向切换，应该绘制两个单向箭头，并且每个箭头旁边标注其必要条件。

　　【解读】

　　游戏开始，角色先进入起始动作。起始动作结束后角色进入“待机”动作。

　　待机动作有两种后续可能性：

　　1）玩家不进行任何操作，角色将循环播放待机动作。

　　2）玩家输入“P”键，角色将播放“拳”动作。拳动作结束后，角色回归到待机动作。

　　这就是一个简单的动作状态机。动作状态机就是这样一个机构：这个机构负责管理角色众多动作片段，以及这些动作片段之间应该如何切换。目前这个角色非常简单，只能使出待机和出拳两个动作。动作状态机内容越丰富，功能越强大，角色就越生动。

　　在实际开发过程中，动作状态机可能有可视化面板，外观看起来就像【例一】的流程图。但是也有可能是看起来枯燥无味的编辑器界面。开发者会使用引擎提供的工具或者自己打造开发工具。本文重点在讨论思路，这个就不展开说了。

　　值得注意的是，玩家眼里的“一个”动作实际上可能是多个动作片段连续播放的结果。

　　三个阶段实质上是三个动作片段

　　例如，上面的“直拳”动作虽然时间看起来很短，但实质上是三个动作片段（即，前摇-中段-后摇）连续播放的结果。其中，只有中间片段配置了攻击属性。把动作分得这么细一是为了更方便地调试手感、竞技平衡性，二是为了细腻地管理动作片段之间如何切换。

　　动作片段之间的切换（非战斗）

　　这个命题非常艰辛，为了保证文章可读性，本文只介绍核心思路，略去一些过于琐碎的知识。

　　穷举法

　　我们使用的是穷举法。此方案的核心思路：穷举动作切换的所有可能性，并穷举每一种可能性的必要条件。

　　所有中断的穷举

　　【例二】

　　为了方便理解，我们假设现在有一个简单的角色。这个角色能执行的动作包括：待机、走路、跳跃、攻击。玩家的输入按钮也很简单，包括：摇杆、攻击键、跳跃键。

　　角色的动画状态机为：

　　【图例】

　　1）橙色的方块：代表自循环的动作片段。在没有任何一个箭头得到条件满足的情况下，这个动作会自循环。

　　其余图例与例一相同。

　　【解读】

　　我们来尝试穷举其中几个：

　　“待机”可切换至：

　　1）待机

　　2）走路

　　3）跳跃上升

　　4）地面攻击

　　“走路”可切换至：

　　1）跳跃上升

　　2）地面攻击

　　如是这般，不一一列举。通过穷举我们可以看出：

　　待机不可能直接切换至空中下坠。然而，待机-跳跃上升-空中下坠，这样的切换则是成立的。

　　每个中断的所有必要条件的穷举

　　观察上述的例子，我们可以发现，这个角色有两个攻击动作，分别是：地面攻击以及空中攻击。但是在一般游戏里面，这通常是同一个攻击键来触发。换句话来说，在不同的情境下同一个按钮能表达出不同的动作。为了实现这个效果，我们需要多重条件判断：

　　1）角色处于地面还是空中？

　　2）玩家有否输入攻击键？

　　上述两个条件共同决定角色使出的是地面攻击还是空中攻击。

　　在【例二】中列出所有判断条件，表现如下：

　　以上只是一个很简单的状态机。可以看到，里面的东西已经不少了。

　　值得注意的是，这个状态机表达出来了一些规则，例如：

　　1）角色在空中只能攻击一次

　　2）角色不能二段跳

　　不妨想象一下，如果这个角色可以二段跳，那么它的状态机会是什么样子。

　　开发者会根据项目需要来决定动作状态机的内容。通常来说，比上图的要复杂得多。例如，在很多游戏里头都有这个设计：按攻击键同时推动摇杆，会使出“前冲攻击”；不推动摇杆则是“原地攻击”。

　　穷举法是一个可靠的方案，能应付大部分的开发需求。但同时它具有极强劝退效果。因为其配置工作量巨大，过程繁琐。下面我们来探讨更牛逼的方案。

　　全局监控

　　请看这个动图：

　　请留意德雷克有个很皮的摸墙小动作。（再摸又要塌了喂！）

　　这个“摸墙”的小动作把我震撼了。我当时在想，是得有多逆天的动作编辑器，才能做出如此细腻的动作表现？顽皮狗太牛逼了。Too good to be ture，但是它真真实实地摆在我们面前。德雷克的言行是如此自然（没错，都可以用上“言行”这个词了）以至于我们游玩的时候，好多个瞬间都忘记了自己是在玩游戏，以为“我就是德雷克”。

　　声明：以下内容均是我的推断，从来没得到过顽皮狗方面的消息。

　　我尝试把德雷克的各种“走路”相关动作片段以及其判断条件逆推出来：

　　这里可以看到一个重要的点：每个条件只影响最终表现的一部分。其中一个表现的变化，会导致角色的言行有相应的变化。假设7）号条件NPC谈话的判定结果为“是”，我们会发现德雷克走路时会一直注视NPC。

　　而为了管理众多的条件，必须：

　　1）优先级：优先执行某些条件的判断。例如，3号条件“是否处于战斗”为优先级最高的判断条件。

　　2）父子关系：如果父条件判断结果为“否”，则忽略子条件的判断。例如，当系统判定角色“不在水中”，就会忽略所有与水相关的条件判断。

　　3）互相排斥：A条件判断为“是”，则自动把B条件判断关闭。假设4）号条件濒死状态的判定结果为“是”，那么程序很可能会忽略5）的判断——此情景下应该着重表现角色的痛苦，而不应该表现其俏皮的一面。

　　以上只是我能想象出来的一些手段。真的要执行起来，考虑到的肯定要更多。