First, I want to say, from a software engineer of 20 years, I love NodeCanvas and FlowCanvas, superb work!
Second I was hoping to get a little info on how best to use them together, more specifically when one approach is preferable over others.
I am relatively new to AI and am grepping the hell out of what you expose for us to use. I have a few question now though.
I used all 3 a flow, a BT and an FSM to handle building a character, all 3 worked, the BT doing it with the least amount of work, e.g. once the UMA is built find its feet pass it to some waiting BB variables then mark the character as built (there will be more, but this to start).
My question is which is the best for a one off, I assume it’s the flow. I am guessing that the BT creates an ongoing tick that needs to be checked to make sure it’s still good, right? With the flow I am using an event capture to know when a get gameobject returns truthy. I assume that even fires then it’s done no longer taking up cycles (or ticks), right?
Anyway, to summarize I am hoping to know if there is a best practices for using the 3 different approaches to solving one offs and the like.
I was thinking maybe a standalone GO that goes away once it’s run to avoid it getting processed anymore.
I am open to suggestions.
Again, thank you for these great products, worth every penny and more!
Thanks a lot for your positive feedback! I really appreciate it!
I think that you already go it right for what to use when 🙂
They are more suitable for continuous and dynamic behaviours that change over the course of time. They are indeed updated every tick, but if you add a pre-condition on the very left side, it could be used for one-offs, even though they will get updated without really required for that use case of one-offs.
They are similar to BTs in that they also get updated every tick for checking transition conditions (apart from updating the states themselves). I think they are very suitable for breaking down self-contained “chunks” of behaviors into separate states, thus why I think using an FSM at a higher level, with each state being a BT, or a FlowScript for example, can be very powerful. Using an FSM by itself (no sub-BT or sub-Flow) to do logic, I would use it less often. As for one-offs, I think the deal is the same as is with BTs. It can be done, but they are continuously updated.
They are of course the more open-ended and flexible that the other two, but that could come at the cost of complexity in the graph due to that freedom (eg more steps required). The complexity can get smaller though by creating custom nodes, or interfacing with existing functions in your code, that are more streamlined to the project, rather than using lots of low-level nodes to accomplish the same thing.
Being event-based driven, I think that can be ideal for one-offs just like you do 🙂 While they do get updated per-frame, if nothing is currently executed in the flow, then it’s mostly an empty update call, except for the case where some specific event nodes are used like Input, which is necessary to check per-frame, since Unity does not provide any sort of event callbacks for Input (including some other things as well).
Thus, to summarize, I think for event-based one-offs, flowScripts are the most suitable. Regarding mixing more that one type of graphs for any use case that suits it, I think the most preferable mix overal, would be an FSM at the topmost root level, and BTs or flowScripts as states of that root FSM.
I hope the above help you in your questions, but if not please let me know and I can elaborate!
Thanks again for your very welcome feedback!