Game Development Reference
In-Depth Information
types—then don't write one. Instead, write one specifically optimized for the game
you're working on.
Let's consider a few examples. Let's say you're writing a 3D first-person shooter and you
want to use physics to simulate how wooden barrels and crates blow apart when shot.
Typically, such an effect would show pieces of wood flying off in different directions
while falling under the influence of gravity. You could simulate such an effect in 3D
using rigid bodies and you wouldn't even need to consider collisions, unless you wanted
the pieces to bounce off each other or other objects. Ignoring these aspects greatly sim‐
plifies the underlying physics engine. Consider another example. Let's say you're work‐
ing on a game involving flying an airplane. You can use physics to simulate the flight
dynamics, as we explain in this topic, without the need for particles, connectors, or even
collision response.
The point of all this discussion is that you should consider which aspects of your game
will really benefit from physics and write your physics engine to deal specifically with
those aspects.
Another thing to consider is whether or not you need real-time physics. You might
expect, after reading the available game physics literature, that your game must include
real-time simulations if it is to incorporate physics. However, there are many ways to
include physics in a game without having to solve the physics via real-time simulations.
We show you an example in Chapter 19 whereby a golf swing is simulated in order to
determine club head velocity at the time of club-ball impact. In this case, given specific
initial parameters, we can solve the swing quickly, almost instantaneously, to determine
the club speed, which can then be used as an initial condition for the ball flight. The
ball's flight can be solved quickly as well and not necessarily in real time. It really depends
on how you want to present the result to the player. If your game involves following the
flight of the ball as it soars through the air, then you might want to simulate its flight in
real time so you can realistically move the ball and camera. If, however, you simply want
to show where the ball ends up, then you need not perform the simulation in real time.
For such a simple problem, you can solve for the final ball location quicker than real
time. Sometimes, the action you're simulating may happen so fast in real life that you'll
want to slow it down for your game. Following a golf ball's flight in real time might have
the camera moving so fast that your player won't be able to enjoy the beautifully rendered
bird's-eye view of the course. In this case, you rapidly solve the flight path, save the data,
and then animate the scene at a more enjoyable pace of your choosing.
We don't want to come across as trying to talk you out of writing a physics engine if you
so choose. The point of our discussion so far is that you simply don't have to write a
generic, real-time physics engine in order to use physics in your games. You have other
options as we've just explained.
Assuming that, after all these considerations, you need to write a physics engine, then
we have the following to offer.