I've been asked a lot about how we made the controls in Stopn't. As always in game dev, the answer is smoke! Smoke and mirrors!

When considering a racing game, the important things to consider are the stability of the physics simulation and the fluidity of the motion in order to get something going really, convincingly fast without tunneling through walls or clipping into the ground. These hold true for all racing games, but for this one in particular as an arcade-y sci-fi hovership racer we also want to capture a particular 'floaty' feeling to get airtime when going over hills.

First, addressing the physics stablity. I started by turning up the physics resolution to 240Hz, meaning you could expect 4 physics ticks to happen for every rendered frame.

The track is actually composed of 3 separate meshes - a floor, some walls and the graphics mesh. The first two are much lower resolution, with the intent of being as smooth as possible to make things easy for the ship's physics calculations. Additionally, the wall colliders are much taller than they appear, to stop the ship bouncing over the low walls too easily. Then, still on collision, we tried a few iterations on ship collider shape before settling on... a spherical cow a sphere. Yep! Turns out to make a satisfying and performant physics racer you really can assume your vehicle is spherical, however pointy it may actually be.

However, stable physics are not necessarily smooth. As the ship aligns itself with the track mesh's normals there's a noticeable 'jerk' when the angle of the ground changes, either as part of an incline or when navigated a banked turn. Also, while cranking the gravity helped the ship stay grounded, this wasn't very fun to watch and made for weird, jerky camera movements.

My first approach to this was to try simulating forces with magnets. This went about as well as you could expect, as by moving the physical craft up and down a bunch I made the collision model less stable without actually gaining much in the way of floatiness. It also would have required me to manually keep track of intertia and adjust the craft's path accordingly, which got very complicated very quickly.

After doing some research into the matter, I came across a technique that suggested separating the physics from the graphics entirely. Instead of having the ship model as a child of the object with the rigidbody, it could instead be a sibling and be configured to follow the rigidbody along its jerky path. By virtue of being physicsless, it became suddenly extremely easy to adjust the flowing movement of the ship, without affect the physics of the situation at all. The graphics could now follow slightly behind the physical ship, having the chance to adjust its position and rotation on every rendered frame instead of being dragged through the mess of colliders and raycasting the rigidbody would pull it through.

In this clip, I added a white ship model to the physics object to visualise its position in relation to the graphics that follow it. I am extremely impressed with the ruggedness and elegant simplicity of this technique and now intend to employ its lessons in every game I make. The future is smooth!