hi.
I don’t have experience with GTF yet, but i have enough experience with node editors to talk here.
Normally, when you develop a graph node, you design the nodes in the editor. Based on how the api is designed there can be two disected sections one for editor and one for runtime. In this approach, normaly each node will be a scriptable object parented under a root scriptable object that is the graph. all the data regarding the connection between nodes, will be kept somewhere in this hierarchy. The editor section will be responsible of reading this hierarchy and draw the graph, nodes and connections.
This approach is hard to implement as an api and has lots of buttlenecks (had done it myself long time ago). But makes the overhead for the runtime as small as needed data for the game.
The other approach will be to have everything inside the node and graph classes, and using preprocessor directives to get rid of editor compiling errors.
How every, I think GFT is none of the above! if we think about GraphView as a reference, the nodes are bunch of info for editor only. The graph class is editor only and you need scriptable object as a container to have all the needed runtime data in it.
Again, GFT looks much deferent that it.
Lets sit back and think. What do we need for an editor and node tree? Nodes that has info specified for their function, and the data for their connections. A container that has info of it’s own as global variables, and also data about what nodes are inside.
We really should not need to get headache about drawing the nodes, and many different aspects of the editor itself, because it’s preatty much standard!
I think GFT is taking a new approach, letting you focuse on this runtime aspect of the tool and handling many aspects for the editor behind the scence.
Long story short, most of the code you write is runtime stuff (at least it looks like it). and the ui element stuff is not that big of a problem to inject into the game itself. if that is the case, then you should read the graph container in runtime and move forwards from there.
I think serialization is happening behind the scene, if not, it should be as easy as having a property on the container, make it serializable and somehow track the active node there.
when you want to pars the tree and move from one node to another, no one can help you there, when to move, what is the logic of choosing the next node? it’s all related to your tool. So, basically, you should have written this logic. at runtime, when it’s time to move from one node to another, simply use the logic, find the new node, activate it and at the same time, set the active node property on the container.
all of this was simple theory, as you said, there is not much documentation out there. and to understand the whole thing without the documentation, you need to sit back and read the api line by line to see what is happening !
knowing that the visual scripting tool is based on GFT, mabe it would be a good place to start looking into usage cases