Add an FSM visual editor for AI flowcharts

[ca3games]

Describe the project you are working on: An action game.

Describe the problem or limitation you are having in your project: I want to write AI that isn't just clutering scripts after scripts.

Describe how this feature / enhancement will help you overcome this problem or limitation: It would be nice to have a sort of visual editor, similar to the visual code editor godot has, but for FSM and related to coding the behaviour of some enemy AI.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work: A visual editor similar to the visual language godot has but for dealing a basic FSM with basic AI functions, like pathfinding, fuzzy logic, behaviour trees, basic behaviours like flock, chase, group around a point, group RTS formations to avoid clustering of enemies, even basic stuff like basic emotional moods. So, the idea is you create a basic circular FSM with a start idle node that the other AI nodes circles back in the end, and he branches to other AI states/nodes based on basic input or conditions that can trigger other nodes.

Describe implementation detail for your proposal (in code), if possible: I was thinking something similar to unity animator FSM, but for AI.

If this enhancement will not be used often, can it be worked around with a few lines of script?: It would optimize the creation of AI, using common behaviours like pathfinding or RTS flocking behaviours.

Is there a reason why this should be core and not an add-on in the asset library?: All games need a basic AI, an AI editor would be something I don't think other engines has by default.

[tengkuizdihar]

I've thought about this before and wanted to implement one myself. But it seems that someone already made it into an addon. I've tried it before and honestly, even if it's very cool and useful, it's still clunky and just doesn't feel right when playing with it. This is the project that I'm talking about btw, https://github.com/kubecz3k/FiniteStateMachine.

If I were you, what I would do to improve this proposal is to ask people more about the problem and dilema that programmers have thought about when implementing a finite state machine inside of their editor/engine. Especially FSM that has a visual feedback. I could think about several of them which is,

1. How does the fsm checked whether a state should be changed toward another state?
   • Should the state itself checked for it and call the fsm to change the state toward another state?
   • Should FSM requires every state to implement a "transition node" where "transition node" would be checked every single update as long as the state is active?
2. Should FSM have some kind of integration with GDScript to make it easier for the user to implement?
   • For example, auto complete for the state's name in editor that will show all of the state's name inside of the currently edited FSM
   • Might be complicated or easy as hell, I have no idea because I've never seen the code for GDScript editor/understand it.
3. Should the people just use other method for their AI and jump straight to behavior tree, as shown in this proposal? #281
   • Although if I'm being honest, I would like to have both of them (FSM and Behavior Tree) in the engine and editor. And add GOAP to it because why not. Because as far as I'm concerned, both FSM and Behavior Tree are both useful and would really make people's life easier by making a uniform framework where they could just create the "brain" of an NPC fairly easily.

I hope someone would pay serious attention to this proposal and make it come true.

[willnationsdev]

It is highly likely that something like this won't ever be bundled into the engine specifically because there are so many different ways to design and implement any sort of AI system, and every user will have different needs, expectations, and preferences for how it is structured, how they interact with it, how it functions, etc. Just look at the above comment for an immediate example:

Although if I'm being honest, I would like to have both of them (FSM and Behavior Tree) in the engine and editor. And add GOAP to it because why not. Because as far as I'm concerned, both FSM and Behavior Tree are both useful

There's too much complexity because the problem scope is too huge to address with any single or finite solution.

What is being done to address problems like these is a full redesign of the addon/plugin system complete with a redesign of the Godot Asset Library, all so that Godot 4.0 will have a much more robust toolset for adding, creating, publishing, sharing, installing, and supporting user-made classes, nodes, resources, editor tools, etc. At that point, the people who have the time and motivation to create high quality content will be able to invest it in addons which get better visibility, better maintainability, and better integration versus what Godot currently offers.

[tengkuizdihar]

Continuing from the many different design of how to implement these features, what do you think of FSM/Behavior Tree on other similar engines, @willnationsdev? If I'm not mistaken, for example, Unreal Engine 4 features a Behavior Tree for AI, with blackboard and everything. Does the way they implement behavior tree is too stiff/awkward for Godot to use?

[willnationsdev]

@balenol "stiff" would be part of it, "awkward" not so much. Having a built-in solution for Behavior Trees/blackboards and using a visual editor to design it all is very appealing. You'd have to design it to support the majority of users' use cases, and maybe the Godot team could do that. But if they did, then they'd have to maintain it forever. And maybe that would be something the team could live with if almost every user needed to rely on that system, or if they could reliably provide 70-80% of what users needed from the system, with the rest being handled via scripts. But in all likelihood, the vast majority of users wouldn't need Godot's specific implementation/design of a Behavior Tree. Some might want...

• a simpler FSM framework that uses nodes.
• a GOAP system.
• a text-based scripting language instead of a visual one.
• a Builder pattern while others want an asynchronous stream system akin to a functional programming language (or a combination/monad of some sort).
• a singleton where all the data is kept.
• data localized to specific node groups or geographical regions.

The core of the issue is that Behavior Trees are but one specific solution to a very broadly scoped problem, i.e. how to design, implement, and maintain game AI. If the Godot team is going to provide a solution to a problem, then they will expect to provide the solution that everyone will want to use. If such a solution proves not to be the general solution everyone wants, then it could be argued that whatever that solution is shouldn't be embedded in the engine. There's already a list of classes somewhere that the team plans to outsource to addons once the addon system is more robust; VehicleBody is one classic example.

With that said, I would love to see a robust and powerful FSM/Behavior Tree visual editor for Godot that is open source and supported by the community. :-) Something similar to Unreal's tools would be pretty grand.

[ca3games]

@willnationsdev Even if this proposal is archived, I think It would be cool to see the visual editor to be reused and repurposed into other more specific niche uses. I don't see a lot of particular uses for the visual scripting system right now, because the normal script editor is way way more efficient and useful.

However, I think maybe Godot could reuse the visual scripting editor into more niche uses, that would be powerful enough and could give godot a huge bump in terms of features. Maybe an AI system couldn't be made too powerfull, but maybe we could design a sort of basic AI system, similar to how godot uses nodes and creates complex behaviours using the combination of simpler nodes.

Maybe the godot team could design some basic AI nodes that every one is like a basic AI behaviour and similar to blender composite nodes, you can sort of link them in complex ways. Not sure how it could be really implemented, but is more like my idea.

Also, another cool thing the visual editor could be extended into, could a basic dialog system.

[havi05]

Hello, I think it would be great to have AI Nodes in Godot. Some AI behaviors should be:

• seek
• flee
• pursue
• wandering

(with align)

Would this be possible? (I didn't figure this out as code in 3D)

Sorry if I have mistakes, Gamemap

[willnationsdev]

@Gamemap Yes, programming such behaviors in Godot is certainly possible, and it can even be done in a variety of ways. But such things would likely be supported by custom logic you write for your own game. Most likely, you would find some third-party addon that provides a framework for AI logic (a Finite State Machine API, a BehaviorTree API, etc.) and then you might find example projects that use the addon to create game-specific movement logic similar to what you have described above. But none of this would likely ever become part of the core Godot Engine. It would just be something you download separately for a given project.

[havi05]

Ok, thank you. I will have a look and try to make my way through such a code. Gamemap

[GeorgeS2019]

@ca3games what do you think of this?

[ca3games]

@ca3games what do you think of this?

Yes, that's good. I think if we can turn the visual script language to be more of a node base system for niche things like shaders and FSM and AI, it would be a stronger reason to use godot. Thanks for sharing.