Java in consideration for MMORPG

There is a group of us that have been sitting on a concept for the last couple of years that we’re finally starting to flesh and design. Of course, we all feel that what we’re proposing to create will re-shape MMORPG gameplay as we know it today.

We’re wanting to develop a system that would compete with the biggest MMORPGs on the market today: Dark Age of Camelot, EverQuest II, City of Heroes.

The question is: could we use, and rely on, java technologies to write such a graphical and bandwith intensive game? I’ve been reading through the other posts and what I’ve gathered is that this new gaming architecture supplied by Sun is mostly being used for mid-scaled games (1st person shooters, single player, and classic models).

I would love to be able to Java, but I’m worried about performance issues.

All of you input is greatly appreciated.

There are no performance issues if you know what you’re doing. You should be reasonably confident of being able to write Halflife 2 or Doom 3 in Java these days.

Cas :slight_smile:

I agree with Cas that the biggest bottle neck in Java is not Java, but the use of it. That pretty much goes for any language.

For high-end graphics, like C/C++ most of it is done on the graphics card anyways.

I am pretty new to Java but I think I can offer some advice.

Yes it is possible, but keep in mind that writing something like EverQuest II in java will be a huge jump from what currently exists.

From my understanding (I have never played DAoC but I was over at a friends house and watched him play for what seemed like 3 hours) DAoC has graphics similar to EQ1?

If I am right, then I think you should first try to develop somthing like DAoC or EQ (graphics wise, you don’t have to copy the gameplay obviously) that can play on can play on a system with low requirements. EQ in its intial release ran perfectly on my 256 mb computer with a 32mb graphics cards. I think writing a graphics engine that has EQ (or a similar game) like graphics in Java that can run on a computer with 256 mb and a 32mb graphics card should be your first step.

Right now there are Java games out there with graphics like that, but they require more powerful systems to run on than would the same game if programmed in C/C++. Before you go about developing graphics like those in EQII, first try to make EQ1 graphics that can run on the recomended requirements for EQ1 in its initial release.

Sun is working on making Java better for game programming, and communities like these certainly give them an incentive. I think eventually Java will catch up to C/C++ but it will surpass it because Java is much easier to use and quicker to write with.

Games like EQ2 use DirectX/OpenGL, and as such most of the work is done by offloading it to the specific card… the extra overhead from using Java to interface to this native layer is pretty minimal…

Thats not to say your not right, Java does need more powerful hardward to perform in the same way but thats not really to do with graphics.

Kev

PS. Incidently, DAoC is under constant develpment including new graphics engines as new hardware emerges.

yes it can be done… think about your networking and
sound… the 3d is pritty much in the bag…

networking; its more of a case of what direction
you want to go in… theres a few people here that can
help with options. java is v.good a networking…

sound; give me a second- just need to make the
website- we have gone with the same engine as
World of Warcraft (FMOD). and have made a very nice
java like api of FMOD coming soon as i get a second.

3d: xith3d or jme- they both have there pros and cons.
but its all rocking. if u want to do your own graph then
theres jogl and lwjgl.

If you knwio what youa re doing, then modern J2SE VMs can deliver the same performance over-all as C/C++

There are techniques that are faster in C then in Java, and techniques that are faster in Java then C. It jus t a questio nof knowing the strengths of your coding environment and coding to them.

Garbage colelction used to be something yo uhad to eb careful of but, frankly, I am not seeing it as a problem in any code Ive written since late JDK1.4/JDK1.5. With justa slight repidation Im going to sugegst that that nut has finally been cracked by the VM teams.

Java does tend to require a bit more memory still, but in these days of games that require 1 gig (Matrix Online) its getting to pretty much be noise level.

The really amazing thing about Java is the time it saves you in Q&A and the srength of the prosduct released. We colelcetd so mstistics from develoerps a few years abck and crunched them and found that the average Java game team spent less then 5% of their total productio time in Q&A. COmapre that with C code…

Secondarily, with a small bit of tuning/debugging work, its more or less portable to the mac and Linux which is a nice little plus. OTOH it is nto yet portal to the game concsoles, which IS an issue for some game developers that those of us in the Game Technolgoies Grou pat Su nare (painfully) aware of.

Now the formula changes when you go down to J2ME and cell phones. If you want the state of that space, let me knwoa s its a whoel other discussion.

Java is also a good language for server development. The GTG’s Sun Game Server project is more or less pure Java. However again there are tricks to getting the best server performance our of Java. Big oens are that you want to use NIO’s sockets, for which there is soem learnign curve, and NIO Buffers to implement a copy-free stack.

Any chance you can explain what you mean by a copy-free stack? Am I correct in guessing that it means that you dont parse game commands/packets out of the buffers and create object of them, but instead let your logic work directly on the buffer?

Thanks

Yes but it goes a bit further.

Any sufficiently compelx and well archietcetd server system is going to have multiple wrapped protocol layers in the game packets. The trick is to do all you un-wrapping and parsing so that you never have to copy the data. The same is true for data you send. NIO Buffers have the facilities to let you do this.

how do u do that then Jeff? :slight_smile:

There are two key things buffers do that help you here:

The first is the slice() method. The slice() method makes a new buffer that is a subset of the old buffer and shares its data. So when you are parsing nested protocols you can read the ehader of the outermost layer, slice to get a new buffer that starts at the next-in header, and pass that to the next layer of code.

If your headers are fixed though you cna actually use something called “scatter loading” which allows you to take onebit stream and read it into a set of buffers in one op. This can automatically sep4rate thinsg for you.

Similarly, and important to the exampel I gave above, there is a “scatter send.” So rather then having to wrap the exisiting data in a new buffer in order to add a heaer at the front, you cna just inster that header in the front of a list of packets and then ask NIO to send the entire list as one packet.

Look at the NIO docs for Buffers and SocketChannel for more info.

Sometimes it feels like I’m the only person on the planet who actually uses scattering, so a warning:

Doesn’t really work on Sun’s JVM’s. Haven’t retested on java 5 yet, but java 1.4.x scattering/gathering is the slowest op you can do - you can go via the CPU with a manual scatter/gather faster in all cases (and exponentially faster in increasing number of scatter/gather targets) with your own software implementation.

So, the message is: never trust Sun’s NIO implementation :P. Always be careful to benchmark, because repeatedly these things that “should be” faster aren’t, and 99.9% of people on the net talking about them have never used them (have a look at the docs and what they say about indefinite blocking, then look at what Sun’s own code does!). No, really - I’ve caught several people out who like to teach others about them but don’t publically admit they’ve never tried them themselves. Gah.

Somewhere in the networking forums here from around a year ago is a thread with source for a test program to demonstrate how slow Sun’s impl is - although there may well be a bug or two in that copy.

shrug

Ive used them a bit and they’ve worked fine for me.
As for speed ive neve really run into the need to tune that part of the code so I really can’t say one way or the other.

Yeah, I’m sure you have - but there are others I know have/had not.

A factor of 10,000 times slower than a manual software implementation ought to give you pause for thought :slight_smile:

If its not a problem, then its not a problem. Tune what matters. The rest is a waste of your time.

Still Id love to see your numbers and test backing this up as it makes very little sense to me and, if true, sounds like a major bug that shoudl be reported…

I already told you where you could find sample code and examples of test runs.

And yes, I did report this as a bug with Sun circa 12-18 months ago - but IIRC no-one @ sun picked it up (apologies if this is wrong, and they fixed it and told me it had been fixed :wink: - I log quite a lot of java bugs, and the (currently) often very slow response times (didn’t used to be like this :() mean these days I often lose track of which bugs have been responded to and which have been ignored)

“Somewhere in the networking forums here from around a year ago is a thread with source for a test program to demonstrate how slow Sun’s impl is…”

Is not an answer. I am not going to searching through a year’s worth of forums to find the proof of your assertion for you.

If you want it taken seriously you need to provide the test case. if you bug reported it, a BR number will suffice.

Um, Dude, I really don’t care if you read it or not! :slight_smile: It was an FYI - you said you didn’t believe it, I pointed you in a direction you could check for yourself. I’ve warned the OP about the problem (and any other readers), and that’s all I wanted to do.

Well, if you want to be taken seriously maybe you should use search/google more often? :stuck_out_tongue:

Nuff flames and bait please. Whinging should be banned on this forum. If there’s a problem and it’s being whinged about but no-one’s submitted an RFE and BR for it, go do that instead of moaning.

Cas :slight_smile:

I guess you always use big endian byte ordering, as otherwise bugs like 4715166 are intensely irritating.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715166