UE的状态树StateTree已经1.0了，可以开始正式学习利用了。

这个视频把状态树的核心概念介绍得非常清晰。 【【UE5 StateTree】极简入门指北】 https://www.bilibili.com/video/BV1SURZYoEnU/?share_source=copy_web&vd_source=553f749818a52eafc8586c3fda832464

这个文章讲了状态树目前的主要问题，有些已经解决，有些官方声明即将解决。关于 UE5 中的状态树的一些你不想知道但又不害怕询问的事情 | Jean-Paul Software --- Some Of The Things You Didn't Want To Know About State Tree In UE5 And Weren't Afraid To Ask | Jean-Paul Software

最近看了下，感觉太强大了。这是一套非常通用的逻辑流管理工具，不仅仅是处理AI，还可以处理连招、相机状态等。本质上我理解就是一个用行为树的组织形式实现的状态机，然后这些状态可以有序地嵌套、传递上下文，状态的流转方式也很灵活完备。

相比行为树，它可以原生支持更灵活的节点跳转和数据读取(分层上下文VS黑板)，而且编辑界面也很现代，说能够完全取代行为树也不为过。有的评论说他们是针对两个不同问题的两种不同解决方案，但目前我看下来状态树的功能是覆盖行为树的，而且交互逻辑也很配置友好（蓝图的功能也覆盖行为树，但是蓝图的交互不适合AI配置），事实上我在思考设计AI的时候，我脑中的模型也是更接近状态树的结构而不是行为树，也许是因为性能差异或者他们的评论针对的是旧版本状态树？

相比LogicDriver(行为树插件)，可实现的功能其实差不多，但状态树的配置方式更简明，像行为树一样可以在单个界面呈现整体的树状逻辑结构，不同层级间的信息传递也更流畅，非常策划友好。如果说LogicDriver还算一个可视化的逻辑功能开发工具的话，StateTree更接近逻辑配置工具的感受。而且作为官方方案集成性也更好，比如对GameplayTag的集成。

虽然这么说可能不太可信，但似乎状态树真的完美地把二者的优点保留缺点移除了。再迭代一段时间应该可以应用于实际生产。

实践了一下，还发现一个严重问题：状态树没有给运行时设置的接口，包括子状态树貌似都只能在运行前配置好，没法设计成读表动态设置状态树，这点和前面“更接近逻辑配置工具”的预期不符。不知道是功能完成度问题，还是我对它的设计定位理解错了。

用了一周，发现完成度实在还是不够，缺少很多必要的回调（比如切换状态后……），状态过渡、任务并发的逻辑也有点混乱，最要命的是崩溃频率很高（必须把其他内容都编译完，最后才写行为树才能稳定，如果同时改蓝图和行为树，就很容易崩溃）。

刚刚又崩溃了……

只好放弃了。还是先用回原来的行为树+状态机组合的方案。等完成度再高点再用。