Game Development Reference
In-Depth Information
This is fine for simple simulations, where the amount of code is small and the
scope of the physics is quite limited. As we'll see, a basic particle system can be pro-
grammed in only a hundred or so lines of code. When the complexity increases, it
can be difficult to get straight to a believable physical effect. In the original Half-Life
game, for example, you can push crates around, but the physics code isn't quite right,
and the way the crates move looks odd. The difficulty of getting physics to look good,
combined with the need for almost the same effects in game after game, encouraged
developers to look for general solutions that could be reused.
Reusable technology needs to be quite general: a ballistics simulator that will only
deal with arrows can have the behavior of arrows hard-coded into it. If the same
code needs to cope with bullets too, then the software needs to abstract away from
particular projectiles and simulate the general physics that they all have in common.
This is what we call a “physics engine”: a common piece of code that knows about
physics in general but isn't programmed with the specifics of each game's scenario.
There is an obvious hole here. If we had special code for simulating an arrow,
then we need nothing else to simulate an arrow. If we have a general physics engine
for simulating any projectile, and we want to simulate an arrow, we also need to tell
the engine the characteristics of the thing we are simulating. We need the physical
properties of arrows, or bullets, or crates, and so on.
This is an important distinction. The physics engine is basically a big calculator:
it does the mathematics needed to simulate physics. But it doesn't know what needs
to be simulated. In addition to the engine we also need game-specific data that repre-
sents the game level.
Although we'll look at the kind of data we need throughout this topic, I won't
focus on how the data gets into the game. In a commercial game there will likely
be some kind of level-editing tool that allows level designers to place crates, flags,
ragdolls, or airplanes: to set their weight, the way they move through the air, their
buoyancy, and so on.
The physics engine we'll be developing throughout this topic needs gradually
more and more data to drive it. I'll cover in depth what kind of data this is, and
what reasonable values it can take, but for our purposes we will assume this data can
be provided to the engine. It is beyond the scope of the topic to consider the toolchain
that developers use to author these properties for the specific objects in their game.
There are two compelling advantages to using a physics engine in your games. First
there is the time saving. If you intend to use physics effects in more than one game
(and you'll probably be using them in most of your games from now on), then putting
the effort into creating a physics engine now pays off when you can simply import it
into each new project. A lightweight, general-purpose physics system, of the kind
we develop in this topic, doesn't have to be difficult to program either. A couple of
thousand lines of code will set you up for most of the game effects you need.
Search Nedrilad ::

Custom Search