East Agent's Blog

이 블로그에 오시는 분들 모두, 올 2010년 한 해에도 늘 즐겁고 행복한 일들과 함께 하시길 바랍니다.

(사진은 정초에 오른 북한산의 동장대에서 바라본 풍경입니다)

폭력으로 엮이고 얽힌 등장 인물들의 관계도 흥미롭고 이것을 아내와 남편 그리고 아내의 정부(더 이상이 자세한 언급은 스포일러라 생략)의 시선으로 이야기한 점도 재미있다. 또 매끄러운 번역도 추리 소설의 긴장감을 더한다. 작가의 명성에 걸맞게 번역도 흠잡을데가 없다. (...작가 미우라 시온은 나오키 상 수상자라고)

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