First at all, I'm not asking how to handle or detect collision. I already have that.

My actual situation is, I have a system collision and I detect the collisions. Every collision detected is store as a message containing the two entities colliding with some information like type of collision or something. Later, all messages is processed.

I'm trying to figure out how to implement the reaction of the entities in every collision with that message. In the game a collision can trigger an action like talking with another, change the level, kill the character, store an object, not letting go...

I don't want to hard-code the calls and methods if possible (in my ideal world,I can define even the behaviour in an xml an read from that!). My first approach is a class where I store a list of possible actions/callback functions and attach it to the entity as a component. When a collision succed, I go to the entity and depending of the collision, execute the correspond callback.

Still I don't know how to determine the callback to execute or where I must code the behaviour. Any ideas? What you think about this approach?

By the way, I'm building everything from scratch, with c++ and SFML and following the entity system approach, for educational purpose.


1 Answer 1


I'm currently on a similar development path, though not explicitly entity-based. Can't say if this is a "typical" approach, but so far seems to work. I'm managing a list of "volumes", and detecting when certain ones intersect others. (Sometimes for physics, sometimes for other kinds of triggers, like you describe.)

Volume *v = new Volume(dimensions and stuff)
v->setKind(23); // in case others are interested
v->canBeTouchedBy(42); // only other volumes kind 42 will be "noticed" by v
v->addGotTouchListener(volumeListener) // call me

And then a listener gets messages like

void VolumeListener::gotTouch(TouchedMessage m) {...}

class TouchedMessage {
    Volume *touchee;
    Volume *toucher;
    EMeVolumeIntersection intersection; // enum, "inside" or "partial" &c

VolumeListener is an interface with just the 1 required method. An implementation of VolumeListener can carry enough context to know what it should do for the particular kind of intersection.

I've paraphrased the code above a little; actually it can mix and match multiple listeners with particular "touched-by" kinds. And there's listeners for "got touch" and "did touch", so you can do the triggering in either direction. And one could carry additional information on the TouchedMessage, for example.

But that's the general idea I used.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .