Randomizing Platforms | Unreal Engine Blueprints Tutorial

Randomly hiding platforms is easy; preserving a useful relationship between rows requires remembering the result of the first random pass. This lesson builds two rows of platforms in an Unreal Blueprint, randomizes their availability, and forces a lower platform to remain wherever the corresponding upper position is missing.

The starting scene already has a ball that can move and jump. Its controller is not rebuilt here; the physics-based ball lesson explains that related movement experiment and its unresolved jump behavior. This lesson concerns platform state and row-to-row data flow. The exact engine release is not established by the transcript.

The source is a long debugging demonstration. It includes several apparently successful tests followed by failures, culminating in corrected array connections. The final result is two related rows, not the indefinitely extending level proposed for a future lesson.

Prepare ordered platform references

At 00:03–06:02, the instructor creates an Actor Blueprint containing the platform mesh components and arranges the example rows. An initial layout runs across the wrong direction for the side-view ball, so the placed arrangement is rotated 90 degrees.

The working example uses six platform references for each row. The first row’s components are assembled into one ordered array, and the lower row later receives its own array. Their ordering is important: the same local array position must identify corresponding locations in the two rows.

Component labels and array positions are not interchangeable. The lower components are described with the later numbers in the twelve-component set, but their six-element array still has its own local positions. A comparison across rows needs a consistent column relationship, not an accidental equality between names.

Before adding randomness, play the scene with the platforms available and confirm that the ball’s movement plane matches their placement. A logically correct randomizer cannot compensate for a row positioned outside the playable direction.

Randomize visibility and collision together

During 06:02–12:03, Begin Play starts the first-row iteration. A First Boolean begins true so the first platform is retained for the player’s starting position; that first pass then clears the flag. Later platforms use a Random Boolean to choose their state.

The current platform component must be the target of both changes. A visible platform has collision enabled, and a hidden platform has collision disabled. The instructor replaces temporary/default targets with the array element representing the platform being processed.

These two properties serve different purposes. Visibility controls whether the player sees the surface; collision controls whether it supports or blocks the ball. Hiding a platform while leaving collision active creates an invisible obstacle, while showing it without collision creates a surface the ball can fall through.

Repeated play tests now produce different first-row arrangements. This establishes the basic per-platform randomization before the lower-row dependency is introduced.

Record missing positions before processing the lower row

At 12:03–21:02, the instructor adds an integer array to carry information from the first row to the second. The final walkthrough clarifies its useful contents: when a first-row platform is hidden, its index is added to the array. Some variable names contain “visible,” but the recorded entries identify the missing positions used by the lower-row check.

The first-row work is collapsed into a function. A second function receives the lower row’s six references, with a separate array available to record that row’s missing positions. A Sequence organizes execution so the first-row result is established before the second row evaluates it.

The lower row still begins with a random choice. If that choice keeps a platform, visibility and collision can be enabled immediately. If the choice would hide it, the function must first check whether the upper platform at the same position is already missing.

That dependency is the lesson’s central rule: a lower platform may be forced visible to cover an upper gap. It does not require the rows to be exact opposites, since random choices can leave both platforms present at one position.

Remember any match, then decide after the inner loop

During 21:02–28:00, the lower-row function iterates through the stored upper missing-position array and compares each stored value with the current lower platform’s local index.

The instructor recognizes a problem with branching directly on every comparison: one comparison can match, then a later comparison can fail and overwrite the intended outcome. A single Platform Match Boolean therefore accumulates whether any match was found.

The required sequence is:

1. Reset Platform Match to false for the current lower platform.
2. Iterate through the stored upper missing positions.
3. Set Platform Match true when a stored position matches this lower position.
4. After that search completes, use the accumulated result to choose the platform state.

A match forces the lower platform visible with collision enabled. No match allows the earlier random hide choice to proceed, with collision disabled and the missing lower position recorded for possible later use.

Resetting the flag belongs to the outer platform iteration. Resetting it on every inner comparison would forget an earlier match; failing to reset it for a new platform would carry the previous platform’s result into the next decision.

Repair types and distinguish array elements from array indices

At 28:00–37:04, the first implementation behaves inconsistently. The instructor pauses, changes the stored arrays from Integer64 to the intended Integer type, and rebuilds affected nodes and connections. That resolves some graph issues, but subsequent tests still reveal missing lower platforms beneath upper gaps.

A separate variable getter is tried for the accumulated match state. It does not by itself solve the problem. The decisive later correction identifies the wrong loop output: the inner loop’s Array Index had been used where its Array Element was needed, and another connection also came from the wrong place.

The distinction is concrete. The missing-position array contains values such as the column numbers that were hidden above. An inner Array Index says where one of those stored numbers sits in that list; the Array Element is the stored column number itself. The comparison needs the stored value, paired with the current lower platform’s column index.

For example, if the first missing position were column four, that value could occupy list position zero. Comparing the list position would incorrectly treat column zero as the gap. This is an explanatory example of the distinction, not a specific random result claimed from the recording.

Keep the type correction and the connection correction separate. Integer64 is not declared universally invalid by this lesson; the graph was revised to consistent intended types. The remaining logical error required different data to reach the comparison.

Verify the final two-row rule and retain its limits

During 37:04–41:11, the instructor walks through the corrected first- and second-row functions. The first row preserves its starting platform, randomizes the others, and records hidden indices. The second row randomizes each platform, but checks the upper missing-position list before allowing a hide choice.

The unnecessary first-platform branch is removed from the second-row function, and the final tests again show a lower platform where the upper row has a gap. This follows the earlier failed tests, so review the corrected connections rather than treating a mid-video apparent success as the final graph.

Inspect both visibility and collision at the same positions. A useful test checks the rule across multiple play runs and several gap patterns, not merely whether the arrangement looks different each time. Also confirm that row-one processing has finished before row two reads its stored results.

This rule does not guarantee that every randomized layout is traversable by the ball. Jump range, spacing, and the controller’s contact behavior remain separate concerns. The source does not establish array clearing for repeated runtime rebuilds, seeded reproducibility, or an infinite row-generation system. Additional lower layers are the announced next step, not a completed feature here.