Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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 7685 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #30 - Posted 2004-01-06 09:41:22 »

Quote

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.


It's quite a common problem that, isn't it? Wink (from earlier in this thread: )

Quote

But XML is not a Universal Hammer ("When all you have is a hammer, everything else starts to look like a nail")

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #31 - Posted 2004-01-06 09:59:58 »

Quote

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

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #32 - Posted 2004-01-06 10:11:56 »

Quote

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?


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

But we're talking specifically about online games, which to my mind means multiplayer, no?

Quote

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
  • ...etc

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Member




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


« Reply #33 - Posted 2004-01-06 13:38:50 »

Quote
In re chat...

But why bother write ANYTHING when IRC is freely available?  



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 Smiley

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 #34 - Posted 2004-01-06 19:49:12 »

Quote

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

... as is with most IT technology. The more detail, the more devil.
Offline Jeff

JGO Coder




Got any cats?


« Reply #35 - Posted 2004-01-08 20:50:55 »

There's one point that seems to have gotten lost here, which is learning curve.  EJbs are very complex and have a steep learning curve.

In the text-adventure example i think the programmer new to EJBs would spend most of his first two weeks getting his tool chain up and running and understanding how EJBs want to be built.

(My background for this guess is having actually written "the worlds smallest EJB execution environment" as part of an experimental project at Sun-- about 100K. )


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 gregorypierce

Senior Member




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


« Reply #36 - Posted 2004-01-09 00:33:14 »

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

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 blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #37 - Posted 2004-01-09 06:08:18 »

Quote

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?


Smiley 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 Smiley, 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 Wink)

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

Senior Newbie




Current project - Venture Capital


« Reply #38 - Posted 2004-02-23 04:54:12 »

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.
Offline brainlounge

Junior Newbie




J2EE games rock!


« Reply #39 - Posted 2004-02-23 14:49:11 »

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.

Slashdot post:
http://games.slashdot.org/article.pl?sid=04/02/23/084232

BIG project:
http://www.alphaworks.ibm.com/tech/big/

White Paper:
http://www-106.ibm.com/developerworks/webservices/library/ws-intgame/

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

Junior Member




Flame On!


« Reply #40 - Posted 2004-06-08 18:38:23 »

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?

Square hole with a square peg indeed.

-Chris
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #41 - Posted 2004-06-08 18:43:29 »

Quote

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 Tongue

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

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

Junior Newbie




J2EE games rock!


« Reply #42 - Posted 2004-06-10 13:51:41 »

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?

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.

BurntPizza (19 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (87 views)
2014-09-10 06:39:09

Tekkerue (42 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!