A Blueprint-only RTS prototype exploring top-down camera systems, spatial resource queries, and autonomous worker behavior.
This project is a resource-gathering simulation built entirely in Blueprints with Unreal Engine 5.1. It was developed following this Udemy course as an introduction to top-down game architecture and agent-driven gameplay loops — the kind of systems that sit at the foundation of strategy and city-builder games.
You can watch the prototype in action here: YouTube
Top-Down Camera System
One of the first architectural decisions was how to handle camera control in a top-down context. Rather than attaching the camera directly to a character pawn, the camera is mounted on a dedicated actor that responds to player input independently — allowing panning, rotation, and zoom without coupling movement to a character’s locomotion system. This separation of concerns makes the camera behavior predictable and easy to tune without side effects on other systems.
Resource Types and the Building Placement Model
The game defines two resource types — wood and stone — each tied to a specific visual representation in the world: trees for wood, large rock formations for stone. Rather than hardcoding resource associations, each gathering building carries its own resource type definition, which drives both what it searches for and what it produces. This means adding a new resource type in the future is a matter of configuration, not restructuring.
Buildings are placed by the player at runtime with a cost in wood and stone, enforcing an economic constraint that creates meaningful decisions: expand extraction capacity now, or conserve resources for additional housing.
Spatial Resource Queries and the Gathering Radius
Each resource-gathering building defines a radius within which it searches for available resources. When a building is placed, it performs a spatial query to find the nearest valid resource node within that radius and dispatches a worker to collect it.
This radius-based query model is a clean way to scope behavior locally — buildings don’t need global knowledge of the resource map, they only care about what’s nearby. It also naturally produces emergent placement strategy: a Lumber Camp placed at the edge of a forest is less efficient than one placed at its center.
Autonomous Workers and the Depletion Loop
Workers operate autonomously once dispatched: they navigate to the target resource, collect it, return to the building, and repeat until the resource node is depleted. When a node runs out, the worker idles until the building triggers a new query for the next available resource.
This loop — query, dispatch, collect, deplete, re-query — is the core gameplay cycle. Keeping it as a clean state machine in Blueprints made it easy to reason about edge cases: what happens when a resource depletes mid-collection, or when no resources are left in range.
Houses and the Passive Economy
Houses introduce a second economic layer: they generate coins from taxes over time, independent of player action. This passive income stream creates a tension between investing in extraction (active resource generation) and housing (passive coin income), which is the fundamental design loop of most resource management games.
The coin generation is timer-based, making it simple to balance by adjusting rate and amount per house — a design pattern that scales well as more building types are added.
Reflection
This was a Blueprint-only project, and intentionally so — the course targets beginners, and the goal was to understand the design patterns of a resource game before implementing them in C++. The spatial query model, the worker state loop, and the building placement system are all patterns I’ve since applied in C++ projects with more complex requirements.
The main limitation of the Blueprint implementation is visibility: logic lives inside node graphs that don’t diff well in version control and are hard to review externally. For a production system, these would be candidates for migration to C++ — particularly the resource query and worker dispatch logic, which benefit from being testable and extensible in code.
Nicolás Bertoa 
Leave a comment