Coup de Grace

有关行为树

之前买了喜鹊造字的几个字体,正好没有合适的题图,显摆一下正版优越感.

之前对游戏开发的刻板印象 tag 可能是响应式,FSM,硬编码等等.

最近看了一点点游戏相关设计思想,我觉得也可以思考是不是可取,为什么没有取.


引用

链接

indienova有一份非常棒的翻译,也是市面上看得到的比较丰富的有关状态树的资料.


一些特点

- 预定义的树状结构 
- 节点类型
    - Composite 节点组合 使用&&去联结 
    - Decorator 节点装饰 常见于 failure 倒转运行
    - Leaf 执行 script
- 节点状态
    - Success
    - Failure
    - Running 常见于行走动作中 

以上是文章中一些简单的摘抄,subtitle 的部分大家自己翻一下就可以了.


思考

状态流转

起始从 Running 这个状态来看,就看的出来该 Flow 适合托管式的流程了.或者说AI.

由一次又一次 tick 来出发或者轮询查询状态.

有关Composite的部分,https://github.com/obviam/behavior-trees这里有一份简单的实现.

状态流转预先编排好这点着实不太适合后端应用了.

有关上下文

显然游戏的生命周期内,上下文相对固定,不会有更多副本

大型的Data Context 对后台应用来说是很危险的抽象.

膨胀到无法阻止的应用往往从开发人员无脑的 Context 开始.

增加复杂度

Composite Nodes - Selector与Decorator Nodes 显然是可以极大的增加流程复杂度的.

这两块抽象我认为比较好,有可取的部分.

作者的扩展

文末有一份作者将其一份领域模型压入栈来控制状态机(状态树)Scope 的操作

当然想必资源与渲染肯定不止这么简单,不过作为后置的逻辑,这份Flow 可以独立于渲染之外.

很有意思,不知道是不是游戏开发都是这种套路.


done.