Game Engine Architecture

(Ben Green) #1

1.6. Runtime Engine Architecture 41


z tools that allow debug print statements to be peppered throughout the
code, along with an ability to turn on or off diff erent categories of debug
output and control the level of verbosity of the output;
z the ability to record game events and then play them back. This is tough
to get right, but when done properly it can be a very valuable tool for
tracking down bugs.

1.6.10. Collision and Physics


Collision detection is important for every game. Without it, objects would in-
terpenetrate, and it would be impossible to interact with the virtual world
in any reasonable way. Some games also include a realistic or semi-realistic
dynamics simulation. We call this the “physics system” in the game industry,
although the term rigid body dynamics is really more appropriate, because we
are usually only concerned with the motion (kinematics) of rigid bodies and
the forces and torques (dynamics) that cause this motion to occur. This layer
is depicted in Figure 1.24.
Collision and physics are usually quite tightly coupled. This is because
when collisions are detected, they are almost always resolved as part of the
physics integration and constraint satisfaction logic. Nowadays, very few
game companies write their own collision /physics engine. Instead, a third-
party SDK is typically integrated into the engine.


z Havok is the gold standard in the industry today. It is feature-rich and
performs well across the boards.
z PhysX by NVIDIA is another excellent collision and dynamics engine.
It was integrated into Unreal Engine 3 and is also available for free as
a standalone product for PC game development. PhysX was originally
designed as the interface to Ageia’s new physics accelerator chip. The

Collision & Physics

Shapes/
Collidables

Rigid Bodies Phantoms

Ray/Shape
Casting (Queries)

Forces &
Constraints

Physics/Collision
World

PhysicsRagdoll

Figure 1.24. Collision and physics subsystem.

Free download pdf