Race Day: Game loop and more
What’s in the game now
A race course to ride. There’s a full run from top to bottom. It has a start hut with a spot for the timing sensor, race tape lining the whole course, and tree pads around the trunks. Like real World Cup and Hardline tracks, the course is defined by tape and protection.
A chase camera. The follow cam is its own system and isn’t attached to the bike. It tracks the bike’s direction of travel rather than where the frame happens to point, so it stays steady through rough sections and doesn’t swing when the bike gets kicked sideways. It also looks slightly ahead down the trail, so you see the line coming, not just the back of the bike. It’s tested at 30 fps, 60 fps and uncapped with no stutter.
HUD and menus. There’s a speed readout, a race timer, and a pause menu with restart, resume and quit.
Sound. The freehub clicks when you coast, driven by the actual rotation of the rear wheel.
The rider has weight now
This is the part I’m most excited about.
In most bike games the rider is an animation sitting on top of the bike. In Race Day the rider is a simulated mass connected to the frame, and that mass affects how the bike behaves.
When you shift your weight forward or back, a real mass moves relative to the bike, and the bike responds to it. A stabilizer keeps the rider’s body oriented correctly. Every correction it makes pushes back into the frame with an equal and opposite torque, the same way a real rider’s body loads the bike.
In practice, it already does things I didn’t have to script, which is the main point of having it. Weight back off a lip keeps the front from diving. Weight forward on the way down lands the bike flat. Leaning through turns loads the bike the way bikes in the real world do. It’s working well on turns and drops. Rough, chattery terrain is the next test.
The long-term goal is pumping. I don’t want a “pump button” that adds speed. I want pumping to emerge from moving the rider mass at the right moment through compressions, like it does on a real bike. That’s the reason the rider is built this way.
What I’m working on now
Tuning the rider and suspension together. The rider mass is now on the newest bike with the custom suspension solver. The first untuned run made it to the bottom of the course, but it was bouncy and rode low in its travel. Now it’s tuning time.
One bike, all systems. Right now I have three bikes: one riderless, one with the visible rider character, and one with the rider mass system. The next big step is merging them into one bike, so the visible rider is posed by the physics underneath.
Camera tuning. I’m dialing in follow distance and smoothing.
What’s next: the race loop
The immediate goal is a playable slice.
A real start. The bike will be held in the start hut, and the timer will start when you cross the timing beam (right now it starts when the level loads).
A finish line and results screen, plus a quick restart.
Crash and out-of-bounds handling.
Freedom to ride off course. Leaving the tape or missing a section won’t teleport or punish you. It only invalidates the timed run. Riding around freely is a good way to learn the handling, and I don’t want to take that away.
Further out
Free riding: an option to ride the race courses just for fun, plus separate free-ride maps built for exploring.
Race Season mode: A world cup style race season with 6 - 9 race locations. Each race is a three day event. Day one: Walk the course and practice. Day two: practice and qualify. Day three: One race run. Races are time trials style / one rider at a time. Fastest time wins
Course walk: a mode to walk the track before racing and mark your lines. The markers will show during practice but not in the race run, like walking the course at a real race.
More camera options: a landing dip, handling for when trees block the view, a crash camera, and a helmet/POV cam.
Better air control.
Pumping, built on the rider mass system.
Menus: Main menu and race results after finishing a race
Loading screens
Replay system: So players can watch their last run.
Putting a Rider on a Physics Bike
Putting a Rider on a Physics Bike
In Race Day, the bike is not a single animated object. It is a full multi-body simulation. The frame, fork lowers, fork uppers and bars, both wheels, swingarm, seatstay, rocker, and both halves of the rear shock are separate rigid bodies. Chaos physics constraints join them, and custom forces drive them on an async physics tick at 120 Hz. The bars steer, the fork compresses, and the frame pitches and rolls on its own. Nothing about the bike's motion is authored ahead of time.
That makes the rider a hard problem. A riding animation assumes the bike moves in predictable ways, and this one doesn't. Put a pre-animated rider on it and the hands drift off the grips within seconds.
The solution splits the rider into two systems. The rider's weight belongs to the physics: a dedicated rider-mass system that the bike actually responds to. The visible rider has one job, which is to stay attached to a bike whose motion is only known once physics has solved it. This page covers the visible rider. The whole system is built in Blueprint, Control Rig, and Unreal's animation framework, with no C++.
A seated starting point
The rider is a skeletal mesh inside the bike Blueprint, attached to the frame. Before any live tracking runs, a hand-authored seated pose holds the rider in a riding position: knees bent toward the pedals, torso hinged forward, arms already reaching toward the bars.
The starting pose determines how good the result looks. Inverse kinematics (IK) solves joint positions so that a hand lands on a target. If it has to pull an arm all the way from a standing pose to the bars, it still reaches the target, but the elbows and shoulders end up in unnatural positions. Starting from a riding pose means IK only makes small corrections, and small corrections look human.
Hands on the bars
Each handlebar grip has a socket. Every frame, the bike Blueprint reads the world transform of each grip socket and converts it into the rider mesh's own space. It then passes the result to the rider's Animation Blueprint. From there, a Control Rig sets those targets on Null hierarchy elements, and a two-bone IK solve on each arm (shoulder, elbow, wrist) puts the hands exactly on the grips.
The space conversion is the critical step. The rig needs to know where the grip is relative to the rider, not where it is in the world, and getting that wrong makes hands float, lag, or snap to the wrong position. With the conversion correct, the hands stay locked to the grips through steering, fork compression, and everything the frame does under them.
Each elbow has a pole target that sets which way it bends. The arms hold a proper attack position instead of folding at unnatural angles.
What's next
The rider's body is currently fixed to the frame. The next stage drives the upper body and pelvis from the physics rider mass. When the player shifts weight back for a drop or leans into a berm, that shift will be visible on the rider as well as felt through the bike.
That change has a direct consequence. Once the body moves independently of the frame, the feet no longer stay on the pedals automatically. They will use the same pipeline as the hands: pedal sockets, conversion into rider space, and two-bone IK on each leg. The architecture already supports this. It is the same pattern applied to a second pair of limbs.
Async / 120Hz Physics
I’m testing the async physics system running at a fixed 120 Hz. To make that work properly in Blueprints, I’m using custom async‑safe force and torque nodes that apply impulses directly inside the physics step, rather than through the game thread. This keeps the simulation stable and consistent under load and gives the bike a noticeably smoother feel and more accurate interaction with the ground. It’s a more advanced setup than the standard Blueprint workflow, but it gives me a much stronger foundation for the handling and suspension systems I’m building on top of it.