Physics For Game Developers 328
| Physics For Game Developers | |
| author | David M. Bourg |
| pages | 326 |
| publisher | O'Reilly |
| rating | 8 |
| reviewer | Richard Jones |
| ISBN | 0-596-00006-5 |
| summary | A good introduction to the difficult subject of writing 3D games and simulations with accurate physics, let down by a few minor snags. |
Programmers who want to get serious about game physics will love David M. Bourg's Physics for Game Developers. As I've said, the subject is inherently very difficult, and the book assumes that you are already familiar with vector and matrix arithmetic up to college level, integration and differentiation, and at least you hazily recall your mechanics/physics lessons from school. You also won't be afraid to wade through Bourg's carefully documented derivations of formulae for various physical effects, and his well-commented source code.
The book starts off by recapping the basic concepts of mass, centre of gravity, moment of inertia and inertia tensors. Bourg assumes that you have a working grasp of these subjects, and I admit that I had to go back to some of my A-level mechanics text books. He then goes straight into kinematics, where he uses standard (but forgotten!) integration techniques to calculate velocities from accelerations and positions from velocities. His examples are excellent, although a few exercises wouldn't have gone amiss. The chapter on forces covers a great many different types of forces such as springs and buoyancy, but curiously omits the important subject of contact forces (the normal force that a table, for instance, exerts on your computer monitor to stop it falling through the floor). In fact contact forces don't appear until much later in the book. Particles, rigid bodies and impulses (forces from collisions) are introduced in chapters 4 and 5.
At this point I have to say I was a little bit confused. What did this have to do with game programming? Everyone knows that games spend most of their time running round a single big "main loop," working out the forces on each object, looking for collisions and working out which keys the user is pressing. It doesn't seem imaginable that a game programmer could completely solve all the equations of motion by pure integration at the beginning of the game, and then just run the positions of the players through the graphics engine like a movie!
I already knew a little about this from what I'd found from the web, but what most games actually do is calculate all the forces on all the objects (players, scenery, etc.) in the game, and then integrate them at each step. Some of these forces will be generated by human players pressing keys on the keyboard or wiggling the joystick, and that's how the objects end up moving. Pure integration isn't usually possible, so the physics engine performs numerical integration - a kind of fast approximation to the pure "closed form" solution. Numerical integration is itself a tricky subject, but it's the meat-and-veg of good game programming. Surprisingly, numerical integration and a realistic main loop doesn't appear until chapter 11 (172 pages into the book). I skipped straight to this section, and I suggest you do so too...
The chapter on numerical integration is excellent and contains the first realistic gaming (or at least simulation) code. Many games I've examined use simple numerical integration, like this:
// At each step ... A = acceleration, dt = time step
Vx += Ax * dt;
Vy += Ay * dt;
Sx += Vx * dt;
Sy += Vy * dt;
Unfortunately this method (Euler's method) is very inaccurate and unstable: if you tried to simulate planets orbiting around a sun using this method, they'd soon fly off into outer space unrealistically. Bourg gives an excellent introduction to better methods such as the "improved Euler" method and the popular Runge-Kutta method, and he covers them in a context which will make it clear how to use these methods in your own programs.
The book reaches a crescendo with three fully developed simulations: two hovercraft which you can drive around and jolt into each other like bumper cars -- they spin around realistically; a flight simulator; and a 3D car which can be crashed into blocks that bounce around. Again the source code is meticulously commented and generally well written. My only two reservations about the code are: It would be nice if Bourg had chosen to use OpenGL instead of Direct3D so that those of us without regular access to Windows could actually compile and run the examples. The book would make an ideal companion to the OpenGL Red Book. And coming firmly from the Windows camp, Bourg's examples are full of all the horrors of Win32 APIs and Hungarian Notation. But maybe that's just my personal preference :-)
So in summary: The Bad Points:
- Measurement systems: Bourg moves uneasily between the English/US system and the European SI units. So we get examples which combine ft/s, meters, slugs and kilograms, uneasily converting between the two. He should have chosen one system and stuck with it.
- A common complaint about computer books: I've just spent 25 quid on a book which will sit open on my desk for months. Is it too much to ask that it be ring bound?
- Some subjects are not explained in enough depth. Particularly: moments, contact forces, impulse methods. Bourg should probably have written a chapter or three on collision detection.
- The chapters are presented in a very strange order. Move chapters 6-10 until later, or introduce numerical integration earlier.
- A few of the illustrations are inaccurate.
and The Good Points:
- Considerably better than the usual round of maths/physics text books which make up this field. In fact, this is really one of only about 2 or 3 significant books in this area which are pitched for game developers as opposed to mathematicians, and it's certainly the best.
- The areas which are covered are done well, in significant depth, with a good bibliography where you can find out more.
- The commentary on the difficult equations is good, and Bourg resists the temptation to derive many of the formulae he presents, instead referring interested readers to other references.
- Code is well documented and explained.
And now I suppose I have no excuse not to resurrect XRacer :-)
You can purchase Physics for Game Developers at Fatbrain
Physics in games (Score:2, Insightful)
How about "extreme game programming"? (Score:3, Insightful)
So pair up a couple of guys. One to worry about the artistic design, and another to worry about realistic physics.
Physics isn't everything (Score:3, Insightful)
A better book to read for Game Physics... (Score:3, Insightful)
Lets face it, the best physics is REAL physics.
If you want your game to have good physics, then slap a good physics engine (based on real formulae) into it!
Don't need to be that exact (Score:2, Insightful)
I think it is more important to include as many effects as you can: gravity, linear momentum, angular momentum, elastic/inelastic collisions, friction (surface and wind), than it is to model the effects perfectly.
In fact one could argue that it is to the game designer's benefit to use an innaccurate and exaggerated physics model. Most real world collisons with the guard rail on a race course are relatively unspectacular (by design) - but that would be oh so boring in a racing game now wouldn't it?
-josh
Re:throw physics out the door... (Score:2, Insightful)
Even on games where there doesn't appear to be any need for modular physics, there will always be some mod author that sees a need. Say you are writing a racer, you might think that the physics should be fixed to real-world physics, but the mod author that wants to write a 'dune buggies on the moon' mod, is going to disagree with you, so keep it modular :)
Re:A better book to read for Game Physics... (Score:2, Insightful)
Sure, the formulas used are *based* on the regular "scientist" formulas, but they *have* to be approximations. The book tells you how to use do those approximations.
If you give a coder a standard physics textbook and tell him to code a physics engine, he'll either implode or spend ages working out numerical methods for approximating real physics... exactly what is in this book.
Re:How about "extreme game programming"? (Score:2, Insightful)
Actually, Half-Life is based upon the Q2 engine and is a lot better than Quake 2 itself.
Maybe John Carmack should just focus on building 3D engines which game developers could than use to produce brilliant games.
Re:Don't need to be that exact (Score:5, Insightful)
Unrealistic suggests that it doesn't behave as in the real world -- but that doesn't mean it isn't modeled on the same principles (acceleration, momentum, etc.) And you still want to simulate it consistently; it should "feel" right.
But an unstable computation method can "blow up", regardless of realistic or unrealistic "physics."
Consider:
Jump pads in games like Quake or Unreal are "unrealistic". But they are modeled at least partially on physics. But to make them work right, in all their unrealistic glory, the computation method must be stable.
If it wasn't stable, then you might something like:
- Multiple, successive jumps on one would lead to a "blow up" where the player would be wildly, and unexpectedly shot through the roof and to the outer edge of the game universe.
For both realistic and cartoon physics, you need accurate and stable computation methods.
Who wants realistic physics? (Score:5, Insightful)
And in *any* game where people jump, realistic jumping becomes completely pointless. People want to be superhuman. Imagine quake with realistic physics....
Realism is not the high mark of games in all aspects, that is the whole point of games, to escape reality...
Basing a whole game around the physics (Score:2, Insightful)
One thing great about this book (Score:2, Insightful)
The book is a good reference to have. To me this would be good to have because I already "learned" all of this, but like most don't remember all of it. Having all these equations right in front of you will enable you to remember everything swiftly and apply what you need to.
Like most O'Reilly books, this is a good reference to have, and I think it should be bought by people that already know most of the basic physics stuff.
LordOfTheRingBound? (Score:2, Insightful)
The book is not ring bound because it costs 25 quid (= British Pounds).
'Twould be far too easy to stick it through a photocopier or scanner if it were.
Re:Who wants realistic physics? (Score:3, Insightful)
It is true that in some games -- a combat flight simulator, for instance -- one design goal would be to achieve the most realistic physics possible. The average kid popping quarters into an arcade game isn't looking for realism, but some folks certainly will.
However, I think the importance of _self-consistent_ physics is quite critical. You can invent your own set of "physical laws", which may be similar to those we are familiar with (ie, with moon gravity instead of Earth gravity) or completely and utterly different (ie, with Matrix-like time and space distortions or a Tolkien-like world replete with magic). However, the world you put forth should appear at once both plausible and self-consistent. Indeed, knowing real physics and the numerical methods to treat it would certainly help game programmers in their own constructions, if only by serving as an intricately balanced example which can serve as a launching point for their work.
Bob
Re:Games aren't about realistic physics (Score:2, Insightful)
But, guess what - even if your computer game has a G that would crush humans, or elasticity that makes super balls look tame, or centers of gravity below the pavement, it still needs to be CONSISTENT.
And being consistent means modeling real world physics. With tweaks.
If you don't model real world physics properly though you're going to end up with erratic behavior that will either lead to frustrated players or exploitation by players (which often trivializes the game).
And while I never thought about it, now I understand the purpose behind some of the abysmal math courses I took in college. I guess it's a good thing I don't do game coding, since I certainly don't recall much at all from those courses. (Another reason why math profs should come out of their theoretical world and mention real world uses for some of the stuff upon occasion).
Re:throw physics out the door... (Score:2, Insightful)
I think accurate physics MUST be present in most motion-oriented games so that the control feels more natural (i.e. feels like what would happen in THIS universe). You can change masses, gravitational constants, whatever, to make objects in your world to WHATEVER you want them to do, but F=ma should still apply
A course in mechanics (Score:2, Insightful)
Re:Runge-Kutte? Give me a break! (Score:3, Insightful)
Even if the gravitational force were extremely strong, it wouldn't make much difference in space battle. You still point the missile at the enemy and shoot it. You, the missile, and the enemy are all accelerating toward the sun at equal rates. The fact that a G-field is present makes absolutely no difference, since the field is uniform, at least when you are quite far from the sun and the spacecraft are relatively close to each other. In a fun game, the craft will not be far apart, since it's not much fun to fire on an an enemy when you can't see the pretty explosion.
Look, I'm going on and on about a specific example, when my real point was much more general. "Realistic" behavior of objects can be very closely approximated with very simple methods. The player will not know the difference. Problems such as integrations "blowing up" can be easily avoided simply by looking for the blow-up and correcting for it.
if you don t know you defy, you don t defy ! (Score:1, Insightful)
"real" physics?! (Score:3, Insightful)
Second, the usual 100-level undergrad textbook in physics tells you a lot of things that you probably don't need to know when designing games (like E&M and some quantum mechanics), but also leaves out the more practical aspects of classical mechanics when dealing with less-than-ideal objects. Once you work with the motion of objects that are not spherically symmetric, you need mechanics at the next level, and you need to work with matrices and vectors. This stuff isn't difficult, but it's not in the typical undergrad textbook. And it does require a bit of mathematics, like most things that are worthwhile.
So it sounds to me like this book does have an important niche to fill, combining undergrad classical mechanics, a sampling of junior-level classical mechanics, and some numerical methods to boot.