Hello, I’m very new to JME3, and I’ve been wondering whether there is a messaging system, or if not what the best tactic for implementing one would be.
To clarify what I mean by messaging system, here’s an example: Thing A’s controller decides that Thing A needs to do something like sound an alarm. Thing A does so which should be able to inform all other things. Thing B’s controller gets the notification that the alarm is on and decides that Thing B should help.
Many engines have a unified messaging architecture where the controller would do something like messageSys.postMessage(MessageSystem.SOUND_ALARM); and then anything that has registered to receive that message will be notified with a callback,
Is there already a system like this in JME3 or would I need to implement that myself?
If so what would be the best way to leverage the existing systems to make implementation easier?
I’d probably use Controls and AppStates for this.
Your AppState is a game-wide thing - that can be used to pass messages. Say your Control is an AIControl of some sort that governs the behaviour of the entity, in its update loop, if a certain thing happens, it can notify the Messaging AppState that something has occurred. Anything listening to messages from the AppState can then act upon that.
So I’d probably create an interface for any class that would want to listen to messages. You may also want to include things like the coordinates of the message, in which case your code would look something like this:
[java]
public class AIControl extends AbstractControl {
//some code here
@Override
public void update(float tpf) {
messagingSystem.addMessageToQueue(new AlertMessage(this.getLocation(), AlertType.ALARM, time));
}
}
[/java]
[java]
public MessagingSystem extends AbstractAppState {
public void addMessageToQueue(Message message) {
//send it out over the network if we are playing over a network, or notify anything that has registered itself to listen
}
}
[/java]
So it doesnt have one built in, no, but its easy to do.
Like @ancalagon said, a messaging system is easy to setup, depending on how flexible you want it to be.
Another question is what type of messaging system you want.
In it’s most basic form, there are two types:
- subscription based
- destination based
What I mean by this is that in the first option, the sender just sends the message and is unaware of the receivers. These just register themselves on a topic in the messaging system. This system is usefull for messages like you stated.
The second option means the sender knows where the message is being sent. This is usefull when you want a result back from your message. In this case you would need more control on the sender side. This is the version I am currently using.
Both versions have their pros and cons. Ultimately you would want a system that's able to mix the two as needed, but this would mean a fairly complex messaging system. Although I might be tempted to work something like that into JME eventually when I can find the time.
@ractoc Yes, my goal was subscription based, although I’m now curious how you implemented a destination based version.
I think having a complicated messaging system implemented into JME would be another good step toward having a professional quality game engine.
@ancalagon Thank you that is exactly what I was thinking I would do, I’m not used to the AppState and Controller concepts yet. I’m a bit confused how AIControl gets a reference to the MessagingSystem, I know I must be missing something about how AppState’s are handled does a control have access to the Application to call something like [java]app.getState(MessagingSystem.class).addMessageToQueue(…);[/java] does the App have to be passed to the constructor of the AppState to do that?
Well you have a few choices. You can pass a reference to the application, the AppStateManager, or the AppState itself. I think the Application is the recommended method.
A Control would not have access to any of those by default, but you can choose to pass them in. You would need to do so if you wanted to use your AppState.
@ancalagon said:
A Control would not have access to any of those by default, but you can choose to pass them in. You would need to do so if you wanted to use your AppState.
Thanks that's what I thought. Next I think i'm going to have to make a level editor... I'm a programmer by trade, and art isn't my strong suit. Blender is great but I can never make things look the way I want them to look, I'm seriously considering procedurally generating everything for my game...
My plan if for a very AI centric game which is the reason I need messaging (processing that a sound was made at a location, sounding an alarm when the player is seen, ect.) Thanks for the help, I'll probably be back with more questions soon.
Well, for my destination based system you can check out my PFfJ system on sourceforge, since that’s where I use it.
Plugin Framework for Java download | SourceForge.net
In short, the message controller has a list of registered plugins. The sender hands the message over to the controller and provides the plugin id where the message needs to go. Easy as that.
Then there’s some fancy stuff since the plugin can be run either locally or remote in another jvm, on another system. In such a case, the controller has to take care of sending the plugin message to the other jvm.
It’s all very nice and hardly close to finished. Currently, there’s only destination based, since this is the easiest to implement with a distributed message box. When you have a subscription based message bus, making it distributed becomes a hassle, since each node of the controller needs to know which subscription goes where etc. Not impossible, but harder. And for now, a destination based setup works fine for me. And since this one isn’t near finished, adding all the subscription based stuff would make it overly complex.