FSM有限状态机 游戏设计方法 01 (FSM有限状态机)
本文目录导航：
- 【游戏设计方法】01 FSM有限状态机--结合状态模式，设计最清晰易懂的游戏动画思路
- 【游戏设计方法】01 FSM有限状态机--结合状态模式，构建清晰动画
- 如何绘画状态机来描述业务变化
- Unity设计模式-状态模式
【游戏设计方法】01 FSM有限状态机--结合状态模式，设计最清晰易懂的游戏动画思路
【游戏设计方法】01 FSM有限状态机--结合状态模式，构建清晰动画
在游戏开发的旅途中，时间如流水，不容停滞。
2024年的学习旅程虽然紧凑，但成效似乎并未如愿。
为了巩固所学，我决定通过写专栏的方式，分享学习心得，同时也方便日后复习。
如果我的分享能帮助到你，避免你走弯路，那将是我最大的欣慰。现在，就让我们踏上游戏编程的探索之路！
面对大量动画需求，引擎自带的动画系统在初期或许足够直观，但当动画复杂度增加，问题也随之而来。
传统的if/else和switch结构可能导致代码混乱和耦合度加深。
回忆起初入游戏设计时，我曾尝试自定义动画控制，代码冗长且难以理解。
那时的自豪感如今看来却是浪费。
其实，有限状态机(FSM)能提供更简洁的解决方案。
有限状态机是一种数据结构，由状态、转换规则构成，是状态模式在游戏中的应用。
通过定义IState接口，我们为状态创建类，每个状态有自己的OnEnter和OnExit方法，实现清晰的动画控制。
在实践中，我们将动画分为站立、巡逻、追击和攻击等状态，通过枚举类、参数类和控制类的组合，实现简单敌人AI。
但要注意，设计模式并非银弹，它可能在团队协作中带来沟通难题。
尽管如此，有限状态机的思维方式在游戏设计中极为实用，它不仅适用于敌人AI，还可以扩展到场景切换和菜单设计等领域。
对于初学者，虽然非必须，但理解这种模式对于未来项目将大有裨益。
希望这篇文章能帮助你理解并应用有限状态机，如果你在学习过程中遇到问题，欢迎留言交流，共同进步。
参考文献:
如何绘画状态机来描述业务变化
对于设计过商品、订单、优惠券等复杂功能的产品经理（PM）来说，描述清楚功能的本质会遇到挑战。
技术团队会不断追问：有几种状态？如何转移？何时转移？系统根据什么条件判断状态？这样的问题，往往是因为缺乏清晰的状态定义和转换规则。
本文将深入探讨如何使用状态机来描述业务变化，以及状态机的原理和应用方法。
为什么需要使用状态机？让我们从一个亲身经历的例子开始。
去年，我在设计电商系统的订单模块时，就遇到了上述问题。
最初，我参照淘宝的订单系统，将订单状态设计为待付款、已付款、已发货、已完成和已关闭等五种状态。
然而，上线后很快就发现了问题：付款之后直接传给仓库发货，导致很多订单信息有误时来不及修改；用户下单后想修改地址或商品，而发货信息已经传给仓库，修改起来非常困难。
因此，我们不得不新增了一个中间状态“已确认”，让客服审核无误后，再传给仓库进行发货流程。
随着业务的发展，我们又引入了退款退货功能，需要引入“退款中”状态，并且增加退款子状态机、退货子状态机。
这些变化最初是通过文字描述和流程图来表示的，但服务端的开发人员难以理解，不得不多次确认。
后来，我研究了状态机的概念，发现使用一张图就可以清晰地表示所有状态及转换条件，这极大地简化了沟通。
状态机的来源和发展状态机最早起源于电路设计领域，用于根据电路信号按照预设状态进行转移，协调相关信号动作并完成特定操作。
后来，这个概念被软件编程领域继承，用来表示有限多个状态以及在这些状态之间转移和动作的模型，称为有限状态机（FSM），是常见的软件设计模式之一。
对于产品经理来说，理解和应用状态机的概念，可以更好地阐述业务实体的功能本质，并让技术团队更容易理解。
如何定义状态机？从产品经理的角度来看，状态机是用来表示业务实体的所有状态以及相互间的转移关系的模型。
业务实体可以是客观上可以相互区分的事物，如订单、优惠券、商品等。
对于大部分对象，尽管存在状态的概念，但不一定需要画出状态机图。
在本文中，我们将重点探讨状态机的描述方法、常见状态机实例以及如何画出状态机。
状态机的描述方法文字描述是最古老的方法，但繁琐且不易理解。
表格可以更系统地描述状态和转换条件，但不够直观。
图形是最推荐的方法，通过圆角矩形表示状态，有向线条上的文字表示条件，线条的方向表示状态迁移。
一般从左向右画图表示初始到终止的顺序，无需特别标注。
常见状态机实例我们可以通过灯泡状态机和订单状态机等实例来理解状态机的基本概念。
灯泡状态机描述了电灯开关的简单状态迁移，而订单状态机则展示了网购过程中订单状态的复杂变化。
状态机的要素状态机的核心要素包括开始状态、终止状态和中间状态。
当达到终止状态，状态机停止。
在状态机中，条件和动作通常可以合并为一个描述，以明确状态迁移的具体条件。
命名时应站在用户立场，力求标准化。
如何画出状态机通常使用状态图工具如Axure来表示状态机。
在状态图中，“状态”用圆角矩形表示，“条件”用有向线条上的文字表示，线条的方向表示状态迁移。
状态图的起点和终点通常用实心圆圈表示。
在画图时，应去除无关状态，确保结构清晰，并考虑状态机的扩展性。
总结与思考并非所有的业务实体都需要产出状态机图，关键在于识别需要清晰定义状态转换的复杂功能。
在设计过程中，可以考虑京东小程序首页的领券功能、电商领域中优惠券功能模块等，尝试画出状态机图，以优化用户体验和业务流程。
此外，思考如何通过状态机图提升设计的可理解性和可维护性，对于提高团队协作效率具有重要意义。
Unity设计模式-状态模式
假设我们要开发一款RTS游戏，需要编写一个我方单位的逻辑。
从上面的判断逻辑来看，内容较为复杂，我们先使用伪代码来实现单位的控制脚本。
这仅仅是我方单位的几个基本行为，若后续添加巡逻、警戒、探索等逻辑，这个Update方法将变得更加庞大和复杂，难以维护。
在这种情况下，我们引入状态模式，根据上述逻辑将单位分为待机、移动、攻击三种状态。
我们将三种状态的Update方法分开实现。
接下来是状态的管理和切换，我们编写一个基类，让三个状态类继承自该类，并重写其Update方法。
通过切换当前状态对象来切换单位的状态。
将复杂的逻辑判断拆分到不同的状态中，单位控制器只需维护一个状态对象的列表。
状态模式定义：当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。
我们通过切换并更新当前的状态对象，切换了控制器的行为，使得控制器看起来像是改变了。
在Unity中，我们可以使用状态模式创建一个简单易用的状态机。
首先定义一个状态接口，包括进入、更新、离开方法。
然后是状态机类，用于维护一个状态列表，添加、移除、转换状态。
状态模式在游戏中非常常用，可以用于维护角色控制器，制作AI等。
它可以将与状态相关的行为局部化，将逻辑拆分成小块，使代码更加清晰易读。
参考资料：《HeadFirst-设计模式》《大话设计模式》
phper