How to properly handle collision in a component-based game?

Question

Trying to wrap my head around the ways to properly handle collision in a game designed around components.

I see many examples have some sort of PhysicsComponent that gets added to the entity's list of components but the actual implementation is confusing me.

For this to work, the PhysicsComponent would need access to the world around it. This doesn't make intuitive sense to me. Shouldn't a component be unaware of not only its container (the entity), but its container's container (the world)?

To me, it sounds like the level or scene should maintain a list of these entities and every game update, loop through the entities to determine which collide.

My question is firstly, whether or not this is good design, and secondly, how to determine which entities can collide. I suppose solid entities could implement an empty IRigidBody interface so the level could determine which entities in the list support collision. But is this breaking the component design?

Instead, should they contain an empty RigidBody component? This may actually be better because it may not always be empty and this approach is more future-proof. The only problem with this is the complexity. The scene would have to loop through not only every entity, but also every entity's components to determine if it had this RigidBody component.

Thirdly, when they do collide both entities should be informed somehow and I am unsure on how to accomplish this either.

Let's say that both entities contained a HealthComponent and when they collided both their healths would be decreased by some arbitrary value, 5. I suppose it would be the scene's responsibility to handle this when it detects a collision between two entities?

But then is the scene responsible for too much? I could see this possibly getting out of hand and becoming unwieldy when the scene is responsible for many things entities should not (?) have access to.

Edit: Question updated with more details.

Answer 1

Honestly, from a component design side of things, my components do not know about each other unless they have to (And that is very rare). Even then I usually prefer the components talk to some managing system of said components instead of the components directly. (The scripting interface looks like its object to object, but its not in the actual engine, hehe).

To that end I would side with what you first said and go with physics components that exist wherever objects need to be tested for their collision. Now clearly these objects may have to inform other components of themselves upon collision resolution but, as mentioned, this is where I prefer the event itself just to go out to the objects through another interface (either to a manager or through an event messaging system if you have one of those for instance).

I think you are on the right track and just need more of a 'Yes, that sounds right' So.. Yes, that sounds right.

Hope this helps!

Answer 2

Normally game engines use a 3rd party library to detect collisions between entities. In that scenario one creates or register those entities that have the PhysicsComponent into the "physics" world. And whenever it detects a collision between two entities (A and B), it would normally call a callback to entity A informing that it has collided against entity B and the same for entity B, informing that it has collided against entity A.

For 2D, a well known free physics library is Box2D. Also it's worth to take a look at Chipmunk. For 3D, Bullet is free (probably the best free one you can find). Havok and PhysX are famous for being used in lots of triple A Games.

Answer 3

The problem you're having is in seeing that collision detection (which is the only reason you would need one physics-component-bearing entity to reference another such) is done at a higher level, usually either by your game loop directly, or by a helper function/class that does this. My answer to someone a few weeks ago talks about entity removal on similar grounds, and bearing in mind that if a collision causes one of your entities to be destroyed, that same answer, in its given context, is going to be very relevant to you, since a "higher power" is still going to have to manage cleanup of the bodies... so to speak.

Doing any of this between entities alone, is not generally viable. There is nearly always a proxy for such things, in a solid architecture, whether that's via direct management as with collision detection, or event dispatches as in eg. a player messaging system where a client-side messaging manager listens for messages dispatched from players, and sends them off to the server to be rebroadcast to everyone.

Answer 4

I'm facing exactly the same problem as you in a project now. The way I decided to tackle it is by having a "ColliderComponent" which holds the body from the physics engine. The bodys are defined externally (shape definitions which are loaded at runtime) and then added to the physics-world and to the game-entities they belong to.

I'm using Box2D where you can attach a "collision-listener" that will get notified by the collision. Since I add a pointer to my "ColliderComponent" to the bodys user-data, I can get my two ColliderComponents that were part of the collision.

So the thing that happens when a collision occurs is the following: The ColliderComponents which were part of the collision will send a message out to their owner-object (the game-entity) which in turn will broadcast that message to all its components.

Every component can then react to that message, so your "health-component" could remove 5 points from health, etc.

Answer 5

Create a collision system that knows the collision "world". Then in your collision component tell the collision system to cast a ray from point A to B and respond if it collided or not.

Good luck. I find the collision system to be one of the more tedious parts of the game engine.