## Oversimulation

By Shamus Posted Thursday Jun 14, 2007

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.)

## 27 thoughts on “Oversimulation”

Actualy, this is a very good read. I too have seen many of the things that you list. Gravity in an MMO that simulates falling damage is another very complex issuse that is nomaly calculated something like (air time x damage value). This works until one is stuck in the air via lag or from falling on another model (normaly NPC) and being suspended in such a way that the games sees you in free fall.

Back in the beginning of my MMO (Dungeons and Dragons Online) there was a gravity bug: Walking along a hall way and you recieve 200-400 falling damage. In a game that the average Hit points at the time were 100-180 that was alot of damage. It came from the game not having all the instance built and then sudenly creating a missing part and said part would “fall” on you. Funny but not fun.

2. wildweasel says:

This reminds me of a game from about 8 years ago – a Sierra racing game called Viper Racing. I would spend hours in the time trial mode, goofing around with the crash physics. I played around with the Wheelie button (inexplicably included with the demo, along with “Horn Ball” which launched a big ball out of your hood when you honked the horn). I would create crash after crash, using the Wheelie button to launch my car into the air until it was crushed so much that it was little more than a lump of tires. And were the engine not blown already, I could probably have raced like that.

3. maco says:

Very true! It seems to be in the newer games that suffer from this, so I suspect it’s the game engine designers playing the raw power of modern CPU’s. I suppose with time, the algorithms will be refined and things will get better.

Then again, a couple of old games had this issue as well… Carmageddon was brilliant, as you could play ‘car ballet’ for hours on end :-D

4. Mmmh… Broderbund Software STUNTS. A crash at a weird angle and suddenly you were playing a flying simulator.

5. The Gneech says:

As everybody and their brother jumps on the “powerful graphics card” bandwagon, things are being way over-rendered, too. The opening movie for Lord of the Rings Online animates every lock of hair and every fold of skin, to the point where faaaabulously coiffured rangers are fighting rubber-skinned orcs.

Yeeks. 0.o

-The Gneech

6. Lee says:

I remember playing Driver, and getting into an accident and having one of the cars fly 100 feet in the air. I could replicate this fairly often, and every time it was AWESOME.

7. gyokuran says:

Reminds me of Elite 2, an old 1.4 MB big DOS game. The physics model was astoundingly well done, one could use momentum or the gravity of stars to save fuel, or make maneuvers in combat – nothing quite like a 180 degree turn still flying backwards and shooting at the hapless pursuer…

8. wererogue says:

I think there may come a time where a full physics model is usable in a game (accompanied most likely with a HUGE library of models and the physical properties of the materials that they are composed of).

That ain’t now though. It’s a long way off. And it may well be a crappy game.

9. Telas says:

Shift the paradigm to RPGs… If you try to recreate every element of a swordfight, you’re left with an ungainly system that takes forever to do anything, and leaves you with unlikely results. (I’ve done some full-contact stuff; it’s far more complex than foam weapons and who-hit-who-first.)

Far better to roll a d20, add some modifiers to it, compare it to another number, and imagine how you’d get that result from the situation.

10. Doug Sundseth says:

As Telas notes, this isn’t just a problem with computer games (or game-like toys). Bottom-up simulation of complex systems is quite likely to run into Chaos problems. Minor errors in critical places synergize to produce a result that makes no sense when viewed from the top.

For another place to see this, take a look at 70s-80s wargames and miniatures rules (AH’s Tobruk, WRG’s 6th and 7th edition, SPI’s AirWar, etc.). At the time, people wanted games that explicitly simulated more and more details at lower and lower levels, because that was thought to be more realistic. The result was slow, painful, and often a poor simulation.

Most modern games in that genre are much more top-down designs. The designer starts with the desired result, works out where the players’ important decision points are, then builds the game from there. The result, when done well, plays faster and with less pain and gives a more plausible result. But you have to avoid the temptation to try to figure out what each game mechanism explicitly includes from the subject being simulated.

11. Scott says:

While gravity (8.9 m/sÂ²) and velocity are fairly easy to program into a game, other factors in physics can be extremely difficult; like friction, momentum and inertia. The reason why games have so much trouble with physics is because it’s really hard to make objects act as if they had appropriate mass.
[For this argument, I am talking about mass. Weight would use the same attributes, but would have to become a separate variable if the character traveled to a place with less or more gravity (PREY) and would affect some things (like friction), but not others (like inertia and momentum)]
Assuming that assigning mass to a virtual object is easy (not affecting gravity since all objects fall at the same rate), programmers would still have to allow the mass to affect how far the object can slide on the ground (friction) compared to another object with a different mass of the same material (another factor in friction) on the same surface. Also, the programmers would have to take into effect that the more mass an object has, the more energy is transferred when it hits an object (momentum) and the harder it is to start or stop moving the object (inertia). This gets especially tricky when you are dealing with the character pushing an object to move it. First the character would have to exert enough force to move the mass of the object (inertia) and to overcome the static friction the object has. Once the object is moving, kinetic friction comes into play and you have to deal with how far it slides based on friction and inertia, and what happens when it hits another object and transfers it’s energy.
Fortunately (or is it unfortunately?), in the context of a single game, programmers don’t really need to do this. If an object is really small, they give it really small mass, if it is really big, it is part of the map and won’t move even if you shoot rockets at it. Little things slide a lot, big things don’t slide too much (usually), and inertia is too complicated to program for a \$30 game. And forget about relativity. If you shoot a bullet from the side window of a car moving at 70 mph, I don’t think programmers are taking into account that the bullet is still moving sideways at 70 mph… it’s just not worth it. And I really won’t start on air resistance or terminal velocity.
Unfortunately, we are so used to seeing these natural forces in play, that whenever something is missing or out of place, we notice right away. I say, let it slide! Video game physics have made leaps and bounds since the 1970’s and they get better every day. The perfect physics engine will come, but we have to let programmers balance out all the crazy new variables they are now able to shove into their games.

12. ZackTheSTGuy says:

Scott said:
If you shoot a bullet from the side window of a car moving at 70 mph, I don't think programmers are taking into account that the bullet is still moving sideways at 70 mph… it's just not worth it.

Actually, in gaming engines as early as DOOM, this WAS taken into account somewhat, at least for the slower moving projectiles like plasma balls and rockets. If your character was strafing to one side and fired, the projectile would follow a decidedly ‘diagonal’ course en route to impact. Standard bullets in the DOOM engine, however, were more or less ‘instantaneous’ and impacted the point directly in front of the character regardless of movement.

13. DaveP. says:

Motorcycle riders have an ideal concept called ‘transparency’. The concept is that when riding, you should NOT have to spend a lot of time performing tiny course corrections, fiddling with your body language, or otherwise being forced to pay attention to the bike instead of to your riding experience. A transparent bike is one you just get on and ride; if you want to hit a corner you just choose your line, press-lean-roll, and there you go.

To my mind that transparency is THE most valuable commodity in games, either computer or pen-and-paper. The more time I have to spend hunting down arcane rules in poorly-written sourcebooks, the more time I have to waste learning overly-complex keyboard-mouse/gamepad controls or wonky physics models, the harder it is to relax into the game and the less time I actually have to do things like roleplaying and having fun.

Make the physics transparent, folks. Make it so I don’t have to “learn” gravity. Your players will thank you.

14. Akatsukami says:

It seems to be in the newer games that suffer from this, so I suspect it's the game engine designers playing the raw power of modern CPU's.

Not altogether. When I was in college (back in the mid-1970s), I played a spacewar game that was quite explicit in posting unit units (initial position distance, velocity, etc.) A glaring oversight was the main drive on the one-man fighter starship; it didn’t specify the unit of acceleration…but judging by the changes in velocity that it caused, was capable of accelerating the starship at approximately one million Gs!

I pointed out to the developer that this was rather unrealistic, particularly since had explicitly eschewed artificial gravity as having no basis in physics. He cheerfully added an a-grav system to the ship…a rather cheap one, that had a significant chance of failing anytime a multi-kilo-grav manuever was attempted, thereby ending the game.

15. Ishmael says:

The biggest example of this in a game I have played has been in Oblivion. Not counting the Remote Manipulation spell (which was capable of creating some truly hilariously physics-breaking situations), it always disturbed me when I’d kill an enemy and, instead of falling limply to the ground, they’d tumble through the air, hit the ground, and then just keep twitching convulsively until I walked away.

16. Scott says:

In Oblivion, you could also jump above an object while holding it, then jump on it while it was still in the air… over and over again. Jumping over buildings with a pair of pants is fun!

17. Schurk says:

Well, talking about funky in-game physics, try this one here

seems the developers had quite a laugh with this.

18. Miral says:

Scott: “While gravity (8.9 m/sÂ²) and velocity are fairly easy to program into a game”

(cough) 9.8 m/sÂ², actually ;)

It’s quite disconcerting when objects get “stuck” in the ground and keep playing their “impact” sound over and over again while twitching madly. I’ve had that happen in quite a lot of games :)

19. Qujoe says:

Still catching up on old posts so this is a little post-dated. I recently saw that Alienware was including a new physics processor as something you could add to your computer. It is a card dedicated to doing physics calculations and already a few games are designed to work with this card.

Here is a link to the PhsyX card by AGEIA.

20. yoshi927 says:

You’d think if they go that far with a physics system, they might as well put in conservation of energy so that you can’t have your car blown into the stratosphere.

21. Illiterate says:

This blog keeps giving me the urge to start coding again.

22. Sydney says:

yoshi:

I don’t think that would help much, considering the way most games handle “energy”. The gas pedal in a car doesn’t “convert” energy per se – rather, it just generates kinetic energy pointed away from the camera. Injecting conservation of energy into, say, a racing game would just break the “go” button, and not much else would happen. You’d have to simulate an internal-combustion engine, and that’s just for one command.

23. Tizzy says:

CGI-animated movies rely also on crazy amounts of simulation. To this, they have to add another layer of insane complexity, where they have millions of ways to directly act upon individuals elements to make the scene look right.

Conclusion: even when you have colossal computational power and you’re not limited to real-time rendering, the result of the simulation must be fixed by hand to look right. Now you know why it takes so long for Pixar to make a movie.

24. Chris says:

Rays can also be used to simulate where the tire collides with the terrain, this can give more control over the type of contact that is modelled if you can specify the friction between the ray and the ground. The problem with spheres is that they are too curvy, the problem with cylinders is the hard edges. Anyway, none of the three solutions is perfect.

25. Zak McKracken says:

As an engineer, I can tell you that the best way to go about simulation is first understanding as much as is understandeable of the system, then deciding wich parts to cut away, which ones to keep and which ones to replace by an approximation. And be sure you make a nice clean cut there, because in the end every relevant effect still needs to be accounted for.
That’s for example what the CG people in Jurassic park (and really, many other CG people at that time) did not get. No need to do a full physical multibody simulation, but just drawing splines for the paths when a dinosaur leaps? Looks artificial, even to untrained eyes. Using a parabola instead of a spline would have solved that (apart from the landing, which requires a spring/mass model or something). To their excuse, the software they had available was probably not comparable to today’s, even though computing s=1/2*a*tÂ² was certainly not beyond their processing power.

For these things, good knowledge of maths is also extremely helpful because sometimes there’s just this small part in your formula that makes it so obnoxious to compute, and then you find that if you change that other part just a bit the two will cancel each other out. There’s a whole new world of simplification opportunities if you can manage to set up a complete mathematical model of what you’re trying to simulate. You won’t believe what you can (and sometimes have to) get away with in CFD: http://en.wikipedia.org/wiki/Computational_fluid_dynamics

Oh and I need to link to this. Simulation FTW!
Just masses, springs and linearised Newtonian physics.

26. Neil Roy says:

Someone mentioned Elite 2, interestingly enough, Elite is one of the first procedurally generated games I know about. The entire universe, which was HUGE was generated at run time. It’s what got me personally interested in this sort of thing and ultimately led me to this great website.

You can enclose spoilers in <strike> tags like so: