Using Unreal Engine’s physics system as the core gameplay mechanic: controlling a rolling sphere through platforms with pure PhysX simulation.
This project is a physics-based platformer prototype built entirely in Blueprints with Unreal Engine 4 — a marble run game where the player controls a rolling sphere navigating a series of platforms and obstacles. The development process was recorded in a full teaching playlist.
You can watch the complete teaching playlist here: YouTube Playlist
You can also watch a demo of the finished prototype here: YouTube
Physics as the Primary Mechanic
Most games use Unreal’s physics engine as a secondary system — objects fall realistically, ragdolls collapse, debris scatters after an explosion. The marble run inverts this: physics is the gameplay. The player’s input doesn’t move the character directly; it applies forces and impulses to a simulated physics body, and the character’s movement is entirely the result of that simulation responding to the environment.
This distinction has significant implications for how the game feels. A standard platformer character moves with precise, frame-perfect control because its position is computed directly from input. A physics-based character moves with momentum, inertia, and surface friction — input applies force, and the character’s response depends on its current velocity, the surface it’s rolling on, and the geometry it’s encountering. The player is influencing the simulation rather than directly controlling the character.
This makes the marble run harder to control precisely than a standard platformer, which is the source of both its challenge and its satisfaction. Landing a difficult roll through a narrow section feels earned in a way that a direct-control platformer doesn’t produce, because the physics system introduces genuine uncertainty into every movement.
The Sphere Pawn
The player character is a sphere mesh with a SphereComponent as its root physics body. The UCharacterMovementComponent — used in most Unreal characters — is not appropriate here, as it’s designed for biped locomotion. Instead, movement is applied directly to the physics body via AddForce or AddTorque, which accelerates the sphere in the input direction while letting friction, gravity, and collision responses handle the rest.
Tuning the physics parameters is the primary design work of a marble run:
Mass determines how much force is needed to accelerate the marble — heavier marbles are harder to redirect but maintain momentum through obstacles. Linear damping simulates air resistance, slowing the marble when no input is applied. Angular damping controls how quickly the marble stops spinning after losing contact with a surface. Friction between the marble and platform surfaces determines whether the marble rolls cleanly or slides unpredictably. These four parameters together define the fundamental feel of the marble — getting them balanced is the tactile design challenge of the genre.
Camera for a Rolling Character
The third-person camera for a marble run has a specific challenge that doesn’t exist for biped characters: the marble spins continuously as it rolls, which would produce nauseating camera rotation if the camera were parented to the marble’s rotation. The camera needs to follow the marble’s position but ignore its rotation — tracking where the marble is while maintaining a stable, upright orientation.
This is achieved by attaching the spring arm to the marble’s position but locking the spring arm’s rotation to world space rather than inheriting the marble’s local rotation. The result is a camera that smoothly follows the marble through the level while remaining stable and readable regardless of how fast the marble is spinning.
Platform Design for Physics Gameplay
Level design for a physics-based game requires different thinking than level design for a direct-control game. In a standard platformer, a gap of a specific width is a fixed challenge — the player either makes the jump or doesn’t, based on their timing. In a marble run, the same gap is a variable challenge based on the marble’s current velocity, approach angle, and whether the player is applying force at the moment of launch.
This variability means that marble run levels need to be more generous in their geometry — slightly wider platforms, slightly more forgiving edges — because the physics simulation introduces variance that the designer can’t fully predict or control. A platform that looks jumpable in the editor might be unreachable from a low-speed approach, or overshot from a high-speed one.
Ramps and curved surfaces are the marble run’s primary level design vocabulary — they redirect the marble’s momentum rather than requiring precise jumps. A well-designed ramp sequence feels like a flow state, where the marble’s accumulated speed carries it through the section with the player applying only gentle course corrections.
Reflection
The marble run is the most physically honest game in this series — there’s no animation system, no AI, no complex UI. It’s a sphere, a set of platforms, and Unreal’s physics engine. That simplicity makes it a pure test of one thing: can you make physics-based movement feel satisfying?
The answer requires understanding not just how to configure a physics body but how physics-based feel works for players — the relationship between input responsiveness and physical momentum, the tuning of damping and friction that produces control without eliminating challenge, the camera behavior that keeps the simulation readable. These are the same questions that physics-based games from Marble Madness to Super Monkey Ball have answered across decades, and working through them in Unreal at any scale builds the intuition for why those games feel the way they do.
Nicolás Bertoa 
Leave a comment