RTS Demo – 02 – Resource Harvesting

The purpose of this document is to provide explanations and descriptions for how resource harvesting 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 “02_ResourceHarvesting”.

Worker units can harvest resources from designated resource objects. In the RTS demo, the harvestable resources are called ‘Metal’, and are shown as a clump of yellow blocks. A screenshot of a resource object can be seen in figure 1. There is also the ‘Energy’ resource type in the project, but that resource is not harvestable. It is instead generated by Energy Generator structures, and thus warrants no AI implementation.

Figure 1 – A resource GameObject in the RTS demo representing the ‘Metal’ resource. These resources are harvestable by worker units.

Harvest Positioning

When workers decide to harvest from a given resource, the first question is where should they position themselves. Multiple workers may be harvesting from the same resource, and ideally they should assume different positions so as not to push each other around (they’re supposed to be working together). While this is not enforced in this project, workers will assume one of a number of harvest positions, depending on which one is the nearest. Thus, in most cases workers will approach from different angles and thus assume different positions around the resource. Therefore, when resources are enabled, they generate a set number of harvest positions in a circle around themselves, at a given radius.

As workers move towards a resource object, instead of moving to the center of the game object (or some other pivot point), they request the nearest harvest position and move to that location instead. As mentioned, in the RTS demo there is no enforcement of only one worker per harvest position, which could have also been added in. Such an implementation would most likely also require a queuing system, in case no harvest spots are open. The method for requesting a harvest position can be seen in the following:

Harvestable Resources

In order to facilitate easy access to harvest a resource object, a simple Harvest method is part of the IResource definition. The Harvest method returns an integer, denoting how many resources were harvested at that time. The method ensures that the amount of harvested resources is within its limits, and handles the deactivating of itself when it becomes empty. Additionally, since resource objects may block structure grid cells, when emptied it must ensure to free any blocked structure grid cells. It must check all structure grids in the scene and all cells, because it could possibly occupy more than one structure grid cell. The Harvest method is shown here:

Harvesting Workers

Worker units also have a Harvest method, not that it should be confused with IResource’s Harvest method. The worker units have their own Harvest method, called through their AI, which in turn invokes the current resource target’s Harvest method. The unit’s harvesting behaviour works by having a designated resource target. Just as for attack targets or other types of targets, workers can set a resource target based on utility scoring, and then test for e.g. distances to the target, in order to evaluate whether they should move or are close enough already. Workers throttle their harvesting by their attack speed, as technically the act of harvesting is considered an attack on the resource. Additionally, they must be within a harvest radius before they can actually harvest. When they do harvest, there are several things which need coordination. The animator needs to know to play the correct animation, the worker should make sure to face the resource, and then ensure that it doesn’t accidentally carry more resources than it is allowed to, even if that results in wasting some resources. Finally, worker units get a so-called ‘Doodah’, which is a small yellow cube, while carrying resources, to provide visual feedback.

The AI for the harvesting behaviour is relatively simple. First they check whether they have a resource target, if so they are either moving towards it or currently harvesting from it. If the resource target is within range, they should harvest from it, if not, they should move to it. When they cannot carry anymore resources, they should move back to the center and return their gathered harvest. Moving if outside of radius, otherwise returning the harvest and nulling the resource target – so that a new cycle can start over. If they do not have a resource target yet, they should set the highest scoring one if they know of any, otherwise they must wander randomly in order to try to discover resources. A screenshot of the harvesting part of their AI can be seen in figure 2.

Figure 2 – A screenshot of the implemented AI for the harvesting behaviour of worker units. Note this is just a part of the full WorkerUnitAI. They set a resource target if they have none. Otherwise they move to and harvest from their target, until they cannot carry anymore. Then they return their harvest to their Center structure.