Interaction between entities

[verilog]

Hi guys!
So, I was thinking about a simple system for setting up interaction between random entities. Let me explain. I have an entity that can interact with another. The interaction link cannot be established until I know which entities are going to share information, however, I can only know the emitter entity prior to setting up the link; The receiver (or receivers) will be determined later on, probably at run time.

I came up with a “broadcasting” kind of system, where all receivers are subscribed to a list. Each time a message is received, it is broadcasted to all the entities in the list. Each message encodes various properties, including who published the message, as well as the time and the place. Based on this information, each receiver can then decide to respond to the message, refrain from taking action or delete it. For multiple messages a queue can be implemented.

I haven't further deepened my research on the topic, but I thought this approach might be a good start. Do any of you have experience with this kind of problem? If so, can you gimme some pointers? Code is not neccesary, any idea will do.

Thanks!

[Plu]

Sounds like you´re looking for the Observer Pattern.

It's a very common design pattern in software and if you google that term you should be able to find a wealth of information on what you're looking for.

[verilog]

Nice, that's really useful information, Plu, thanks for sharing it!

[ivan]

This sounds like the publisher/subscriber pattern.
Although I think something so complicated may NOT be very useful for games.
Things may get even messier if you are using an entity system.
What type of game are trying to make?
Can you give us some examples of how the whole thing is supposed to work?

[verilog]

Hi ivan,
I'm working on a platform/action kind of game. During production I thought I’d need some entities (not necessary the player) to react to actions triggered by other entities. These are some examples I’d end up implementing with such a system:

• An enemy carries a bomb, the enemy is disabled by the player, the bomb is dropped and after a while it explodes, destroying all entities within a known radius.
• There’s a giant electromagnet, when the magnet is activated, it naturally attracts all metal-based objects that are found in a certain distance.

So the problem that I faced is that the “affected” entities are not known until much later, so I figured I’d need a communication system where an event is “published”, and then a set of subscribed entities can decide to act upon the event.

So far, my entity system only manages creation, updating and drawing. I can share information point-to-point between two entities, but I need to know the “receiver” beforehand.

What do you think? You are right; this setup may be a little too much for most games. I'm sure there are other (easier) ways to accomplish the same, that’s why I opened this thread. I would appreciate any advice you may have.

[ivan]

Hey Verilog,
Regarding entity systems: this is something I've dabbled with a little bit but unfortunately didn't find them very useful so I can't comment.
I've programmed a couple of platformers before, so I and may have some tips for you.
1) the collision/physics system you are using is probably the most important thing since it largely determines the gameplay. You want to separate your collision/physics code from the rendering, AI and other game logic.
2) both of your examples are related to AI/behavior. The easiest solution for AI is finite state machines. The idea there is that each agent in your game has a "current" state and you update that each frame.
3) if you want to have messaging between agents, each message is received by the STATE of the agent, not by the agent itself. So an agent can react differently to a "bomb explosion" message depending to its "current" state. For example, if the agent is already in a "dead" state it wouldn't react to a "bomb explosion" message.
4) to make your messaging system more useful, you can have a "send_msg_range" function which sends a message to all agents within a specified radius. OR if you use sensor shapes (like in Box2D) you can have "send_msg_contacts" where an agent sends the same message to all other agents which it's currently intersecting with. The basic idea is: you send a message and the receiver handles or ignores the message depending on its current state.

Lastly, I have to say that it's very hard to design software from the top down unless you have experience in making similar software. So if you've never designed an action game it's not a good idea to try and design it from the top down. The are 2 major problems:
1) you don't know what features you are going to need (later on) and if your system CAN support them
2) even if the system you have designed works, there are probably simpler (and more elegant) solutions
I would suggest a more pragmatic approach, where you add features as you need them rather than programming a whole framework ahead of time.

[verilog]

Hi ivan,

Thanks for the info and your suggestions, I’ll definitely take them into consideration, I now have a clearer idea of what I need to implement. I completely agree with you on the bottom-up design pattern, so far my approach has been based on defining a specification and working features in as they are needed. It is a little slow, as you probably know, the refinement of every new subsystem takes time (i.e., write some code, test it, write some more, test it again, ad infinitum), but the overall engine keeps steadily growing.

Thanks again guys for your input, hope I can show you what I've been up to some day.