A platformer prototype exploring jetpack fuel mechanics, Blueprint communication patterns, and asset performance optimization.
This project is a platformer prototype built in Blueprints with Unreal Engine 5.4, developed following this Udemy course. The central mechanic is a jetpack with a fuel resource that must be managed and recharged, set across a series of platforms with different behaviors. Beyond the gameplay, the project served as a practical exercise in two Blueprint architecture topics that are often treated as advanced: inter-object communication patterns and asset memory optimization.
You can watch the prototype in action here: YouTube
Jetpack Mechanics and Fuel Management
The jetpack adds a second movement dimension to a standard platformer: the player can extend jumps, reach higher platforms, and traverse gaps that would otherwise be impassable. The constraint that makes it interesting is fuel — the jetpack drains a resource when active, and the player must find fuel pickups or land on recharge platforms to replenish it.
This fuel mechanic does several things for the game design simultaneously. It converts the jetpack from an unconditional ability into a resource management decision: use it now and risk running dry, or conserve it for a harder section ahead. It also gives platform types a clear purpose — some platforms are progression gates, others are safe zones for recharging. The fuel bar in the UI creates constant visibility into this tradeoff, keeping it at the forefront of player attention.
The fuel system itself is straightforward: a float value on the player character that depletes on a rate-per-second while the jetpack is active and replenishes when conditions are met. The interesting design question is the recharge model — instant refill versus gradual regen versus pickup-only — each of which produces a different pacing feel. This prototype explores gradual regen combined with fuel pickup items.
Blueprint Communication: Interfaces vs. Event Dispatchers
One of the most important decisions in any Blueprint architecture is how actors communicate with each other without creating tight coupling. This project explicitly works through two of the main patterns available in Blueprints: Blueprint Interfaces and Event Dispatchers.
Blueprint Interfaces define a contract — a set of functions that any actor can implement, regardless of its class hierarchy. When the player interacts with a fuel pickup, a platform, or any other interactive object, the code doesn’t need to know what type of actor it’s talking to. It calls the interface function, and whatever actor is on the receiving end implements the response in its own way. This is the Blueprint equivalent of programming to an interface rather than an implementation — it keeps the caller decoupled from the callee and makes adding new interactive object types trivial.
Event Dispatchers solve a different problem: broadcasting a notification from one actor to multiple listeners without knowing who those listeners are. When the fuel level changes, the UI needs to update. When the player lands on a special platform, a trigger might need to fire. Rather than having the player character hold direct references to every system that cares about these events, it exposes a dispatcher that interested parties subscribe to. The player character fires the event; it has no knowledge of who receives it. This is the observer pattern, implemented natively in Blueprints.
The key insight is that these two patterns complement each other. Interfaces are for sending messages to a specific actor when you don’t care about its type. Event Dispatchers are for broadcasting notifications from an actor when you don’t care who’s listening. Using both correctly produces a Blueprint architecture where actors remain loosely coupled and easy to extend.
Platform Variety
The level is built around platforms with different behaviors, each providing a distinct traversal challenge:
Static platforms are the baseline. Moving platforms introduce timing requirements — the player must predict position and manage jetpack use to land safely. Disappearing platforms create urgency, pushing the player to commit to a path rather than hesitate. Bouncing platforms interact with the jetpack by amplifying vertical momentum, rewarding players who time their fuel use around the bounce. Each platform type is a self-contained actor that implements the shared platform interface without requiring the player character to handle them differently.
Performance Optimization: Texture Sizes and Soft References
The project explicitly addresses two common sources of unnecessary memory usage in Blueprint projects:
Texture size: In a prototype, it’s easy to import textures at their full resolution without considering the actual display size. A texture used on a small platform tile doesn’t need to be 4K — the visual difference is imperceptible, but the memory cost is not. Auditing and resizing textures to match their actual rendered footprint is a low-effort, high-impact optimization that’s easy to overlook during development.
Soft references: By default, a Blueprint that references another asset (a mesh, a material, a particle system) creates a hard reference — the referenced asset is loaded into memory when the Blueprint is loaded, regardless of whether it’s actually needed yet. Soft references (TSoftObjectPtr in C++, or soft reference pins in Blueprints) defer loading until the asset is explicitly requested. For a project with many levels or conditional content, this is the difference between loading everything upfront and loading only what the current context requires.
Both of these are habits rather than one-time fixes — they need to be applied consistently throughout development to have a meaningful impact. Addressing them in a prototype context builds the discipline to apply them correctly in larger projects.
Reflection
The jetpack prototype is a good vehicle for practicing Blueprint architecture because the core mechanic is simple enough to implement quickly, leaving room to focus on how it’s built rather than just that it works. The explicit focus on communication patterns and performance habits makes this more than a gameplay demo — it’s a study in Blueprint best practices that translate directly to production work.
In a C++ context, Blueprint Interfaces map to UInterface / IInterface pairs, and Event Dispatchers map to DECLARE_DYNAMIC_MULTICAST_DELEGATE macros. The patterns are identical; the implementation layer changes. Understanding them thoroughly in Blueprints first makes the C++ versions significantly easier to reason about.
Nicolás Bertoa 
Leave a comment