Behavior Designer - Behavior Trees for Everyone

Alright, I was confused because I think I remember reading that you were including it in the unitypackage for a period a while back.

 

The base Behavior Designer package used to include the third party tasks and runtime source, but I moved that to being online so I could more easily update it and to prevent you from having to download a Unity package for third party tasks that you'll never use. The Movement Pack has always been a separate package.

 

Has anyone managed to get Behaviour Designer to work with the unity 4.6 beta? I downloaded it to play with the new UI system but behaviour designer now wont compile. It seems that unity compilation is now a lot more strict.

 

No worries, I got it. There is a bug in the code, referencing the private group member variable rather than the public Group getter. in BehaviourTree problem with accessibility levels.

 

Make sure you are using the latest version of all of the integration tasks. They have been updated to use the Group property rather than the group field on the behavior tree component

 

That must be it! Thanks.

 

Yeah, that's what I'm doing, like :

Code (csharp):

1.  
2. var speed=(SharedFloat)_bt.GetVariable("Spider speed");
3. if (speed!= null)
4. {
5.     speed.SetValue(_speed);
6. }
7. else
8. {
9.     Debug.LogError("The spider's behavior tree need a variable called 'Spider speed" of type 'SharedFloat'");
10. }
11.  

And basically what trigerred me to search for an AddVariable function. The idea was if I needed to do another different AI, I could put a new behavior tree, drop the script and I would have the variables already set for the behavior tree, only have to create the tree then.

But I realised I could easily just copy the behavior tree component to another object and have my variables set up, so no need for that in the end.

A couple usability feedbacks for the designer window :
- It could be useful to manage the mousewheel with modifiers (ctrl, alt, shift). Like, in photoshop if you scroll with ctrl down, it scrolls horizontally. And maybe shift or alt down could make the wheel zoom or scroll depending on the "default" action. In the end it could be like : whell : scrolle vertically, ctrl+ wheel : scroll horizontally, alt+wheel : zoom in/out
- It's good to be able to collapse/expand nodes when the tree becomes larger. Is it possible to have a shortcut for that? like ctrl click/ triple click maybe?


Lastly, I've got a question : if I want to do a set of actions/decision that are the same at different places on my tree, what would be the way to go? I don't think there's a concept of "sub-tree" in your package, but maybe it can be achieved with external trees, or with another behavior tree componnet like you did in the CTF example?

 

Great to hear that you found a workaround for the variables. SetVariable will assign a new variable if there isn't one already with that name but it looks like you got it figured out.

In the preferences you can change it so the mouse wheel will scroll the graph instead of zoom, but it will only scroll vertically with a standard mouse scroll wheel. I will add a modifier so if you are pressing control it will scroll horizontally.

Sure, I can add that. I like the control click idea better since that is less clicking

The subtree concept is the same thing as external trees. If you take a look at the RTS sample project you'll see that I use it on the Unit prefab to duplicate an attack branch.

 

I can't seem to find how to utilize multiple behavior trees - from a design perspective. What is the use of having multiple trees on the same object? I ask because I notice that you can change the tree you are messing with in the designer. Is it of any use to have multiple trees on an object? Should it be that only one is active at a time or something?

 

If you take a look at the CTF sample project you'll see that I have added multiple trees to the same GameObject. One of the trees is for when the agent is on offense and the other is for when the agent is on defense. I could have achieved the same results with just one behavior tree but this is just the way that I chose to organize it. So multiple behavior trees can be used as an organizational/structural standpoint.

In the case of the CTF sample project, only one is active at a time but that is by no means a requirement. If you have two different behavior trees managing two completely different objects/parts of an object then you can have multiple behavior trees running at the same time.

 

Great

Ok, I'll check it out then.

Lately the icons on the Behavior designer have become blurry. I suspect unity made a mess while reimporting them, but I can't seem to find the asset files to change the import settings. Can you point me to where I could find them?

Reading this (http://www.opsive.com/assets/BehaviorDesigner/documentation.php?id=52), from what I understood, it seems that either all behavior trees are ticked automatically (each updtae or fixedinterval), or all manually, right?

 

@SteveB hit the same problem in October. The icons are stored in the editor assembly so you shouldn't need to change any import settings. For him it was happening to all of the Unity icons - is that true for you as well? Are you running 4.6?

If it is set to every frame the tree will be ticked within Update. If you want to change it to FixedUpdate you can set it to Manual and do the ticking yourself within the FixedUpdate loop (or at whatever timeframe you want). The third option is to use coroutines and that will allow you to tick every n seconds.

 

How do I get the latest version of the movement pack? I notice on the web site that I can enter my invoice number to get the add ons but the movement pack doesn't have this option? you have sent it to me previously but I notice you have added 2d support so would like the latest.

cheers

 

You figured it out I just sent you a link.

 

Cheers Justin.
I have a quick question about the movement pack.

I have been implementing Craig Reynolds Boid logic manually. I notice in the movement pack that these behaviours are implemented as tasks.

The way that I was looking to do it was with a single MoveUsingPath task that then calls all the relevant behaviours (separation cohesion ect)

I notice in the movement pack there are separate actions for seek/flee/avoid ect.

Do you have a screenshot of an example tree in how to chain these behaviours?

For example,
I want a pawn to seek a target(food) using the path supplied by my A*. for this I could use the seek behavior. But while seeking I want the pawn to avoid enemies if the pawn has a low courage attribute. I am struggling to see how to combine these tasks. Would it be via a parallel task?

another example,
I want a pawn to seek an enemy if it is visible or heard and enter an attack state, but to flee if its health becomes too low rather than duke it out to its death. Would this be done with interrupts somehow?

and another,
I want a pawn to follow a path to a target (seek) while avoiding other pawns to prevent them overlapping. Also I would want some form of cohesion so that pawns on similar paths cluster together until their paths diverge.

Are these examples possible or would I have to roll my own implementation of MoveWithPath that calculates forces for all of the boid behavior?

Finally is there is a good example of how the interrupts work? Currently I have a branch of my tree checking for enemies to attack as the first action. If another task is in process I return failure if the pawn is attacked. This means that I have to check for these attack events in each task and manually cancel the task.

And one more . Have you implemented the ability to pass variables to sub tree's are populate them? As I have a lot of FindItem->PathToItem->MoveUsingPath->PickupItem->ConsumeItem branches in my main tree, the only difference being the itemtag set in the FindItem task. I know we spoke about this some time ago but haven't seen anything mentioned in the forum.

Sorry for the Essay

Cheers
Dave

 

Hey Dave,

In this situation I personally would modify the Seek task to be able to detect enemies and change its route accordingly if it gets near one. You probably could achieve similar result with conditional aborts (see my answer to your next question), but the tree would become more complicated then it needs to be.

You could do it with interrupts, but it would be a lot easier to use conditional aborts (doc, video). Here's an example tree with a conditional abort set to lower priority for your situation:

It sounds like you'll need a modified version of the Follow Leader task in the Movement Pack. The Follow Leader task sets the destination of all of its agents to the same point, where you need a different point for each agent.

There's a screenshot of a tree using interrupts in the first post here, but for most situations you can move away from interrupts and just use conditional aborts.

Yes, there are two different ways. You can either specify that the field should be inherited manually (Inherited fields are described at the bottom of the page), or on the Behavior Tree Reference task you can specify it to automatically inherit all of the Shared Variables. The RTS sample project has an example of this with the Unit's behavior tree.

 

I've been shopping around for a behavior tree asset and Behavior Designer looks like the best one...

Plan on having any sales any time soon? I bought Playmaker when it was %50 off so I sorta got spoiled with sales haha- anyway great work with BD and I'm going to buy it anyway just hate missing a sale-

 

hehe - it doesn't hurt to ask. No - no plans for a sale anytime soon You can get the Movement Pack for free right now though so that may help

 

You got yourself a new customer now I'll probably bug you a ton on your forums so watch out lol-keep up the great work!

 

I appreciate it! No worries on the question - I'm here to help. For a good overview on how behavior trees and Behavior Designer works, take a look at this post.

 

Thanks! btw I haven't received the Movement Pack download yet- Is there something else I need to do to get that?

 

Yes - send me a PM or email with your invoice number. I'll send you a link. You can give Asset Store vouchers now but you only get 12 of them per year so instead I just send you a link

 

Can anything be done about how much "wait for FSM completion" slows things down? It makes your playmaker integration unusable I'm afraid. I have an example scene attached, but as I've never shared one I don't know if it will work.

Both times the FSM is called it counts to 100. Using a bt for a separate call for each count absolutely kills performance. Letting the FSM count by itself is instantaneous.

 

Your sample scene worked and I am looking at it now. In the first case you are starting the FSM and then returning success. As soon as the int reaches 100 you then return failure and the tree continues. Your second start FSM call doesn't return failure until 100 has been reached. In the first case you are transitioning back and forth between the behavior tree and the FSM 100 times, and in the second case you are only doing it once, so the second case will always be faster. Now, in the first case, as soon as StartFSM returns success Behavior Designer waits for the tick to end before it calls StartFSM again. We talked about earlier allowing Behavior Designer to continue on even though it has already ran that task within the same tick, and I was planning on adding that to the next version.

 

@gravyleaves -

I just added the feature which allows Behavior Designer to continue process tasks that it has already run within the same frame. Your example of going back and forth between Behavior Designer and PlayMaker to increase a count can now run in the same frame. I still don't know how much use this will actually get since normally a task returns a status of running at least once within the tree but your case is now covered.

I am leaving the default to stop executing that frame when all of the tasks have run once, but you can change it on the Behavior Manager to be how ever many you want:



I don't know how much I like the name Tick Execution so if you have any better name feel free to let me know.

 

Wow, awesome. Will there now be problems with the variable synchronizer not being able to keep up? A manual sync playmaker action would stop that problem, I think. And I'm assuming the max execution count only applies to the editor, not runtime, correct?

Speaking of synchronizer problems, I am now unable to sync anything except Int's with playmaker. Still works for other sync types. I have no idea what happened all of the sudden.

Edit: I mean adding variables to sync. The ones currently set up still work

Edit2: looks like ints, floats and bools work for setting up sync. not color, vector2, vector3 and game objects, objects

 

The Variable Synchronizer is independent of the Behavior Manager so if you need that level of control then you'll need to either select sync variables within the Start FSM task. I will be adding more tasks to do this manually but in the meantime you can take a look at the new section on the Opsive forum dedicated to sharing tasks. A user has posted just what you are looking for here. The max execution count applies to both the runtime and editor. In the editor it will output a log message telling you what is happening but it has been added to the runtime to prevent infinite loops.

Looks like you're right. I wonder what happened. Either today or tomorrow I will be adding the ability to sync global variables so I'll make sure I take a look at this. Send me a PM if you want this new version early (I am planning on releasing the next version towards the end of this week or very early next week).

 

is it possible to define the tick update interval per gameobject? instead of the behaviour manager

 

There isn't an option within the Behavior Manager, but you can set it to manual update and then you can do your own ticking with:

Code (csharp):

1.  
2. BehaviorManager.instance.Tick(BehaviorTree);
3.  

 

thank you but is this option affecting all the behaviour trees in my scene? what if i want only one unit that have a think rate of 0.1 sec when the others unit have 0.4 sec?

 

Do you plan on integrating with icanscript? It looks faster than the alternatives.
Also, i would be using this on mobile, for an rts with 3000~ units, will the performance hold up?
How does the performance compare to writing pure c# scripts?

Thanks, great asset.

 

Hi

Just seen this on sale and I was thinking of picking it up as I have A* and UFPS already. Can I still get the Movement Pack for free if I buy today?

Also, I just wondered whether there were any plans for UFrame integration at all?

cheers

Nalin

 

@Damien Delmarle -

What does your script look like? You should be able to have each tree tick independently with something like:

Code (csharp):

1.  
2. using UnityEngine;
3. using BehaviorDesigner.Runtime;
4. using System.Collections;
5.  
6. public class UpdateTree : MonoBehaviour
7. {
8.   public BehaviorTree behaviorTree;
9.   public float tickRate;
10.  
11.   private WaitForSeconds tickWait;
12.  
13.   public void Start()
14.   {
15.     tickWait = new WaitForSeconds(tickRate);
16.     StartCoroutine(TickTree());
17.   }
18.  
19.   public IEnumerator TickTree()
20.   {
21.     while (true) {
22.       BehaviorManager.instance.Tick(behaviorTree);
23.      yield return tickWait;
24.     }
25.   }
26. }
27.  

@Kiori -

The developer of icanscript has started integration with Behavior Designer, just need to finish the sample scene and it should be complete.

In terms of handing 3,000 units on mobile, what you will want to do is to manage multiple units with a single behavior tree. If you add 3,000 MonoBehavour scripts which have any sort of processing at all chances are you'll see an impact, so this isn't just related to Behavior Designer.

In terms of performance compared to regular C# scripts, I honestly don't think you'll notice much of a difference. Most of the processing time is spent in performing the specific task action (the OnUpdate of the task), rather then traversing the tree. Traversing the tree is fast.On this page you can see that we ran some performance tests. From our tests, 2,000 behavior trees took 1.2ms to run each frame, and 4,000 trees took 1.38ms. Granted this was on the desktop, and you should never be running that many trees at once anyway, but that should give you some sort of an idea.

 

This sale was a complete surprise to me. When Behavior Designer goes on sale like this we stop the Movement Pack promotion so unfortunately it is not free. You're getting a great deal though I have talked to the uFrame developer, we're working on getting something together. I'll try to make sure uFrame is in the next batch of integrations (it won't be in the update that we are releasing later this week)

 

Thanks for this - hey, I had to ask

Cool - look forward to the uFrame integration

N

 

Yes, please!

 

Aww, where's your Christmas spirit? Lol You should at least do one intentional Christmas sale!

I'm just bustin your chops. Keep up the great work

 

hah. Our other asset is in an intentional sale if that counts Honestly though I feel bad telling @mdotstrange a few days ago that Behavior Designer isn't going to be in a sale anytime soon.. I really had no idea that Behavior Designer was going to be in this sale.

 

Thanks for the response, and yeah it would have to be one behavior tree, specially for the sake of predictability.
I saw the test but they were on a pretty powerful machine, considering mobile. Yet my guess would be its a really good asset performance-wise.

Thanks for the info, your response was right on the money.

 

I saw Behavior designer on sale and wanted to know if I would be able to create hex based AI to get similar game play to this game http://www.cybersalt.org/games/cat-herding.

Many thanks
Ray

 

Hi Ray,

As a general principal, behavior trees are not limited to a specific genre and can be used in pretty much any type of game. The AI in Cat Herding is relatively basic: compute the shortest path on a hex based map and move there. As the game runs that path is blocked by obstacles so the path needs to be able to be update at runtime. Behavior Designer is not a pathfinding solution but it does include other assets which do pathfinding through the Movement Pack.

It is now a question of if that pathfinding solution allows hex based map. Out of all of the pathfinding solutions that the Movement Pack is integrated with, the A* Pathfinding Project is the only one that can work on a hex based map through their grid graph. All of the other solutions use a navmesh in order to generate the path. The downside of the A* Pathfinding Project is that it is mostly a 3D pathfinding solution and it looks like you are wanting something 2D. It looks like the A* Pathfinding Project can work with 2D but I've never tried it.

Long story short, yes, you can definitely create a 2D hex-based AI with Behavior Designer, but it will take some tweaking of the A* Pathfinding Project. The upside is that when you do get the A* Pathfinding Project working with 2D the Movement Pack will work immediately with that as the Movement Pack doesn't care if it is in 3D or 2D.

 

Very through response, thanks opsive! I would buy just from your response ( and the discount ) I took a look at the pathfinding project , it's a bit out of my price range at the moment.

I remember that I picked up this asset https://www.assetstore.unity3d.com/en/#!/content/12520 some time ago. Would your behaviour designer work with with the pathfinding in this kit?

Many thanks,
Ray

 

I haven't actually seen that asset before but it sounds like it would be a good addition to the Movement Pack. Currently Behavior Designer is not integrated with Hex Grids so there aren't any specific tasks for it. I'll make sure to include it though in the next Movement Pack feature update.

 

When you say BD is integrated wtih a* path prjct does that include the free version?

 

Yes, the Movement Pack supports both grid based (free version of A*) and navmesh based (pro version) movement. I should have mentioned that in my post earlier. See this page for a bit more information.

 

What's the difference between your asset and NodeCanvas? Are they the same thing, just implemented differently? Both are on sale right now so I'm trying to to choose one. Thanks!

 

@opsive Hello, I'm starting to put several enemies into the scene (10) and I noticed something very puzzling (and worrying) using Unity's Profiler (using the Deep Profile option).

The Physics.Simulate element is taking A LOT of CPU cycles. But the weird thing is that I've looked into my scripts (tasks included) as well as the Physics matrix and there's absolutely nothing going on here, besides a couple of OnTriggerEnter calls (which take about less than 0.5ms). In fact the element which is responsible for thousands upon thousands of calls and up to 150ms PER FRAME (so the game's pretty much a slide show) is called BehaviorManager.BehaviorOnTriggerStay().



Would you have any idea what's happening here? Because I have no clue what's going on. Why is BehaviorManager triggering so many calls? And why is BehaviorManager dealing with Physics in the first place? And last-but-not-least is BehaviorManager (a fairly generic name) in fact related to BehaviorDesigner?

 

OntriggerStay is a collider function that trigger every frame as long as there is an object with rigidbody/collider inside the trigger. if you want to trigger only once use ontrigger enter/exit instead of stay

 

Thank you Damien. I am quite familiar with OntriggerStay() indeed and I do not use it in my scripts (only OnTriggerEnter and Exit). Which is why this situation has me so confused...

 

@eridani -

The both are a behavior tree implementation. To be as unbiased as I can be, take a look at the Behavior Designer comparison chart and the Node Canvas comparison chart. If you have any specific questions I'd be happy to answer them.

@Seith -

The Behavior Manager is part of Behavior Designer. It does the actual execution of the behavior trees. Because Behavior Designer tasks are not MonoBehaviour objects I need a proxy in order to send the collision/trigger events. What BehaviorOnTriggerStay is doing is looping through all of the tasks and sending the trigger event to each task. I have already removed the Dictionary ContainsKey call in the next version which should help, but I have a few ideas on how to reduce this even further. I'll get back to you.