If it comes down to behavior trees many developers think of AI, robotics, or NPCs. I started to use behavior trees to make my stupid soldier NPCs patrol and shoot. They are still very stupid and sometimes shoot each other. I realized that I can use behavior trees for more than just my NPCs.
For example for my weapons. It’s actually so much fun to design and model weapons, not only from the visual representation but also in how it behaves and how it feels to use it.
Note that…
this blog article doesn’t want to explain behavior trees in all lengths and depths. There are many blogs and articles available which do a great job explaining behavior trees. Furthermore, you will probably also need to read the documentation for your behavior tree implementation at hand.
Here a small selection of links:
It starts always simple
When I first introduced my weapons to my platformer "All Fucked Up", I did it the classical way by simply programing them. It started simple with a weapon which eject a shell, launch a bullet, place a flash light and make a boom sound. Even when I modeled a submachine gun it was simple. I thougt well how messy can that possible go. And then a double barrel shot gun came along the way and everything started to get messy.
After two shots the shotgun should eject two shells, not imediately but with a small delay. As well I wanted to limit the rounds per minute. I managed to do this and ended up with the following code:
public void shoot(double tpf, Vec3d location, Quatd orientation) {
time += tpf;
if (pull) {
if (cartridge > 0 && time > 0.25) {
cartridge -= 1;
time = 0;
launchProjectile(orientation, location);
if (cartridge <= 0) {
eject = true;
ejectTime = 0;
}
}
if (time > 2.5) {
cartridge = 2;
}
}
if (eject && ejectTime < 0.6) {
ejectTime += tpf;
} else if (eject) {
eject = false;
ejectShell(orientation, location);
}
}
It doesn’t look too bad to be honest, if you carefully read it you will get your head around it. But you probably also see the problem with this approach. Just think of extending it with a limited amount of ammo you collected. A force-reload, where you want to reload the weapon even if you didn’t shoot all ammo. It was no fun to try to extend it.
There must be an alternative to this messy code, which is hard to maintain, extend, or adapt. I tried to refactor it in breaking it down to smaller and simpler pieces. The main problem remained, it was still hard to extend or adapt.*
The weapons do have behavior and why not use a behavior tree implementation as a way out. It was one of the best decision I made for this game.
A very short story about behavior trees
I use the behavior tree implementation from libgdx-ai.
We have tasks, sequences, selectors, and parallels. In this article, I don’t need parallels.
I just describe very short what the single parts do.
Task
A task can either fail, succeed or stay running. A task in the state running, will be reentered on the next execution of the behavior tree.
Sequence
A sequence is a special task that runs each of its child tasks in turn. It will fail immediately when one of its children fails. As long as its children succeed, it will keep going. If it runs out of children, it will succeed.
Selector
A selector is a special task that runs each of its child tasks in turn. It will succeed when one of its children succeed. As long as its children are failing, it will keep on trying the next child. If it runs out of children completely, it will fail.
Ok then let us use this behavior tree
On the top level of the behavior tree we have a sequence with two tasks, the first one will reload the gun if needed and if possible, the second task will shoot if the trigger is pulled and there is at least one round chambered.
Let’s look at how we model the "need reload" task. Probably not the best naming. The reload task consist of a selector with two child tasks. The first task checks if the ammo count of the gun is bigger than zero. The second task does a delayed reload of the gun and fails if the player does not have any shotgun rounds left else it succeeds. The check if it really can reload is done in the reload task.
Shooting is basically a sequence of tasks. First, we check if the trigger is pulled and fail if not. If the trigger is pulled we launch the projectiles, this task does always succeed. After that, we wait until the trigger gets released to have a controlled shooting. After we release the trigger we check if there is still life ammo chambered and fail if so. In the case there is no life ammo anymore we wait a fraction of a second and eject two shells and succeed.
As you can see the shoot task also returns with fail or succeed this is important and has to be considered if you want to proceed after the shooting task with an additional task whatever this might be…
And here the complete behavior tree
Looks cool. The code of this behavior tree looks like this
this.bb = new WeaponBlackboard(main, this);
Sequence<WeaponBlackboard> reloading = new Sequence<>();
reloading.addChild(new Wait(1.4f));
reloading.addChild(new Reload());
Selector<WeaponBlackboard> needReload = new Selector<>();
needReload.addChild(new AmmoCount());
needReload.addChild(reloading);
Sequence<WeaponBlackboard> shoot = new Sequence<>();
shoot.addChild(new DetectPullTrigger());
shoot.addChild(new LaunchProjectile());
shoot.addChild(new WaitUntilSuccess<>(new Invert(new DetectPullTrigger())));
shoot.addChild(new Invert<>(new AmmoCount()));
shoot.addChild(new Wait<>(0.6f));
shoot.addChild(new EjectShell());
Sequence<WeaponBlackboard> gun = new Sequence<>();
gun.addChild(needReload);
gun.addChild(shoot);
this.bh = new BehaviorTree<>(gun, bb);
And in the update loop you call something like
bh.next()
It is so much easier to change the behavior or to adapt it. And a new weapon is done literally in no time. Even if I don’t use a graphical editor. It’s so much fun to model weapons with this approach.
Tasks and reusable code
Because we have capsulated the stuff into tasks, we can reuse these tasks for new weapons. Like DetectPullTrigger(), LaunchProjectile(), AmmoCount() and EjectShell(). And also very generic tasks and decorators like Wait(seconds), WaitUnitlSucceed(task), AlwaysSucceed(task) and Invert(task).
For our own tasks, we can handover a weapon blackboard where we keep together everything we need. The weapon itself implements an interface with the basic actions, like launch bullets, eject shells and reloading as this is very weapon specific.
So let’s conclude
The main message of this blog article is not the solution for the double-barrel shotgun. The main message is that you can use behavior trees beyond NPC AI. Whatever has a behavior can be modeled with a behavior tree even if it is not too obvious in the beginning. If you have a graphical behavior tree editor your game designers can model that part of the game directly and have instant feedback if their ideas work out or not.
I also model my controller and the level switching logic with a behavior tree approach. These parts are much easier to adapt and to extend now. It’s also very handy as you simply can try out all your weird ideas without a lot of coding. What makes it really really fun.
The end
That’s it, I hope you enjoyed it.
