Chapter 03

The C++ / Blueprint Boundary

Designing the exposed surface: reflection macros, meta specifiers, and structuring a system that is both fast and tunable.

In this chapter

Exposing C++ to Designers
Meta Specifiers — Safe, Well-Ranged Knobs
Performant and Designer-Tunable at Once
The C++ Base / Blueprint Subclass Pattern

Exposing C++ to Designers

It happens through the reflection macros. They are how C++ becomes visible and editable to designers.

UPROPERTY — exposing a variable

Specifier	Effect
EditAnywhere	Editable in the details panel, on both defaults and instances
EditDefaultsOnly	Restricts editing to the class defaults — the CDO (Chapter 6)
BlueprintReadWrite	Blueprints can get and set it
Category="..."	Organizes it into a labelled section of the panel

UFUNCTION — exposing a function

Specifier	Effect
BlueprintCallable	Designers can call it from a graph
BlueprintPure	Marks a side-effect-free getter (no exec pins)
BlueprintImplementableEvent	Declared in C++, implemented entirely in Blueprint
BlueprintNativeEvent	C++ provides a default that Blueprint can override

BlueprintPure nodes have no execution pins, which also means you cannot place a breakpoint on one — see Chapter 18.

Meta Specifiers — Safe, Well-Ranged Knobs

Safety and polish come from the meta specifiers:

ClampMin and ClampMax constrain the value itself — a designer physically cannot enter something outside the range.
UIMin and UIMax set the slider range, without hard-limiting typed input.
EditCondition gates one field on another, so irrelevant options grey out instead of confusing people.

This is the craft of the role: designing the exposed surface so designers get safe, well-organized, well-ranged knobs — not a wall of raw variables.

Performant and Designer-Tunable at Once

When a system has to be both, split it by kind of work rather than trying to compromise:

Put the core loop and heavy computation in C++, where it runs at native speed across many entities every frame.
Expose tuning values as data — UPROPERTY fields, Data Assets and Data Tables that designers edit without recompiling (Chapter 8).
Expose hooks as events — BlueprintImplementableEvent or dispatchers — so designers can attach behavior at key moments without ever touching the hot loop.

Designers tune numbers and compose responses in Blueprint and data. They never run expensive per-tick logic in Blueprint.

The C++ Base / Blueprint Subclass Pattern

"Gameplay logic in C++, tuning and composition in Blueprints" is the typical pattern because it puts each kind of work where it belongs.

C++ base class

Defines the system and its contract
Owns performance-critical logic
Declares the properties and events it exposes

Blueprint subclass

Sets the data
Composes components
Implements designer-facing events
Handles content-specific one-offs

What you get out of it:

Performance where it counts and iteration speed where designers need it.
A clean split between framework and content, with code-reviewable, diff-friendly logic.
Designer autonomy — they build and tune content without an engineering bottleneck.

Interview drill

Answer each out loud before re-reading the chapter.

How do you expose C++ functionality to designers?
If a system must be both performant and designer-tunable, how do you structure it?
Why is "gameplay logic in C++, tuning and composition in Blueprints" the typical pattern?

← Chapter 2 ↑ Index Chapter 4 →