Demo & redundancy

[Arkuni]

Hello,

Would you be so kind and allow me access to a trial or demo of NodeCanvas? It looks like a sweet product, but the limited amount of resources available makes it feel like a leap-of-faith.

Regardless, I would like to know if NodeCanvas supports polymorphism. Can you create a behaviour tree and then derive from that tree to make other sligthly different trees? I am looking for something akin to abstract classes.

[Gavalakis]

Hello,

NC does not support polymorphism in the sense that you describe it and to be honest I don’t personaly know of any behaviour tree system that does that. The way this works with behaviours tree, or to be more precise in NodeCanvas is different. There are different ways to alter the functionality per type that come into mind. For that let’s take an example.

You have an abstract class Unit, and 2 subclasses: Fighter and Archer.
These are normal MonoBehaviour classes that you add on your game objects.
The abstract class Unit has abstract methods or even properties, like for example: Attack, Health, Speed etc

You create a behaviour tree that defines the global behaviour of a Unit. As such you attach that behaviour tree on each game object that has a Unit subclass.
Now within that behaviour tree you make calls, sets and checks on that Unit type (using Script Control tasks) which allow NC to “interface” with your classes.
As such, the Fighter will Attack differently than the Archer, since each Unit defines it’s own method for Attack.
(this can also work with interfaces instead of abstract classes if you want to)

Furthermore, the Blackboard Variables (which can be used to parametrize behaviour tasks amongst other things), are not coupled to the behaviour tree, but rather with the agent. As such the same created behaviour tree, can be further parametrized per the type using it, by altering the variables.

Using blackboard variables versus your own properties within a class and interfacing with them, is more or less the same thing. In both cases you can use them to parametrize the attached behaviour tasks and thus the behaviour as a whole, by reading, setting and checking values.

Another thing at your disposal is SubTrees. So you create the master behaviour tree for all units and when a unit is about to attack, define that Attack as a SubTree. Then depending on the Unit type (Fighter, Archer etc), each one may use a different whole SubTree for Attacking and thus differentiate their behaviour. (currently assigning subtrees can only be done through code, but it will be possible through UI in the next version).

So as you can see, behaviour trees (at least in NC) have lot of ways to be parametrized based on the sub type using them 🙂
My personal preference is the first in case you are into and prefer coding your behaviour pieces. The more you want to rely on the behaviour tree system, the more you lean towards using SubTrees instead.

Finaly, as for a demo version, if you still have doubts :), I could make a quick and dirty .DLL version for you to try it out.

Cheers!

Join us on Discord: https://discord.gg/97q2Rjh

[Arkuni]

Wow. I am impressed by your dedication and I don’t want that to go unmentioned. Thanks a lot.

If I use the Script Control Tasks to interface with an abstract class, wouldn’t that defeat the purpose of having a Behaviour Tree where you can separate actions into neat tasks and combine them as pleased? I ask out of ignorance. This is my first venture into serious AI design.

It does sound a bit hacky to inject a sub-tree at runtime, but I guess it could work.

I would love to try your quick and dirty DLL. It is more about the flow and feel than anything else. 🙂

This is totally off-topic, but I gotta ask you anyway because I’m naughty like that, did you study at ITU? I was looking through the different resources regarding AI and it popped up more than once.

[Gavalakis]

Hello again,

You are welcome 🙂

By using Script Control tasks to call existing functions, you still seperate actions (functions) into small pieces and combine them together in the behaviour tree. So this way the behaviour tree controls the flow of which the functions will be called, checked etc.
Actions can still be reconnected as you please to define or alter the behaviour. Its almost the same as writing custom tasks. Only this way, you are writing the “task” within your own class and it’s definition it’s even based per type (as in our previous example). The script control task simply wraps the functionalities of your class. I hope this made sense 🙂
Behaviour trees are more about how and when things are executed rather than what. That’s how I see it at least.

Replacing subtrees at runtime is currently non convenient, but in the next version there will simply be exposed fields in the inspector to choose what subtrees to replace with which.

I will build a dll version tomorrow that I will be back and send it to you (at the email you registered with?)

No, I did not study at ITU. Not even close. I am self tought regarding programming 🙂

Cheers!

Join us on Discord: https://discord.gg/97q2Rjh

[Arkuni]

Thanks a bunch, again.

Yes, now it makes perfect sense and sounds very reasonable. If I can make it work in practice, then I will be sure to buy your asset. Looking forward to see how the subtrees will work out too.

Yes, my email is fine and thank you.

Impressive. Looks like you did very good for yourself. 🙂

Kind regards,
Arkuni

[Author]

Posts