Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am making a multiplayer game. Now I am trying to choose the technology to connect the android devices to the server. The clients run on Android, and the game is MMORPG. I would like to write the server in java. Right now I have only 3 ideas for it:

1) creating multithreading environment with plain java and sockets. In this way it will be easier to perform full-duplex connection between the game client and the server. But I have the following concerns:

1.1) The game is MMORPG with a large number of objects, and I am not sure how such solutions are scaled if there are for example 5000 people playing at the same time. How many threads will I be able to run on java Machine? How can I approximately calculate that? In case 1 thread is reading for each socket and 1 thread is writing to the socket (so 2 threads for 1 player).

1.2) When the number of players grows, how will I be able to scale my self-written jar-archive to distribute over several servers? Maybe there is some special trick to do that?

1.3) A lot of programming overhead - sockets API is quite low level.

2) Creating a Servlet-interface for serving HTTP requests.

2.1) Easy to control sessions (and authorization) as long as each player has his/her own session.

2.2) can connect to java EE EJB or whatever - a lot of complications with system-level programming are taken away. So I can concentrate on writing business logic.

2.3) Can serve all types of clients with HTTP - mobile devices + browsers.

2.4) High-speed - even 1 servlet container can serve a few thousand requests per second so it will be really fast.

2.4) But this approach cant provide a full-duplex communication. I will have to send requests every 1 second to check for updates. 1 second delay does not make a lot of difference for the game as it is turn-based, but still it generates a lot of traffic. Is it feasible when there are many players playing? I heard about some COMET technology, but it seems like if the server has to push many messages in row, I will still have to send requests every time + this technology is not well established yet.

3) Creating sockets and connecting them through JMS to the java EE server.

3.1) Cool because allows for full duplex communication between clients and server + provides all cool features of java EE. Later can be extended to browser through servlet interface.

3.2) It seems like some kind of overengineering. Is it really how people would do that? I mean is it even the correct way? Would any sane developer do it like that?

I would like you to help me out with the choice please. I dont have much experience with doing some work like that. And would like to stick to the best practices.

share|improve this question
    
Do you want to write a lot of this from scratch or have a vested interest in Java? There are a lot of projects and other JVM technologies that would fit well here. –  Rig Jun 11 '13 at 23:40
    
I would like you to help me choose one of the options presented =) Yes, it would be preferrable to write everything from the scratch, but only if there is no technology that makes the process of creating things like that faster =) As long as I have googled there is no common technology for the server side of a multiplayer game except reddwarf, which has little documentation. But if you have some suggestions about technologies that would help. please share. I am willing to check all the options. –  John Jun 11 '13 at 23:58

1 Answer 1

up vote 4 down vote accepted

Why Rewrite What you can Get Off the Shelf?

Why not use RedDwarf Server (formerly Project DarkStar)?

RedDwarf Server is an open source middleware solution for developing the server-side of massively multiplayer online games. It is the official community fork of Project Darkstar, an open source project supported and managed by Sun Microsystems. - from RedDwarf's Wikipedia article

RedDwarf's domain seems down today (2013-06-12), but there's still a wiki, and they are migrating to a GitHub repo.

RedDward presents its philosophy and goals as:

  • Make server-side game code reliable, scalable, persistent, and fault-tolerant in a manner that is transparent to the game developer.
  • Present a simple single-threaded event-driven programming model to the developer. The developer should never have his or her code fail due to interactions between code handling different events. (from the RedDwarf Tutorial)

Not that this doesn't mean that server-code is single-threaded, but that it is abstracted from the game developer's perspective. The RedDwarf Tutorial provides a lot more information on what RedDwarf can do and clarifies many of its design decisions.

One point of concern for you, though, was that the multi-node capability wasn't fully implemented last time I check (ca. 2011).

From Scratch

That shouldn't stop you from attempting to do most of these things from scratch, if you value the learning experience. However, this is a major effort and will be rather time-consuming, and as, you noted in your question, some of these issues are rather low-level in the tech stack to deal with and will greatly increase the complexity of the code you'll have to maintain.

But anyways, regarding your 3 options, your first one seems the best to me, if you were to go for a home-made implementation. Option 2 (using HTTP servlets) seems only adapted for some games, though I guess it could be a relatively decent alternative to implement something yourself while still delegating to the a middleware, and you could benefit from many web server additions for handling the load (cache modules, etc...). Option 3 (using JMS + JEE) indeed seems overengineered, but it's hard to know for sure without knowing what you have in mind.

And if you're here to try to learn, then obviously Option 1 will cover a lot of ground. But it's going to be a rather uphill battle.

share|improve this answer
    
Adding a little about how these fit the needs would improve the quality of this answer - edit: beat me to it –  Rig Jun 11 '13 at 23:40
    
Rig: yes, yes. hang, on still editing! Give me 5 minutes or something :) I already updated twice in 2 mins! :) –  haylem Jun 11 '13 at 23:42
    
Yes. I`ve read about this project. But it seems like there is not much documentation on it + it seems like its easier to write everything from the scratch than to explore the code from within. Have you used it for your projects? –  John Jun 11 '13 at 23:56
    
As for the game itself - it is a turn based MMORPG game which runs clients on Android (future ports to I-whatever and maybe browser and winPhone). The server should run most of the tasks to prevent cheating and synchronize players. It like playing chess. So the notifications might come from the server every second and in bunches - but a second latency would be possible to tolerate. –  John Jun 12 '13 at 0:02
1  
@John: I actually haven't used Netty myself so I wouldn't want to mislead you on that, but I have coworkers who have been experimenting with it and are very eager for us to use it on our applications when we need custom protocols. And it seems like it is also designed to hide the threading away from you. There's an article list on their page (netty.io/wiki/related-articles.html), and a guide (netty.io/wiki/index.html). –  haylem Jun 12 '13 at 0:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.