Um... J2EE?

I know that most of the networking discussion has centered around needing quick network responce times for games like FPS.

However, my play and development has forever been focused on RTS and even turn based play. (You know, like board games).

Part of that kind of play would also include having a server system to support setting up matches in 'rooms'. Right off the bat I figured that using J2EE would be the best solution to handle user registration and login, rooms, chat, and game setup. This could even be separate from the actual in-game networking code, designed to just set gaming sessions up. Think BattleNet or Steam.

Thus I built a system on JBoss w/ a MySql backend that allows for a remote ejb or webservices (SOAP) interface to register new users, assign them a unique id, and allow them to set up games.

Question: Would anyone else be interested in this code?

I have also considered this for online games to handle things like account management, billing, esupport, forums, …

How are you handling async messaging for things like chat and even notification? JMS works but it seems to be overkill.

I like your idea off having seperate networking for game playing. You could probably event make a framework generic enough that for a new game the implementor would justneed to write the code that tells the clients how to conntect up to the game when it starts (like what protocol, port, address, etc). IT would also be cool to use j2ee to handle things like rankings, ladders, stats.

Even for mmorpg games like WoW this may have value. J2ee can easily hand the login, authentication, character creation/selection. Then switch over to socket based tcp/ip (i think this is what wow uses) when you enter the game.

I wonder if there would be any interest in something liek this as an open source project. I am sure there are a few game developers out there who could make use of this. I have been doing j2ee development ( now Java EE 5) for several years now and have been looking for a way to apply this to game development somehow.

Yes I agree. A open source project who's goal is to provide a simple way for games of all varieties to be registered and use the services make a good amount of sense.

I have two different ways of handling the async stuff… 1. JMS (not so much overkill since I create/destroy topics for each room so you don't get overloaded with messages and have filter). 2. SOAP notification.

I would see where ideally a network of servers could interconnect, thus balancing the load; kind of like Peer-to-Peer servers :slight_smile: handling client requests.

I'm using the J2EE framework for my game as well since my game is turn based and JGN would be overkill. But that can be handled separatly.

Thanks for the input.

Let me know if you want to throw around some ideas for and open source reusable framework. I have a fair bit of of experience with server side j2ee services and persistence. I dont have much game dev experience apart from messing with the jmonkey/jirr tests and tutorials but I dont think that matters much for something like this.

I'm a J2EE developer to.

JBoss/MySQL as Backend for gaming is a good solution. It's stable and cost effective.

I have a look at "jgroups" for the realtime stuff in my current project. It comes with JBoss 4.x

Have a nice Day

I just noticed that jgroups supports TCP protocol. Is this new? I thought it only supported IP multicasting so I always disregarded it for client/server messaging (although I have looked at using it for syncing object stores in a cluster). I will have to take another look at it.

I would recommending using an ORM solution for a persistence backend. EJB3 persistence is quite good and very easy to use. I have been using the hibernate implementation and although there are still a few bugs it is very fast to build your domain objects. I havent tried toplink but it is another option if you dont like hibernate. Also I think epox is working on an ejb3 version. The best part is you can use whatever database that hibernate supports, which is pretty much any you would ever use. Switching from Oracle to MySql was pretty trivial and did not require any code changes. Also EJB3 is as app server agnostic as it gets, however most app server implementations are still buggy or early access so easy porting still isnt reality. I just tried to take a jboss app and drop it in oracle app server and it is taking a lot of changes to make it work, but these are not final versions.

I sent you a private message about this econn because this has maybe gone beyond the bounds of jME… don't want to use up their bandwidth.

I like all the interest…

I've set up a wiki location for continued discussion at my website: