client/server Game, what is used for server ? Java SE or Java EE ?

Hi,
I searched the forums and payed google a visit, but somehow I did not find out whether you use Java EE or Java SE for Gameservers.
For example you are coding a game which has clients, and a Gameserver where clients connect to (e.g. MMORPGs).
Until now i thought that everything that has to do with Servers has to be done with Java EE, but after reading what Java EE is about I am not that sure anymore.
I guess I still haven’t got what exactly Java EE is capabale of / used for.

I am asking because in the near future I want to make a online game and wanted to know whether the Server should be coded in Java EE, so I might start learning the basics of Java EE.

Thanks in advance.

EE = SE + web framework

So if you’re not interested in the webframework (which you probably aren’t when building a gameserver) you’d best use SE.

If you are writting LAN type games, then you can roll your own, if you are aiming towards enterprise scale MMO games, then take a look at project darkstar. It’s to games, what J2EE is to the enterprise application. Scalable, fault tolerant, transactions, persistance, transport layer etc etc.

It also helps that a couple of the Guys from SUN who architected and wrote it hang around on these forums, lots of useful information flowing about.

HTH

Endolf

What they said 8)

One of “the Sun guys.”

Note that certain kinds of games can be done in J2EE, generally slow-paced and transactional things like trivia games.

Having said that I’m not really sure J2EE buys you anything in those cases for all the extra work it makes you do. In general
you only see this sort of thing happen when the server coders already know J2EE backward and forward so its easier then
learning a new way of doing things.

thx guys.

[quote]EE = SE + web framework
[/quote]
Guess my big misunderstanding was what Java EE actually is.
(Anyone knows a list of example what you usually do with Java EE? I know you can do Servlets, though such thinks can also be done in php or something like that, i guess)

I guess I will check project Darkstar out for an another game where actually many clients/connections have to be managed.
But for the game I am now going to write I’ll be fine with out it, since its just a student projects where we have to code a simple MMORPG.

There is no such thing as a simple mmorpg :wink:

Anyway, good luck with it.

thx, and yeah you are right.
I just meant that it doesnt really have to handle many connections (though its called MMORPG), since we wont have that many testers :smiley:
And it doesnt need to look good (not even 3d) and i guess it doesent even need many features, since we (8-10 people) have to do it within 2 month (in our freetime).

So once I am done with that I can think of coding my own game where I don’t have to rush to get it finished :smiley:

JEE != SE + webframework.

It is aimed at server-side applications, but mind you, in general. Design decisions where made to accompany most of them. (others will say mainstream, or babble about 80% stuff.) (game like mmorp -backends fall into the other 20% / not mainstream) arguably most mainstream server side applications are web(internet?) based, thus leaving its tracks.

also using the word framework to describe something in the IT word makes the description very foggy.

Servlet containers are at the edge of your serverside mess and thus are the most visible part. there is, depending on the situtation, quite a lot behind it.

php’s execution is afaik request based I’m not sure how webgames written in php would elegantly do periodic tasks.

I’d actually like to throw a small spanner in here and say that J2EE is often used for running the server for a client-server game, but that as has been stated above J2EE is generally useless for game servers.

Why the apparent contradiction? Sadly, the J2EE brand is another great example of Sun’s marketing dept being incapable of saying what they mean, or of meaning what they say. J2EE is several things (just like “java” is several fundamentally unrelated things).

  1. J2EE’s special features that seem relevant for networked games and for enterprise games are, mostly, crap - which is what JeffK’s referring to.

  2. J2EE’s core features that most of the mainstream IT world knows and loves are, mostly, excellent - and are frequently used in game servers for the management of the gameserver itself, and for integrating with NON real time parts of the game (for instance: serviing web pages, providing file downloads / patches/updates, serving forums, serving authentication and encryption systems, etc).

The latter bunch of stuff can be “added” to any J2SE implementation just by downloading a bunch of JAR files and downloading a “container” (3rd party “Application Server” that provides a harness from which to run your gameservers, and abstracts away some parts of making a multithreaded server).

So, really, the parts of J2EE that would be of itnerest to you you don’t even need to think about until you get to the point of needing them, because you can bolt them on later.

IMHO. Apologies for the gross generalizations, as normall… :wink: