Hierarchical Task Network Planning

Hierarchical Task Network Planning

This plugin adds HTN planning functionality as an alternative to Behavior Trees.

Traditional AI techniques like state machines or behavior trees make decisions on the fly with little to no foresight. An AI based on Hierarchical Task Networks predicts consequences of its actions and plans ahead. Here’s a short video of an HTN-based character inventing the optimal plan to attack a target.

Compared to other planning techniques like Goal-Oriented Action Planning, HTN planning is more efficient and gives designers much more control over character behavior. Instead of just providing the AI with a set of actions, you create networks of tasks defining dependencies between them.

In order to predict consequences of actions, HTN planners represent hypothetical futures using worldstates. The plugin efficiently uses blackboard data for that. Because of this worldstates are very flexible and can be easily interacted with by nodes in C++ and Blueprints.

Those familiar with Behavior Trees in Unreal Engine 4 will recognize familiar elements like Tasks, Decorators, and Services, but with planning functionality on top of the usual execution-time behavior. It’s just as easy to create custom Tasks, Decorators, and Services for HTN as it is for Behavior Trees, both in C++ and Blueprints.

The plugin seamlessly integrates with the Environment Query System and the Visual Logger, allowing for tactical planning and visualizing the current plan of any character.


  • Node-based HTN graph editor
  • Seamlessly using blackboard data as worldstate
  • Ability to make custom Tasks, Decorators, and Services in both C++ and Blueprints
  • Parallel planning
  • Any-order planning
  • Integration with the Visual Logger
  • Integration with the Environment Query System
  • Realtime debugging features


  1. Basic setup & Introduction
  2. Gun & Ammo

Purchase on the Marketplace

Official website

Example project

Very interested in this.

My concern with using a HTN planner is similar to my issues with BT’s - how dynamic can they be?

Is this something you’ve addressed at all?

Thank you.

What do you mean by “dynamic”?

If you mean how adaptive they can be to changing conditions, there’s a system of plan rechecking that makes sure the plan is always valid for the current situation.
Services and decorators on if nodes can also trigger replanning.

By dynamic, I mean adding new nodes/tasks/what have you during runtime.
For example, adding sniping behaviour when an AI acquires a rifle with an optic.

The easiest way to achieve that is to have a part of your task network locked behind a condition check.
You example can be easily done by putting a “Has Rifle With Optics?” decorator on the first task of sniping-related behavior.
Or, even better, have a separate HTN for the sniping behavior, include that HTN as a compound task in the main HTN, and put said decorator on the compound task.

Of course in this case the sniper behavior node(s) would need to be part of the asset before runtime.
For future updates, I’m considering introducing an HTN analogue to the BTRunBehaviorDynamic node which would let you change the sub-HTN of a compound task at runtime, allowing to add/remove specific behaviors at runtime.

Tutorial 2 – Gun & Ammo

The second tutorial video is now out here

It covers creating an AI behavior that can find a gun and ammo in the level and use them.