Consider using node diagram instead of scene tree for workflow

[Shadowblitz16]

instead of something like this...

maybe something like this would be better?

you might even be able to obsolete AnimationTree node.

[derkork]

The node diagram sure looks nice and would work for simple state machines but for any reasonably complex example it would quickly become very tedious to edit, as you need a way of expressing hierarchy in the diagram (these are state charts after all, not simple state machines). For example, the diagram for the frog in the platformer would look something like this:

Just creating this in a drawing program was a lot of mouse clicking and dragging and arranging stuff, whereas creating the same setup in nodes was done very quickly and easily, especially with the new sidebar, that @folt-a made and that eliminates a lot of clicking.

Editing is also a lot easier, e.g. you can just duplicate and drag nodes to a new parent node whereas with a diagram you would need to draw everything and editing hierarchies is very difficult (e.g. how would the editor distinguish between "i want to drag this node over here to make more space" and "i want to drag this node over here but it should move up to the parent state" ?). Also note how in the diagram the transitions back to Grounded state are there multiple times, where in the tree I can just add one transition at the Airborne node.

There are also a few other reasons why I chose nodes over a diagram:

• they are already a familiar concept for users of Godot as almost everything is a node in Godot
• they are very easy to understand whereas the animation graph editor seems to confuse a lot of people - at least from my experience in the Godot Discord
• they allow you to use the built-in features for scene composition and inheritance to make your state charts - or parts of them - reusable
• the amount of code needed for graph editor would very likely exceed the amount of code needed for everything else. That time can better be spent elsewhere (e.g. good documentation) , especially given that a graph editor would not even be a better editing experience.

As for replacing the animation tree node, the intention of this library is to complement existing functionality, not to replace it. This library is meant to provide easy state handling facilities for your game code, where animation trees do a similar thing for animations. They have some overlap in that they use states but each one is specialized to do its particular thing well.

So given all this, the library will not use diagrams for editing the state charts.