views:

98

answers:

4

I'd like to throw together a small game and put it online. It would be multiplayer (ideally it would be MMO, but it's a side project, so I'll settle for MO hehe), the content is rather unimportant. I'm planning on writing the game (server and client) in Java.

I'm considering options I have for getting information around reliably. Will JMS be sufficient for this? Will I need more (if so, what)? Are there better alternatives?

I've made a few games in the past, but nothing multiplayer. I work with an app that uses JMS, and there's plenty of tutorials, so that's why I figured it would work... but I'm really open to anything.

Thanks!

Edit: It appears I have a lot to learn about JMS. Perhaps my question should be rephrased to be: "What implementation of JMS will best serve my purposes for an MMO?"

Criteria thus far:

  • Free
  • Low overhead
  • Easy to configure
+3  A: 

Don't forget that JMS is an API and doesn't specify an implementation. I suspect that for a game you're going to require prompt delivery, and choosing an implementation may depend on attributes including this.

You may want to check out JGroups. As well as implementing JMS, it is enormously configurable and can be used to implement many different messaging patterns. You can choose to enforce reliability, ordering etc. and tune for different applications / clients etc.

Brian Agnew
I see. I will revise my question accordingly, based on the quick google-fu your answer led me to.
glowcoder
A: 

JMS is good if you need guaranteed transacted message delivery. Typically those kinds of constraints aren't there in a game (though it depends on the kind of game). If you want low latency communication, JMS is probably not the solution. Beyond that, without providing more information about the requirements of the game, its really impossible to say if JMS would be good for you or not.

Jherico
I'm curious, under what circumstances would I not need guaranteed delivery? If someone tries to cast a spell, it can't just... not reach the server!
glowcoder
FPS games often use UDP (which does not guarantee delivery or order) for communication because every packet has all (or most of) the state and only the latest packet is ever worth processing. If you miss one or two packets out of 100, it doesn't matter because it will just be an imperceptible hiccup in terms of playing the game.
Jherico
That might be true for state information about the environment coming from the server to the client, but what about user actions? Wouldn't that require a higher level of reliability?
glowcoder
You want it to be acknowledged, but it doesn't need to be anything like transacted in the way JMS is. A simple implementation would be that a client would send the 'pressed fire at x time' signal as part of its packet until it received back a packet from the server acknowledging the state change. Its still orders of magnitude less overhead than JMS or even TCP.
Jherico
You bring up an excellent point - I can separate the packets that are higher priority from the background state-awareness packets... Would you be able to suggest a Java library that handles these concepts in an abstract way?
glowcoder
+4  A: 

JMS would assume that your players are all on the same local network. I don't think it would work as well if your game is played over the Internet.

duffymo
+1 for not second guessing what the user is trying to solve. :)
tholomew
I see. So JMS might work well for interaction between the various components of my server, but not for the server-client communication? If that is the case, what alternatives can you offer?
glowcoder
ActiveMQ does actually have an HTTP transport. Not sure how that scales, but it should do the trick to get your first release out quickly. http://activemq.apache.org/http-and-https-transports-reference.html
tholomew
+3  A: 

Yes, and as a JMS implementation ActiveMQ will work for you rather well. It is robust and can be made to scale as well as be fault tolerant.

Also note:

  • It has wonderful performance characteristics, and is well suited for low latency applications including trading applications.

  • It is easily configured, and yet very configurable. Do have a quick read of the JMS spec, and also the ActiveMQ docs for more.

All the best with your game project!

Edit: This is assuming you will use JMS as a messaging backed for your application components to talk to each other.

tholomew
By application components, do you mean internal components? Right now I'm really looking for a solution that handles client messaging i.e. player moves/actions to the server.
glowcoder