# PW / MMOG server language?

This topic is 4836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm currently working on the client for a PW. I've got to the stage where I need to make a serious start at the server side of things. It seems fairly obvious that a Linux platform is the right choice for PW servers, but I can't decide whether to implement it in C++ or Java. I have professional experience in both, and am having a hard time making the call. Can anyone suggest some pros & cons? i.e. "I can develop the Java server on my win32 laptop and porting to Linux when the time comes is as easy as copying the Java files over and recompiling." vs "C++ is faster, period"... and so on. :) Thanks!

##### Share on other sites
If you are comfortable in both languages, and have no annoying constraints (e.g. "all users have only java v1.1"), AND you don't need it to run on consoles, then java is better all round. Sun has been promising a JVM on consoles for 2+ years (and hinting heavily that the first one would be PS2 or PS3), but so far they've delivered nothign, so assume the worst in that direction.

The speed difference is negligible, both have fully working OpenGL with shaders, both are decent (though far from perfect) OOP languages.

Java is consistently faster to develop with, and the bugs are much quicker/cheaper to find and fix (apparently you tend to get fewer of them too, although that probably depends on programming style and ability). This is not opinion per se, but the result of endless studies into programmer productivity; it's why IBM et al ended up adopting java for all their internal development where possible - because they proved that on average it was cheaper to develop with.

Bascially, java benefits from being 10 years younger than C++, so some of the thigns C++ was experimenting with, Java has been able to copy the good bits and get rid of the bad bits. They only got this process 90% right, which is why C++ experts still get frustrated with a lot of esoteric aspects of Java (but, when you happen to *need* one of those esoteric bits to work, as it did in C++, it doesn't seem so esoteric any more!). However, the chances of you hitting that problem are very low unless you are doing something sufficiently specialized that...you'll probably know you're going to hit it before you even start.

c.f. http://grexengine.com/sections/externalgames for more info on developing java games - the games section has some ****-hot games in there (although the latest generation of pure java games, e.g. those using realtime shadows, haven't been added yet since they're still being tested). There's also a technologies section which conveniently lists the major OpenGL bindings in java, with links to downloads, demos, etc.

##### Share on other sites
Ooops just noticed that you are asking about the server only. I saw the "working on the client" in the first sentence, and...

Java is definitely better on the server if you have no other constraints and are equally good with Java and C++. Look at all the commercial MMOG middleware servers: every single one uses java.

Even the hobbyist / open source engines: almost every single one uses java.

This is not likely to be co-incidence, nor a major conspiracy!

##### Share on other sites
Wow, ok, I should've done my research better. Thanks for your prompt reply :)

It's time to dust off my Java hat again...

##### Share on other sites
Quote:
 Look at all the commercial MMOG middleware servers: every single one uses java.Even the hobbyist / open source engines: almost every single one uses java.

oh really?.. :/ Got any links that supports that claim?

##### Share on other sites
I'd go for whatever the client is using. You simply don't want to rewrite large portions of the game in a different language.

##### Share on other sites
Quote:
Original post by peter_b
Quote:
 Look at all the commercial MMOG middleware servers: every single one uses java.Even the hobbyist / open source engines: almost every single one uses java.

oh really?.. :/ Got any links that supports that claim?

Here's some that I remember:
Terrazona from Zona Inc. use java for the server infrastructure.

Butterfly.net also.

Ice has a java implementation.

And also, Globus Toolkit, a widely used grid infrastructure, use java.

------
Nevrax powering the game Ryzom is done in C++.

I personnaly choose to do my implementation in c++.

Gizz

##### Share on other sites
Globus is irrelevant to my original point, since it's merely a distributed computing platform - i.e. that fact that it's done in java is unrelated to games development - despite the fact that people are considering using it (or, in BF's case, have based some of their work off it) for MMO work.

There's also GrexEngine and BigWorld (MicroForte) - both of which are commercial java MMOG server systems.

##### Share on other sites
Hmm, I've studied BigWorld with some interest, as their 'cellular' load balancing is something of a parallel to what I did my CS dissertation on, allocation heuristics. Wonder how much the licence would be ;)

Interestingly, MicroForte seem to be branching out into mobile device MMOG development, and are paying a crapload of \$ for the people to do it.

After sleeping on it, I'm still fairly happy with Java. I did think about the 'rewriting code in a different language' argument, which definitely has merit, but overall Java just supports backend infrastructure better - db connectivity, stability, threading, networking and so forth are what the language was designed to do...

##### Share on other sites
The Java libraries are fairly nice for cross-platform development...but if you only ever need it to run on Linux, then it doesn't really give you much over C++. You should probably choose whatever you're more comfortable in as a language.

##### Share on other sites
The platform differences relevant to a game server between Windows and Linux (in say, C++), are incredibly trivial compared to the task of writing a MMOG server itself.

We're talking about wrappers that could be hacked up in an afternoon here and there. Just trivial.

Winsock and Linux sockets are for the most part identical. File IO is likely to be identical. Threading will be a little different (just call different functions to achieve the same thing), but basically the same.

True, the actual main loop architecture might vary a bit - but that will be something you need to study carefully to get it right anyway.

Personally I'd want to code the client and server in the same language so I could share code - but I haven't actually written a MMOG, so what do I know :)

Mark

##### Share on other sites
One of Java's big strengths is its database connectivity - it took me about 15 mins last night to download and hack up a JDBC/MySQL Java class.

I think overall I am more comfortable writing the server in Java, since I've done serious industry back-end work before in Java, while my C++ experience, though greater overall, tends more towards the graphics/game frontend side of things.

##### Share on other sites
Quote:
 Original post by davedxHmm, I've studied BigWorld with some interest, as their 'cellular' load balancing

As far as we could tell, BigWorld's architecture is almost the same as GrexEngine's. Although very little public info is available on grexengine, we recently had some patents provisionally accepted, and will now start publishing much more info (we had to get permission from the patent lawyers first).

Quote:
 Original post by Promitif you only ever need it to run on Linux, then it doesn't really give you much over C++.

No. That completely ignores most of what's different between java and C++ (hint: cross-platform is a bonus side-effect of java's design rather than the central plank; it was Sun marketing that made it seem the be-all and end-all :( ). However, if the OP is equally familiar with both languages, they'll already know this.

Be warned, however, that for an MMOG server the I/O aspects of java *right now* are both much better and much worse than C++. Within a month (according to rumours) java 1.5 should be released. If that is a good, stable release then java will be *almost* entirely superior to C++ in I/O; if not, then it will still be a toss-up between them. Java is currently much easier to program fast, efficient I/O, and doesn't have to be recoded for different OS's; OTOH, you are at the mercy of your JVM when it comes to which of the asynch I/O subsystems they implemented with - one of the Sun JVM's actually used poll, which is quite shocking. You *can* get 3rd party soloutions (e.g. IBM offers a standalone cross=platfrom asynch I/O lib for java), but such esoteric things run major risks of support problems.

redmilamber

##### Share on other sites
Quote:
 Original post by markrThe platform differences relevant to a game server between Windows and Linux (in say, C++), are incredibly trivial compared to the task of writing a MMOG server itself.

Before I comment on what follows, let me just say that I agree entirely - the MMOG writing is a vastly difficult task, and most things pale in comparison.

Quote:
 We're talking about wrappers that could be hacked up in an afternoon here and there. Just trivial.

I disagree strongly with this.

You could, theoretically, use the lowest common denominator functionality - if you emasculate your implementation on all platforms, then it will largely run without code changes equally badly on all platforms.

However, we are talkiing about MMOGs. Realistically, the LCD is not good enough, and you need to go for something better. It's not reasonable to refuse to use IOCP, to refuse to use the epoll replacement, etc.

Once you start trying to use those, you hit major x-platform incompatibilities (IOCP == windows only; most of the poll-derivatives == unix/linux only, and only some unixes).

Quote:
 Winsock and Linux sockets are for the most part identical. File IO is likely to be identical. Threading will be a little different (just call different functions to achieve the same thing), but basically the same. True, the actual main loop architecture might vary a bit - but that will be something you need to study carefully to get it right anyway.

Again, I agree that if you stick to just looking at the socket level, then it is for the most part identical.

However, speaking as someone who actually codes IO layers for MMOG servers (c.f. grexengine.com) I can attest that when you go just one abstraction layer higher then the differences between the underlying OS subsystems become glaringly obvious and a major headache. I say this having spent the weekend polishing our abstraction layer because (in my free time) I've been working on a game that needs to stream hundred-megabyte files, and I wanted to do it transparently through the same IO systems that are efficiently serving tens-of-byte responses (e.g. position updates sent to clients etc). What really came home to me was how - even in java, which has done an excellent job of abstracting and unifying the different asynch IO systems - the I/O primitives are still extremely heterogeneous, making life a real pain (assuming you need to achieve high performance both on throughput and latency, whilst simultaneously keeping your programmer API's clean and efficient).

Quote:
 Personally I'd want to code the client and server in the same language so I could share code - but I haven't actually written a MMOG, so what do I know :)

Point taken. However, you currently CANNOT write java client games for PS2, and writing your server in C++ will cost you 20%-50% more than using java.

So, in many cases, people are having to use one language for the clients, and a different one for the server.

And, of course, there's the issue of multiple client platforms: if you're writing your game for consoles + PC + mobile phones, it's unlikely you'll be happy using just one languge across all of them; especially seeing as you'll typically have independent teams working on the different platforms, so that using different languages is easier. Most of the mobile coders are java, most of the console and PC coders are C++.

Although I'm still praying for the day when you get the best of all worlds using just one language, because personally I find that maintaining multiple parallel language-teams throws up just enough problems to keep me awake at night :(.

##### Share on other sites
As far as I've been able to determine, there are two kinds of MMOG servers: those that just act like big routers and forward data between places (with a modicum of validation), and those that actually run the same physical simulation on the server as the clients.

If your requirements for interactivity, latency hiding or integrity of the game world aren't that high, then the first is good enough, and you can use a different language on the server from the client. If you co-simulate on server and client (as in the Forterra platform), then you have to use the same language on both ends, or write ALL of your simulation code TWICE and have both implementations always come to the same result -- not my idea of fun :-)

As far as I can tell, Persistent Worlds (Second Life, There, etc) lean more towards distributed simulation, whereas RPGs lean more towards packet forwarding with validation (EQ, CoH, WoW, etc).

##### Share on other sites
Quote:
 Original post by hplus0603If you co-simulate on server and client (as in the Forterra platform), then you have to use the same language on both ends, or write ALL of your simulation code TWICE and have both implementations always come to the same result -- not my idea of fun :-)

Java has a small advantage here (and in all lockstep distributed simulation games) in that all operations are guaranteed identical on any hardware - for instance, the reason that some ix86 floating-point maths is damn slow in java is that the available processor instructions don't adhere to the full strictness of the IEEE spec that Java mandates, so the Sun JVM uses software emulation.

This is great for reproducability on all platforms, not so good when you don't actually care (e.g. when you just want to render something fast, and 1-pixel errors don't matter). IIRC, the current implementation is slightly over-cautious and is about to be improved, so YMMV (and check the facts rather than take my word for it!).

But IMHO your client-side simulation should generally be non-perfect and checkpointed against the server anyway, because it's easier and more robust. Of course, YMMV according to game-design.

##### Share on other sites
*shrug* My server is 95% in C# managed code running on Windows 2003 server. I did have the majority of it written in unmanaged C++ and only had the scripting system built in C#.

I ported over fully to C#, profiled, and than put back in some of the unmanaged code calls just for slight performance reasons. Right now my server that is ( 95% C#, 5% C++ ) is performing the EXACT same as my old server that was ( 90% C++, 10% C# ).

##### Share on other sites
Quote:
 the reason that some ix86 floating-point maths is damn slow in java

I would hardly say that this is an _advantage_ of Java for distributed simulation ;-)

##### Share on other sites
I was thinking about the PW vs MMORPG thing.

Ok so an RPG type is just a validating packet forwarder - but doesn't it still need to run the simulation in order to validate the packets? Like, how can it know if a movement vector is valid or not if it doesn't know the spatial details of what's being moved, where, in which part of the world?

I understand obviously the graphical side of things only runs on the client, but doesn't the simulation still have to run on the server more or less the same as on the clients? (In fact I would think it runs at full 'detail' on the server, and less 'detail' on the clients).

##### Share on other sites
Quote:
 Original post by davedxI was thinking about the PW vs MMORPG thing.Ok so an RPG type is just a validating packet forwarder - but doesn't it still need to run the simulation in order to validate the packets? Like, how can it know if a movement vector is valid or not if it doesn't know the spatial details of what's being moved, where, in which part of the world?I understand obviously the graphical side of things only runs on the client, but doesn't the simulation still have to run on the server more or less the same as on the clients? (In fact I would think it runs at full 'detail' on the server, and less 'detail' on the clients).

The simulation 'has' to run on the server, the real question is wheter the client needs it.
A 'dumb' client might not need to do much more than render the world, however for a MMORPG you really want to do as much as possible to on the client minimize server load.

And this is exactly why you don't want to use different languages: You'll end up writing two versions of the simulation code.
For example, in our game (not a MMORPG) about 90% of the code is shared between the client and server.

##### Share on other sites
The question is how MUCH of the simulation needs to run on the server. Perhaps doors don't turn; they're just polygons that are passable or impassable. Perhaps trees don't collide on the server ( I know they don't in EQ -- and mobs will warp when they collide with a tree on the client). Perhaps you run a swept sphere along the path of travel of your character five times a second on the server, but every rendered frame on the client. Maybe you do rigid body simulation on the client, but bouncing spheres on the server.

If you run the full simulation on the server, you're getting towards a distributed simulation, rather than just an RPG. If you're doing a persistent world, then that's probably what you want to be doing, but for an RPG, it's currently probably overkill.

##### Share on other sites

This topic is 4836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628720
• Total Posts
2984393

• 25
• 11
• 10
• 16
• 14