Can Jboss and EJB be used for server side online gaming ?
What kind of games? If you want to create something like a complex persistent-world turn based strategy game where features like fail-over, scalability, distributed transactions, etc. are important - why not.
Yeah, pretty much any technology can be used for writing games. I’d personally like to see a game with the game state described in an XML document, so events could be written in XSLT… ;D
I designed a simple text-adventure a while back that stored all its info in a database and used standard SQL to pull it out. It used HSQLDB, so you could distribute an adventure as a DB dump. The engine would import the data into a blank structure and modify it directly - the save game.
When you think about it, a game’s save/reload routines could make good use of commit/rollback. There are some fun CGI-based MMO games that could easily use JSP/Servlets. I expect somewhere there’s someone who’s written an FPS in APL…
You could probably write a puzzle game cunningly designed such that, when processed in some way, only the corrrect answer will be well-formed HTML. Post the user’s guess to the W3C’s validation service to see if they’ve won.
You can certainly use EJBs (and AppServer of your choice) to develop online games, but as “sma” implies, it really depends on the type of game and how you use them.
EJBs are heavyweight and fairly ponderous (slow) objects, so you would really want to use them for large, coarse-grained game objects (e.g. a TerrainGrid or an NPC, or such), and not for lightweight game objects (like projectiles). You would most likely have some core EJBs and then lots of lightweight helper classes to keep the performance high.
Even though it would be more “pure” distribution if you could just invoke the EJBs directly from the client, you probably do not want to do that because of the latency and network traffic issues – you have to look up the EJB, then look up it’s method, then invoke it, and those are all RMI operations – slow and heavy. And you are paying for the bandwidth! Instead you would probably want to use a layered approach with the actual net messages being as small as you can get them, and then turning them into events on the client and server sides.
However, you could certainly get away with EJBs only on the server side, and use it to scale your server-side processing. Many commercial websites and enterprise apps do that with great success.
Finally, if all you want is really object persistence and transactions, without the security and naming overhead, then you might be better off with JDO or a roll-your-own persistence layer. Then you can tune it for speed or whatever. But it’s obviously a lot more work than just installing jBoss.
EJB 2.0 should help a lot in this arena.
With ejb you cannot send asynchronous messages from the server to the client. Normally a client sends a request to the ejb server (with lookup etc…) and waits for the answer.
With ejb 2.0 you have the possibility to use Message Driven Bean. These beans can send messages to the clients. Every client can “register” for one theme.
But I think more than a news ticker isn’t possible.
But with an ejb-server you need more bandwith than with a pure TCP connection.
If you want to handle every client separtly you have to implement your own I/O protool over TCP or UDP.
But on the server side, you can use an EJB server as an database interface behind your network interface.
Raven
Charlie,
In the next iteration of my server programming, I was thinking about using some of the techniques I learned while working for a content management company. Specifically we were using a web form that called a servlet that took what was in the form, wrapped it in a Java class, compiled that class, and would then execute it dynamically over the web when requested (we would wrap HTML inside this class, and the HTML was in the form… it allowed us to also use Java functions in those classes).
I’m thinking that my event classes would be dynamically generated Java classes that the server could then call once it is registered… how about that idea?
Yeah, that’s pretty sick! ;D Ah, Java gives us so much technology to play with. It’d be a crime not to abuse it…
hum i wondered if EJB could be used because i don’t see how for exemple i can make my own thread for ping every players just to be sure they are alive. Because whatever the online game looks like there must be chat and i don’t think EJB is usefull for handle chat.
Raven ;D :-[ ;D
Re-read Raven’s comment… ;D :
;D
:-[
…
Raah i am going back studying english.
@Thierry
I dont ping all my clients to see if they are alive. I catch the I/O Exceptions if I want to send messages to the client. If the exception occurs I know that this client doesnt shutdown normally and isnt avaible. --> I delete this client from the list.
If the client doesnt crash, then the clients sends a shutdown message to the server–> the server knows that this client is not avaible in the future --> delete this client from the list.
If all you want is a Chat server, and you don’t want to roll your own message layer, then you could use JMS topics without having to rollout an entire EJB infrastructure.
Yeah this I know but chat is one part of an online game there much more work to do with data base to insure persistance.
I’ve seen many articles saying that for interface to the database JDO is much better than EJB entyties Any of you have informations about this ?
We rolled our own database persistence layer, but that was because I had written it for another enterprise consulting project and was able to reuse 90% of it for our game.
This was before JDO came out, but alot of the approach is the same – database peers, transaction handling and connection pooling, etc.
If I had to start from scratch I would probably take a good hard look at JDO vs. EJB 2.0 and make the decision based mostly on performance. I’d probably go with JDO because games don’t usually need the naming and security parts of the EJB spec, and do need good performance.
…but then I look at object distribution on the server and heave a heavy sigh… :-/
We looked at this, since most of our technology requires many Enterprise-Arch features. But, to be honest, EJB sucks for games development. It’s designed for a completely different set of applications, which have little in common with games; the features (DTP etc) are there, but they’re usually optimized in the wrong ways, or make assumptions that will never hold, or just ignore most of the problems games developers need solved.
So, we made an alternative to J2EE, specifically intended for games development. With lots of emphasis on MMOGs. There’s no public release at the moment, and I’m not the person to ask about when there will be, but contact details etc are available at www.grexengine.com
…at the moment, we’re still implementing our tech within this alternative-enterprise-arch.
[quote]Yeah, pretty much any technology can be used for writing games. I’d personally like to see a game with the game state described in an XML document, so events could be written in XSLT… ;D
[/quote]
LOL.
But sadly, lots of people ARE doing games that use XML for all game state, and are too ignorant to even imagine such an intelligent use of XSLT :). It seems that usually they’re using XML for no better reason than “it’s really easy to edit by humans. And its a standard”
LOL. “Quirky”
[quote]they’re using XML for no better reason than “it’s really easy to edit by humans. And its a standard”
[/quote]
That’s not exactly a bad reason… actually it can be pretty good.
Binary formats may pack the bytes more efficiently, but often that isn’t significant. Working with a standard for standards sake gives you access to more tools and APIs for manipulating your data… that’s why I like it. I mean, I’m not going to store audio tracks or image data as base 64 in XML, but for structured data, why not?
More on topic… I would suspect that EJB and such are usually overkill for a game environment (I’ve never used them) but they must be good for something… and if you can make use of them efficiently why not go for it.
Oh, I certainly agree - for general situations. But XML is not a Universal Hammer (“When all you have is a hammer, everything else starts to look like a nail”), and we’re talking about game state here.
For any decent (even slightly complex) game, there are lots and lots and lots of little bits of data in the game-state - encoding that in XML is going to guarantee slowness and memory bloat, without giving anything back (except for specific games, you will always be altering the game-state programmatically, and when it’s just an API call, you don’t care what the underlying state is. Even debugging is hardly any easier with pure XML state - see below).
The “normal” way that games developers seem to do this seems millions of times better - having internal binary formats with (normally rather simple) converters to “your preferred human-readable format”, giving you all the advantages of XML, and without any of the penalities.
I have yet to work on a project that necessitates EJB.
All projects Ive witnessed going down the eJb track,
never return…!!!
Id always go for JDO unless:
-1) your are a sadomasachistical techiee
-2) you want to explore with J2ee flexible architecture
-3) your serverside app is really distributed, integrated over various systems