East Agent's Blog

Integrating Physics with the game engine

I am not making a physics engine, just implementing 'as-much' physics as
required for my game


Once you start doing proxy-against-concave-mesh, and
multiple-contact-constraints, the difference will start to diminish.
Especially the "handle multiple contacts" part ends up more or less leading
you to actually write a physics engine. If you want physics without writing
a physics engine, use either an open source physics engine (Bullet, ODE) or
a "free for PC" commercial physics engine (NVIDIA PhysX, Havok Physics).

Regarding structure, I find that each subsystem should have its own data
structures, optimized for that subsystem. Thus, you may have a RigidBody
with some BodyCollisionShapes on it. Separately, you have an AnimatableMesh
with some Materials and Animations on it. You may also have a SoundSource
with some PlayingCues, and one or more SpecialEffects, and maybe even an
InputListener. Each of those are for a separate subsystem (physics,
animation, sound, scene graph, input in these cases).

The "game object" as such is the union of all these sub-components. There
are a few ways of doing that union:

1) Each subsystem allow *you* to define the ID of each subsystem object. You
say "create a rigid body, and call it '3'." A game entity is then just the
ID, and it's created as a collective hallucination of all the subsystems
that happen to have an object with that ID.

2) There's a bit struct with a pointer to every kind of component: struct
Entity { RigidBody *body; AnimatedMesh *animated; ... }; An entity comes to
life with NULL everywhere, and you populate it as appropriate.

3) You build an abstraction for "being a component" and for "containing
components." The entity is then a container for components. You write
component wrappers for each of rigid body, animated mesh, sound source, etc.
The entity is then created as a component container with whatever components
in it that you need. If you want editor support for arbitrary component
packages, for a fancy designer-built world, then this approach, plus XML
serialization, will get you there. The container will generally contain a
message bus, reflection support, etc.

The main problem you have to solve is how to get data from "here" to
"there." For example, the physics object collides with a wall, and thus
needs to adjust the animation to not penetrate an arm. Or the graphics scene
graph node moves, and you need the sound emitter to move as well. Generally,
this kind of data ends up in the "entity" component, so the "pure" ID
approach is not too common. However, if each of the subsystems can accept
some kind of "pull" input for common data like position, and the
authoritative source of that information can "push" it, then it can still be
done reliably and without pain.

Sincerely,

jw