Best Practices When Designing
These are the habits that make behaviour authoring go smoothly. None of them are enforced by the tool, but working against them tends to produce trees that are hard to debug.
Build small test scenes
To speed up iteration, develop specific scenes that isolate the loop you are working on. These should have the bare minimum objects required for the flow you are developing: a house, a workplace, the items needed, and a baked NavMesh.
This makes problems quick to spot, and gives you a solid base to build on when you move the behaviour into a more complex scene.
The ExampleBehaviourRepositoryOverride component lets a test scene select its own behaviour repositories without changing Module Settings, so you can keep a test scene and a main scene side by side. See Example Scenes.
Name things after what they do
Jobs, duties and actions all show up in the tree editor by name. A duty called Collect Wood is far easier to follow six months later than one called Duty 3, and the editor gives you no other clue about intent.
Methods should achieve the same state for the agent
When creating more than one method it is good to be aware that the system expects the agent to achieve the same state to be used effectively. This means if you have a method which is meant to find a specific item within the scene, if you have another method for that parent node it should get the same specific item or equivalent but by different means. This could mean instead of using the work supply they use their own supply, or they travel to buy it from somewhere. In each of the scenarios mentioned the end result is the same but just achieved by different means.
This matters because when a method is exhausted the system moves to the next method of that duty. If the methods leave the agent in different states, the follow-on actions become unpredictable depending on which method happened to succeed.
Change one thing at a time
Behaviour trees fail in ways that look alike from the outside — an agent standing still could be a missing NavMesh, a role that matches no job, an item with no POI, or a condition that never passes. Changing one node between test runs keeps the cause obvious.
Common Issues lists the usual suspects.
Next step
Continue to Using the Behaviour Tree Editor.