J2EE Servlet custom protocol for realtime game server

Game Play & Game Design
#1

Hi

I’m pondering the logistics of using the J2EE framework for a game. Some of the reasons I’m considering it are the design patterns that already exist and are supported by the framework and the framework is already there, scalablilty, clustering, data sources, authentication etc don’t have to be recoded.
The biggest issue I see for realtime work is how to access the servlet, fairly obviosuly HTTP isn’t an option. I’ve read about JBoss’ remote customisations. This should if I’ve read it right, allow me to implement my own binary protocol and reduce the bandwidth. I’m sure if I were to implement my own clustering etc then i’d end up with either a slower solution than just using J2EE, or something non reusable.

Does anyone have any experience of doing this? do they have any examples?

What are the pitfalls I should look out for?

Thanks

Endolf

#2

You just stated the big one. J2EE servers are not built for real-time work. The performance metric in the J2EE world is average throughput, not worst-case latency.

I think you will find you cannot get the performance you want for a real-time game out of a J2EEE system. Everyone I know of who has tried to date has failed…

#3

Hi

I’m going to be exploring the posibilities of introducing a known level of ‘lag’ into the system. You’ve mentioned before that humans can perfectly adapt to a known amount of lag. Although i’m doing an x-wing/elite style game, I figure I’m going to have some network lag in there, so why not explore some of the techniques that have been suggested here.

The client will update it’s graphics of the orientation of the ship, and say 4 times a second send to the server the average velicoty vecotr for that period, the server will then set that as the next velocity vector for each client to apply at the next simulation step. All the clients use that velocity vector so at all times, all clients are in locational sync, even if the orientation isn’t.

I don’t know how it will work, it may not, but there is no harm in exploring it. A constant 1/2 second lag with thrust vector may be more playable than an unknown and unpredictable lag in all directions with clients out of sync.

Endolf

#4

Wehlp good luck and share your results as Im sure we’ll all be curious.