Quick Development Practices
Common Issues tells you what to check when something is broken. This page is about not getting stuck in the first place.
Work in a small scene
The single biggest speed-up. A scene containing one house, one workplace, the items involved and a baked NavMesh loads instantly, and there is only one agent to watch.
Behaviour bugs in a busy town are hard to see because ten agents are doing ten things. In a one-agent scene, a stall is obvious.
Use ExampleBehaviourRepositoryOverride so your test scene can select its own behaviour repositories without you editing Module Settings each time you switch scenes. See Example Scenes.
Watch the agent, not the console
Select an agent in the Hierarchy while in play mode. The inspector shows the current behaviour, action and target, which answers most "why is it doing that" questions directly.
The useful sequence when an agent stalls:
- Which behaviour is active? If it is the wrong one, the problem is weighting, not the action.
- Which action is it on? If the action is null or unexpected, the tree is not resolving.
- What is the target? A null target usually means no item matched the search.
- Is it moving? If it has a target and is not moving, it is navigation.
Use the Getting Started window
BardTreeLtd/Civil AI/Help/Getting Started
This tracks what is actually in your open scene and tells you what is missing. It is faster than working through a checklist by hand, and it updates as you fix things.
Regenerate rather than repair
Example scenes are cheap to recreate. If you have broken one experimenting, BardTreeLtd/Civil AI/Examples/Create Example Scene will rebuild it from scratch rather than you unpicking what you changed.
This is worth mirroring in your own work: keep a known-good test scene you never edit, and copy it when you want to try something.
Change one thing at a time
Several different problems produce an agent standing still — no NavMesh, a role matching no job, an item with no POI, a condition that never passes. Changing one node between runs keeps the cause unambiguous.
Check colliders early
A surprising share of setup problems are collider problems:
- Buildings need colliders for valid bounds.
- Population regions need colliders to define their area — and if the collider is offset from its object, the region uses the collider's actual position.
- Ground needs a collider or the NavMesh bake produces nothing.
Watch performance while you build, not after
Add FpsTracker to a scene you are scaling up. Finding out that a population size is unaffordable while you are still designing is much cheaper than finding out at the end.
See Performance Intro for what to change.
Next step
Common Issues for specific symptoms, or Best Practices When Designing for behaviour authoring habits.