Worth using behaviour trees for AI over standard code approach?

I am asking more experienced people, who used either method.

I will soon be focusing on AI part of the game, and I want to make best, informative decision I can.

Was implementing some AI behaviour tree into your project architecture worth the effort? I am talking about any kind of behaviour tree (Behaviour Designer, Panda etc.).
Focus is on doing complex AI (lets say RTS AI which is controlled by factions, AI leader grouping etc.).

Or do you think standard code approach do the job? In previous project I have found out that it can sometimes get pretty messy with AI in plain code.

This is solo development, so I dont have designers needing to tweak AI by themselves. I also do not use standard component & monobehaviour design, just plain c# and have GameObjects as "renderers", so this could be problem with behaviour trees requiring monobehaviours.

What is your advice on AI behaviour trees? Are they worth it?

 

This Gamasutra article Behavior trees for AI: How they work by Chris Simpson is what convinced me to start using behavior trees for my AI. There is a certain level of complexity where using something like this makes sense over just coding it. I think that level is fairly low.

That said, there are also libraries and assets for state machines and goal oriented action planners and utility based AIs. I tried each of those major AI technologies before settling on behavior trees as the most intuitive and flexible for my needs (and simplest to develop my own library).

So I'll just say they were worth it in my experience, but you need to evaluate based on your needs. Perhaps start with coding up some simple actions and see what obstacles pop up - what do your agents need to know, how do they communicate with the world and each other - then see how behavior trees can help fulfill those needs, or the other AI technologies.

 

I was using behavior tree based on the gamasutre article for a while, but it was just too messy. Maybe because it had no UI like in RAIN, but it never really did what I wanted it to do. Also in my poor implementation it looked like this: image
For some it may look nice, for me it didn't.

Now I'm using a basic state machine. It is a class that updates a State class, which has Start, Update and End methods, and can change state from the running state itself, or from outside. It is much cleaner and I like it more, but I think that professionally made behavior tree still has more freedom.

 

I made a parser so I could create the trees in a pseudo-scripting language with parameters and such.




Easy to modify that way and I prefer it to visual editors.

 

If your AI have several modes, each of which have sub modes (and those submodes can have their own sub-modes), and the ai controller can bounce back and forth between them, then using behavior trees helps a lot, as long as you have a visual aid that tells you what the ai controller is "thinking" at the moment.

I can't recommend any specific unity behavior tree asset, but in general, yes, they're definitely worth using for anything above the trivial behavior (as in "locate nearest enemy, run to them, start attacking").

 

I wrote an entire space invaders game using PandaBehaviour when it came out. BTs can be a surprisingly flexible way to do logic, they don't need to be restricted to just AIs. BTs are also pretty easy to visualise and debug at runtime. And having your logic separate from your code is a good idea for complex systems.

I normally use a multi-layered approach for AI. For high level decision making I would definitely use behaviour trees. For mid level AI FSMs work great. And for the bottom level stuff, just use plain code.

 

Yeah... it's pretty much a case of using an appropriate data structure to manage the problem at hand. BTs happen to be a really effective data structure for certain types of decision making.

With that in mind, when working with any data it's important to have an effective way to view, navigate and edit it, so a visual editor of some kind is definitely the way to go.

 

If I were you, I'd strongly consider giving the Apex Game Tools set of products a look. They have an excellent Utility AI implementation (which has been well documented to cover many of the shortfalls of state machines and behaviour trees).

Their set of products also contains excellent, high performing steering and path finding implementations for group behaviours, perfect for a strategy game.

 

The Madness Sale has Behaviour Designer for sale. Is that a good one?

 

I tried BT, it certainly is one of the most polished. But its so robust, with so many functions and possibilities that I think it will be overkill. Its like making angry birds in cryengine.

BT is meant more for making entire game, rather than only AI, what just from what I`ve seen.

It looks really robust, and Im not in stage where I wanna shell out money for plugins.

I think coding some behaviour tree from scratch and using some existing editor could will be the best approach. If you guys all think the trees are really useful in this way.

 

What do you mean?

BT are certainly useful for things other than AI. Anything that could use a decision-making approach is a potential fit. But I wouldn't describe them as being used for an "entire game".

 

Yes sorry, I meant Behaviour Designer. I just wanted a lightweight behaviour tree, where I create most of methods myself, but Behaviour Designer is heavy package where you can make almost entire game in it, which is ton of additional stuff I dont need.

 

I've been kinda stuck on where to get started with the next part of my project. This article is fantastic and has not only helped me wrap my head around how to handle the more complex portions of AI decision-making, but convinced me that behavior trees are the way to go! Thanks for sharing!

 

Awesome! I'm so looking forward to Uncharted Galaxy. Makes me think of the very first game I played on a computer, Star Trek on a TRS-80.

 

Did you build your own behaviour tree (with editor UI and everything)? Or used some of the existing ones?

 

I wouldn't have the first clue where to start with building my own system! I had Behavior Designer on my radar before, but before this thread didn't really understand how it all worked, or even what the difference was between that and Playmaker!

I just purchased BD, as it's on sale, and am thinking through a tree for an enemy combatant now (using draw.io to plan the structure out before messing with my project). I'm at work, so can't do any actual work with it yet. I'll certainly keep you appraised of my progress, though, if it'll help you make a decision for your project.

One of the negative things I've seen marked against BTs as opposed to FSMs is the added complexity and lack of re-usability. I get that things can get pretty complex, but this is AI we're talking about here! If anything's going to get complex, it's that! And having something like BD with a visual representation of that complexity sounds way better to me than giant nested code blocks or something.

 

You are right, the AI in games can get pretty complex, and doing it all by code could get pretty messy.

How long are you working with Unity?

Also, I wonder how other big studios do AI. Like Stellaris, hearts of Iron or Master of Orion (which is in Unity).
I think Rimworld (Unity as well) was done in pure code.

But I think I will get that Behaviour Designer as well, maybe its good you said it was on sale

Also, do you use MonoBehaviours for your logic, data and other stuff, or plan c# and do gameObjectsjust to "render" the game. Because I fear behaviour Designer will work good only with the first approach.

 

@Wrymnn So far, the limited data and logic I have in place are regular C# classes, nested under various singletons that communicate with each other where necessary. For example, my App (master singleton) class contains a reference to the Game object, which contains all the core data relevant to a player's game, such as generated Characters, Ships, the current GameTime, player's location, etc. When I instantiate a character, for instance, I keep a reference to its GameObject in its class object.

This would, feasibly, mean that a character can look up another character by what post he occupies, get that character's location using his GameObject, and have his own GameObject walk to the other character. I don't anticipate this being a problem to implement in Behavior Designer. From what I can tell, I should be able to define all these trees, and then call them on those C#-class-based objects as needed. Since the leaf nodes can use your custom-written code to actually perform character actions, it's really not all that different from how you'd call any action without using BD. The advantage the BT provides is allowing you to chain and conditionally call those actions depending on the situation, thus creating a convincing behavior in the AI.

But... I'll let you know if it's as easy to actually implement as I'm hoping.

 

Another big advantage, at least in my case, is "action over time". They work great for actions that require multiple frames to complete.

 

Great point. I have exactly 2 hours worth of experience with them, so I'm learning quite a bit as I go.

 

In Behavior Designer you can export entire tree's and reuse them in other trees by using the "Behavior Tree Reference" task- this makes them very re-usable as you can pass variables into them etc-

 

They're surprisingly straightforward. Once you understand the principles the basics of the system can be set up in an hour or two. (I've seen students do it in two class periods, so ~4 hours.) The UI portion will of course take longer, plus you need to implement actions that integrate with your game. But the core BT part is fairly straightforward.

I guess the main challenge, if you haven't done it before, is understanding how to implement functionality as data rather than as code. There's an extra layer of abstraction in there that can be a bit challenging at first.

 

Neither would I. That was one of the scary parts of BTs that kept me from them for a long time. Then I tried a premade solution. I was actually surprised how easy they are to program and use.

I would strongly recommend taking a layered approach. Have your BT make the high level decisions. But have the actual movement handled by a regular component.

 

Based on what I just posted, one of my hypothesis of gamedev is:

Behavior Designer makes AI fun (easy).

When it would likely be NOT so, if I were to not use it (i.e. Behavior Trees + Game Tool).

However, I have limited experience in AI outside of Behavior Designer, so this post is not worth much.

But my experience working with Behavior Designer / Behavior Trees is pretty awesome. Easy to understand, fun to work with, and even chasing bugs & learning for the first time isn't so bad.

 

Heh, I've been dealing with this myself recently. At the very least, you need a way to effectively debug your AI. Especially if you're looking into the behavioral systems being talked about here.

It's fun to mess up sometimes, though... I've seen AI do some law-of-physics-defying stuff.