NodeCanvas - (Behaviour Trees | State Machines | Dialogue Trees)

Hello,

Indeed there are no 2D equivalents for those 2 tasks. Here they are :

Spoiler: CheckMousePick2D

Code (CSharp):

1. using UnityEngine;
2. using NodeCanvas.Variables;
3.  
4. namespace NodeCanvas.Conditions{
5.  
6.     [Category("Input")]
7.     public class CheckMousePick2D : ConditionTask{
8.  
9.         public enum ButtonKeys{
10.             Left = 0,
11.             Right = 1,
12.             Middle = 2
13.         }
14.        
15.         public ButtonKeys buttonKey;
16.         public LayerMask mask = -1;
17.  
18.         [BlackboardOnly]
19.         public BBGameObject saveGoAs;
20.         [BlackboardOnly]
21.         public BBFloat saveDistanceAs;
22.         [BlackboardOnly]
23.         public BBVector savePosAs;
24.  
25.         private int buttonID;
26.         private RaycastHit2D hit;
27.  
28.         protected override string info{
29.             get
30.             {
31.                 string finalString= buttonKey.ToString() + " Click";
32.                 if (!savePosAs.isNone)
33.                     finalString += "\nSavePos As " + savePosAs;
34.                 if (!saveGoAs.isNone)
35.                     finalString += "\nSaveGo As " + saveGoAs;
36.                 return finalString;
37.             }
38.         }
39.  
40.         protected override bool OnCheck(){
41.  
42.             buttonID = (int)buttonKey;
43.             if (Input.GetMouseButtonDown(buttonID)){
44.                 var ray = Camera.main.ScreenPointToRay(Input.mousePosition);
45.                 hit = Physics2D.Raycast(ray.origin, ray.direction, Mathf.Infinity, mask);
46.                 if (hit.collider != null){
47.                     savePosAs.value = hit.point;
48.                     saveGoAs.value = hit.collider.gameObject;
49.                     saveDistanceAs.value = hit.distance;
50.                     return true;
51.                 }
52.             }
53.             return false;
54.         }
55.     }
56. }

Spoiler: WaitMousePick2D

Code (CSharp):

1. using UnityEngine;
2. using NodeCanvas.Variables;
3.  
4. namespace NodeCanvas.Actions{
5.  
6.     [Category("Input")]
7.     public class WaitMousePick2D : ActionTask {
8.  
9.         public enum ButtonKeys{
10.             Left = 0,
11.             Right = 1,
12.             Middle = 2
13.         }
14.        
15.         public ButtonKeys buttonKey;
16.         public LayerMask mask = -1;
17.         [BlackboardOnly]
18.         public BBGameObject saveObjectAs;
19.         [BlackboardOnly]
20.         public BBFloat saveDistanceAs;
21.         [BlackboardOnly]
22.         public BBVector savePositionAs;
23.  
24.         private int buttonID;
25.         private RaycastHit2D hit;
26.  
27.         protected override void OnUpdate(){
28.            
29.             buttonID = (int)buttonKey;
30.             if (Input.GetMouseButtonDown(buttonID)){
31.                 var ray = Camera.main.ScreenPointToRay(Input.mousePosition);
32.                 hit = Physics2D.Raycast(ray.origin, ray.direction, Mathf.Infinity, mask);
33.                 if (hit.collider != null){
34.                     savePositionAs.value = hit.point;
35.                     saveObjectAs.value = hit.collider.gameObject;
36.                     saveDistanceAs.value = hit.distance;
37.                     EndAction(true);
38.                 }
39.             }
40.         }
41.     }
42. }

What do you mean that DynamicVars are not available in the ITween actions?
DynamicVars are possible to enter in any BBVariable (the ones with the radio button on the right), except for the one that refers to the target agent when overriding it. This is done on purpose for now
Are you refering to this kind of variable?

Regarding the "Convert to SubTree" it was temporary removed in the last update due to not working properly with Undo. It will certainly apear again though

As for your last questions, yes, I will definetely add this way for creating states just like it's done in Behaviour Trees.

Cheers!

Hello and thanks a lot! It's definetely worth learning
Regarding your questions:

1. I have on purpose not added tasks that simply get or set a property, or call a method, because it would mean adding thousands of tasks that in most cases would not be used. Instead, there are the GetProperty, SetProperty, ExecuteFunction etc "Script Control" tasks that can do just that, and of course if need be it's very straightforward to write your own . Again, the reason is to keep only somewhat important tasks in the default list.

2. This really fall under the above answer . There are really infinite of operations someone can do with values. You might want to check the distance of 2 vector BBVariables, or of a vector BBVariable and a transform(.position) BBVariable and so on. If I was to add a CheckDistance for each combination of Vector3, Transform and GameObject, this would lead up to 9 actions, practicaly doing the same thing
With that said, I am looking for ways to satisfy those needs with other ways.

3. The .gameObject property doesn't really need caching and as far as the .transform goes, I've gone ahead with the thought that in Unity 5 it will be cached automaticaly. Furthermore, the 'agent' property used in the Tasks is always a cached Component type of the one specified with the [AgentProperty] attribute.
The BBGameObject is indeed a proper location to cache the transform until Unity 5. I could do this in the next update.

4. I don't really understand what you mean by "using strings with reflection" , but using hash IDs to access variables is one thing I can add in the next version. Speaking of the next version, I will make a post in the comming days. It's actually a total overhaul, namely version 2. Amongst the *really* many great things about it, there is but one bad thing and that is the fact that it's not backwards compatible, even though I'm looking for possible ways. Again, I will make a post about it later on.

Thanks a cheers!

 

Awesome, thank you for the answers and the 2D actions! And yeah, I wanted to override the target agent in the ITween Move action with a DynamicVar (a gameobject) that I got from a "Check Mouse" condition (especifically the "Save GO as" option), I know I could use a BB variable but it's faster to prototype with DynamicVars.

Glad to know about "Convert to Subtree" I thought I was crazy haha

And creating FSMs with the "node dragging" feature will be way faster, thank you very much!

P.S: NodeCanvas is awesome! I bought PolyNav too, very useful.

 

Excellent!

I will watch closely on your future post(s) about NC 2

 

It will be very easy to enable DynamicVar option in task agent variable. Basicaly the only reason it's not already, is to limit possible user mistakes with wrong types. I might enable it though if it's consider important for the next version, along with your other request

Thanks a lot by the way! I am very glad you enjoy NC and PolyNav as well
Cheers!

Hey!
These will be soon enough

 

Thanks for the response nuverian.

Also, have you heard of DOTween? It's from the creator of HOTween. It'd be awesome to see native methods for that instead of iTween due to the huge performance increase of DOTween.

 

Hey, Sorry for late reply.

I will replace ITween with DOTween for version 2, comming soon

Cheers!

 

I'm excited about this new version, nuverian. Cheers!

 

Hey @nuverian ,

I couldn't find this in the documentation: How do you transition from a nested graph to the parent graph? Or is this something we have to manually implement in an action?

 

We are about to start production on a game, and are happily using the current version of NC right now for other projects. Should we wait for 2.0 to drop (ie. it is coming before end of month), or continue with 1.x? I only ask because i've seen that 1.x stuff will not be auto-upgradable to 2.0. I think we would be happy with 1.x, but i know that there will be some stuff in 2.x that i would be sad to not have access too

 

Thanks! Me too Cheers!

Hello,
There are basicaly 2 ways that a nested FSM will give control to it's parent:

1. When a parent's transition happens.
2. When the nested FSM finish for any reason. An FSM is also Finished when it reaches a state which is Finished and has no transitions at all.

So, you can either send the nested FSM in an empty state without transitions, in which case it will be considered Finished and the parent will take over, basicaly performing the OnFinish transition.
Or, you can have a transition on the parent NestedFSM node state which may have a condition that is triggered because of something happening in the NestedFSM. For example you could use a SendEvent in a state of the NestedFSM and use a CheckEvent on the transition of the parent NestedFSM node state.

I generaly recomend the first solution because it's more "natural"

Let me know if this works for you,
Cheers!

Hello Jos,

I definetely recommend to wait for version 2. There are so many stuff in there, but especialy core changes, that it will be a pitty
Yes it will be released before end of month!

Cheers!

 

Thanks for the note!

I do have another question about 1.x (and i guess about 2.x, if it makes sense with however 2.x is working).

When using BehaviourTrees, and backboards, we would like all the variables defined in the Tree to be auto-added or show up in the Agents individual backboard. Is there a way to do this? Does that even make sense? Each agent does it its own BBoard, but we are simply using it to parameratize the Behaviour attached to that Agent, and so we want to see all the var's defined in the Behaviour in the BBoard so we can tweak them.

Any suggestions?

 

Hi Nuverian I've endlessly searched and even bought various AI Packages from the Asset Store and I see yours as being the most promising for sure good job on it bro! A question though is Node Canvas able to assist me for AI in my fighting game? I see where you listed on your website that Node Canvas has many advantages over Behavior Designer and RAIN for example and for what I seen since I have both of those as well Node Canvas and I say Node Canvas is the best one. So yeah I assume Node Canvas is capable of making AI suitable for a fighting game judging by how powerful it is.

 

I'm using NodeCanvas FSM to control a game and would like it to handle the Pause state. My question is, how to return to the state where the game was just before it had been paused. Is there some kind of "go to previous state" method, or am I on the wrong track here? Thanks!

 

Hello,

Yes that totaly makes sense. Using agent Blackboards is really ment to parametrize the BT for the specific agent (like you use them). So if I understood correctly, you would like for all defined parameters (the same ones that are shown in the Graph Inspector "Defined Parameters"), to be automaticaly be created into the agent blackboard (?)
Here is a very quick way to do it through a button on the GraphOwner inspector. You can add this code in GraphOwnerInspector.cs:

Code (CSharp):

1.             if (owner.behaviour != null && owner.blackboard != null && GUILayout.Button("Create Variables")){
2.                 foreach (BBVariable bbVar in owner.behaviour.GetDefinedBBVariables().Select(pair => pair.Value)){
3.                     if (!owner.blackboard.GetDataNames().Contains(bbVar.dataName))
4.                         owner.blackboard.AddData(bbVar.dataName, bbVar.varType);
5.                 }
6.             }

(Make sure to add System.Linq and NodeCanvas.Variables namespaces)

Let me know if that is roughly what you are after?
I can improved that one for version 2

Cheers!

Hello and thanks a lot!
I am very glad you enjoy NodeCanvas
You can certainly use NC for a fighting game, or any type of game for that mattter. BehaviourTrees (or FSMs) are not bound to any specific game genre, thus you are free to use them in any genre you like.
Tailoring the system to suits your game needs is also one of the prominent focus of NodeCanvas.

Let me know if you have any questions of otherwise.
Cheers and thanks!

Hello,

Can you please clarify what you mean when the game has been paused? Does this involve pausing of the FSM or what you mean is that you have a state that is named "Pause" and form that state you want to go to the last state before that?

Code wise, the FSMOwner has a reference to the last (previous) state name of the FSM as well as a function to Trigger states by name. So what you could do is something like this:

Code (CSharp):

1.  
2. private FSMOwner owner;
3.  
4. void GoToLastState(){
5.     owner.TriggerState( owner.lastStateName );
6. }

But, there is not integrated way to do that within the FSM editor context.
Here is what you could do though, although a bit exagerated:

1. Create an Action that stores the last state name in the blackboard and add that in the Pause State
2. Create a transition from the 'Pause' State to an 'Unpause' State, which is triggered when you want the game to unpause.
3. Create and add an action in that 'Unpause' state that reads the stored last state from the blackboard and calls TriggerState.

Actually, here are the actions:

Use this on the PauseState to store the last state.

Spoiler: StoreLastState.cs

\

Code (CSharp):

1. [AgentType(typeof(FSMOwner))]
2. public class StoreLastState : ActionTask{
3.    
4.     [BlackboardOnly]
5.     public BBString saveStateName;
6.  
7.     protected override void OnExecute(){
8.         saveStateName.value = (agent as FSMOwner).lastStateName;
9.         EndAction();
10.     }
11. }

Use this on the Unpause state (or anywhere) to trigger a state

Spoiler: TriggerState.cs

Code (CSharp):

1. [AgentType(typeof(FSMOwner))]
2. public class TriggerState : ActionTask{
3.  
4.     public BBString stateName;
5.  
6.     protected override void OnExecute(){
7.         (agent as FSMOwner).TriggerState(stateName.value);
8.         EndAction();
9.     }
10. }

Let me know if this works for you.

Cheers!

 

What's up Nuverian, thanks for the reply. I'm quite stuck on what approach I should make to create AI for my fighting game like. I'm been looking for an example throughout the internet of how to make the AI less predictable when using Behavior Trees and FSMs. All I've read is Behavior Trees, Decision Trees, and FSMs aren't very good in terms designing Human-Like AI especially in fighting games. I'm not sure if that's true or not but I also have a couple of Neural Net AI packages from the Asset Store. The thing is Nuverian I'm definitely willing to still give the Behavior Trees and FSMs in Node Canvas a try and possibly use it along with the Neural Net packages I also purchased. Thanks again for making such a good AI solution. Cheers!

 

My view is that players like to see consistency in AI. AI can be complex, but if it's not consistent players will think the game is buggy.

 

Thanks Hopeful, I needed that kind of reply! Yeah I agree that players seem to expect some things from the AI like it being consistent like you stated. I agree that's not always the way AI should be in games if you ask me as well.

 

What I mean is that - as I see it - what you're looking for and thinking of as "inconsistency" is probably better thought of as "complexity." Players generally like both consistency and complexity.

If you want to have an AI respond in a somewhat unpredictable way, it should still be a rational response ... even if it is simulating an irrational behavior, if that makes sense.

 

Hi Nuverian,

This is exactly what I was looking for. To clarify, by "Pause" state I meant a state that the FSM would switch to from any state if a pause button is pressed. So, FSM actually doesn't stop. Basically I needed a way to jump to the previous state. Your answer (as always) has been a great help. Thanks again!

 

Yeah, that code is pretty much what we figured out ourselves. So, yes, that would be a great "built-in" for v2.

Thanks for the code and help!

Jos

 

@hopeful
I agree with your view on player expectations design wise

@username132323232 Glad I could be of help. Let you know if you come up with any other questions.

@Jos Yule Nice I will definetely add that functionality then

Cheers!

 

Hi! It's about 5AM and I just finished reading through this thread and the Behavior Designer thread. I've been planning on buying PlayMaker as my first asset but reading through your updates has swayed me. In fact, I was going to buy PlayMaker today before stumbling upon Behavior Designer and NodeCanvas on a final runthrough. I'm fairly competent with code so their gigantic library of custom actions isn't absolutely necessary for me. NodeCanvas seems to do a great job considering it contains what could effectively be three separate assets.

Just have a few questions so I can seal the deal:
1) Version 2.0 will be a free update, correct? I don't need backwards compatibility since I haven't purchased yet. Would like to know if I should buy now and get some practice or wait.
2) Are you currently leaning towards the new node-based script editor being an extension for NodeCanvas or standalone? Do you have any plans for a package deal with NodeCanvas or a rough estimate on a price point? Are you aiming for it to fill a unique role in the same way a FSM/BT does or is it purely aimed at providing visual access to scripting for non-programmers?
3) I've read through dozens of Unity manual and forum pages so my brain is a little too KOd to answer this on my own. Does NodeCanvas have a shortcut similar to Behavior Designer's Conditional Aborts (thread post, and recursive)?
4) In your honest opinion, will PlayMaker and Behavior Designer fill some gap that NodeCanvas leaves open? I've read both (highly biased =P) comparison pages and I do not especially need their cross-compatibility with other assets. I'm especially interested in your opinion on NC's dynamics with PlayMaker, since I didn't expect an FSM alternative to pop up last-second. If you could name one thing you think Behavior Designer does better (aside from videos) that would be great too!

Honestly, I can't afford to throw out $150 for PlayMaker, Behavior Designer, and Dialogue System for Unity at this point in time. NodeCanvas is already winning on price point alone. I'd just like a rough idea for down-the-line purchases and/or what order to purchase in.

P.S. One year later and you still don't have videos. hahaha =) Your detailed responses and quick implementation of feature requests more than make up for it though. Great work!

 

I have some updates I'd like to make to my AI behavior trees. I am also wondering when 2.0 will come out since I don't want any work to be wasted in 1.x version not being compatible with 2.0.

 

Hello there and welcome

There are practicaly many "visual scripting" tools on the asset store, so I can definetely understand you, so let me answer your questions and if you have any more, just let me know:

1. Version 2 will be a free update, yes! It was a hard decision.
2. If you are talking about the tool Im posting about in the WIP section, that will be a seperate, standalone package, although fully compatible with NodeCanvas' other systems of course, since it's build on the same...canvas. Like NodeCanvas the aim of that tool is to be a great workflow bridge of designer and programmers, enough user friendly and programmer extendable alike. Certainly though, that other tool is less specialized than a BT or FSM is, kind like Unreal's blueprints are for general usage. If you have any questions or otherwise regarding it, please don't hesitate to post there
3. Yes, NC Behaviour Trees have a selective "Dynamic" option to work reactively very similar to BD.

​

4. Rough question and very difficult to stay unbiased. Even though NC comes with both BTs and FSMs, it stays specialized in each one respectively. That was the hardest part of it's design. They could certainly be sold as different products.
The biggest advantage I can think of BD over NC, is data serialization. That is though something that is already changed in version 2 (thus the reason of being incompatible with prior versions). Other than that, BD has a great lot of 3rd party asset support. On the other hand, I can think of a lot advantages of NC over BD, but that is of course a biased opinion.
Regarding PlayMaker, the PM FSM and NC FSM simply work quite differently. The most prominent difference being that Playmaker is event based while NC is condition based. It's a matter of workflow preference, where I (obviously) prefer the second. But again, this is a preference.
As a final say:
"If I thought that some other tool other than NC was filling the gaps I was missing, I wouldn't commit into creating NC in the first place and especialy keep updating it, but rather use that other tool directly".
I hope that kind of answers your question

(PS: Indeed no videos yet Which is basicaly a matter of language)

Let me know if you have any other questions or otherwise
Thanks!

Hey there,
Version 2 will be realeased within next 2-4 days
So yeah, it would be great if you hold on for a while.

Thanks!

 

Nuverian, you are an inspiration to the Unity Community. I feel kind of guilty taking NC 2 for nothing, if it has required such drastic reengineering. Is there a way to donate to you and your work in return for the excellent support and software that you create?

 

You don't have to worry so much about being "biased" when you've put so much genuine effort into making your product better. Questions like that are always a bit unfair but I think that last sentence made your point brilliantly. I'm sure that Behavior Designer is an amazing tool. At the very least it's beautifully designed (sorry, but Behavior Designer wins it 60-40 here for me).

With that said, I'm now a proud owner of Node Canvas. Can't wait to start playing around with it. =)

I don't know if I'll be able to handle that 2.0 changelog though. Your .1 increments are already chock full of features so that 2.0 might KO some people.

 

Hey, Thanks a lot!
Don't worry about it If you'd like you can get that other asset I am working on when it comes out, consider you do need it of course!, and thus you get something in return as well
Again, thanks for the motion!

Hey,
Thanks a lot for getting it I am sure you will enjoy it and if you come by any kind of questions, dont hesitate to ask
I really hope v2 doesn't KO people. Apart from adding stuff, there are things that have been removed or deprecated as well, for a better more streamlined workflow. Features are only good as long as they serve in a consistent manner
If you have any suggestions to the design, I'll be glad to hear them as well.

Cheers and thanks!

 

I've to disagree that this is about preference because PM FSM hurts workflow.

I may miss understand PlayMaker's events for transition. But for me it seems that those events just make the whole graph 'abstract' and that for no benefit. While NC FSM just gets to the point and offers more. Just by looking on a graph in NC, all actions tasks and condition tasks along with their settings are visible at first glance. Meaning I don't have to click my way through states, just to get some information and break my head over how to name an event in the first place.

Unlike PM, the NC FSM does improve workflow in this regard!

My tasks are mostly modified to give information to the graph to make the most of this clickless overview. For example, my mouse input condition task prints whether or not GUI block is enabled. The execute function of the script control action tasks, prints the script name instead of the game object name.

NC's action task 'Set Visibility' would print: * Set Visibility to 'Visible'
My own action task 'Game Object Set Active' would print: Set Active: GameObject = True

Obviously 'GameObject' would be replaced with your own game object's name you want to set. I only use the inspector of the canvas when I actually want to change something. Conveniently, the inspector inside the NC graph does not show itself when a state or condition is not selected.

 

These may not be relevant with 2.0 coming up but some things I noticed from using NodeCanvas for a bit:
Functional: Dynamic Variables can have the wrong type assigned to them and nothing will happen. You may want to add a simple type check and error here.
Functional: On a similar note, would it be possible to make the Blackboard "set" actions have dynamic typing? It'd look better than a dozen menu items for setting each type. Or alternatively nest the sets in a submenu, as they're taking up a majority of the space.
Bug: When switching to Dynamic Variable the radio button for switching back to Blackboard Variable will sometimes disappear. The only way to revert this is to undo right away or remove+readd the action/condition.
Bug: When the window is smaller than the graph I'm getting some scrolling issues where I can't see the nodes in the bottom right. It seems to be locking the window to the center of the nodes instead of the right.

Currently out and on my phone but I can provide screenshots of those last two later if necessary.

Overall very happy with NodeCanvas! I haven't gotten too far in since I'm still reading through the Unity manual but I followed an intro PlayMaker/Behavior Designer video and the concepts transfer pretty easily. All these tools are amazing for controlling logic and paired with scripting it's game programming heaven.

 

Hey,

I am really glad you appreciate the immediate readable design and that "floating" inspector panel
I am also glad of your opinion on the condition vs event based transition. Thanks!
I could make the Script Control tasks show the component type instead of game object by default. Basicaly the reasons I've decided to read the game object was to know from first glance if the agent is an override of the owner, but it could work that way too.

Cheers! Thanks!

Hey,

I am glad you like NC thus far
Regarding your reports:
1. I have just added a log for when using dynamic variables with non assignable blackboard variable type.
2. The problem with dynamic casting is that you get "value boxing" for value types which really hurts performance. Although in version 2 there is such an action (Set Any/Get Any), it's use is not recomended for the above reason. Furthermore the Set Variable action of each type respectively, have extra options for Addition, Subtraction etc when it applies and since not all types can have such operation, it would have to result in a lot of if then elses, which again..the more the slower. Generaly speaking it's way better to treat it's type explicitely ( and that why 'Generics' are great )
I could certainly nest the "Sets" into a subcategory, although that would not leave much left into the main "Blackboard" category, since basicaly the "Blackboard" category is for such things
3. Thats a very weird bug that havent happened to me. Some variables are able to read only from the blackboard and have no radio button in any case. Can you please confirm that this happened in a GUI control that has a radio button in the first place?
4. Do you mean that the scrollbars don't work or that you can't pan the nodes? In v2 the graph handling has changed a lot, so whatever that problem might be it's most than certainly no more applying to v2, but I would like to know what you mean

Cheers and thanks!

 

I was going to take a video but my computer wasn't up for it today. Here's a screenshot instead:

3) Apologies for remembering incorrectly. Variables with the radio button are actually fine because you can toggle between manual and variable to reset that Blackboard/Dynamic choice. It's ones without a button that can't be reverted. X is set to a Blackboard variable. Y is set to Dynamic Variable. There is no way to change it back to Blackboard variable aside from removing the action or performing an Undo.
4) This one is harder to describe with just a screenshot. The scrollbars work fine going up/left but attempting to move them down/right beyond this point results in the window bouncing back. In fact, only the scrollbars move and the node(s) never pan into view. Dragging the node will correct this until you scroll away and back, causing it to break again.

1) Thanks! I've gotten too spoiled with Python...
2) Definitely see your point of view. I didn't mention this in my first post but a nested menu would also require an extra movement (for little aesthetic gain) so even that's not the best solution. It's not worth worrying over really.

 

Hey,

3. Dont worry about it. So, to go back to the drop down selection menu, you simply have to delete whatever string is there . Just select the text and delete.

4. Oh. Now I understand. To be honest, I havent noticed that since I always use middle mouse to pan around. But, consider this solved in version 2.

1. You are welcome. It's useful
2. I can't come up with anything better than how they are listed now really. And believe me, I realy try to minimize or compact tasks when possible. Else there would be (set float, add float, subtract float, divide float...etc ) where now they are all into one SetFloat

Cheers!

 

3) Do'h. That's a great way to do it though it's not immediately obvious.
4) Middle click panning definitely circumvents the problem. Thanks!

Back with two more little questions. Sorry for the incessant posts and followups! These screenshots are from a nested FSM but the questions aren't related to that. Here is the parent FSM just in case.

Self-Transition: Is there a built-in way to self-transition? I've tried a bunch of ways and looked through relevant parts of the documentation. The alternative is what's done here (circularly link an empty action node with a single condition going out). It's a little messy for a simple transition as opposed to a self-directed arrow like this one.
EDIT: Just saw this debug log. I think it would be a worthwhile feature nonetheless.

Timeout: The script calls a coroutine to increment a counter. When the FSM transitions into another state this coroutine continues to increment the counter until it reaches the timeout and resets to 0. This seems incorrect. Shouldn't the timer reset to 0 upon transitioning to another node OR transitioning back into the node it points out of? Currently it's possible to "bake" the timer by starting it, transitioning to another node, then transitioning back before it reaches timeout. In other words, Timeout is based on when the node was last exited rather than when it was last entered. If I transition to the starting state in this screenshot it will take the Timeout transition in 0.54 seconds.

EDIT: A desirable use for this implementation of Timeout is placing an independent limit on how often a state can be reached. You can access it exactly once every 3 seconds rather than 3 seconds after entering the start state. To transition a fixed interval after entering the state (sorta) we could end it with a Wait action followed by setting a Boolean to true. Our transition would instead check this boolean and the resulting action must reset it to false. This breaks apart for serial action lists with time-reliant actions and all parallel action lists. The cleanest solution would a "Reset on State Enter" property for the Timeout condition. I took a stab at implementing it myself but couldn't figure out how to communicate with a State from a Condition.

A more correct (but godawful) workaround is to daisy-chain short Timeout transitions and Empty States. Here you won't be able to "bake" the timers as long because they'll reset much faster. For example, 1s->1s->1s resets in 1s instead of 3s. To get absolute correctness it'd be around 2/updateInterval extra states and transitions (a useless but amusing statistic).

EDIT 2: You can do it very cleanly with a delayed SendEvent Action and CheckEvent Condition.

 

Hello,
Don't worry about it. Thats why I'm here for

Indeed, self connections are not allowed, at least not right now. An alternative way of doing this would be to use "Repeat State Actions". So if you have a state with:
{
Debug Beep
myFloat += 1
Wait 2 sec.
}

Every 2 seconds, a beep will be heard and myFloat will increase by one.

Regarding the Timeout condition, it's a very special case situation.
Here is an alternative Timeout condition check:

Code (CSharp):

1.         protected override bool OnCheck(){
2.  
3.             if (currentTime >= timeout.value){
4.                 currentTime = 0;
5.                 return true;
6.             }
7.             currentTime += Time.deltaTime;
8.             return false;
9.         }

Let me know if that works for you better.

Cheers!

 

Thanks so much for the response! I've implemented and attached a (somewhat inefficient) modified Timeout script based on the original and the modification you posted. It creates a secondary "reset" timer coroutine that is continuously called and reset on check. Once the checks stop (i.e. when you exit the state) it will increment. Upon reaching the specified "Reset Time" it will reset both itself and the timeout. For small values this will effectively reset the timer as soon as you exit the state. If you put in a negative/zero value then it changes its functionality to the default Timeout, 'cause why not.
Note: This Condition continuously stops/starts a coroutine on check, plus uses >= instead of !< and an inline if for the info, so the runtime probably sucks more than it should.


For self-transitions it wasn't actually about repeating a state after a time interval. It's for a more general case where you want to want to repeat the actions in a state if a condition is met.


Say we have a game where you bounce along a rainbow. Every turn you can either hop to an adjacent color or stay on your current color. To the best of my understanding, this is currently the optimal way to implement such functionality. The sideways transitions are omitted for clarity and the "Stay" event condition could be anything else.


Something like this with a shorter arrow would be a lot cleaner, though I understand it may be more effort than it's worth depending on how you've implemented transitions. "Self-transition" could just be a shortcut for creating an invisible empty state with the desired condition directed in and no condition directed back. From my (somewhat basic) understanding of state machines, transitioning into the same state upon a certain condition/event being met is just as valid as any other transition.


Also, this might already be fixed in 2.0 but grid snap totally stops working when you drag multiple nodes. xD

Overall very satisfied with Node Canvas. I know it seems like I'm pointing out problems non-stop but in reality these are pretty minor issues and everything else is working wonderfully. You've done a remarkable job on this asset and your code is disgustingly clean.

 

Hey,

You are welcome
Yeah, definetely starting/stoping a coroutine, especialy by name will slow things down. Furthermore in v2 starting/stoping coroutines with name in the task is no more supported by the way. For a good reason.

The snaping turned off when draging multiple nodes is on purpose because it looked weird to be honest. They snap back to position on release though.

I will take a look at 'transitions to self' once again, although the actual issue is the UI representation, especialy when there are more than one such transitions. Code wise, transitions to self, are already possible, so there is no further works other than good representation.

Im glad you enjoy NC. Dont worry about posting issues, suggestions or otherwise. On the contrary. If it wasn't for people posting such thoughts and issue, NC would not have been what it is. Thanks!!

Cheers!

 

Hi, it's that time again. More requests This time I've got a few hybrid layout ideas.
I've put them in a google doc (The rest above it is a tutorial for my students, but it won't let me start another one and paste the images!)
See what you think.
Google doc

 

Hey again

Nice document you have there and thanks a lot for taking the time to suggest these!
So, I've read it through and here are my thoughts.

Generaly speaking, everything that has to do with automaticaly re-arranging the nodes is something I havent look at but should be quite difficult in the sense that you describe here.

The reason that a task doesn't start as an ActionList or ConditionList by default is simply for performance when a list is not needed (although in your case I think it's always needed )

Now, having the lists represented with nodes snaped verticaly, I really think that the single node with a list is smaller and more readable (apart from the fact that is center aligned, when left in this case would indeed be better).

Regarding having clickable elements within the node I think would confuse usability, as opposed to the whole node area being for draging the node around. So if it was that the list's elements are shown within the node, then each element would have to catch a right click of it's own, where you (me or anyone), may have wanted the node's context menu. I think that doing this doesn't result in a clear UI seperation of what a Node is and what a Task assigned on the Node is, but rather kind of blends them together.
So basicaly, if I had to chose between exposing the list's tasks within the node GUI, or snapping several nodes verticaly, I would have prefered the second.

Doing the second idea though, (apart from the snapping) would though require that a Condition and Action nodes accept child nodes as well. This is not far fetched, when in reality you can easily create such a Condition node for example, that does have 1 child and when the condition is true instead of returning Status.Success, it returns the child node status. Basicaly this is what the 'Accessor' Decorator does (and is). You could do something similar for Actions as well, where when it's done, it executes it's child instead of returning Success or Failure.
Of course there is still the vertical snapping thing.

Now, for some of the misc ideas, which I have better news

• Code like formating is something possible, but on the other hand I was thinking of removing the "if" prefix completely.
• I will take a look at collapse mini button
• Play/Stop etc will be added in the editor window
• Breakpoints are already added (and Debug decorator removed)
• Will take a look at replacing Composite.
• Zoom is already added
• Comment box (kinda) is already added
• I've just fixed comments to give more space to them
• I've just added shift for counter hierarchical move

Cheers! Thanks again for your feedback and support

 

@Vectrex
Here are some other things I forget regarding the document ideas:

• Regarding per node 'updateInterval', this could be realized with a decorator that alters the update interval for everything bellow it. I could add that one.
• What do you mean speed slider for the update interval value?
• The bug with the hierachical move is fixed. I can't reproduce it.
• Regarding ExecuteFunction and 2 same components, yes it will only show the first of the type. A solution will be to override the agent and manualy set the audiosouce component.
• What text/boxes do you mean are not colored?

Thanks

 

So, I guess it's time for the NodeCanvas v2 change log So here it is.
It's a big post with more than just bullets, so bare with me.

Core Highlights

JSON Serialization
As many of you might know, up to now NC was using MonoBehaviours and GameObjects for structure. This had some advantages, but several disadvantages as well.
So, the new version no longer uses MonoBehaviours or GameObjects, but instead nodes, tasks etc now all derive from system.object .
Graphs themsleves are now ScriptableObject Assets and the whole Graph is Serialized to JSON.
This has been the number one concern of many people. Well, not anymore

Workflow Improvement
The workflow is naturaly improved since there are no extra game object lying around for graphs, or graph prefab confusion. You create a Graph asset and you assign it to any GraphOwner. Using the GraphOwner blackboard which is still a Component, you can parametrize the graph, with the ability to also reference scene objects this way which is not possible to do in asset files otherwise.

Graph Binding
Being assets now, a Graph can optionaly be binded to a GraphOwner. What this does is that it creates a local instance of the graph asset. Doing this allows you to reference scene objects within the graph directly apart from the usage of blackboard variables (as described above).
If at a later point, you decide that you'd like that graph to be re-used elsewhere as well, you can 'Save the Graph' back to an asset once again. These options are all exposed to perform with nice information as of what's going on.
As a by-product, you can also 'SaveToAsset' the graph while in playmode, in case you've done some 'LiveEditing', although not fully tested

JSON Import/Export
You can now also import and export any graph to a JSON file format, with respective extensions for each type of graph (.bt, .fsm, .dt). This is a nice way of sharing graphs in a text format with others. Naturaly UnityObject references are not exported, but of course work fine within unity.

Full Missing Error Recovery
There is now full error recovery for missing nodes and tasks. What this means is that if you have created a Graph with a node or task, that no longer exists, apart from the fact that it will show as 'Missing', the moment you import that node into the project (or in any case the type is found), it will load back and at the full state in which it was serialized!

Types, Variables and Generics
There is no longer the need to create custom variables, or wonder if it exists.
A blackboard can now hold ANY type of variable; lists, dictionaries or really anything.
Much similarily, within nodes or tasks, you can simply use BBVariable<T> instead of the usual BBFloat, BBString etc.
For example: BBVariable<string>, BBVariable<Transform>, BBVariable<List<Vector3>> etc...
That way you can simply have any type of variable to parametrize the task with, or select a blackboard variable from. Even a dictionary and there is even a (simple) dictionary inspector as well now.
So, again, creating custom variables is no longer needed simply because you can use any type of variable.

Script Control Tasks (Reflection)
All script control tasks can now show and use any type of property, or method parameter. So there is no longer that old 'BBVariableSet' class or the need to extend it.
All script control tasks performance has been vastly increased by using direct delegate calls and no value boxing.
Furthermore, script control tasks now use the type selected instead of the declared type to call the function or property on.

Graph Events<T>
Apart from the usual SendEvent, CheckEvent, there is now the ability to SendEvent<T> and CheckEvent<T>, or in other words, send a float event and check a float event for example. Within the CheckEvent task, the received event's value can be saved to the Blackboard. So this is quite usefull to also communicate variables with events apart from just checking if an event has been send.

Task Generics Support
You can now declare AND use open generic tasks! The editor will find those tasks and show the type with which to create the new task in a subcategory, and also with parameter constrains imposed. So in other words, there is no longer the need to have an AddFloatToList, AddBoolToList etc etc. This also works great along with BBVariable<T>. All you need is this:

Code (CSharp):

1.     [Category("✫ Blackboard/Lists")]
2.     public class AddElementToList<T> : ActionTask{
3.         [RequiredField] [BlackboardOnly]
4.         public BBVariable<List<T>> targetList;
5.         public BBVariable<T> targetElement;
6.  
7.         protected override void OnExecute(){
8.             targetList.value.Add(targetElement.value);
9.             EndAction();
10.         }
11.     }

And the editor will show it with a submenu to select a type (categorized by type namespace)
The types shown are all those that have been added in the 'PreferedTypes Editor Window'

Effectively this minimize the number of tasks needed, make them more reusable and a lot of other obvious benefits.

Blackboard Save/Load Improvement
Saving/Loading a blackboard in game now works with Windows Phone as well and basicaly with all platforms. Also Saving/Loading is now done by providing a string Key to save and load from ( eg blackboard.Save("mySave1"), blackboard.Load("mySave1") ).

Even More Blackboard Improvements
Generaly speaking, accessing and using blackboard variables is now simply fast. Furthermore the API has changed a bit, like for example instead of GetDataValue<T>, to GetValue<T>. There is also an indexer so that you can access blackboard variables more easily likeso: blackboard["myFloat"] = 1.5f;

SubTree Dynamic Parametrization
All Nested/SubTree node fields are now a BBVariable, thus able to parametrize which SubTree to run at runtime and through Blackboard variables. So say you have a master BehaviourTree with some SubTrees nodes in it. You can specify which SubTree it reference to with a variable of the BehaviourTreeOwner's Blackboard. Thus a SubTree node by itself becomes a runtime parameter, instead of being fixed.
(The same applies to FSMs as well)

BehaviourTrees
BehaviourTrees have some new Decorator nodes:

• TimeOut: Will interupt the decorated child and return Failure after a specific amount of time in seconds and if the decorated child is still Running.
• Invert: Inverts Success to Failure and Failure to Success. While there is already a Remap Decorator, this simply makes the operation a bit more streamlined.
• WaitUntil: It will return Running until a Condition is met. When the condition is met, it will Tick and return the decorated child's status.

Furthermore:

• Composite nodes can now be set as a BreakPoint through the node context menu.
  
• The 'PrioritySelector' now have an icon (which was missing).
• Accessor decorator has been renamed to Conditional decorator.

DialogueTrees

• DialogueTrees now work without the need of the DialogueActor component.
• The names added in the DialogueTree inspector are now simply parameters of an optional 'IDialogueActor' interface reference. If no reference is given, one will be created for you. So basicaly you don't have to worry about it unless you need to.
• The old EventHandler has been deprecated and all dialogue events are now static c# events where you can subscribe to show your UI or do anything else.
• Furthermore, DialogueTrees are now started by using the static DialogueTree.StartDialogue function, since in any case, only one dialogue can (and should) be active at a time.

Editor Highlights

Better Graph Manipulation
Panning the graph around now actualy pans the graph instead of the nodes like it was perviously.
Scrolbars now indicate the direction of the nodes that are out of view, while pressing "F" centers the view on the center bounding box of all nodes.

Smooth Editor Zoom
Editor zoom in/out final implemented. In smooth version



Canvas Groups
Canvas groups allow you to group a bunch of nodes together. It's purely an organization thing that helps quite a lot.



Nodes Copy Paste
Up to now nodes could only be duplicated, although Tasks could be copy/pasted. Nodes can now be copy/pasted normaly. You can even copy and paste multiple nodes at the mouse position while keeping their "formation". Copy Pasting also works amongst different graphs of course.

Editor Error Checking
Nodes will now show a warning icon when there is something that is potentialy wrong going on with how the node or it's assigned task is set up. Basicaly when a RequiredField is non set, the agent is null etc. This is a 'warning' instead of 'error', since the a RequiredField for example, might be set to non null at runtime.


Automatic Variable Creation
There is now a small '+' button, next to a variable GUI inspector. Clicking this button will create a new blackboard variable with same name as the field and of the respective (any) type for you, and also automaticaly assign it to the parameter in question.



Unity Object Field Convenience
All unity "scene types" (Components, GameObject) editor fields in nodes and tasks will now be non-editable for convenience when editing an asset graph or blackboard. This can avoid unhappy accidents.



Further Stuff (bullets)

• The ability to "Create SubTree from Branch" in BehaviourTrees is now possible again.
• There is now a ContextMenu item in the GraphOwner Component ("Create Defined Variables"), that Creates a Variable in the current GraphOwner blackboard for all defined variables in the current Graph assigned.
• The Variable Sync Components have been removed in favor of the better integrated "Variable Property Binding" that exists from within the Blackboard Inspector. This also works with iOS now.
• Normal Blackboard can no more be "Global". Instead there is a new GlobalBlackboard to use, which makes things more streamlined.
• Tasks and nodes no more need to be in a seperate file with same name, unless you want to be able to open them by clicking the 'script icon' in the inspector of the task.
• TaskAgent override will now list only GameObject and the type of the agent specified in the variable selection dropdown.
• The [AgentType] attribute WILL be removed, so it's better if you use the generic version of ActionTask and ConditionTask from now on to define the agent type of the Task.
• Added SetAny and CheckAny Variable tasks.
• Lists (and now Dictionaries) show under a normal foldout now.
• The Blackboard panel in the Editor Window, now minimize/maximize by clicking the header of the panel, instead of the now removed button in the toolbar.
• Dropping a connection on the canvas in FSMs now opens a context to create and connect a new State, much like it's done in BehaviourTrees editor.
• Undo is no more recordable in Playmode.

Needless to say, there have been miriads of fixes, performance improvements and code clean-ups for all aspects of the package, that I can't possibly or is not worth writing about right now.


Meta

As a final word, the DialogueTree will become a separate NC extension asset (will require NC), thus keeping the core NC package more AI/Logic focused. This new asset will be free for some time ahead, so that all of you owning NC already (or getting it within that time) also get it for free, since the DialogueTree was part of the basic package up to now. After that period it will cost something very little. Even after that period and if you missed the chance to get it, but you have purchased NC before today, I will send it to you once you send me your invoice ID, so that none feels unfair.


Version 2 is going to be submited tomorrow or the day after tomorrow, after wrapping up some things. I will also send it to those whom have requested to get it early at this time.

So that's it for this long post! There are some other many things ahead that I have in mind. I hope I didn't miss any important feature request along the way. There might be some new bugs introduced that I'm not aware of, due to the total core overhaul, but hopefully nothing critical.

Cheers and have fun!
Gavalakis Vaggelis

 

Amazing! Can't wait.

 

Thanks for the huge improvements in workflow and performance! The fact that most updates are targeted at improving core functionality rather than adding gadgets and gizmos was one of the main appeals of NodeCanvas for me. Bells and whistles are nice, but even better is a sleek, aero-dynamic bike to put them on.

Even the "smaller" features like Copy/Paste will really improve productivity, particularly when working with nested BTs/FSMs. Is there Copy/Paste functionality for FSM transition conditions as well? It'd be a significant boost in wiring speed for similar transitions with multiple conditions.

Canvas Groups look snazzy. You may want to tweak the transparency on the wire running through the Canvas Group Name at the top so it doesn't obstruct the name. It's a minor visual detail, but the entire feature is a visual detail so it might be relevant.

I also noticed that the Variable and Editor windows are fixed. Being able to reposition/resize them, either by dragging or anchoring to a corner, would be pretty useful for people with smaller monitors. Exactly the same functionality as Canvas Groups would work nicely. Furthermore, it's possible to click through the Editor scrollbar and on to nodes/transitions below. This leads to a lot of misclicks while scrolling through larger designs (or in smaller windows).

Can't wait for 2.0! I'd better finish crawling through the Unity manual before it's accepted in the Asset Store so I can come out guns blazing on my first Unity project.

P.S. I was wondering where the Create Sub Tree from Branch option went while reading through the docs. Glad to see it back! Though it's less necessary with full copy/paste now.

 

Nice! Put me down for sending v2 early. I especially like any sort of playmode editing, so being able to (maybe!) save will be great.
My email is 'octamed' at gmail. Which should also be what I used to buy it.


Now your notes. Thanks for the quick response!

"The reason that a task doesn't start as an ActionList or ConditionList by default is simply for performance when a list is not needed (although in your case I think it's always needed )"
Ah, thought so. Can't you have it so it starts as a single thing, but if you add another one it converts it to a list, without the user even knowing or caring about the explicit list option?

"...I would have prefered the second."
Yeah I prefer the snapped nodes too. More consistent. Plus the list option can still be there of course.

"Doing the second idea though, (apart from the snapping) would though require that a Condition and Action nodes accept child nodes as well."

Not exactly. I was thinking that internally it would wire it up as if you just manually wired it up, left to right, like the first big graph example. Very much an extension on how you auto-rewire when you change left/right order. Now it's just up/down with some snapping. You just wouldn't actually display the individual wires when they're snapped. You could then happily just keep 'left to right' separate nodes and mix and match.

This really comes into play with graphs like this wikipedia one
http://en.wikipedia.org/wiki/Behavi...le:Integrated_Behavior_Tree_Larger_System.png

(Hmm, but with your suggestion of conditions/actions having an output might be interesting in it's own right. You could do something like this (bottom graph) where they're stacking them, but they can be separate too, and flow through each other. Probably beyond the scope of the idea!
(Then you could have an 'OR' and 'AND' node?)
http://en.wikipedia.org/wiki/Behavi...:Behavior_Engineering_Support_Environment.png)


"Code like formatting is something possible, but on the other hand I was thinking of removing the "if" prefix completely."
That's cool. Either actual code or normal language. It helps my students having the real code though, but plainer would be more compact.

"...I've just fixed comments to give more space to them
I've just added shift for counter hierarchical move"
Neat!

"Regarding per node 'updateInterval', this could be realized with a decorator that alters the update interval for everything bellow it. I could add that one."
Yeah that'd be cool. I was thinking of a right click on node option, but that works for more reasons. Like you might actually want some sections to work faster or slower for cpu reasons.
Maybe adding things like that to the new Canvas groups might be cool?

"What do you mean speed slider for the update interval value?"
Oh, just a slider as well as a typed value, for quick changing of the speed for debugging (usually during playmode).

"Regarding ExecuteFunction and 2 same components, yes it will only show the first of the type. A solution will be to override the agent and manualy set the audiosouce component."
I tried that, but it didn't seem to work.

"What text/boxes do you mean are not colored?"
In the light skin (Unity free) all the text is just black. I guess if changing the text colour didn't work, you could change the node skin colour instead?


Oh, I forgot. Can the blackboard allow normal Unity value mouse dragging? I do that all the time in normal Unity play mode to test things.

Nice work!

 

Great work @nuverian!

I will try it as soon as it land on Asset Store

ps: i will surely get dialogue tree extension when it's available so i dont miss any core functionality

 

Looking forward to this.

 

Hey nuverian,

I haven't updated yet (it's not on the store yet), but I'm having a problem with global blackboards where if I instantiate a prefab that is set to look for the global blackboard, it throws a null reference error and then starts throwing an infinite loop error.

This does not happen to actors that are set in the scene ahead of time.

There is a second situation caused by some of the instantiated actors where they always (incorrectly) register that they can see and are in range of the player, but throw these errors:

• "SetDestination" can only be called on an active agent that has been placed on a NavMesh.
• "ResetPath" can only be called on an active agent that has been placed on a NavMesh.

The above actors all work properly if set ahead of time and not instantiated through code.

What could be going wrong with the instantiating of actors that is causing them to infinitely loop, but not the ones who are set ahead of time?

 

Any News of NCv2? Waiting eagerly.

 

Hello everyone.

Sorry for the delay, but got into some trouble in the weekend. I will send it today.
I am glad of your responses to see that there is something different for everyone to like here

Hey,

I will surely take a look at some of these things as soon as v2 is up, as I'm a bit overwelmed right now
Thanks for those ideas.
More specifcaly:
- The coloring in the light theme is removed on purpose because it didn't show very clear.
- Overriding the agent in ExecuteFunction when 2 same components are there, is now fixed.
- Having normal sliding variables for blackboard is something I am looking at as well for when in play mode at least.

Cheers!

Hey,

These error cases have been fixed in v2, so you won't encounter any more problems regarding that.
Cheers!

 

Very interested to have a good go on V2!

thanks for supporting it so well.