An independently designed endless runner prototype in Unreal Engine 4 — no tutorial followed — with a complete step-by-step teaching playlist.
This project is a third-person endless runner prototype built entirely in Blueprints with Unreal Engine 4. Unlike every other project in this series, it was designed and implemented without following a course or tutorial — the systems, the architecture, and the implementation decisions were made independently, from a blank project to a working game. After completing it, I recorded a full step-by-step teaching playlist explaining the implementation in detail.
You can watch the complete teaching playlist here: YouTube Playlist
You can also watch a demo of the finished prototype here: YouTube
Designing Without a Guide
The distinction between following a tutorial and building something independently is significant. A tutorial provides the architecture upfront — you implement a design that someone else has already validated. Building independently requires you to make every architectural decision yourself: how tiles are structured, where the difficulty escalation lives, how lane switching interacts with obstacle collision. You discover the problems by encountering them, not by being warned about them in advance.
This project was designed at a point where I had working knowledge of Blueprints from the SpaceShip game and prior Unreal work, but no specific endless runner reference to follow. The design process was iterative: a rough implementation of tile streaming, test it, identify what breaks, fix it, move to the next system. This kind of iterative problem-solving from first principles produces a different quality of understanding than tutorial-following — you know not just how it works but why each piece is the way it is, because you tried the other way first and saw it fail.
The Core Systems
The endless runner prototype implements the same fundamental systems covered in more depth in the UE5 Endless Runner project — tile streaming, lane switching, obstacle generation, and difficulty escalation — but designed from scratch rather than guided by a course. The UE4 implementation is intentionally more basic: this was a proof-of-concept built to validate that the core mechanics were understandable and fun before adding visual polish and additional features.
Tile streaming is the central technical challenge: the world must feel infinite while being built from a finite pool of reusable tile actors. The implementation spawns tiles ahead of the player and recycles them from behind — the same object pooling concept used in the UE5 version, implemented here without the reference of knowing that’s the standard approach. Arriving at object pooling independently, by recognizing that spawning new tiles on every cycle was causing frame spikes, is a good example of the kind of problem-solving that tutorial-free development requires.
Lane switching maps player input to discrete lateral position changes — left, center, right — interpolated smoothly over a short transition time. The transition duration and the input buffering (should an input during a transition queue the next lane change or be ignored?) are design decisions that only become apparent when you’re playtesting and finding that the controls feel wrong. Resolving them without a course to reference requires iteration and a clear sense of what “feels right” as a goal.
Obstacle placement distributes hazards across lanes within tiles in patterns that are readable and fair. Designing these patterns independently requires understanding what makes an obstacle fair — the player must have enough time to see it and respond — and what makes it interesting — it shouldn’t always require the same response.
Teaching What You Built
Recording the teaching playlist after building the prototype produced the same effect described in the SpaceShip game project: explaining every decision forced a level of articulation that building alone doesn’t require. The playlist audience is a developer who has never built an endless runner — they need to understand not just what the Blueprint looks like but why it’s structured that way.
The teaching process revealed several places where my initial implementation was correct but not well-motivated — it worked, but I couldn’t easily explain why I’d done it that particular way. Those places became candidates for refactoring before recording, producing a cleaner final implementation that was also better architecture.
This combination — independent design followed by teaching — is the most complete learning cycle in this series. It covers three distinct phases: design (making architectural decisions without guidance), implementation (building and debugging the result), and reflection (articulating the decisions clearly enough to teach them). Each phase builds on the previous one and produces a different kind of understanding.
Reflection
This project sits at a pivotal point in the trajectory of this project series. The earlier projects — the SpaceShip game, the VR interactions — followed courses that defined the destination and the path. This one defined both independently. The subsequent projects in the series return to course-following for specific new techniques, but the confidence to make independent architectural decisions — to know what to build and how to structure it — was established here.
The endless runner genre is an excellent vehicle for independent design precisely because its core systems are well-understood enough to set a clear target, but open-ended enough that there are multiple valid approaches to every implementation decision. Having a known genre as the goal — rather than an entirely open-ended creative project — keeps the scope manageable while still requiring genuine design work.
Nicolás Bertoa 
Leave a comment