Unreal Randomization

This Unreal Blueprint lesson makes a sphere choose a direction, keep moving that way for a period, then choose again. It introduces bounded random integers, a Switch on Int, a movement function, and a counter that separates movement updates from new decisions.

The instructor explicitly limits the behavior: the object does not perceive the environment, plan a route, or avoid collisions. Its “AI” is a random choice among simple motions and a stationary state. The exact engine release is unidentified, and the final movement is not established as frame-rate independent.

Store a random choice before using it

At 00:01–05:02, an Actor Blueprint receives a sphere component. The instructor demonstrates Random Integer in Range with bounds zero and four, stores the result in an Integer variable, and prints it when play begins.

There are five possible values in that example because zero is included. Repeated play sessions show different results. The source also distinguishes the separate Random Integer node, whose maximum input describes an exclusive upper bound, from the bounded range node used here.

Storing the chosen value gives the later movement logic a decision to reuse. The sphere should continue its selected behavior until the script deliberately replaces that value, rather than asking for an unrelated random decision at every place the graph needs the current choice.

The debug print is useful before adding motion: it isolates whether the random value is being assigned from whether the movement branches are wired correctly.

Map four cases to relative component movement

During 05:02–10:02, the range is narrowed to zero through three for four directional cases: positive X, negative X, positive Y, and negative Y. Switch on Int selects the corresponding operation from the stored integer.

The sphere’s relative transform is read, and its location is split into X, Y, and Z. Each directional branch modifies one location coordinate by adding one or negative one while passing the other location coordinates through to the new value.

Directional case	Location change
Positive X	Add one to current X
Negative X	Subtract one from current X
Positive Y	Add one to current Y
Negative Y	Subtract one from current Y

These are relative component coordinates, so their meaning follows the component’s parent frame. They are not automatically camera-relative commands or a navigation path through the world.

The important operation is accumulation: read the existing coordinate and add the step. Assigning the same fixed coordinate repeatedly would place the sphere at that value rather than keep moving it. Preserve the unaffected location coordinates deliberately; the captions do not fully enumerate the remaining rotation and scale pins, so inspect those when reproducing the complete transform node.

Add a stationary choice and organize the movement graph

At 10:02–13:05, a fifth switch case is added by copying a movement branch and removing its addition. The current location is passed through unchanged, producing a stop state in the demonstrated test.

The random generator must include that fifth case for it to be reachable. The narration clearly shows the added state and a successful stop test but does not spell out every range edit at that moment; inspect the generator’s bounds as well as the switch pins.

The directional branches are collapsed into a movement function to simplify the Event Graph. The function performs the behavior represented by the current stored choice. Selecting a new direction remains a separate task.

That separation makes the later counter easier to understand: a decision can persist through many movement updates, including many updates in which the selected behavior is “stay still.”

Set an update interval and count completed updates

During 13:05–18:02, the instructor uses Set Actor Tick Interval with an example value of 0.01 seconds, then introduces an Integer counter beginning at zero. Each update adds one to the counter and stores the result.

A Branch checks whether the counter is greater than 100. While that condition is false, the graph calls the movement function using the existing random choice. The source tests that the object continues in its initial direction before the new-decision branch is added.

The comparison matters: “greater than 100” is different from “equal to 100.” Starting at zero and incrementing before the comparison, the next decision is reached when the count crosses that threshold. The narration later describes this loosely as every hundred updates; the graph’s stated comparison is more specific.

The interval is a requested update cadence, not proof of a measured fixed rate. The movement uses a step per update rather than a demonstrated delta-time-scaled speed. Do not infer an exact world-units-per-second value or an exact one-second decision interval from the settings alone.

Choose again, reset the counter, and inspect the behavior

At 18:02–20:29, the true branch assigns another random integer and resets the counter to zero. Subsequent updates can then perform the selected movement until the counter crosses its threshold again.

A new random choice does not have to be different from the old one. The sphere can continue in the same direction, reverse, turn onto the other axis, or remain stationary. The final test demonstrates several direction changes and a stop period.

Follow the execution paths when comparing timing: the source places movement on the false branch and decision/reset work on the true branch. It does not demonstrate an additional movement call on the decision branch, so do not assume every counter update performs an identical motion step.

Verify the stored choice, counter growth, threshold crossing, reset, and resulting motion separately. If the sphere never changes direction, inspect the reset/assignment path; if it flickers between directions on every update, inspect whether the random value is being replaced too often.

The final object follows the numbers it generates. No environmental query, collision-avoidance policy, target seeking, or navigation-system integration is built. Its usefulness is as an inspectable example of discrete random decisions driving repeated motion, with timing and spatial limits still explicit.