Resource Gathering AI in Unreal: How the Gather Loop Is Structured

The architecture behind autonomous gatherer AI in Unreal Engine: three actor components (Gatherer, Resource, Extracted Resource), one Assignment data asset, and a Behavior Tree that sequences the find, extract, carry, drop loop, all server-authoritative.

Most strategy, survival, and base-building games run on the same quiet loop: a worker walks out, harvests something, carries it home, and goes back for more. This guide takes that loop apart in Unreal Engine, one moving part at a time, using the Resource Gathering Minions plugin as the worked example. This first card is the map: what the pieces are and how data flows between them. The cards that follow each open one piece.

The plugin's three core component blueprints in the content browser: BP_Extracted_Resource_Component, BP_Gatherer_Component, and BP_Resource_Component

The loop, in one sentence

A player issues an order, the worker finds the nearest matching resource, walks to it, extracts it over time, a carryable item spawns in its hands, it walks home, drops the item on a growing pile, and repeats. Everything below exists to make that one sentence run, and to make it run the same over the network as it does offline.

Three components and one data asset

The system is deliberately small. Three UActorComponents you drop onto actors, plus one data asset that says what a job is:

  • Gatherer component (UGathererComponent) goes on the worker AI. It is the brain: it begins assignments, finds resources, starts extraction, spawns and attaches the carried item, and drops it. See The Gatherer component.
  • Resource component (UResourceComponent) goes on any harvestable actor. It is a USphereComponent subclass, so it doubles as the overlap trigger and the extraction timer. See The Resource component.
  • Extracted Resource component (UExtractedResourceComponent) goes on the actor that spawns when extraction finishes, the log or rock that travels home and re-enables its collision once dropped. See The carried resource.

The fourth piece is the Assignment Definitions data asset (UAssignmentDefinitionsDataAsset). One entry is one job: a Gameplay Tag the player uses to start it, the resource tag it searches for, the actor it carries, and the Behavior Tree it runs. Because orders and resources match by tag, adding “gather stone” next to “gather wood” is a new entry, not new code. See Assignments and Gameplay Tags.

The plugin content folder with its readme describing the Gatherer, Resource, and Extracted Resource components

The Behavior Tree is the conductor

The components do not call each other in a hard-coded sequence. Instead, each exposes a small BlueprintCallable API, and a Behavior Tree calls that API in order. The tree is a flat sequence:

ROOT -> Sequence
          BTT_Find_Resource_Location   (TryFindClosestResourceActor)
          Go To Resource               (MoveTo ResourceLocation)
          BTT_Try_Extract              (TryBeginExtractingOverlappingActor, wait)
          BTT_Set_Home_Location        (read CharacterHomeLocation)
          Go Home                      (MoveTo HomeLocation)
          BTT_Drop_Extracted_Resource  (DetachExtractedResourceFromCharacter)

The BT_Extract_Resource Behavior Tree: a root and sequence feeding find resource, go to resource, try extract, set home location, go home, and drop extracted resource tasks

This split is the whole design. The C++ owns capabilities (find, extract, carry, drop); the tree owns order. Want the worker to flee when threatened, or to top up its stamina between trips? That is a branch in the tree, not a change to any component. The tree communicates through three Blackboard keys (SelfActor, ResourceLocation, HomeLocation), which the tasks read and write.

Server-authoritative from the start

Look at almost any method in the source and it opens the same way:

if (!GetOwner()->HasAuthority()) return;

Beginning an assignment is a Server, Reliable RPC; extraction runs on a server timer; the carried actor is spawned and owned server-side; and a replicated EGathererState (Idle, Extracting, Carrying) flows down to clients so each one can drive its animation from it. The gameplay only ever happens on the server, so single player and multiplayer are the same code path. The price of that guarantee is one rule, ownership, which the multiplayer card is entirely about.

Where to go next

If you would rather drop the whole system in than build it, the Resource Gathering Minions plugin packages every piece in this guide, replicated and multiplayer-ready, with a demo project. This whole tour starts at Resource Gathering AI in Unreal Engine.

Frequently asked questions

What are the three components in a resource gathering system?
The Gatherer component goes on the worker AI and runs the loop. The Resource component goes on harvestable actors (a tree, a rock) and times their extraction. The Extracted Resource component goes on the actor that spawns and is carried home. A separate Assignment data asset ties an order tag to the resource, the carried actor, and the Behavior Tree.
What drives the gather loop?
A Behavior Tree. The components expose a Blueprint-callable API (find the closest resource, begin extraction, spawn and attach the carried actor, drop it), and the Behavior Tree's tasks call that API in order: find, walk, extract, set home, walk home, drop. Swapping the loop's behavior is swapping the tree.
Does the loop run on the server or the client?
The server. Almost every method begins with a HasAuthority() check, beginning an assignment is a server RPC, and the gather state replicates down to clients to drive animation. The visual result appears identically in single player and multiplayer because the logic only ever runs in one place.