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.

This is perfectly true. It is also rather incredible (literally) ... I can imagine this happening (sort of) but I would find it hard to believe it ever happening, for purely practical reasons. E.g. it would take many months just to produce enough (textual) content for a single adventure (MUD), and probably require many people working on that time scale to satisfy enough people to make clustering and failover a requirement - so it's very unlikely that the engine for running this would have to be delivered in two weeks.

Quote

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 ;-) )...Online chess is a game where latency is NOT critical. Is this board restricted to any game flavor?

Hmm. I'm not sure I understand your first sentence here, but you seem to be implying that the vocal posters here have obvious particular narrow fields of expertise, and are overly critical (and suspicious) of anything outside of that. If so, you need to read more carefully - many of us have very wide experience (e.g. there seem to be a lot of people here with a commercial J2EE background), if not - sorry for misunderstanding you!

The posts on this topic seem to have mostly followed:

Quote

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

More specifically, in the light of your initial statement

Quote

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.

part of the problem is that J2EE is NOT made for MMOG architectures. It's even less suited to "normal" game architectures, where most of J2EE is useless.

The other part is that the J2EE implementations are also NOT made for MMOG apps. They suck - the performance is dismal (given the problem domain).

Therefore, most of us with direct experience feel that J2EE is not suited to game apps; we understand that it is first and foremost an architecture, but it doesn't work on either that level or the practical level.

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?

Myst is a single-player game; of course latency (of a J2EE implementation) is not an issue!

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.

Indeed. However, the posts in this thread have pretty much said "for most games, J2EE is a bad choice"; you seemed to start by suggesting that J2ee was more widely appropriate than this. In fact, the percentage of online games for which J2EE is appropriate is, IMHO, somewhere under 5%, probably much less.

Perhaps you could post specific examples of games where J2EE is an appropriate choice, which could be useful to readers of the thread? Although vague examples wouldn't help, unfortunately, since with choosing J2EE "the devil's in the detail".

Quote

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.

No, use J2EE only when you both need j2EE features AND your game (app) actually follows the basic assumptions in J2EE - that is a long list which includes:

particular traffic patterns

separate ranges of tolerable latency for each of: per-method, per-bean, AND per-user-request

potential re-usability of code (N.B. business logic potentially has 99% or so reusability, games exhibit much less for quite complex reasons)

existence of many 3rd-party component vendors, creating a huge marketplace of purchasable components

Integrating IRC into a Java application is actually a LOT more work than staging a clusterable JMS solution. I could stage a JMS solution in a day right now, no question - and be able to pass arbitrary application specific object across the architecture, secure it, and break it up into topics with little to no effort. Easy as pie with JMS. If you've written more than 200 lines of code for the client and the server, you did it wrong

Indeed. However, the posts in this thread have pretty much said "for most games, J2EE is a bad choice"; you seemed to start by suggesting that J2ee was more widely appropriate than this. In fact, the percentage of online games for which J2EE is appropriate is, IMHO, somewhere under 5%, probably much less.

Re-reading this thread I have difficulties coming to the same conclusion, while at the same time agreeing to most of the thing said here.But you are right, I don't know if J2EE is appropriate for a game. I cannot prove it. I'd have to write one, I guess. But I can in my weird mind think of games where J2EE was worth evaluating.

One question concerning "grexengine", described on the web site as "approximately equivalent to J2EE". Assuming you are right and J2EE/enterprise architecture was _potentially_ appropriate for <5% of all online games and let's roughly assume that online games have an overall game market share of, say, 50% (??more, less??). Then how much of the game market is your company targeting with grexengine? Is it a niche product?

Quote

Although vague examples wouldn't help, unfortunately, since with choosing J2EE "the devil's in the detail".

Sun REALLY needs to work with folks to simplify J2EE overall. Many many lines of code to do even simple things. If it weren't for XDoclet, I would probably still be figuring out that EJBs for gaming (even on the backend) are not performant enough for prime time Even MDBs (which was extremely disappointing) just don't cut it for the latencies that one has to deal with for the average online game.

One question concerning "grexengine", described on the web site as "approximately equivalent to J2EE". Assuming you are right and J2EE/enterprise architecture was _potentially_ appropriate for <5% of all online games and let's roughly assume that online games have an overall game market share of, say, 50% (??more, less??). Then how much of the game market is your company targeting with grexengine? Is it a niche product?

I'm not quite sure I understand your assumptions, so I'll be verbose in replying...

Describing the grexengine relative to J2EE is a convenient starting point to give people a handle on it.

Both are based first-and-foremost around a particular architecture

Both fit into the category of "service-based" architectures

Despite any failures of J2EE , chunks of it were clearly designed to be very easy for people to program against. E.g. Servlets are incredibly simple, at first, and seem to try and remove the need for most HTTP-specific knowledge. The GE is aimed at developers with no distributed-systems expertise, so there's a lot of emphasis on making all the services and the main architecture very simple to understand and use, AND requiring as few lines of code to achieve things as possible (and it takes a lot of effort and head-scratching to achieve that without producing "dumbed-down" interfaces that lack power/flexibility).

Some versions of the GE actually have many elements in common with J2EE - e.g. TP, clustering, etc.

The biggest difference is that the architectures are completely different as soon as you step below viewing them as "basically service-based". The second biggest difference is probably that the GE is explicitly designed to be customized by the customers at every point - whereas with J2EE implementations, you aren't supposed (historically often weren't given any means of doing it) to fiddle with large sections of the system; you just had to accept that there was a container doing what you wanted it to. If it was slightly doing the wrong thing, or in the wrong way, you weren't allowed to go and tweak it. Over time, more implementations have given you more tweaking options AFAICS, although IIRC none of this is mandated by the J2EE spec? With the GE, the opposite is true; everything can be customized, and this is mandated by the architecture (in fact, it accounts for a major part of the architecutre itself).

Finally, on to market shares. The main GE is targetted at MMOG's, defined as games with approx 10k to 500k simultaneous players today (scaling up to millions in the future, if necessary; it's not clear yet how many non-trivial games will grow to that size, if any).

The recently completed GE-Lite is aimed at much smaller games (typically 0.5k to 50k) and uses the exact same architecture, so you could swap back and forth between the two without recompiling your own code. In particular, the GE-Lite is for games that probably don't think of themselves as MMOG's (except when their marketing droid wants to use some buzzwords); for instance it currently doesn't include any of the "shared virtual world" systems like the geographic ones. Most games in this segment don't have a world-map with people running around on it. It's also for games that are starting with modest playerbases and want cheap technology to get started with.

MMOG's have a market share of something like 5%-20% of the games market (I'm basing that estimate on knowledge of how many US homes purchase games, and how many players each of the US-played MMOG's currently has, then adding some more to take account of the MMOG's that are not really played in the US but have many more players).

So, the two GE-based products together are probably not serving a niche market, although each alone is arguably in a niche.

Hope that helps. (fx: wishes something like this were on the website and I didn't have to type all that out )

There is a lot of very interesting dialog in this thread. I know the common consensus has been that EJB is not a game oriented technology, but a critical assumption has been made. J2EE may not be suitable for real time applications, but it looks perfect for turn-based games such as board games, text adventures, and turn-based strategy games. I am working on speccing out a complex web-based turn-based strategy game and can see applicable uses for almost the entire J2EE spec. JSP/Servlet for my presentation layer, EJB for my application logic and database abstraction, and possibly even JMS for talking to alternative I/O like SMS messaging. So, be careful when completely ruling J2EE out of the game world. Square pegs work wonders in square holes.

Today's Slashdot pointed me to an IBM alphaworks project called 'BIG' (Business Integration for Games) which allows an online game to make use of a Webshere based online billing service. It's not yet (and maybe will never be) a product, but it shows that there are notions of seeing certain games as 'enterprise' systems.

brainlounge: Good links, and underscores a good point that is possibly being missed in this thread (but also may not have been the perspective of the poster) which is: EJB can play a role in online game development outside what the gamer actually sees. Perhpas J2EE is not the correct technology to maintain the state of players and NPCs as they move across the universe, but what about some of the other aspects of a MMOG? Billing is a great example: If you have EJBs to handle the 'business rules' of account creation, then it would be a very trivial matter to include a third party billing Bean that you could fold into the transaction that involves account creation.....if the BillingBean throws an exception, you can rollback the account creation performed in your AccountManagerBean. (for example).

In addition, one aspect of MMOG that EJBs would be a very good fit for would be inventory management: How many dup bugs would be eliminated if the inventory and transaction mechanisms used was based on something with a proven track record vs. something homegrown?

In addition, one aspect of MMOG that EJBs would be a very good fit for would be inventory management: How many dup bugs would be eliminated if the inventory and transaction mechanisms used was based on something with a proven track record vs. something homegrown?

Or people developing MMOG's could just do their due-diligence and buy real software for their backend instead of paying interns to hack it together

Really, eliminating dupe bugs has no need for bean solutions - TP systems are extremely well researched and understood (I have a 3 inch thick book on my shelf above my desk entitled "Transaction Processing" which is more than 10 years old, yet 80% of it is still perfectly valid today) - and little inherent advantage (beans and J2EE are slow, for instance).

If you're just going to look at functionailty offered by J2EE (which is what you're starting to do again) then it's a very bad fit because it just can't cope at runtime .

my guess would be that in any server-side application you have to trade performance and bandwidth for "enterprise"-capabilities like fail-over, data consistency over the cluster, message transaction management, scalability and modularity.

so you would either have the first and your system would have reduced or no "enterprise" features.or you have the latter, reduce performance and bandwidth, and your game would no longer work.

having read most of the dozen-or-so specs constituting J2EE I never read a phrase like "This feature should be implemented to run slow".

if someone would like to make his very own, balanced trade, the choice is given to him by modern J2EE servers. they offer all kinds of optimisations, caches, tweaks and different transaction strategies.

i don't believe anyone stating he can give you unlimited speed and unlimited scalability and unlimited data replication at the same time before he has not put the system under production load (be it J2EE or proprietary). but you don't need /unlimited/ speed and scalability in a production environment, just as much as is needed ;-). and that's what where the deal starts.

"proprietary" engines may be optimized for more-or-less-general gaming needs. but i doubt they can right now be as good as established, well-known J2EE engines when it comes to "enterprise" features, can they?

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