Creating a Custom Motorcycle System for Unreal Engine 5
Ihor Fridman discussed how he built a custom motorcycle system for his own game, explaining how the physics of a motorcycle's stability work, how he treated the bike and rider as one system, and sharing some of the lessons from the project.
Introduction
I'm a Technical Artist and the Owner of Trailblazer Entertainment LLC, which is home to the Wilder Way brand. For the past year, I've been writing a motorcycle system for my own game, a linear road drama. I won't spoil the story. I'll just say that the motorcycle is essentially the second main character: it's on screen almost the entire time, and everything that happens to it serves the narrative.
That's why Chaos physics didn't work for me. It turned out to be too general-purpose for what I was trying to get. If I were making a car, I'd have stuck with it and never written this article.
I Tried the Easy Way First
I didn't sit down to write my own core right away. For two or three months, I tried to make life easier for myself and worked with Chaos Vehicles. That time was wasted. After that came four attempts from scratch, and I abandoned each one at some point. What eventually pulled me through was reading: academic papers, breakdowns of motorcycle simulations.
From those, a foundation gradually took shape, and once it did, it became clear that one person could actually build this. Over the course of a year, many such foundations accumulated. Failure was as regular as morning; it came every day. By that point, my system design was ready. I knew what I wanted. The only question was making it work:
Mass & the Skeletal Component
I needed to understand how mass is distributed across the machine's skeleton and how that affects its behavior. And not just the bike's mass; my rider isn't just a mesh; he's a weight that affects how the bike moves. In practice, the bike kept falling apart on me. Maybe I was doing something wrong with Chaos. I fully admit that's possible. But I couldn't figure out what exactly was wrong.
And that's what really wears you down: over and over you get something other than what you expected, and ahead of you lies a mountain of someone else's code and patterns you'd have to learn just to ask the right question. At some point, I walked away from the whole idea.
Fixes That Faked the Physics I Needed
To make the bike behave like a bike and not like a log with wheels, I had to bolt hacks on top. Gyroscopic effect, tire behavior, suspension response. Each patch works well enough on its own. The problem is what they add up to: a layer of hacks sitting on top of a model that honestly describes a different kind of machine. What you end up debugging isn't the physics. It's the interactions between the hacks themselves, and that's significantly worse.
Mass on Two Wheels Doesn't Behave the Same as on Four
With four contact patches, weight distribution gives a vehicle its character. On two, it decides whether it falls over. At some point, the balance shifted. The hassle outweighed the obvious benefits of sitting on a ready-made system. That's when I started writing my own. To be clear: on a car, all of this works beautifully, and I say that without sarcasm. My vehicle just happened to be a motorcycle.
A Motorcycle Has to Fall, But Not Always
It took me a while to put this difference into words, and it's easy to get wrong in both directions. A car is stable by definition. Stop simulating it, and it just stands there. That isn't a simplification in the vehicle model; it's a correct description of a car. With a motorcycle, everything depends on speed.
At low speed, it falls over no matter what the rider does. In motorcycle dynamics literature, this mode is called capsize, and by its nature it's an inverted pendulum: two contact points on the ground connected by springs, with all the mass above them. But get it up to speed, and the picture flips. From roughly 7–8 m/s, which is 25–30 km/h, a motorcycle enters a range where it's stable on its own.
You can take your hands off the bars, and after a sideways push it will straighten itself out with no human involvement at all. This is a good place to kill a popular myth, because it's a persistent one. What holds the bike up in that range is not the gyroscopic effect of the front wheel. The gyroscopic effect exists, but it isn't the main actor, and at low speed it's negligible.
Back in 2011, a paper in Science described a bicycle built with its gyroscopic moment canceled out and negative trail, and it still straightened itself after a push. Stability comes out of steering geometry, mass distribution, and tire behavior, which together make the machine steer underneath itself. That's where the difference between a stabilizer and a model comes from.
A stabilizing torque gives you stability everywhere and equally, in a parking lot and at a hundred kilometers an hour. A bike held up by a stabilizer feels exactly like that: there's nothing for the rider to balance, because nothing has been knocked out of balance. An honest model gives you three different regimes. In a parking lot, the machine falls over; at speed, it holds itself up, and between them there's a transition you can feel through the bars. I didn't write any of the three separately. They come out on their own.
The Bike and the Rider as One System
I didn't want a motorcycle with a human model parked on top of it; I wanted a symbiosis. The rider here is part of the same mechanical system: his weight, his position, his actions all feed into the physics. Collisions are their own story. The engine has its limits here, and going at them head-on didn't work.
I found the solution somewhere I didn't expect, in self-driving cars: an approach that, instead of reacting to a collision that has already happened, gets the physics ready for what is about to happen in the scene. It ports over almost unchanged.
Everything That Isn't Riding
This was the argument that settled it for me. At some point I sat down and wrote out the states the bike has to go through over the course of the game. What I got was a list where most of the entries have nothing to do with driving:
- Parked on its kickstand
- Parked on its kickstand and knocked over
- Going down while riding
- Lying on its side, on flat ground or on a slope, sliding or not
- Being picked up off the ground by someone standing next to it
- Being walked backward out of a parking spot with the rider's feet, engine off
- Rolling with the engine dead, bump-started
A vehicle movement system has no opinion on any of these, and that isn't a defect, it's scope. It's about moving a four-wheeled machine, and it does that well. But half of what a bike does isn't moving at all. So what I was running into wasn't the limits of the physics, it was the boundary of what the model set out to describe in the first place. Those are different problems, and only one of them can be fixed by tuning.
What Writing My Own Core Gave Me
Complete freedom and a pile of integration problems. I had to write my own collision resolution, and that wasn't a one-off task; it was the background hum of the entire project. On the other hand, every system after that fell into place without negotiating with someone else's model. Here's what came out of it.
The Bike Rests on Whatever Sticks Out
One detail is worth more than half the physics above it. After a fall, the handlebars turn toward the ground and stay turned. They don't spring back when the bike is picked up, and that matches how it behaves on a real motorcycle. Nobody notices this consciously, and everybody feels it.
But for that to work, you have to account for the shape of the bike, and an honest shape is expensive. I found a simpler option, and I liked how it turned out. The bike comes to rest on whatever actually sticks out, and it does it the same way take after take.
Sliding
The first version was simple: the bike goes down and bleeds off speed along a curve. On flat ground it looked fine, everywhere else it was absurd. The stopping distance on a two percent grade and on a twenty percent grade came out the same. I replaced that with an honest setup. The slope pulls, the surface resists, whichever wins is what happens. Out of that one rule came three behaviors I never wrote separately:
- On flat asphalt the bike travels a couple of meters and stops
- On a gentle grade it goes noticeably further and still stops
- Past a certain angle it doesn't stop at all and rides down until the terrain flattens out
This is what the whole thing was for. When a model actually describes the object, the interesting cases show up on their own. The same setup gave me a detail I hadn't planned on, for free. Static friction is higher than kinetic friction, which means it's harder to get a fallen bike moving than to keep it moving.
So the angle at which it starts creeping is slightly steeper than the angle at which it stops. There's a narrow band of slopes where the motorcycle lies there quietly until something nudges it. Nudge it, and it goes, and it won't stop again.
Picking It Up Should Be Hard
The bike goes down, slides along the asphalt, and comes to rest. From here, fail-state logic calls for a fade to black and a respawn. I wanted the opposite: this is the one moment in the game where you can let the player feel how much the machine weighs, and it seemed a shame to lose it.
From the player's side, it works like this. Walk up, grab it, hammer the button. There's a gauge; it drains on its own, and the bike comes up exactly as far as you keep pushing. Stop, and it goes back down. What you get is a small, exhausting event with a real chance of not making it the first time. It tests stubbornness rather than reflexes, which suits this scene much better.
Wheels
The wheels were what I fought with most, and the work turned out far harder than I'd counted on. The base is the Pacejka model, but reworked to the point where mostly the idea survives. And here's the thing I tried not to do. A lot of people hide gaps in the physics under the animation blueprint: the visuals draw what the model doesn't have. I went the other way, feeding the AnimBP real data from the physics instead of substituting animation for physics. It's more expensive, it takes longer, and it doesn't show up in a screenshot. It does show up in motion.
Seeing the Invisible
Almost none of this can be debugged by eye. A bike lying one centimeter wrong looks perfectly correct right up until a shadow gives it away. So a good part of the year went not into simulation but into being able to see what the system believes. Where it thinks the ground is, what it thinks is touching, where the weight sits, whether it's actually at rest or just moving very slowly.
This doesn't come up often when people advise you to write your own system. No built-in tooling is going to explain your own model back to you, so you have to treat diagnostics as part of the work rather than preparation for it. Every hour I put into being able to look paid me back several times over.
Honestly, the volume of work here for one person is such that it really ought to be a talk rather than an article. Or a book.
Would I Do It Again?
For this game, yes. The bike here has character, and half of what it does was outside the boundary of the vehicle model. If the motorcycle were just a vehicle between missions, then no. In that case, Chaos plus a stabilizer is the correct engineering answer, and I'd have closed the task in two weeks instead of a year.
Here's the test I'd offer anyone facing the same choice: write out every state your object has to go through. If most of them are about getting from A to B, take the engine's system. If they aren't, tuning won't get you there. What else I'd tell myself at the start:
- Tooling gets written before the simulation, not after the first unsolvable bug.
- Failure states are designed as a full feature from day one. Mine started as a patch on top of the riding code and only worked once they became their own thing.
- The last centimeter costs more than the first meter.
- Don't trust your own confident comments in the code. I spent months looking in the wrong place because I believed a note I'd written myself.
Conclusion
Everything described above is a small part of the work. Living alongside it in the same system are the suspension, a two-stage shock damper, the fork and swingarm, tires, steering and countersteering, lean, drift, a fuel system with a battery, a throttle on the twist grip, and an engine with a curve taken from real physics. Plus an enormous number of small things I've already forgotten.
Riders were a separate source of revisions, myself included. Some things in this system came not from a paper and not from a formula, but from a feeling that something was off, which first had to be caught and then explained to myself.
One small thing that didn't fit into the article but is worth mentioning: the throttle sits on the mouse wheel. It sounds strange right up until you try it, and after that a normal analog trigger starts to feel crude. But that's a separate conversation.
The project is in active development.
