architecture - How does entity communication work?

I have two user cases:

1. How would entity_A send a take-damage message to entity_B?


2. How would entity_A query entity_B's HP?

Here's what I've encountered so far:

• Message queue
  
  
  
  1. entity_A creates a take-damage message and posts it to entity_B's message queue.
  
  
  2. entity_A creates a query-hp message and posts it to entity_B. entity_B in return creates an response-hp message and posts it to entity_A.
  
  
  
  


• Publish/Subscribe
  
  
  
  1. entity_B subscribes to take-damage messages (possibly with some preemptive filtering so only relevant message are delivered). entity_A produces take-damage message that references entity_B.
  
  
  2. entity_A subscribes to update-hp messages (possibly filtered). Every frame entity_B broadcasts update-hp messages.
  
  
  
  
  


• Signal/Slots
  
  
  
  1. ???
  
  
  2. entity_A connects an update-hp slot to entity_B's update-hp signal.
  
  
  
  

Is there something better? Do I have a correct understanding of how these communication schemes would tie into a game engine's entity system?

Answer

Good question! Before I get to the specific questions you asked, I'll say: don't underestimate the power of simplicity. Tenpn is right. Keep in mind that all you're trying to do with these approaches is find an elegant way to defer a function call or decouple the caller from the callee. I can recommend coroutines as a surprisingly intuitive way to alleviate some of those problems, but that's a little off-topic. Sometimes, you're better off just calling the function and living with the fact that entity A is coupled directly to entity B. See YAGNI.

That said, I've used and been happy with the signal/slot model combined with simple message passing. I used it in C++ and Lua for a fairly successful iPhone title that had a very tight schedule.

For the signal/slot case, if I want entity A to do something in response to something entity B did (e.g. unlock a door when something dies) I might have entity A subscribe directly to entity B's death event. Or possibly entity A would subscribe to each of a group of entities, increment a counter on each event fired, and unlock the door after N of them have died. Also, "group of entities" and "N of them" would typically be designer defined in the level data. (As an aside, this is one area where coroutines can really shine, e.g., WaitForMultiple( "Dying", entA, entB, entC ); door.Unlock();)

But that can get cumbersome when it comes to reactions that are tightly coupled to C++ code, or inherently ephemeral game events: dealing damage, reloading weapons, debugging, player-driven location-based AI feedback. This is where message passing can fill in the gaps. It essentially boils down to something like, "tell all the entities in this area to take damage in 3 seconds," or "whenever you complete the physics to figure out who I shot, tell them to run this script function." It's difficult to figure out how to do that nicely using publish/subscribe or signal/slot.

This can easily be overkill (versus tenpn's example). It can also be inefficient bloat if you have a lot of action. But despite its drawbacks, this "messages and events" approach meshes very well with scripted game code (e.g. in Lua). The script code can define and react to its own messages and events without the C++ code caring at all. And the script code can easily send messages that trigger C++ code, like changing levels, playing sounds, or even just letting a weapon set how much damage that TakeDamage message delivers. It saved me a ton of time because I wasn't having to constantly fool around with luabind. And it let me keep all of my luabind code in one place, because there wasn't much of it. When properly coupled, you can use embedded languages like Lua to easily add new features/monsters/weapons/levels/etc to the game without ever recompiling the C++ code.

Also, my experience with use case #2 is that you're better off handling it as an event in the other direction. Instead of asking what the entity's health is, fire an event/send a message whenever the health makes a significant change.

In terms of interfaces, btw, I ended up with three classes to implement all of this: EventHost, EventClient, and MessageClient. EventHosts create slots, EventClients subscribe/connect to them, and MessageClients associate a delegate with a message. Note that a MessageClient's delegate target doesn't necessarily need to be the same object that owns the association. In other words, MessageClients can exist solely to forward messages to other objects. FWIW, the host/client metaphor is kind of inappropriate. Source/Sink might be better concepts.

Sorry, I kinda rambled there. It's my first answer :) I hope it made sense.