Function Basics with Unreal Engine 4 Blueprints

This lesson uses a small arithmetic example to explain Blueprint functions: a button press adds a chosen amount to a stored number, then prints the amount and the new total. The instructor calls it a jump, but the demonstrated graph does not move a character or implement physical jumping. Keeping that distinction clear makes the example much easier to follow.

The useful result is one calculation reused by different inputs, with its outputs passed to a separate display function. Along the way, three mistakes reveal different things to inspect: an unconnected message, swapped values and a missing execution connection.

Prepare the Actor and input events

The recording belongs to an Unreal Engine 4 Blueprint basics series. It assumes familiarity with creating variables, placing nodes and connecting pins. No character asset is needed for the demonstrated arithmetic. The exact UE4 point release is not established by the caption evidence, and this article does not claim a UE5 reproduction.

The instructor creates an Actor-based Blueprint and adjusts its input setting to Player 0 because it will respond to button presses. He creates a function called My Jump Function, then adds left mouse, right mouse and J-key events in the Event Graph. Initially, only the left mouse press calls the function; the other events are prepared for later comparisons.

A function call in the Event Graph represents the work contained in its separate function graph. Double-clicking the call opens that graph in the recording. This organization lets the input event communicate what action it requests without placing every arithmetic and display node beside the event.

Build and inspect one update before generalizing it

The first function uses two floats: a stored value called Y Position and an amount called Jump Height. The demonstrated defaults are zero for the stored value and ten for the amount, after compilation makes those defaults available.

The calculation is:

new stored value = previous stored value + jump amount

The instructor gets the previous Y Position, adds Jump Height, and sets Y Position to the sum. The execution path then reaches Print String. The order matters to the intended message: the display should describe the updated total, not the value before the addition.

Here, “Y Position” is a variable name in a toy example. It is not a demonstrated connection to an Actor transform, nor a lesson about which world axis should represent vertical motion. The observable result is changing text.

The instructor builds a Format Text message with separate fields for the amount and the new position. He compiles, places the Blueprint in the level and tests it. The first click prints the default greeting because the formatted text has not been connected to the print input. Connecting the final output, with the text-to-string conversion shown in the recording, makes the intended message appear.

That failure provides a useful checkpoint: successful compilation does not prove the right value reaches the display. When the text is wrong, inspect the data input to Print String before rewriting the arithmetic.

Pass the amount into the function

The next stage introduces a second amount: a normal jump of 10 and a super jump of 15. These are example increments chosen to make the comparison visible, not physical jump settings.

Instead of maintaining two copies of the addition logic, the instructor adds a float input named Jump Height to the function. He replaces the function’s internal normal-jump reference with that input. Left mouse supplies the normal amount; right mouse supplies the super amount to another call of the same function.

The distinction is between the procedure and the choice made by its caller. Both calls perform an addition and store the result. The input event chooses how much to add. If the function still reads the old internal amount, the new input pin alone will not make the behavior variable.

The recording also shows a call retaining the temporary parameter label. The instructor uses Refresh Node so the call reflects the renamed input. Inspect the function definition and its call together after changing the interface: the pin label, its connected value and the value used inside the function should agree.

During testing, the message fields are crossed. The instructor reconnects the jump amount to its field and the stored position to the other. The corrected output distinguishes the increment from the accumulated total. Test with both buttons; one call should add ten and the other fifteen in this example.

Separate calculation from presentation

The instructor then identifies two responsibilities inside the function: changing the stored number and displaying information. He selects the display portion and uses Collapse to Function, naming the resulting function Display Jump.

To show how outputs work, he removes the display call from inside the original function and adds two float outputs to it: the jump amount and the new position. Back in the Event Graph, the update function’s outputs feed the corresponding inputs on Display Jump, and execution proceeds from the update into the display.

Follow both kinds of connection while inspecting this stage:

1. The update function receives the selected amount.
2. Its arithmetic computes and stores the new position.
3. Its return carries the amount and new position back to the caller.
4. Those data outputs feed Display Jump.
5. The execution path reaches the display after the update.

The first test of this arrangement reports zeros. The instructor finds that the execution connection leading to the return has not been completed. After connecting it and recompiling, the ten- and fifteen-unit increments appear again.

The lesson is more specific than “check your wires.” Data connections identify the values being passed; execution connections establish the demonstrated order of an impure function’s work and return. Inspect both before assuming a default or type is wrong.

Read the final pure-function experiment with care

Late in the recording, the instructor duplicates the jump function, marks a version Pure, and demonstrates calls without execution pins feeding display operations. He subsequently chains display operations and observes two messages from one J-key press.

This is an observation from the recording, not a reliable recipe for a double-jump system. It also needs a technical qualification: the earlier function changes stored state. Epic’s function documentation describes pure functions as computations that do not modify state; their outputs are evaluated when required through data connections. That current documentation is explanatory context, not evidence that this historical graph was independently tested.

Do not interpret the Pure checkbox as a general instruction to repeat a state-changing operation. The supported core of this lesson is the explicit update-and-display sequence above. The final experiment requires visual and software review before it could support an instructional recipe about evaluation counts or repeated mutation. A real jump also needs movement behavior absent from this example.

Return to the relevant part of the recording

These are reading references from preserved caption cues, rounded down, rather than official chapters or player controls:

• 00:00–03:02: Actor setup, Player 0 input, function creation and button events.
• 03:02–08:02: floats, addition, setting the stored value and connecting formatted text.
• 08:02–13:00: normal/super amounts, a function input, refreshed pins and corrected message fields.
• 13:00–17:00: separating Display Jump, adding outputs and finding the missing return execution connection.
• 17:00 onward: the later pure-function experiment and its reported behavior.

What to carry into another Blueprint

Use a function input when callers need the same operation with different values. Use outputs when a later operation needs results without reaching into the first function’s internal work. Check the message fields against the intended quantities, and trace execution through the return when an impure function reports unexpected defaults.

This recording demonstrates those ideas with numbers and text. It does not establish character movement, airborne state, landing logic or a tested pure-function evaluation model. Those limits keep the small example useful without asking it to prove a larger gameplay system.