Behavior Tree Extension - Select behaviors based on dynamic priority weighting

Updated to 4.12+

Hey guys.

BTUtility is a simple plugin that adds a new node type to the UE4 behavior tree. It doesn’t require C++ or any special integration steps.

The Utility selector is similar to the built in Selector node, but prioritizes children based on a utility value attached to each child via a special decorator node.

There are three basic types of utility decorator: constant, blackboard, or using a custom blueprint that will evaluate each time the Utility node starts.

Example uses are to add some random variation to AI behaviors, or to select a behavior by weighting various criteria to determine what is most important to the AI at the time.

It’s available in binary form (just unzip into …/YourProject/Plugins or Engine/Plugins) and the source code is also on Github (MIT license).
Links and more info here.

This was originally an engine mod and there’s still a chance it might make it in as a PR at some point. It’s been sitting around for a while though, so when I realized most of it could be done in plugin form I figured I might as well release it to the community now.

Enjoy, and if you have any questions or problems with it, just post here. Cheers.

I like this :smiley:

Excellent stuff

No worries, happy if somebody can make some use of it.

I was about to figure out a weighing system for my AI. Seems like this exactly what I’m looking for :smiley:

Thanks for making this… Looks really neat. Are you updating when newer versions of UE4 come out? Thanks again!


Yeah I’ll do my best. Won’t always be immediate but if anyone upgrades and has an issue with it, just let me know here.

To be honest I’d expect it to require close to zero maintenance in this respect anyway. The core behavior tree API won’t change much from here on I wouldn’t think.

Edit: Just built for 4.11 P4, no problems. I’ll push up a binary build when 4.11 gets released.

Interesting implementation. Have you experimented with modifying the base BT nodes so you can use all existing BT nodes? I added a utility goal based virtual that is overridden on a sequence and selector and evaluated in custom decorators and tasks and found it to be more flexible.

@dzeligman: I’m not quite sure what you mean by ‘so you can use all existing BT nodes’, or what the meaning of utility would be in the case of a sequence node? If you can explain or give an example of what result can’t be achieved with my setup, I’d be happy to look into it.

I can say though that this was developed with input from Epic’s Lukasz Furman, since it was initially written with a possible PR in mind. As such, it was done in a way so as to:

  1. Minimize changes to existing engine code (obviously since it was converted to a plugin, there are now none).
  2. Add as little as possible in terms of new nodes/new UI, to avoid adding complexity to the BT editor.
  3. Respect some fairly strict rules defining how decorators should behave, and in particular how a composite is allowed to choose child execution based on decorators.

Outside of these restrictions, then of course there is a whole lot more functionality and flexibility that could potentially be added.
One thing I did consider was having a kind of two-tier utility, with utility functions returning an integer priority class along with the float utility value. That would I think allow more easy control over which child was executed, by first filtering children to the highest priority class available, before selecting based on utility value.

When shooting for those goals it makes sense. It def appears pretty simple and easy to extend. What I meant when saying use all existing nodes is being able to do more DFS/recursive based lookup of utility. Independent utility for selectors and sequences. Its possible my current implementation does not obey all decorator execution rules such as latent abort/event based execution as a result.

Right yeah I think I see what you’re getting at. Yep, it’s certainly a pretty simple implementation, though makes it easy to do a lot of things that were hassle or borderline impossible with the default nodes alone. Truth is though I did this as an engine learning exercise, it wasn’t driven by any particular project needs. So as yet I haven’t really made much use of it or tested the limitations.

Appreciate the feedback.

I’m getting a build error when trying to compile anything with this plugin enabled:

MainFrameActions: Packaging (Windows (32-bit)): CommandUtils.Run: Run: F:\Games\Unreal Engine 4\Epic Games\4.10\Engine\Binaries\DotNET\UnrealBuildTool.exe SpaceBossesCPP Win32 Development -clean F:\Projects\UE4\SpaceBossesTD_Fork\SpaceBossesCPP.uproject  -remoteini="F:\Projects\UE4\SpaceBossesTD_Fork" -nobuilduht -rocket -NoHotReloadFromIDE
MainFrameActions: Packaging (Windows (32-bit)): UnrealBuildTool: ERROR: Couldn't find module rules file for module 'BTUtilityPlugin'.
MainFrameActions: Packaging (Windows (32-bit)): CommandUtils.Run: Run: Took 1,237922s to run UnrealBuildTool.exe, ExitCode=5

complete log:

Hi aureon.

Am I right in assuming you added the binary form of the plugin into the Plugins directory within your project, and also that your project contains C++ code?

I am having this same issue with another plugin I’m currently developing for the marketplace. As far as I can tell, for projects with C++, UBT assumes plugins should have source code too and generates this error if only the binaries and content exist. Blueprint-only projects with binary plugins work fine, as do C++ projects with plugins with source code. I’m currently awaiting a response from marketplace staff regarding this.

In the meantime, if you clone or download the Github repo linked in the original post, and put the whole thing into your project’s Plugins directory, I think you may find that fixes the problem.

I’ve already done so, but this results in:

MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: ERROR: UBT ERROR: Failed to produce item: F:\Projects\UE4\SpaceBossesTD_Fork\Plugins\BTUtilityPlugin\Binaries\Win64\UE4-BTUtilityPlugin.lib
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: Total build time: 99,49 seconds

Hmm, is there no output prior to that, detailing the error?

Can you let me know a bit more about your setup - engine version (I assume 4.10), build config (Development/Shipping and Editor/Game), and how you’re building (it looks like you’re packaging? Do you get this error if you just do a straight build, either UBT command line or within Visual Studio?).

Sorry you’re having problems. If you can give me more info I’ll look into it right away.

I just realized I pushed an update for 4.11 to the Github repo, which would cause the latest version of the source on there to no longer build under 4.10.
If you clone or download this commit here, hopefully that will allow it to build from source with 4.10.

I’m currently looking into whether I can somehow make the binary version work with C++ projects.

Okay so it looks like including the build script with the binary plugin will allow it to work with C++ based projects. I’ve uploaded a new 4.10 zip file to the same location.

Also discovered there may be a packaging issue with the plugin, I’ll look into that tomorrow.

Hi, kamrann. I have problem with build C++ base project yet. Working on 4.11. Can you help me and give some advice please.

I’ve been away for a few months so this got rather forgotten.

Have just now uploaded an update for 4.12, available here.
The recommended way to use the plugin with a launcher build is now to unzip this into your ‘[EngineInstallation]/Engine/Plugins/’ folder (as opposed to your project’s ‘Plugins’ folder). I’ve tested it in this scenario and it will successfully package even with Blueprint-only projects.

There is a simple Blueprint-only example project (also at above location), which now relies on the plugin being installed to the engine as described above.

Full source is still available on Github.

Just wanted to say that you do some really neat work… Lots to learn from your source…!