Hi,

I recently made a small multiplayer online game (MOG) "test" using node.js / socket.io / express.js etc.

However, although I liked them, I don't like the fact that error handling is really tricky, if something goes wrong, it is really hard to trace down.

Therefore, I began to wonder, how big boys are doing game server development?

What I wan't to achieve:

- To develop MOG which runs in the browser and communicates with the server over web sockets. Hence, I would like to program server-side using Java, not JavaScript. The whole thing would be part of my M.S. thesis. I try to suggest to my supervisor that I program a browser-based MOG using web sockets (TCP) and trying out different application-level techniques (I made a research about these earlier) to make it work despite variance in latency and packet loss.

But, this is the point where I am really clueless, and I am having hard time to find the "right" tools for the job. However, I did find at least one game (bombermine.com) and it uses jetty so I think that is one option. (?)

However, I would like to hear your opinions and suggestions for this matter. Thus, it would be really awesome if someone knows some sort of tutorial(s) or a book(s) which I should read regarding game server programming. I am worried about the multi-threading issues which I am not that familiar with.

Thanks!

Regards, Mane

Most MOGs currently out there fit one of two molds:

1) They use a native download client (written in something C-like, perhaps with a scripting language like Lua or Python added) and they use plain TCP sockets for communicating game data to/from the servers. Note that Unity plug-in games also fall in this camp, because the plug-in itself is written in something C-like and doesn't use the surrounding web stack.

2) They use a technology like Flash or HTML5, and use a more relaxed "MOG" definition, where immediate real time is not needed. Examples include anything from Farmville to Neptune's Pride. These kinds of games use HTTP batch-style communications, although with proper double-buffering, you can get latencies down to 100-200 milliseconds or so using this method.

Websockets aren't yet the "major" use case, that's optimized the most -- but it's certainly up and coming. We use it at IMVU for some real-time interaction, and it works okay (not as well as straight TCP, but better than HTTP.)
What you want is a nice library for websockets on the server side, because the negotiation and set-up of the server side is a little bit fiddly. We used some websockets library for our Erlang based server, although it had significant challenges for us and we ended up changing a lot of that code.
Another nice library that works well is socket.io, which is natively hosted inside the node.js server package. It then provides a nice wrapper on top of web sockets for messaging that the client requests and is available as a JavaScript library (that the server provides.) socket.io also falls back on other methods (Flash, HTTP polling, etc) when real websockets aren't available.

For Java servers, a quick Google says that TooTallNate's Java-Websocket library is the top hit (in addition to some native Java websocket support in the JDK from Oracle.) I have no idea whether they're any good or not.

For what it's worth: If I were to build a HTML5+websockets game today, that scaled to dozens of players (not worrying about 1000's of players,) I would very likely use socket.io, and write the server-side in node.js. The benefit is that I can re-use the same JavaScript code on the client and on the server. The draw-back is that I have to write my server in JavaScript, and I prefer more strongly-statically-typed languages...

hplus0630,

Thanks for excellent reply. I have been refreshing this post like a maniac. :)

However, what worries me is the fact that you brought socket.io up again and using of node.js (Don't get me wrong, I love them) but, I would like to try some other solutions as well. Namely, the error handling alone and the draw-back you also mentioned "..I have to write my server in JavaScript, and I prefer more strongly-statically-typed languages... " is one of those reasons why I am looking for alternatives. I might be wrong as well, maybe the socket.io and node.js is the best combo for making browser-based mog's. However, I think that part of this is just this "hype" which is going on & other part that I am not sure what I am looking for, so it makes me to question this whole node.js approach - it seems so new to me that people must have used some other stuff at game server-side for a long time.

I think the relevant questions here is:

- Do you think that I can make equally good MOG (in terms of networking) by using any of the approaches.. (rolling out with js or java) ?

- Do you think that programming game server which is not running in single-thread like node.js will be so hard that it is not worth to even try? (With node.js it was pretty easy to store connected players currently at the server and do all kind of things). I am bit of unsure how to synchronize the stuff between threads etc.

You can absolutely make an equally good game using any other technology. The only question is how much effort you have to spend.

socket.io / node.js is hyped, because it's easy to get started, and "the skids are greased" -- there are enough examples and documentation to make it easy to get to the point of "proof of concept." It's the path of least resistance.

If you want to do it on top of Java, or Erlang, or C99, that can totally be done, although you'd likely have to do a little more research on your own, and you'd have slightly fewer introductory examples available to get you going.

If I wanted to use Java, I would start with TooTallNate's Java-Websocket library and read the documentation surrounding that, and see how far that could take me.

Yea, valid points.

I need to think about this more once I get back to home, I even tried to contact makers of bombermine but didn't get reply from there. Hopefully, they will send me something later, until then I try to research more or even make small poc with java -stuff.