RTS Demo – 06 – Group Movement

The purpose of this document is to provide explanations and descriptions for how unit group movement was handled in the Apex Utility AI RTS (Real-Time Strategy) Demo project. It is a part of a series of use-cases showcased through the demo project. If you haven’t already, we recommend reading the High Level Overview Document first. The scene associated with this document is called “06_GroupMove”.

When the Controller chooses to collect units in a group and issue an order to them as a group, they should also attempt to move as a group. This means that units should wait for each other to move as a group. Additionally, units that are far away from the group need to move directly to the group, while the others wait. As they get within reach, they can stop moving again. This can be seen in figure 1.

Figure 1 – A screenshot of the implemented AI for units to act as groups. Please note that this is just a small part of the complete unit AI.

Group Position

There are multiple ways to define a group’s position. The perhaps most intuitive would be to define the center of the group as the position – that is, the ‘average’ of all the group’s units’ positions. However, the challenge with such a center, a center of gravity, is that all units contribute to it, and it is constantly shifting and moving around. This means that it is not a ‘consistent’ point that other units can rely on and move to in a robust way. It can work fine for certain evaluations, e.g. is the group ‘as a whole’ within a range threshold? However, for gathering the group, another position property was implemented, simply utilizing the 0th unit’s position as a proxy for the group’s position. This position is reliable and consistent. The 0th unit will simply stay where it is, and other units will see the 0th unit’s location as the group’s position. The code for the property can be found in the below code snippet:

Going Backwards

As can be seen from the screenshot in figure 1, if a unit is away from the group and not in movement, the unit should go to the group’s position, as mentioned defined as the group’s 0th unit’s position. This means that in some cases, a unit may be in front of the 0th unit, possibly a lot in front. In order to have a simple mechanism for gathering the group, such units will move backwards towards the group position, in order to stay collected with the other group members.

This also applies to straggling units that may have gotten off course due to e.g. spontaneous combat, or even being stuck in geometry or congested areas. When units evaluate whether their group is gathered, they compare the position of each member to the center of gravity. If all members are within a certain threshold, the group is considered to be gathered, and all units can progress forward to the next waypoint. The AI scorer for this can be seen in the following code snippet:

Unit Waypoints

The way that group movement is implemented in the RTS demo project is quite simple. Each unit has a list of waypoints that it will move through, as long as the group is gathered at each waypoint. This means that when units receive an group order involving attacking movement, they also get an attack point, an attack target and possibly one or more staging points, which are basically waypoints prior to the attack point, which is considered the ‘final point of entry’ for attacking. Thus, the Controller figures out the optimal attack target and points and passes these to the group through the issued order. Thus, each unit evaluates the received order and stores a queue of waypoints in its Context object for each staging point, attack point and finally for the attack target. This structure facilitates that each unit evaluates its progress along the way to combat, while still attempting to move as a group. A part of the AI action for this can be seen in the below snippet, where ‘o’ is an instance of an ‘OffensiveGroupOrderBase’:

Visualization and Debugging

The specific visualization for group purposes is limited in the current implementation of the RTS demo. The group model is very simple and thus not very error prone. Nonetheless, visualization for the sake of debugging should always be considered.

In the demo project, the Controller’s visualizer shows the current group count, as well as how many units are in the default group at any given point in time. Select a Controller to see this in the visualizer’s inspector.

Units use gizmos to draw lines to show their waypoints and move target. The move target is the current position they are moving towards and is by default shown with a blue colored line from the unit’s position to the move target position. The waypoints extend from the move target to the last waypoint, and are by default drawn in yellow color. Finally, the attack target is also gizmo drawn with lines, by default in red color. A screenshot of this can be seen in figure 2.

Figure 2 – This screenshot shows a group of units moving towards their individual move targets, located at the same, blue wiresphere. The yellow lines show the way to the subsequent waypoints, which there may be multiple of (hence the yellow diagonal line comes after the horizontal one).