Game Development Reference
In-Depth Information
The second reason is quality. You will most likely be including more and more
physical effects in your game as time goes on. You could implement each of these
as you need it: building a cloth simulator for capes and flags, and a water simulator
for floating boxes, and a separate particle engine. Each might work perfectly, but you
would have a very difficult time combining their effects. When the character with a
flowing cloak comes to stand in the water, how will his clothes behave? If the cloak
keeps blowing in the wind even when underwater, then the illusion is spoiled.
A physics engine provides you with the ability to have effects interact in believable
ways. Remember the movable crates in Half-Life 1? They formed the basis of only one
or two puzzles in the game. When it came to Half-Life 2, crate physics was replaced
by a full physics engine. This opens up all kinds of new opportunities. The pieces of a
shattered crate float on water; objects can be stacked, used as movable shields, and so
on.
It's not easy to create a physics engine to cope with water, wind, and clothes, but
it's much easier than trying to take three separate ad hoc chunks of code and make
them look good together in all situations.
1.2.2
W EAKNESSES OF A P HYSICS E NGINE
This isn't to say that a physics engine is a panacea. There are reasons that you might
not want to use a full physics engine in your game.
The most common reason is one of speed. A general-purpose physics engine is
quite processor intensive. Because it has to be general, it can make no assumptions
about the kinds of objects it is simulating. When you are working with a very simple
game environment, this generality can mean wasted processing power. This isn't an
issue on modern consoles or the PC, but on hand-held devices such as phones and
PDAs it can be significant. You could create a pool game using a full physics engine on
a PC, but the same game on a mobile phone would run faster with some specialized
pool physics.
The need to provide the engine with data can also be a serious issue. In a game
I worked on recently, we needed no physics other than flags waving in the wind. We
could have used a commercial physics engine (one was available to the developer),
but the developer would have had to calculate the properties of each flag, its mass,
springiness, and so on. This data would then need to be fed into the physics engine to
getittosimulatetheflags.
There was no suitable level-design tool that could be easily extended to provide
this data, so instead we created a special bit of code just for flag simulation; the char-
acteristics of flags were hard-coded in the software, and the designer didn't have to do
anything special to support it. We avoided using a physics engine because special-case
code was more convenient.
A final reason to avoid physics engines is scope. If you are a one-person hobbyist
working on your game in the evenings, then developing a complete physics solution
might take time from improving other aspects of your game: the graphics or game-
play, for example. On the other hand, even amateur games need to compete with
Search Nedrilad ::




Custom Search