Elysian Shadows

So with the whole talk of Component based entity systems, I've decided to revamp the code I've been working with for so long...

At this point, I've been busy, and haven't really done any programming in a month or two ( laaame, I know)... But I have a good amount of free time now, and I've been kicking around this idea in my head, so I was looking for some constructive criticism, or for people to just straight out call me a dumb ass, either works :p.

So I want to implement a sort of 'Messaging System', and here's how I thought I'd go about implementing it:

Composed of 3 main classes: MessageManager, MessageListener, and Message.

The MessageManager would be composed of a container of messages and a container of listeners. It would have function(s) to send messages which would either instantly send the message, or send it after a period of time (which would be stored in the message container). I'm not really sure at this point about how to go about finding which listeners should receive which messages.

The MessageListener would be something that any class could have it's own instance of. It would contain some sort of container of Message IDs which would determine which messages it was subscribed to. It would have an 'OnMessage' function which would return a boolean to indicate if the message was 'consumed' or not. I was thinking I could use this to make a 'messenging' component to add easy messaging capabilities to any entity.

The Message would simply be a struct that would hold the message ID, and the accompanying message data.

So essentially the process would be like:

*Create Listener
*Subscribe to Certain Event Types via Listener
*Attach Listener to Manager
*Create Message
*Send Message Through Manager
*Manager Checks to Find Which Listeners are Subscribed to That Particular Message
*Manager Sends the Message to Those Listeners
*Listeners Handle Stuff, and Can Choose to Consume the Message (Meaning it won't get sent to any other listeners...)


Sooo, does anyone see any potential holes in this? I won't have time to program until this weekend, so I figure I might as well get as much thought out on this as I can .

i have heard of what you are doing and from what i heard it sounds good. im working on an entity system as well and would like feed back as well

here is the src http://code.google.com/p/racing-game/so ... #svn/trunk

i will look over your system in a bit and come up with some thoughts on it :D just short of time right now

Alright I put a little bit more thought into it and found out how I'll store the listeners, I figure it will be something like this: This way, I can grab the list of listeners based on the string, and then store that type of listener, so when a message is sent, I just send the message through all those.

The next thing I really need to figure out, is how to act upon these messages...

So I'm thinking of having the listeners store a queue of messages/events and then whatever object owns it can then go through the messages and act upon it.

Any thoughts, suggestions, comments, or criticism?

Sounds pretty good to me, I only recently learnt about event/messenger systems about a month or so ago ( I've known of them for awhile ), and threw a simple system together of my own which turned out quite well but I haven't really had a use for yet.

Your system sounds pretty similar to mine but more advanced, mine was just able to create events and either send them to the listeners immediately or store them and send them whenever the manager is updated. I was going to just have different instances of the manager to handle different events types, for example one for user input, menu events, game events... etcetera, which might not be the best way but whatever.

Trimmy wrote:Sounds pretty good to me, I only recently learnt about event/messenger systems about a month or so ago ( I've known of them for awhile ), and threw a simple system together of my own which turned out quite well but I haven't really had a use for yet.

Your system sounds pretty similar to mine but more advanced, mine was just able to create events and either send them to the listeners immediately or store them and send them whenever the manager is updated. I was going to just have different instances of the manager to handle different events types, for example one for user input, menu events, game events... etcetera, which might not be the best way but whatever.

Ahh, yeah I want to think of another way to handle sending the messages. Because the listener itself isn't going to handle the message, the object that HOLDS the listener will...

And it just seems a bit inefficient to me to send the event to each listener of that message type, I was thinking of having a function like:
And I could return true if that object 'consumed' the message, meaning it wouldn't be sent to any other listeners. Like if you had a mouse click event, and clicked a button, I don't want that mouse click to be passed through EVERY object that gets mouse clicks. Once it iterated to the button that was actually clicked, I'd like the button to consume the message.

I'm also thinking of instead of having multiple listeners, just have one of each type held in the manager, and then it will hold a queue of messages and any object can look through that queue and consume messages if it wanted. That would increase efficiency and solve my problem, I think...

This post is slightly motivated in an effort to bump my post up... But I do have some more ideas to add...


So I was thinking of having a single Listener for each event type (rather than each object having it's own...), and then each object could have a pointer to this and access it. I can think of two possible issues for this:

1) If one listener exists for each different event types, what happens when I have an object that needs access to more than one different type of listener? I'd have to have multiple pointers... So this definitely needs some type of organized structure (Maybe a ListenerManager that encapsulates Listeners?).

2) How to handle messages. This method would allow any object to 'consume' the message, and therefore remove it from the queue, but what about messages that aren't consumed by anything. How will I know when to remove it from the queue?

Again, any help and/or ideas is greatly appreciated

just posting this to prove it actually happened... XianForce is EVIL!!!!

Ginto8 wrote:just posting this to prove it actually happened... XianForce is EVIL!!!!

Darnnit ginto I was JUST about to do that...

That's funny

I was thinking of implementing this in almost the exact same way. For me I would make the MessageManager a singleton object that acts upon Message components. That way I could make any Entity in my game able to send and recieve messages. I still havn't made a Messaging/Event System, until now I've just been using function calls triggered from collision detection.

eatcomics wrote:

Ginto8 wrote:just posting this to prove it actually happened... XianForce is EVIL!!!!

Darnnit ginto I was JUST about to do that...

I have tried to do something simmilar. One problem is that you will have to backcast every Message If you want to be able to send different kind of data with different kinds of events.

ismetteren wrote:I have tried to do something simmilar. One problem is that you will have to backcast every Message If you want to be able to send different kind of data with different kinds of events.

What do you mean by that ?

XianForce wrote:

ismetteren wrote:I have tried to do something simmilar. One problem is that you will have to backcast every Message If you want to be able to send different kind of data with different kinds of events.

What do you mean by that ?

When i created the system i called it Events instead of messages, i see i used both words in my post, that might have caused the confusin, i mean the same thing with both of those words. If that wasen't what caused the confusion, i will try to explain what i mean(using the word "event").

Say you have the super type Event, this class must have a field specifying the type of event(COLLISION_EVENT, KEY_PERSSED_EVENT, MOUSE_MOVED_EVENT and so on, atleast in C++ where there AFAIK not are any instanceof operator). CollisionEvent and KeyPressedEvent both inherit from this class, CollisionEvent have 2 fields, one for each object colliding and KeyPressedEvent have 1 field indication what button was pressed.

Now, suppose we have an EventListener, who for some (strange (this is just an example)) reason listens to both CollisionEvents and and KeyPressedEvents. It would have the function: void onEvent(Event e). If it is a CollisionEvent til will need the collision data, if it is a KeyPressedEvent it will need the key data. The only way is to check what kind of event it is, and then backcast it to that type.

If i have missed a better solution, please tell me.

Well, shouldn't you just have each Event, have an event data structure associated with it? You shouldn't have to back track that way...

Like the event would consist of a type, and data (the data being specific to the event type), and then when the listener receives it, whatever object that wants to handle it, will handle it...

Unless you mean TYPE cast and not BACK cast... Back cast is what threw me off :/