Building interconnected survival systems in Blueprints: stats, inventory, resource gathering, AI enemies, and procedural world population.
This project is a survival game prototype built entirely in Blueprints with Unreal Engine 5.4, developed following this Udemy course. It covers a wide range of systems typical of the survival genre — stat management, inventory, resource gathering, basic combat, and world generation — implemented on an open island environment.
You can watch the prototype in action here: YouTube
Survival Stats and Their Interdependencies
The core of any survival game is its stat system: health, hunger, thirst, and stamina. What makes this interesting architecturally is that these stats are not independent — they influence each other in ways that create meaningful gameplay pressure. Stamina depletion accelerates hunger and thirst drain. Low hunger reduces health regeneration. Thirst affects stamina recovery rate. The result is a web of dependencies where the player has to manage multiple resources simultaneously rather than optimizing one at a time.
The implementation centralizes these stats in the player character, with each stat decaying on its own timer and broadcasting state changes to any system that needs to react — the UI, the death system, the animation state. Keeping stats as a single source of truth in the character rather than distributing them across multiple actors avoids synchronization problems and makes the interdependency logic easier to reason about.
Inventory System
The inventory is a grid-based system with support for item stacking, tooltips, item selection, pickup notifications, and equip/consume actions. The widget layer is separated from the inventory data — the grid UI reads from an inventory component on the character, rather than managing state itself. This is the correct separation: UI should display state, not own it.
Items fall into two categories based on their interaction verbs: consumables (food, water) and equipment (tools, weapons). Consuming an item directly modifies a stat — eating fruit restores hunger, drinking water restores thirst. Equipping an item changes what the character can do — equipping an axe enables tree cutting, equipping a weapon enables combat. This distinction drives how items are registered and what data they carry.
The pickup notification system — the transient UI feedback that appears when an item enters the inventory — is a good example of a purely presentational concern that should be completely decoupled from inventory logic. The inventory fires an event; the UI subscribes to it and handles its own display lifecycle independently.
Resource Gathering: Trees and Stones
Trees use Foliage Instanced Static Mesh Components, which is the correct approach for large quantities of repeated meshes — they render efficiently via instancing and can be queried and removed at runtime. When the player cuts a tree, the specific instance is identified, removed from the Instanced Static Mesh Component, and replaced with a falling tree animation before yielding wood items.
Stones are simpler — static mesh actors that are destroyed on interaction and replaced with pickup items. The distinction in implementation reflects the distinction in world population strategy: trees are numerous and generated as foliage; stones are fewer and can be placed individually or via PCG.
The resource gathering loop — approach, interact, receive item, item enters inventory — is the same regardless of resource type. Both go through the same interaction interface and the same item pickup pipeline, which keeps the gathering code consistent even as the specific resources differ.
AI Enemies: Tigers
Tiger enemies serve two roles in the game: they are a threat to the player’s health, and they are a food source after death. This dual role is important for survival game design — enemies shouldn’t just be obstacles, they should be part of the resource economy.
The tiger AI uses Unreal’s Behavior Tree system for basic patrol, detection, and chase behavior. Detection is sphere-based: when the player enters the tiger’s awareness radius, it transitions from patrol to pursuit. Combat is melee — the tiger closes distance and attacks on a timer. On death, it spawns meat items that can be picked up and consumed or stored.
The meat-from-enemy mechanic closes a loop that connects combat directly to the stat system: fighting a tiger is risky (health damage) but rewarding (food source), which creates genuine risk/reward decisions in a resource-scarce environment.
World Environment: Nanite, Water, and PCG
The island environment uses several of UE5’s rendering and world-building features:
Nanite landscapes with displacement mapping allow the terrain to have geometric detail — actual surface displacement rather than normal map illusions — without a fixed polygon budget. This is one of Nanite’s most impactful applications for open-world environments, where terrain covers large areas and needs to read well at varying distances.
The Water plugin handles the ocean surrounding the island, providing buoyancy, surface rendering, and interaction volumes. For a survival prototype, the water also defines a natural boundary — the player can approach the water but swimming or leaving the island isn’t part of the scope.
PCG (Procedural Content Generation) is used to populate the island with items and enemy spawn points. Rather than manually placing every stone, tree cluster, and tiger, PCG distributes them according to rules — density masks, exclusion zones around spawn points, surface normal constraints for steep terrain. This makes the world feel naturally populated and allows rapid iteration on distribution without re-placing assets by hand.
The day-night cycle drives ambient lighting changes over time, affecting mood and, in a fuller implementation, could tie into gameplay — visibility affecting enemy behavior, temperature affecting stat drain rates. In this prototype it’s primarily atmospheric.
Reflection
What this project demonstrates most clearly is the challenge of keeping systems that share state clean as complexity grows. Every new system — combat, gathering, crafting, hunger — needs to read or write the same player stats and inventory. Without a disciplined approach to how those shared resources are accessed, the codebase quickly becomes a tangle of direct references and circular dependencies.
The Blueprint implementation makes this visible: you can trace exactly where every connection goes. In a C++ version of these systems, the right pattern would be a component-based architecture where each system (stats, inventory, interaction) lives in its own UActorComponent, communicates via delegates, and never holds a direct reference to another component it doesn’t own. The survival game genre is one of the best practical exercises for understanding why that kind of decoupling matters at scale.
Nicolás Bertoa 
Leave a comment