AI: Behaviour trees in Unity: Behave 1.1 released

Yay! The workaround is working like a charm w/ my Behaviour tree which uses all the features, excepting priority selectors.

However in the debugger you'll see that the workflow falls into actions when a decorator fails but keep in mind this is not the case. Also unnecessary calls to reset will be made. To palliate this, you might want to use some stack to keep a track of which nodes have been really called instead of keeping if one of the decorators has failed.

 

@scadieux
Reset optimization is part of the next update. Only components needing reset calls will get them. This has been on my TODO for quite a while

All:
Yea I'm sorry about the confusing nature of my decorator implementation. It stems from trying to have one component do two things without increasing the resolution of the return value. I've got a change scheduled which splits it into two, but since I can't do any meaningful automagic upgrade of existing libraries (I will have no idea if a given decorator is meant to be a repeater or interrupter), I'm aiming for a 2.0 release of that.

 

Anyone had success building an application on iOS w/ Behave specifying "fast but no exceptions" in player settings?

For some reason it doesn't work for me, before digging too deep I'd like to know if this is a known issue.

 

Works fine for me but I find the debug build of the BT always blows up on the device but runs fine in the editor...

 

Sounds complex! Emil reckoned we could hack an interrupt in using an action + parallel. I've yet to try this however...

 

Emil, can you quit teasing us with V 2.0 talk and give us a hint which year/quarter to expect it in?

 

Hi everyone...
I've got a problem with subtrees, maybe someone can help me.

I've got a simple top tree which control if a automated enemy is inside a defined area and if it is... it move around.
In my first version the tree comprehend all nodes in a single tree...and everything worked fine.
Actually I'm expanding the behaviour so i decided to move all "move around" nodes in a sub tree. According to this new layout I've setup on the game object 2 .cs files with the appropriate code to handle the behaviour, one for the top tree and one for the "move around" subtree.

When I hit play, nothing happen...looking at the tree debugger I can see that the "move around" subtree get ticked correctly...but none of the ActionTick in the subtree handler code get called (so the object doesn't move anywhere... ).

Where could be the problem? Can someone provide a simple example on handling subtrees with the related code?
Thank you very much.
Bye!

 

Just to let you know, I got it working on iOS, the issue was on my side.

@Magomigo
When I splitted my behaviour tree into subtrees I had to do absolutely no changes in my code and everything worked fine.

Maybe its a changed you've done somewhere?

 

Hi again,

I've done several trials...
Inside the generic tick function of my top tree, looking at sender.ActiveReferenceTree now I can reach access to the automatic instanced subtree and I know also it's type...so I could query the correct IAgent based upon the subtree type.

The problem now is... how can I pass to sender.ActiveReferenceTree the correct IAgent??
or how does TickAgent works?

Here is the generic (NOT WORKING) tick function of the toptree:

Code (csharp):

1.  
2. public BehaveResult Tick (Tree sender, bool init)
3.     {
4.         if(sender.ActiveReferenceTree != null)
5.         {
6.             if(sender.ActiveReferenceTree.GetType() == BLGraship.TreeType.BaseBehaviour_CollisionAvoidance.GetType() )
7.             {
8.                 ((Tree)sender.ActiveReferenceTree).Tick(m_TreeCollisionAgent,null);
9.             }
10.             if(sender.ActiveReferenceTree.GetType() == BLGraship.TreeType.BaseBehaviour_MoveAround.GetType() )
11.             {
12.                 ((Tree)sender.ActiveReferenceTree).Tick(m_TreeMoveAgent,null);
13.             }
14.             if(sender.ActiveReferenceTree.GetType() == BLGraship.TreeType.BaseBehaviour_EngageEnemy.GetType() )
15.             {
16.                 ((Tree)sender.ActiveReferenceTree).Tick(m_TreeEngageAgent,null);
17.             }
18.         }
19.        
20.         return BehaveResult.Success;
21.     }
22.  

Thanks!

 

Hi everyone...
I think I'm a bit confused so I'll try to rollback and explain better what is going wrong with my behaviours...

Using Behave 1.3 I've setup the following generic tree containing calls to other subtrees ( CollisionAvoidance, EngageEnemy and MoveAround ).
For each of the tree ( and subtree ) I've created a .cs file containing the code to handle Action and decorators ticks, so I've got one file for the generic tree, one for the CollisionAvoidance subtree, one for the EngageEnemy subtree etc.

According with the example made by Emil, I've created an Instance of the generic tree in his code handler which i Tick on every FixedUpdate. Other subtree code files don't create any instance of their corresponding tree, cause I expected it would have been created by the generic one (as written in the tips of the subtree node in the behave editor).

This is actually happening as supposed (I've traced the sender.ActiveReferenceTree in the tick function of the generic tree) so there are istances of the subtrees and looking at the Behave debugger I can see them ticked.
What's wrong is that the code hadlers of the subtrees are never called.

So I supposed I would have to attach the handlers to the appropriate subtree generated by the generic one looking around I've seen that is possible to tick an Agent from a Tree by calling TickAgent or passing it as a parameter of the Tick function.
Unfortunately these functions are not so documented and by doing experiment the only thing I figured out is that by calling TickAgent function and passing the corresponding agent code...only the main Tick of the passed agent is ticked! ...but none of the undergoing nodes get checked.

The only way I found to make It work is to manually create istances of all the trees and call them manually when needed. I don't like very much this solution cause trees and calls to them are doubled.

Finally I noticed another thing...if I copy actions and decorators code from the subtree handlers and paste them in the code of the generic handler they get ticked!

So my question is...I'm wrong in thinking that every tree or subtree shoud have It's own agent handling the code?
What is the correct way to use TickAgent...or in which way I could attach the appropriate agent to the corresponding sender.ActiveReferenceTree?

Thanks to all.

Here is my generic tree:


This is the CollisionAvoidance subtree:


This is the EngageEnemy subtree:


And finally this is the MoveAround subtree:

 

Now that I finally understand what is going on with Decorators, I must say that I do like how they are. The main thing that needs to be understood (and I think Emil has stated this already), is that Decorators do not invert at all like Actions. Actions return Success, Failure, or Running. Inverting an action causes a Success to return Failure and a Failure to return Success. I think this is the way most would expect it to work.

Decorators behave a bit differently in that just because the tick returns Failure doesn't mean that the Decorator will return Failure. This is clear if you read the description. If it the tick returns Success, the result of the child is returned. If the tick returns Failure, the child is not executed and Success is returned. If the tick returns Running, the Decorator returns Running irregardless of the child's result.

I think what will clear up all the confusion is just some clear documentation on what inverting a Decorator does.

So I feel the main thing causing confusion is that the documentation does not thoroughly explain what Invert does to the Decorator.

So if you want to use the Decorator as a condition/assertion, this behavior would work for a Sequence but not a Selector. The Sequence will go to the next child on Success but a Selector will not. If you want to use a Decorator as a condition for a Selector, you would invert it. This would cause a failed tick to return Failure instead of Success.

And of course, as Emil has stated in the past, the Decorator is also great for looping. Just have it return Running until your condition is met.

Also note that you can create a condition structurally by using an Action as the first child in a Sequence. If it returns Failure, the Sequence returns Failure (and this is how Alex tends to do it if you watch more of his videos).

 

What would probably clear up the confusion would be documentation on what inverting a decorator does. After reading the description in the inspector, I really had no clue what an invert would do.

 

Whoop! Sorry about my long absence from this thread. Been a bit busy. But now Behave 1.4 is here! Blogpost contents:

So obviously I ended up not spending more time on that RPG thing... I did however work on some 3.5 stuff back at Unity, some upcoming demo stuff and baby Lili was born.

Meanwhile I spent spare time on Behave rather than the RPG thing, so now 1.4 is ready for release. TADAA!

This release primarily holds runtime optimizations, fixes and tweaks. Specifically I would like to highlight the ability to mark components as "instant". The instant flag affects sequences and selectors when moving between child nodes. When an instant child component completes, rather than waiting for the next tick to tick the following child node, the sequence or selector does it immediately.

Anywho, get it on the asset store and remember to rebuild your libraries after installing.

The rest of the changes follow:

1.4:
- Fixed decorator incorrectly initializing on every returning tick when tick handler returned Running.
- Fixed debugger view dependency on active tree editor - causing reported null reference exception.
- Fixed missing scrollbars on browser window.
- Reduced logging noise from debug builds.
- Agent blueprints can now be MonoBehaviour based.
- Clarified wording on "library not loaded".
- Now handling reset a bit cleverer - potential performance boost.
- Changed the default success criteria of Parallel components from SuccessOrFailure to Success.
- Added "instant" flag to components. Components marked instant will affect sequences and selectors when moving between child nodes. When a child node marked "instant" completes, rather than waiting for the next tree tick to tick the following child node, the sequence or selector does it immediately.
- The compiler progress bar returns.
- Editing a Behave asset now focuses the asset browser last instead of the tree editor.
- Behave can now be installed in any subfolder of Assets - provided its internal folder structure remains intact.
- Compilation speed improvements.
- Enabled references across collection borders.
- Added Tree.DataSize - returning the number of bytes used by a tree instance. This is also displayed in the debugger window.

You'll find a link to the package in the download section. Have fun!

Blog post.

 

AngryAnt, would it be possible to release a version of Behave (Behave.Runtime and Behave.Assets) that does not depend on UnityEngine?

My team and I are working on a multiplayer game that uses Unity for the client and a dedicated server where AI and other simulation is handled. We would like to use Behave to make editing BTs easier for our designers, but want to run the agents on the server (where we don't have UnityEngine.dll).

 

The version of Behave available in the asset store and its license is only valid for the Unity runtime. So for alternative platforms, another license is needed. Please contact me for details or use the alternative license form on http://angryant.com/licensing

 

Has anyone else tried upgrading from 1.3 to 1.4? When I import the new package from the store, the editor crashes while compiling the new scripts, and once I reload, I get a few of these exceptions:

TypeLoadException: Could not load type 'BehaveAsset' from assembly 'Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType)
System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit)
System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit)
UnityEngine.AttributeHelperEngine.CheckIsEditorScript (System.Type klass)

 

Make sure that you overwrite the old Behave install. Aside from that, as mentioned in the release notes, remember to rebuild your libraries with the new install.

 

OK, deleting the lib and installing from scratch helped, but I also had to remove all existing references to my old behave library (I was referring to specific tree-type constants) in order to get the BehaveAssetEditor to work again. Thanks!

 

Hi there,
All good so far, getting the hang of Decorators, Inversion and the BT theory in general, happily Debug.Logging the states of the Decorators and Actions, now trying to experiment with some real functions and I'm having two problems:

1) I'm guessing that blueprints and handlers are also used for calling external functions to the tree, but I'm not familiar with the abstract class inclusion paradigm, I'm going to look at it from a C# general perspective, but if someone is willing to delve into the issue in this context it would be much appreciated, I'm currently using this code at the beginning of my IAgent script:

Code (csharp):

1.  
2. public class TreeAgent : MonoBehaviour, IAgent {
3.  
4.     Tree m_Tree;
5.     public Actions actions;
6.  

where Actions is obviously a script, followed by:

Code (csharp):

1.  
2.     public BehaveResult TickPatrolAction (Tree sender)
3.     {
4.        
5.         actions.Wander();
6.         Debug.Log("Tick Patrol");
7.         return BehaveResult.Running;
8.        
9.     }
10.  

and it works, sort of!

Is that the optimal way, or is there a way to have the BT TickPatrolAction handle the Actions.Wander Function?
Is that what setTickForward is used for? Or BehaveResult {Name}{Action|Decorator} {get; set;}?
I'm of the impression that setTickForward is used to handle BT Actions and not external script Functions.

2) (This is more of a design problem I guess) If I try and use the BT to trigger my action.Wander() function
the frequency I need to use to have a smooth wander is closer to Update() than what is suggested one should go for. How does one code BehaveResult Running to trigger a behavior that runs at Update() speed untill the Decorator above it fails?

Thanks for the tool, I'll keep trying, and I hope the scenarios I present are intelligible

 

Why do you want your actions handled outside of your agent class? The Set{Init|Tick|Reset}Forward methods handle exactly that, but are meant for special casing - not core design.

IAgent derived agents have handlers set up by Behave reflecting the class on tree instantiation - doing pattern matching to find Tick{Name}{Action|Decorator} and friends.

Agent blueprint derived classes have their handlers already set up as virtual methods on the blueprint class, meaning implementing them in your agent class is a simple matter of overriding those. The main benefits of blueprints are no reflection on tree instantiation (which can get costly for complex libraries) and code completion in IDEs supporting that.

 

I guess one scenario would be of one coder writing the low level behaviors, and a gameplay programmer triggering those functions in the BT. Thanks for the answer.

I guess for the second part it's a matter of having an Update() script interrupted by the BT, and using yield and coroutines...

 

I'm seeing the old "Error running gmcs: Cannot find the specified file" whenever I try to build a library. Mac OS 10.7.2, Unity 3.4.2f2. Fresh install, no weirdness with permissions in the Unity and project folders.

 

Please use the Unity bug reporter to report that issue. I'm just invoking the compiler via the .net API. If there are issues with the pathing, it's a Unity issue.

 

Is Behave suitable for controlling enemy AI across all six axis is full 3D space; for example, controlling enemies in a Descent like game or 3D asteroids clone. Or is Beahave primarily targeted at 2.5D movement typical in FPS style games?

 

Behave deals with behaviour logic. Not navigation. You can use it in whichever context you like.

 

Hi,

The greetings :
I would say that this Behaviours are very usefull !
Thanks a lot Angry Ant for these great tools that make me (once behaviours trees a bit learned) save a lot of time.
I really beleve that investing some time to learn this is good investment.

The context :
Now i would like to share common behaviours (like Dead/Hit/move) with some of my creatures, and apply specific behaviours sometimes, for some creatures (wandering for the player is'nt the same than for the mobs, by example).
To do that, i would like to have a base tree (said "BaseKillable" with the actions "IsDead", "IsHit" and "Wandering" managed with a selector. Nothing special for the "IsDead" and "IsHit" actions as they are the same for all my creatures.
On the other hand the "Wandering" state is different for each creature.

My intuitive solution :
I want to create a base class (with the blueprint stuff) that implements the "baseKillable" tree (IsDead, IsHit and virtual Wandering).
Then i want to inherits from this base class specific creatures classes.
Finally, The inherited class implements a complementary tree (said "playerBehaviours") overrides the "Wandering" states by sending ticks to the complementary tree.

Now the question :
Is this a good solution or is there a better way to do this with behave ?

 

Hey Alewinn

Thanks for your interest in Behave. Agent blueprints are not designed to inherit from one another, but it's a good point. I'll see if I can get that added soonish.

That aside, remember that you can always have multiple instances of multiple tree types tied to the same agent instance. So in stead of just being simple callbacks, an action implementation could tick a different tree in its implementation - leading to arbitrarily complex action implementations which could indeed be overwritten in more advanced agent subclasses.

Because Behave is so abstract you can and indeed should take advantage of the opportunity to combine the power of behaviour trees with that of object oriented programming. You should view a Behave tree as a set of instructions of what to do when - not necessarily *how* to do it.

 

Thanks a lot Angry Ant.
I've found some time to implement this solution and inheriting from a base class (which is a blueprinted class, of course the child class isn't a blueprinted one, but it's sufficient for what i need) works great (i marked as virtual all the actions i wanted to act differently for my mobs and it just work fine ! Cool !).
Then i can releay ticks from these inherited classes to another tree that is specific to the child class, like you said.
If it's for some interrest for anyone i can create a simple sample scene.

 

Hi,

...Is the named priority selector (that was pointed out here) usable in the current version ?

 

Named priority selectors are not implemented yet. At the moment you're still stuck with using contexts.

 

[SOLVED] needed to install the mono framework to get this to work: http://www.go-mono.com/mono-downloads/download.html


Im getting the "Error running gmcs" issue as well, unity 3.5.0b6

Have you tested it on the beta yet? Any success?


This is with a blank project otherwise, with just behave added from the asset store, and a test behaviour tree



Thanks,
Chris.

 

Hi Angry,

I really enjoyed the tutorials to walk me into behavior trees as a FSM and LUA script man its been an adjustment indeed.

I saw in a previous post you had HasEnemy and HasNotEnemy as two different decorators.

Would you then in their respective ticks have the fail condition of having a target?

Is there a way for the HasNotEnemy to know when its children have completed the sequence and thus can flag this whole sequence as complete to find another point to walk to?

sorry for the basic questions, just going into this at a walking pace and want to make sure I don't take early wrong turns.

Thanks

 

Hi,

I try to call a subtree and when I it the functions on the agent will not be triggered. All calls will be received in BehaveResult Tick(...) of the SubAgent. Is this a Bug?

My workaround looks like

and call this from other parent. Than all implemented action functions will be triggered.

Thanks
Martin

 

So I've read this thread multiple times now and read all I can find about BTs on the net.

I see alot of people asking about the decorator. I do understand that if we return failure in the tickdecorator we will get a sucess from the decorator when using Behave.

Now my question is if this is the way others view decorators in BTs? I read multiple other articles and none seem to explain it this way.

For example this article:

http://aigamedev.com/open/article/decorator/

A quote:

You say that you may change this for Behave 2.0 but in which way? Is this considered the correct aproach by others working with BTs at places like aigamedev.com?

Thank you for a great product and hope to get some answers about this!

 

@MartinBK:
That does sound like a bug. Could you inline or link a screenshot of your scenario?

There are more ways of doing behaviour trees than I care to count and none of them should be considered more "right" or "wrong" than the other.

With regards to the new decorators, they will allow the child component its full resolution of return values when applicable, while (like it is now) being able to override for return-ticks (repeater) or tick end (interrupter).

 

@AngryAnt:
Hi, I think I did something wrong. Since my last post my code changed a lot. Right now I got almost all working. But It's hard, you documentation didn't helped a lot. I had to find out a lot by my self.

What I found out:
1. To use tree references you have to pass all Agents, except the agent of the top, to AddReferenceTree()
2. Tick() will only be called on root agent. To get a Tick() at child agaent you have to do it by yourself
3. You don't need to instanciate reference trees. They are inside of the main tree.
4. Frequency will not be taken from reference tree

Here some ideas that make it easier using Behave interface:
1. It would be greate if I could define a function that will return an agent. This function could be used if a reference tree will entered
IAgent GetAgentFor{NameOfReferenceTree}()
2. Passing an agent for reference tree this should call Tick() of the new agent. The default agent should be ignored.
3. Maybe this is also a way to remove the AddReferenceTree() . (?)

But I like your Bahve

CU
Martin

 

Does anyone have any Behave 1.4 projects they would be willing to share as a learning tool? Perhaps something really simple. A little example would go along way to understanding how to use this fantastic extension.

I'm not a programmer and I've read so much on the subject of Behavior Trees but I'm afraid I need a project to help me understand how to get started.

Thanks for taking the time to read this post.

Mitch

 

Hi Mitch,

If you don't know how to program than I'm sorry to say, you won't be able to use Bahave right now. You can build a BehaveTree with the graphical editor but the reaction has to be programmed. It is not like other scripting tools in the asset store.

CU
Martin

 

Thanks for responding, Martin.

I should rephrase that - I can program, just not nearly as good as a lot of the folks on this forum, but I can do enough in Unity to get myself in trouble. I've been using Unity since v 1.2. And I majored in Computer Science back in 1978, yes I'm that old. And I do prefer scripted programming over visual tools like Playmaker, UScript and Vizio having tried them all.

But I'm still learning C# (well versed in Unity javascript) and in combination with Behave, I'm a little lost.

I do think I'm closer in comprehension this morning than I was last night. Some of my Behave brain synapses may have connected last night while I was sleeping. Going to give a simple Behave project a whirl this weekend.

Anyway, a simple sample project would be so helpful to learn from if anyone feels kind and generous.

Best to everyone,
Mitch

 

Does this, or will this work with export to flash in 3.5?

 

Hi Mitch,

have you seen the two videos on developer site?

http://eej.dk/angryant/behave/documentation/
under Video-Tutorials ?

CU
Martin

 

Yes, I'm going to watch them again. But I have a hard time hearing/following what Emil is saying/doing. I think I'll pay a quarterly fee to AIDeveloper so I can watch Emil and Alex and their presentation of Behave. Perhaps I'll be able to follow that video with more success.

Found a very good but short youtube video of Behave. That little gem explained a lot.
http://www.youtube.com/watch?v=wkDMTcUV5cU

I think I have enough to go on to put together a small learning project. At that point I'll have specific questions as opposed to the generalized "how do you make Behave ... behave."

Thanks, Martin. I appreciate your suggestion.

Mitch

 

Hi Mitch,

I watched the videos I send you and it took me a lot of brain stuff to understand the Behave Interface. It's said that the documentation isn't such good. But it's a fee software and so I say it's ok.

Maybe i find to to build an a smal Unity project for demonstration.

CU
Martin

 

Yes, it is free software so no complaints.

 

I am trying to compile a very simple tree - a selector with 2 actions. I am getting the error message - Error running gmcs: Cannot find the specified file.

I'm on Unity 3.5, Behave 1.4 OS X 10.7.3. Anyone have any insights as to what file can not be found?

Thanks,

Mitch

 

Hi,

this looks like a mac problem. This doesn't happens under Win.

I found sone articles about this problems:

- https://github.com/AngryAnt/Behave-release/issues/21
- http://www.tech-recipes.com/rx/2621/os_x_change_path_environment_variable/

I don't know how to store environment variables permanent so open the Terminal and enter:

now you can compile the tree




CU
Martin

 

Thank you very much, Martin, for pointing that out. Now the Behave lib compiles.

Moving forward -- slowly.

Best,
Mitch

 

Okay - making progress - Behave is behaving. Thanks to Emil's video and Martin's help and that short you tube video I now understand how to implement Behave's interface.

Pretty cool.

Now on to playing around with Behavior Trees.

 

Earlier in this thread, Angry Ant posted a JS version of the Agent class. He said it was untested and I tried it out to no avail. It wouldn't compile with the few errors it contained.

I spent a few minutes reworking the JS code and now its working fine with my very basic Behave Tree. For those who may be interested, here is the JS code for the Agent class that works with Behave:

Code (csharp):

1. // Agent.js //
2. import Behave.Runtime;
3.  
4. class Agent extends MonoBehaviour implements IAgent
5. {
6.     var tree : Behave.Runtime.Tree;
7.    
8.     function Start ()
9.     {
10.         tree = BLNewBehaveLibrary0.InstantiateTree (BLNewBehaveLibrary0.TreeType.NewCollection1_NewTree1, this);
11.  
12.         while (Application.isPlaying  tree != null)
13.         {
14.             yield new WaitForSeconds(1.0 / tree.Frequency);
15.             AIUpdate();
16.         }
17.     }
18.    
19.     function AIUpdate() : void
20.     {
21.         tree.Tick();
22.     }
23.    
24.     function Tick (sender : Behave.Runtime.Tree, init : boolean) : BehaveResult
25.     {
26.         return BehaveResult.Success;
27.     }
28.    
29.     function Reset (sender : Behave.Runtime.Tree)
30.     {
31.        
32.     }
33.    
34.     function SelectTopPriority (sender : Behave.Runtime.Tree, IDs : int[]) : int
35.     {
36.         return IDs[0];
37.     }
38. }