T w e n t y S i d e d

I’ve run into a lot of problems with oversimulation in the past, where a programmer tries to replicate the behavior of a complex system with brute force. I’ve done it myself, and I’ve witnessed the results when others did it. The results are usually time consuming, maddeningly complex, and prone to a variety of hilarious failure modes. If you’ve ever played a buggy driving game where complex crashes led to nonsensical results, then you’ve probably seen oversimulation in action.

I’ve seen several games recently where heaps of random objects will “twitch” and “bounce” on top of each other instead of coming to rest. I also remember playing a game (back in the late 90’s) where two cars managed to intersect during a crash. They began to jerk around wildly, each attempting to come to rest on the ground but then “bumping into” the other car. This would nudge the other car up, causing it to fall harder, causing it to bump back harder, and building a nasty feedback loop until one of the cars was knocked free of the impasse and blasted into the stratosphere. Made me giggle. Not that I’ve seen the source for either game, but in both cases I suspect oversimulation is the source of the problem.

The key to making a good simulation is knowing when to replicate and when to approximate. Keeping in mind that in videogame it doesn’t need to be right, it just needs to look right.

Gravity is the most obvious example of something to replicate. The mathematics behind it are astoundingly obvious and well-known. It wouldn’t save you any time to “approximate” the effects of gravity. Just make everything fall at the correct rate and it will look right.

On the other hand, tires interacting with the road is a far more difficult subject. The SHAPE of the tires is exactly the sort of thing you want to approximate. Tires are not perfect cylinders. Off-road tires have maddeningly complex topography. They’re very knobby, with lots of deep groove patterns. You’ll kill yourself if you try replicate this shape in 3D and then do per-polygon collision on those bumpy surfaces as they touch the road, and then try to figure out how much “grip” you’re getting at the moment. The system will most likely fail, and you’ll find yourself adding more and more complexity trying to fix it. You’ll realize you’re not taking into account the effects of dust and dirt clinging to the wheels. Or what happens when the grooves become caked with wet mud. Or you need to account for the way tires bend a bit to “embrace” a small convex surface, like small rocks or imperfections in the road. Or take into account structures which should puncture the tire. Things can get impossibly complex very fast if you try to replicate everything.

No, this is probably the perfect time to approximate. For the purposes of collision with the road, treat all tires like perfect cylinders, and then have a few variables (smoothness, temperature, and a guess about how much of the surface area is touching the road) govern how much “grip” you’re getting. This method will be easier to code, less CPU intensive, and will most likely look far more realistic.

I think a good sense of when to simulate and when to approximate is more important than a deep understanding of physics when it comes to writing a good physics engine. (Although finding someone with both is always nice.)

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.