The Route System
From Bots-United Wiki
THE ROUTE SYSTEM
Contents[hide] |
Why routes?
Suppose that a team is assaulting a fortress wall and the engineers must blow a hole in it for their forces to get through. You've made a path from spawn to the dynamite site but, alas, the engineers keep getting killed by the defenders up on the fortress walls. So you create a safer path for the engineers that passes close along the wall out of sight of the defenders. But they won't use it because a bot always takes the shortest ... To direct the engineers to take this alternate route, you need to set up a route. A route node specifies the action that it leads to and an "alternate_roam" action that you place along your longer path to mark it. Basically what happens is that the bot first travels to the alt_roam and from there goes to his objective. Routes are generally used for the offensive team; for the defense you usually want the team members to take the fastest, most direct way to their positions. If there is only one way to get to an objective, you don't need a route.
Route specifics
You can specify up to six alternate paths to get to an action and you can have up to six actions that can be handled by a single route node. The specific action and path that the bot takes is randomly selected. There are complications for actions that are not high-priority objectives and will be discussed later in #Cautions. Unless mentioned specifically, the following discussion applies only to high-priority actions such as dynamite plants, major constructs, steal, and deliver objectives.
You must use separate route nodes for Axis and Allied teams, although alt_roams can be used by both teams. Some route actions are class-specific: routes linked to dynamite and construct actions apply only to engineers, while routes linked to steal and deliver actions will be used by all classes. In order for a bot to use a route, the objective action it references must be active and it must apply to the bot class. The paths defined by the alt_roams must be complete and at least one of the alt_roams must be active. Once an alt_roam is made active via the Goal Tracker or the aiscript, it remains so unless turned off in the script (i.e., it's "active forever"). Routes cannot be turned on or off in the aiscript. Route paths are mandatory for the bots -- that means that if a bot chooses an action that is linked to a route, he MUST choose one of the alt_roams given. If you want him to occasionally take the shortest path, you'll have to put an alt_roam on it.
How a bot chooses a goal
A bot chooses a new goal at spawn and whenever he completes his current action. He runs to a roam. then goes to a camp, stays there for a random time, then runs down the hill to an MG42 emplacement, then goes on to another roam, and so on. After each action he looks through the list of active actions and determines which ones apply to him. Then he checks for high-priority actions (dynamite, major constructs, steal, and deliver) and if one is present he selects it; if more than one exists, he randomly chooses between them. A vehicle is considered a high-priority goal and may be choosen by the bot instead of an action; however, it is not possible to route to a vehicle. If no high-priority objectives exist, he makes a random choice from among the regular actions (roams, camps, minor constructs, etc.).
Having chosen an action, he looks to see if he's inside the radius of a route having that action as its target. If so, he randomly picks one of the route's alt_roams as his destination and, goes there by the shortest way. Once he reaches the alt_roam, he then takes the shortest way from there to his objective. If no route exists, he simply takes the shortest path to his objective. Sound familiar?
Where to place routes
Route nodes are most commonly located at spawn areas. If a team spawns at more than one point, you'll need comparable routes at each spawn area. The usual route at a spawn point will be one directing the bots to a steal objective or the engineers to a dynamite_plant. Suppose the security door blocking access to the secret documents is finally blown by the engineers and the aiscript activates the map-steal action. Suddenly a high-priority goal is available: the newly spawning bots see it and follow your alternate paths to the document room. But what about the bots that are still alive in the field? They normally would take the shortest route to the documents when they complete their current goals, but if you want them to take a less direct path to the documents, you can place another route in battlefield. This route would need a large radius to cover the area where the bots are spread out.
On some maps, it is possible for engineers to attack either side of a dynamite goal, such as a door or gate. In those cases, you'll likely have linked dynamite actions placed on each side of the door. Be aware that if you route to these actions, you'll need a separate route for each action.
Another usual route location is at the document-steal site itself. When the documents are taken by the lucky bot, your aiscript turns on the delivery action and turns off the steal action. The bot selects the high-priority delivery action as his goal, sees the route for that action and chooses one of your alt_roams directing him how to get to the delivery point. All the other bots on his team will take the shortest way to the supporting actions you have set up for the document delivery. Unless, of course, you create a special route linked to those actions.
Another likely spot for a route is at an alt_roam of a main route node. See #Daisy-chaining routes below for an explanation of this option.
And, of course, you can place a route at ANY action and it will be used to guide the bot when he has completed that action.
Choosing the radius
A spawn-area route must cover the entire area where the bots emerge from limbo. The best way to ascertain what size of radius is necessary is to load the largest team you expect to have (such as 16 bots), allow them to spawn and immediately pause them (/bot_pause 1), and see where they stand. Then locate your route node in the center of the bots, turn on the radius view (/drawradius), and observe the extent of the radial lines as you alter their value (/route_radius <value>). Make sure all the bots are completely covered. Use a similar procedure for other route placements.
Remember that the radius shown by the /drawradius command is a 2-dimensional representation of a 3-dimensional sphere. If you place a route too high in the air, its influence will cover a smaller area on the ground. Note also that a route's radius will penetrate walls, hills, and any other obstructions. You do not want a route to overlap another route that is linked to the same set of actions or you'll get unexpected results.
Deleting routes
As is the case with path nodes and action nodes, once a route has been entered into the waypoint database it cannot be deleted. To disable a route, set all its linked actions to -1 (/route_actions <routeNumber> -1) and set its team to -1 also (/route_team <routeNumber> -1). It helps to move the route to a far-off location to avoid confusion with other valid routes in the area.
Where to place the alt_roam action
Alternate_roam placement is very critical to the proper functioning of a route. If you want a bot to take a longer way to his goal, you need to have the alt_roam placed in such a way that when the bot arrives there, the shortest way to the goal is the path that you want him to take. Referring to the figure, the bot starts at point A (where the route node is located) and you want him to travel to point E using the longer route ABCDE. Where do you place the alt_roam?CASE 1: if the alt_roam is placed too close to the start, say at point B, the bot will first go directly to B (the shortest distance) and then it calculates that the shortest way to reach the goal at E is to backtrack to A and take the direct path to E. A little math will give us the minimum distance that B must be from A to ensure that the bot goes the long way instead:
We want distance BCDE to be less than distance BAE:
which converts to:
solving for AB:
dividing by the long path ABCDE to get ratios,
To determine where to place the alt_roam, we need to know the relative distances. For instance, if the desired path is twice as long as the short path, we find using the equation that the alt_roam must be placed no closer to the start than 1/4 the length of the long path:
Thus, using our previous example for a 2:1 ratio in distances, you must place the alt_roam no closer to the end than 1/4 the length of the long path and no closer to the start by the same distance. If the path distances are more nearly equal there is considerably more latitude in alt_roam placement. If there is a large unbalance in the lengths of the two distances, the alt_roam must be put almost exactly in the center of the long path. These restrictions can make it difficult to get exactly the path that you want the bots to follow. A less restrictive way to create multi-branched routes is described below in #Daisy-chaining routes.
To get an estimate of the distances, run over the paths yourself and time how long it takes to travel each path. Assume the times are proportional to the actual distances. Or take the EASY way: adjust the position of the alt_roam until the bot follows the route properly!
If the bots behave like an alt_roam is too close to the start and when it is moved they suddenly behave like it is now too close to the end, there is almost certainly a break in the path somewhere. Look for unconnected nodes, one-way paths, and team-specific nodes. A rarer situation is when two path nodes have been accidentally placed on top of each other and the incoming path is connected to one of them and the outgoing path is connected to the other. Even though the nodes occupy the same physical location, they are not recognized as connected by the bots.
How to stack the odds
Since a bot chooses from among a route's alt_roam paths randomly, all paths have an equal chance of being picked. But suppose one of the paths is safer than the others and you want the bots to take it more often. Simply add more instances of the desired alt_roam to the route's pathactions parameter. For example, route 9 has alt_roams 1, 2, 3 and you want alt_roam 3 to be used 50% of the time. Just add an extra 3 to the route's alt_roam list: /route_pathactions 9 1 2 3 3. Slick, heh? Want it to be selected 2 times out of 3? Change it to /route_pathactions 9 1 2 3 3 3 3. Obviously, you can use this trick only when some of the pathactions slots are empty.
Daisy-chaining routes
Some maps have layouts that make it difficult to achieve the routes we desire. The shortest distance to the first alt_roam might not be good enough to get the bot to travel the entire path to the goal because of further path branches along the way. "Daisy-chaining" routes is a method used to increase the flexibility of the route system. This only works for high-priority actions due to way the bots reselect their goals when they complete an action. Beginning with an initial route node (the master route), secondary route nodes are placed at the alt_roam actions of the master. These secondary routes have their own paths leading to further alt_roams and so on, allowing unlimited branching to be accomplished. This works very well for moving bots to a steal objective and helping with their escape. The more alternate paths to reach a goal the better, because the more unpredictable you are the less chance the opposing team will stop you. Remember you're not very inconspicuous with that big green balloon and exclamation point stuck to your head! An example of the escape routing in Caen2 will show how it is done. In the drawing, gray circles are the route nodes, green dots are the alt_roams, and red dots are the goals.
The Axis must take the maps located in the Allied HQ at the top of the map and deliver them to a boat on the river. When an Axis bot takes the maps, the aiscript activates delivery action #12 in the escape boat, and he chooses it for his goal because it's the highest-priority action available. The master route (#8) is placed right at the map location, so as soon as the bot selects the delivery action he must take his instructions from the route node. The master route's action is set to #12 and three possible escape paths are offered for our bot to choose from:
- Out the door to the east (alt_roam #132)
- Climb the roof to the north (alt_roam #133)
- Through the hole in the west wall (alt_roam #134).
Path 3 is the most dangerous because it's near the Allied spawn and was where all the fighting with around tank took place to open up the Allied HQ. We decide that we don't want the bot to go that way as often as we would like him to take the east-door route, so we increase the chances of using the door to 50%,dropping that of the roof and west paths to 25% each.
When he arrives at alt_roam #132, he encounters route #11 (also with action #12 as its target), giving him two possible ways to continue:
- Down the stairs to alt_roam #134
- Through the covered hall to alt_roam #114.
As before, the west path is dangerous, so we increase the chances to 80% that he'll go to #114. Since he will choose #132 50% of the time at the map room, the actual odds that he'll go to #114 from here is 40% (80% of 50) and is 10% to #134 (20% of 50).
We have also a route on the roof at alt_roam #133, directing our bot to go directly to alt_roam #114. Combined with the odds from #132, there is a 65% chance that he'll head for #114. At alt_roam #114, guess what? Another daisy-chained route, further splitting the path, and so on, as you can see from the figure.
Daisy-chaining greatly enhances the route system, making it possible to send your bots wherever you like on a map using the shortest distance trait to best advantage. In this example we have provided 5 different ways for our bot to get to the boat. There is an ample number of route nodes available in ET (64 compared to 12 in RTCW), so you shouldn't run out!
Bots getting lost
You create a sneaky path through a convoluted vent system to get into the room where the secret documents are located. To test your route, you link it to only the alt_roam in the vents, giving the bots no choice but to go there. A squad of eight bots starts on its way and you run ahead of them and wait at the alt_roam to make sure that they go the right way. Here they come, one, two, ... six. Oops, two of them didn't show up! You track them down and find them taking a different path to the documents. What happened? How did they get lost? A route path is mandatory, isn't it?
The common cause of lost bots is an obstruction somewhere along the way. Take Foo Fighter for example: the entrance to the vents is up a short ladder where the bots have to crouch to get into the vent system. When a group of bots arrives, the first bots have to slow down to get in and the following bots (who don't know about forming a line) begin jumping and bouncing around, all trying to force their way into the vents at the same time. When a bot gets stalled at such an obstruction, he'll persist trying for a random length of time before abandoning that path and finding another way to get to his goal. So you may get some bots taking unexpected paths to the objective.
To keep this from happening, place a route node at the obstruction, using the same action and same alt_roam as the original route. When a bot gets frustrated and tries to choose another path, he is confronted by this route giving him no option but to continue with the current alt_roam. So he'll keep trying until the way is clear and he can continue into the vents. This can happen at narrow doorways as well -- anywhere there may be traffic congestion.
Cautions
As discussed in #How a bot chooses a goal, each bot selects a new goal when he completes his current action. Unfortunately, this applies to alt_roams also. If the bot's goal is a single, high-priority objective, he'll always choose it again when he reaches the alt_roam and there'll be no switching of goals. But if he's heading for a normal run-of-the-mill action, there's no guarantee that he'll choose it again at the alt_roam. In fact, the odds are that he will not. If your route is set up to lead him to a camp and when he reaches the alt_roam he chooses a different action on the other side of the map, he'll NOT go to the camp where you intended for him to go.
Perhaps the best use of routes for normal actions is when you want the bots to travel given paths to get to a group of closely-spaced actions and there are no other active actions elsewhere. Suppose that the offensive team's goal is to steal a set of codes and deliver them to a transmitter. You have set up defensive actions around the transmitter to hold off the opposing team while the guy with the codes makes his way there. However, you don't know which way he'll go to get the transmitter; he could take any of the alt_roam paths you have provided for the delivery route. If you create a large-radius route for those transmitter actions and use the same alt_roams as the delivery route, then there's a chance that some of the team will escort the map carrier to the transmitter, whichever way he chooses to go. It's not important which actions they choose at the alt_roams because they're all near each other at the transmitter area.
Test, test, test
Clearly, there are a number of ways that your routes can go awry, so it is important to test them to confirm that they operate as expected. Each and every route node and alt_roam must be tested -- don't skip over this! If your steal route offers multiple alt_roam paths to the objective, temporarily change the route pathactions to just one of the alt_roams. Then put yourself into the game alone (no bots to interfere with you) and play to set up the conditions for the route to work. You may have to repair a tank, drive it to the bank, and blow the doors to the bank before the gold is ready for the taking. Then start one bot and follow him around to make sure that he follows the route to the gold. Do this for each of the alt_roams linked to the route. If all works well, fine. If not, analyze what went wrong, fix it, and test again until you have it right. Each time when you make a change to the map, you must save the nav (/node_save) and restart the map from the beginning (/map_restart). This can get tedious, especially if the route you're working on doesn't get used until near the end of the game. Persist!