Example of NextBot Behaviors

From Valve Developer Community
Jump to: navigation, search

The NextBot AI system uses an "Intention" factor to choose the "Behavior" of an AI-controlled actor, which in turn runs a series of "Actions" for the actor to perform.

This page is meant to show a visual representation of how the Intention factor works in-game, as we look at a round of Team Fortress 2 with nothing but bots. The example map we will work with is koth_badlands; a map with a single "control point" in the center which the bots will attempt to capture and defend.

The nb_debug console command is what's used to actually see what events, behaviors and actions the bot has in mind. For this example round, we will use nb_debug BEHAVIOR.

Capturing the point

The behavior of a Soldier bot, as shown with nb_debug BEHAVIOR.
As the round begins, this red Soldier bot has already chosen its behavior and actions. Let's take a closer look as to what these actions actually are:


This is the root of the bot's actions, as all child actions are stored within this one action.


This handles what the bot actually wants to do. In this example, the TacticalMonitor is telling the Soldier bot to look at its ScenarioMonitor.


This handles how a bot manages certain situations regarding either its class or the map's gamemode. In this example, the ScenarioMonitor is telling the Soldier bot to CapturePoint. ScenarioMonitor examples for specific classes can be found below.


This the actual AI code the Soldier bot needs to be doing. In this example, the CapturePoint is telling the Soldier bot to move towards and capture the central control point.

With these actions in mind, the Soldier bot's current thinking process is MainAction > TacticalMonitor > ScenarioMonitor > CapturePoint.

Defending the point

The Scout bot's "DefendPoint" action leads to a child "BlockCapture" action.
Let's say that the Soldier bot managed to successfully capture the point. Now what would the process look like?
The Soldier bot's "TacticalMonitor" is now telling it to "RetreatToCover".

Surprisingly, only one action changes. The previous CapturePoint action has been replaced with DefendPoint, which is simply telling the Soldier bot to defend the point it just captured. The Soldier bot's thinking process is now MainAction > TacticalMonitor > ScenarioMonitor > DefendPoint.


Unfortunately, while the Soldier bot wasn't paying attention, a pesky blue Scout bot managed to reach the point and capture it. Now the red Soldier bot needs to CapturePoint once more, but the Scout bot is interfering with its action. Once the two bots see each other, both of their actions change.

Scout's actions

Let's take a look at the Scout bot's actions first. Before it saw the enemy bot, the Scout's thinking process was MainAction > TacticalMonitor > ScenarioMonitor > DefendPoint. Now that the two bots have seen each other, the Scout bot needs to make sure that the Soldier bot doesn't capture its point. With this scenario in mind, the Scout bot's DefendPoint action initializes a new child action called BlockCapture, which will tell the Scout bot to move to its point so that it will stop the Soldier bot from capturing. The Scout bot's current thinking process is now MainAction > TacticalMonitor > ScenarioMonitor > DefendPoint > BlockCapture.

Soldier's actions

The Soldier bot needs to CapturePoint, but it isn't going to just leap blindly into battle. For once, the Soldier's TacticalMonitor has changed, telling it to RetreatToCover. Because of this new child action, the Soldier bot is forced to retreat until the Scout bot is either dead or nowhere nearby. Once the Scout bot is no longer a threat, the Soldier bot will return to its initial CapturePoint action. The Soldier bot's thinking process for this scenario is MainAction > TacticalMonitor > RetreatToCover.


During its fight with the Scout bot, the Soldier bot has accidentally killed both itself and the Scout bot by shooting a rocket at point-blank. Both bots run a Dead action, which prevents them from doing anything until they have respawned. The thinking process for both bots is simply Dead.

Class-specific actions

The Engineer bot's "ScenarioMonitor" is "EngineerBuild" instead of "CapturePoint". The bot's objective is "EngineerMoveToBuild".
As mentioned earlier, the ScenarioMonitor manages both the bot's class and the gamemode the map is on. Let's take a look at what some different classes have for their ScenarioMonitor.
The Spy bot's objective is "SpyInfiltrate". Since it has seen the Engineer bot, its now ready to "SpyAttack".


This red Engineer bot is not interested in CapturePoint, unlike the Soldier bot. Instead, the Engineer wants to EngineerBuild in order to defend the point. Having chosen a location to build its contraptions, the Engineer bot's EngineerBuild action initializes a child action called EngineerMoveToBuild. This new child action tells the Engineer bot to move to wherever it wants to build; in this case the location is right next to the control point. The Engineer bot's thinking process is MainAction > TacticalMonitor > ScenarioMonitor > EngineerBuild > EngineerMoveToBuild.


A blue Sniper bot has joined the battle, and like the Engineer, it isn't interested in CapturePoint. The Sniper bot's ScenarioMonitor is instead telling it to SniperLurk, in which the Sniper bot goes hunting for certain sniper spots. The Sniper bot's thinking process is MainAction > TacticalMonitor > ScenarioMonitor > SniperLurk.


Like the Engineer and Sniper bots, the blue Spy bot isn't looking for a point to capture. With SpyInfiltrate, the Spy bot is wandering into the enemy base in hopes that there is something it can do. Once it finds the enemy Engineer bot, the Spy bot prepares itself for a backstab by initializing a child action called SpyAttack. The Spy bot's thinking process is MainAction > TacticalMonitor > ScenarioMonitor > SpyInfiltrate > SpyAttack.

See also