Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (532)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Would Jboss and EJB be usefull ?  (Read 7410 times)
0 Members and 1 Guest are viewing this topic.
Offline Thierry

Junior Newbie




Java games rock!


« Posted 2003-04-07 12:51:25 »

Can Jboss and EJB be used for server side online gaming ?
Offline sma

Junior Member





« Reply #1 - Posted 2003-04-07 13:05:00 »

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.

.: Truth Until Paradox!
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #2 - Posted 2003-04-07 13:44:18 »

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... Grin

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.

Hellomynameis Charlie Dobbie.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bmyers

Junior Member





« Reply #3 - Posted 2003-04-07 16:12:48 »

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.

Offline Raven

Senior Newbie




Java games rock!


« Reply #4 - Posted 2003-04-07 17:42:24 »

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
Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #5 - Posted 2003-04-07 18:34:49 »

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?

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #6 - Posted 2003-04-07 21:31:58 »

Yeah, that's pretty sick! Grin  Ah, Java gives us so much technology to play with.  It'd be a crime not to abuse it...

Hellomynameis Charlie Dobbie.
Offline Thierry

Junior Newbie




Java games rock!


« Reply #7 - Posted 2003-04-08 11:51:00 »

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  Grin  Embarrassed  Grin
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #8 - Posted 2003-04-08 14:55:34 »

Re-read Raven's comment... Grin Roll Eyes

Hellomynameis Charlie Dobbie.
Offline Raven

Senior Newbie




Java games rock!


« Reply #9 - Posted 2003-04-08 17:00:03 »

Grin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Thierry

Junior Newbie




Java games rock!


« Reply #10 - Posted 2003-04-09 07:44:44 »

Embarrassed

...

Raah i am going back studying english.
Offline Raven

Senior Newbie




Java games rock!


« Reply #11 - Posted 2003-04-09 09:57:50 »

@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.
Offline bmyers

Junior Member





« Reply #12 - Posted 2003-04-09 17:26:00 »

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.

Offline Thierry

Junior Newbie




Java games rock!


« Reply #13 - Posted 2003-04-12 13:18:08 »

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 ?
Offline bmyers

Junior Member





« Reply #14 - Posted 2003-04-15 19:58:26 »

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...   :-/

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2003-04-15 21:01:19 »

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.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #16 - Posted 2003-04-15 21:05:05 »

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... Grin


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 Smiley. 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"

Quote

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.


LOL. "Quirky"

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #17 - Posted 2003-04-28 00:11:53 »

Quote
they're using XML for no better reason than "it's really easy to edit by humans. And its a standard"


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.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2003-04-28 00:43:43 »

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?


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.

malloc will be first against the wall when the revolution comes...
Offline larry

Junior Member




.. son of jor-el, kneel before zod ...


« Reply #19 - Posted 2003-05-09 09:23:09 »

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

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2003-05-09 12:29:51 »

Quote
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



Yeah, I think it's suffering from the universal-hammer-syndrome I mentioned above; EJB is really tempting if you're writing a network-server with a large number of (potential) users, and you don't know / don't like writing network handlers etc. J2EE does SO MUCH WORK for free - but it's non-configurable, non-extensible, and so it's like running down a tunnel - you CANNOT get J2EE to work for situations other than the ones it was designed for without MASSES of work.

As for reasons for using it... can I add:

 - being able to put on your CV that you developed a "major J2EE/EJB project", and hopefully get a higher paid job somewhere else on a similar failing project that you know will never reach completion Cheesy

malloc will be first against the wall when the revolution comes...
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #21 - Posted 2003-06-21 05:24:05 »

If you're going to consider JDO, I would suggest first taking a look at Hibernate 2.0. Its easier to work with, and is more supported by developers than JDO (at the moment). This may change when JDO 2.0 specification comes out.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline webgeek

Junior Newbie




Java games rock!


« Reply #22 - Posted 2003-12-30 19:20:13 »

JBoss isn't known for performance, so I imagine that would be a problem and I am hard pressed to see a need for EJB on a game. My experience with EJB has typically been pretty bad. The only exception would be MDB (Message Driven Beans) which work wonders. One thought though about MDB and JMS in general. If you have data that HAS to be updated in the database but isn't terribly time sensitive or can be delayed a little bit, why not throw it in a queue?

I mean think about it, you are running along the ground in your multi-player, tile-based world and suddenly get disconnected. You lose 20 minutes of game data in one shot. Crap! If the game were to set up to request a position save every 1 minute or some such and that request sits in a queue until serviced, you could easily tune the load on your database by increasing or decreasing the number of MDBs listening on that queue.

This is just one example, but queueing can be VERY useful for places where time isn't so important but it HAS to work.

I have used a similiar technique for several enterprise projects I have worked on where data had to be written to the database and we didn't want to consume all the processor of the server with it at one time. So we trickled out the updates based on CPU load. You would dump it in the queue and as CPU became available, we would then do some work.

Have fun!

Mike
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #23 - Posted 2004-01-01 20:16:13 »

Let's just be blunt about it - JBoss is slow - even its MDB performance is slow, painfully unusable for a game slow. I'd been down that path not once but twice and both times I turned away swearing never to go that road again. EJB is a round peg square hole type of thing - completely useless for gaming. Jboss would be nice and some of the protocols they support now are nice, but Jboss as a collective is way more overhead than the average game can absorb on the server side. Unfortunately.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline brainlounge

Junior Newbie




J2EE games rock!


« Reply #24 - Posted 2004-01-04 09:19:23 »

Well, I disagree with the general statement made here, that

"J2EE is not made for game apps."

A J2EE server is a framework and is not designed for specific apps but for specific architectures.
These are:
- client/server-based
- transaction-driven
- complex (like (much) more than 10 db tables)
- a significant number of business classes
- a team of developers larger than, say, 5
- distributed (clustered)
- integrative (integrates with another already existing service)
- session-based (multi-user environment)
- secure.

Of course, this is only a buzzword list but it can help sort out really fast if J2EE is matching the needs of a specific game app.
To me, this would probably meet for large multi-user RPGs and other apps where the computational overhead is on the server.

I turned away from J2EE a few years ago but right now, with the current JBoss Releases (3.2.x) (together with xdoclet) I am more than surprised how easy you can build up and deploy "enterprise applications". (It was like switching from Java 1.1 to Java 1.2.)

Performance. A J2EE server is like an Oracle DB. You can do very bad things that kill performance. So many switches... It took me really some time to become familiar with the J2EE patterns (do's and dont's). It's a world of its own. And I can recommend to try CMP (container managed persistence) instead of those other persistence frameworks.

RMI/remote calls. Method calls within the J2EE container are no longer remote calls. That was yesterday.

The simple fact that there is no profound J2EE know-how on a game development team rules out the use of that technology!

And: Yes, J2EE is well suited for a Chat app. Why not?
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #25 - Posted 2004-01-04 10:42:27 »

Quote
Well, I disagree with the general statement made here, that

"J2EE is not made for game apps."
...
To me, this would probably meet for large multi-user RPGs and other apps where the computational overhead is on the server.


I would be fascinated to know how you would solve the single biggest (one could almost say the "defining") technical problem of MMORPGs: Every single action by every single player potentially needs to be communicated to every single other player in less than a few tenths of a second, and has to be extensively pre-processed beforehand (e.g. to ensure the client is not sent any more data than it absolutely needs, to prevent cheating via hacked clients).

I have some friends still working at IBM on enterprise arch, and they assure me that IBM at least is moving it's servers in that direction (i.e. capable of huge interdependency between the actions of all clients without loss of performance), but none of them are from a games industry background, and I'm not convinced they fully appreciate the extent of the problems.

Shrug. The buzzword list you provided for J2EE was almost entirely devoid of use-cases, and as a systems architect I'd say it was almost entirely useless to evaluate an architecture for any particular project...it just doesn't contain any of the really important details that allow you to evaluate an arch for your particular needs!

Sure, it's very easy to be vague and say "well, J2EE kind of does the same sorts of things as a multiplayer server with large numbers of players" but by the same token QNX = Linux = Win NT (they're all OS's that are POSIX compliant, except perhaps QNX [I know there *is* a major RT OS that is POSIX compliant, but perhaps not QNX?]).

This certainly doesn't prevent you from being right, it's just I've seen no evidence that would support your disagreement with the statement you quoted. I also know there are other good architectures you can use for MMOG development that are considerably different from J2EE and I cannot possibly believe you could ever code MMOGs as rapidly or effectively in J2EE as in these.

Fundamentally, performance is AFAICS the deal-breaker for J2EE. The things that you need to scale up and the performance criteria that must be obeyed for Walmart's datamining apps are pretty much 100% unrelated to those for a game. J2EE was designed specifically for (things like) the former; I've never heard any suggestion that the latter was even considered?

malloc will be first against the wall when the revolution comes...
Offline brainlounge

Junior Newbie




J2EE games rock!


« Reply #26 - Posted 2004-01-04 14:44:49 »

Quote
I would be fascinated to know how you would solve the single biggest (one could almost say the "defining") technical problem of MMORPGs: Every single action by every single player potentially needs to be communicated to every single other player in less than a few tenths of a second, and has to be extensively pre-processed beforehand (e.g. to ensure the client is not sent any more data than it absolutely needs, to prevent cheating via hacked clients).

Keeping distributed systems in sync (source code, databases, game clients...) comes with the penalty either of (a) complex sync logic or (b) reduced performance (but only when lacking server CPU or bandwith!).

Don't use J2EE for peer-to-peer or fat-client scenarios since they are not strict client/server.

Quote
Shrug. The buzzword list you provided for J2EE was almost entirely devoid of use-cases, and as a systems architect I'd say it was almost entirely useless to evaluate an architecture for any particular project...it just doesn't contain any of the really important details that allow you to evaluate an arch for your particular needs!

The original question was: "Can Jboss and EJB be used for server side online gaming ?" -- Strictly saying No does not seem to be the right answer to me because J2EE is already heavily used for server-side online apps like Online Banking, webbased Bug Repositories, Online Shops -- all kinds of online information systems. What more do you need to know? If a MMORPG is an online information system, I would not rule it out beforehand.

I am not a professional game developer and I am not a game developer at all. I can't prove anything. The target use case has not been given together with the question. If Thierry needs online, real-time audio chat, it does not sound like a server-based application to me. The audio is send to the peers directly, isn't it?

Quote
Fundamentally, performance is AFAICS the deal-breaker for J2EE. The things that you need to scale up and the performance criteria that must be obeyed for Walmart's datamining apps are pretty much 100% unrelated to those for a game. J2EE was designed specifically for (things like) the former; I've never heard any suggestion that the latter was even considered?

Performance is always the killer argument. -- Even for saying Java is not ready for game development, or for anything at all :-)
J2EE is not designed for real-time applications, as isn't TCP/IP, nor Java. All this stuff which is done to achieve that are workarounds (IMHO).

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #27 - Posted 2004-01-06 04:39:50 »

Quote

The original question was: "Can Jboss and EJB be used for server side online gaming ?" -- Strictly saying No does not seem to be the right answer to me because J2EE is already heavily used for server-side online apps like Online Banking, webbased Bug Repositories, Online Shops -- all kinds of online information systems. What more do you need to know? If a MMORPG is an online information system, I would not rule it out beforehand.


I can tell you with certainty that JBoss is not performant enough at the moment to be useful for performance intensive gaming applications where you need the server to process 10's of thousands of messages in few seconds. Performance wise JBoss isn't there yet. JBoss != J2EE. Jboss is an application server implementation. EJB is wildly overkill for anything related to gaming. If you're considering EJB, you might as well just code your networking layer entirely in RMI and be done with it.

The J2EE APIs that are generally useful for gaming applications are: JMS, JSP 2.0, and to some extent JNDI.

If you are building a Flash game that generates all of its content based on server calls - JSP (and possibly EJB) are for you. If you need to pass a lot of messages around quickly - JMS may be for you, if you can deal with the overhead that comes with the implementation... and not all implementations are suited for gaming. Jboss is unfortunately one of them. JNDI is generally useful for just about everything - including gaming, if you have a need for it.

I've been writing code in Java since 96-96 and have done the J2EE track and certified as a Enterprise Architect. I can tell you with certainty that if you are building a game with J2EE - you have done a poor job at architecture. Even if we get past the performance of application servers, what you've just ended up with is an architecture full of a lot of services, features, and overhead that give you absolutely nothing.

Quote

I turned away from J2EE a few years ago but right now, with the current JBoss Releases (3.2.x) (together with xdoclet) I am more than surprised how easy you can build up and deploy "enterprise applications". (It was like switching from Java 1.1 to Java 1.2.)


There is mistake number 1. Games != Enterprise Applications. Your requirements are entirely different. Takes maybe a day of spec'ing out the system in UML to see quickly that J2EE is just the wrong direction to go.

Quote

Performance. A J2EE server is like an Oracle DB. You can do very bad things that kill performance. So many switches... It took me really some time to become familiar with the J2EE patterns (do's and dont's). It's a world of its own. And I can recommend to try CMP (container managed persistence) instead of those other persistence frameworks.


Mistake #2. Performance of a J2EE application server is relative to how its used and not equivalent to that of a games 'server' kernel. Any average multiuser game is simply passing around packets that are ending up on a server. The only mechanism of J2EE that even makes sense in this approach is JMS. However, JMS is for asynchronous messaging and in 80% of cases a game is more interested in synchronous messaging.
 
Quote

RMI/remote calls. Method calls within the J2EE container are no longer remote calls. That was yesterday.


In-VM RMI calls have been removed as an optimization - yes, but the calls between clients and an application server are STILL RMI or JMS based if you're anywhere near J2EE compliant. By law, EJBs do not open sockets nor native resources because that would screw with the ejb lifecycle, particularly passivation and load balancing across multiple containers. As such, the primary mechanisms you'd want to use to communicate (UDP and TCP) are all but forbidden to you by definition in the specification. Ergo, the specification is telling you outright - round peg, square hole.

 
Quote

And: Yes, J2EE is well suited for a Chat app. Why not?


Very true. This is one case where J2EE is the obvious choice. The reliability and scalability provided by JMS make it the ideal platform for a chat application. Throw in a cluster of MQSeries servers and you're done - one week tops.


J2EE is NOT a magic bullet for everything. That's what gets projects into many of the problems they have now. Same with XML. People use it as a magic bullet to solve every problem. I see this same clear lack of requirements gathering with people sending XML to MIDP class devices because XML is universal - cool, so now you're sending large docs across an extremely narrow pipe to a device with very limited CPU for parsing XML, and costing yoru customer a crap load of money in the process. Any design you put on paper will quickly tell you which technologies are well suited and which ones are not well suited.

For most conventional games - J2EE is not well suited, will cost you more money to develop, and give you a lot of 'functionality' that you will end up trying to 'turn off' to get things running quickly.

Wrong direction!

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Jeff

JGO Coder




Got any cats?


« Reply #28 - Posted 2004-01-06 05:46:30 »

In re chat...

But why bother write ANYTHING when IRC is freely available?  Im always astounded that games feel they have tow rite their own chat and then up doing it badly.

And frankly, I think its a heck of a lot faster to write a chat server in J2SE then EJBs and performance is likely to be better without all that unused structure around it.  It would be interesting to do a "race" between a very knowledgeable J2SE progrmamer and a similar EJB programmer and see what they came up with.

J2EE was desigend for enterprise apps.  Its good for enterprise apps. But it can easily become the  hammer thats starts you thinking every problem is a nail.

In enterprise apps throughput is everything, latency is almost a non-issue.  In games, worst case latency performance  IS the critical measure.



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline brainlounge

Junior Newbie




J2EE games rock!


« Reply #29 - Posted 2004-01-06 08:36:52 »

Quote
In re chat...
It would be interesting to do a "race" between a very knowledgeable J2SE progrmamer and a similar EJB programmer and see what they came up with.

Come on, this is the old OpenGL vs. Java thing with new clothes. J2EE is build upon J2SE. So it is trivial to say that a pure J2SE implementation would be favourable over a J2EE implementation without needing J2EE specific features.

By the way, J2EE is not just EJBs. It's JSP and Servlets, too.

When somebody needed to implement a massive multi-player text-adventure in two weeks which does fail-over or clustering and stores large amounts of data on the server(s) and could be tolerated to use HTTP instead of sockets he really gets some bad advice from this thread for not using/evaluating J2EE. Because it maybe is his only chance to do the job on time.

People might call "It's not a game, it's an enterprise application!" because it's not using graphics or not trying to do real time communication. But maybe new types of games are of that kind.

So again, do use J2EE _only_ when you really need J2EE specific features whether it's a game or "a real enterprise app". If not, _do_not_ use it.

It's fascinating to follow the expertise on this forum around those networking and online topics. On the other hand, isn't "the engine" often confused with "the game"? (Which really is the best fun case for a software engineer ;-) )

Quote
In re chat...
In enterprise apps throughput is everything, latency is almost a non-issue.  In games, worst case latency performance  IS the critical measure.

There are enterprise apps where latency issues cause transactions to role back. With regard to TCP/IP latency, you are probably right.

Quote
In re chat...
In games, worst case latency performance  IS the critical measure.

Not agreed. Myst et al. are games where latency is NOT critical (There really where latencies when I originally played it! - Not reducing the fun I had.).
Online chess is a game where latency is NOT critical. Is this board restricted to any game flavor?
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (15 views)
2014-07-24 01:59:36

Riven (14 views)
2014-07-23 21:16:32

Riven (13 views)
2014-07-23 21:07:15

Riven (15 views)
2014-07-23 20:56:16

ctomni231 (43 views)
2014-07-18 06:55:21

Zero Volt (40 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (36 views)
2014-07-16 23:30:00

Cero (51 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!