network apis for mmorpg

Networking & Multiplayer
#1

I’m trying to make a mmorpg that can be played on the internet which can send data at least 10 times per second, allowing multiple local and global chat sessions going on at the same time, and storing character names, states, interactions with terrains/players, etc.

As I’m concerned with the networking part of this program, I want to know whether OpenJMS is a good choice for this and if so, why. There aren’t much sources for this api, so if links for any good tutorials can be provided, I’d be very much appreciated.

Also, is java.net.* sun api a good alternative? Right now I’m considering using this package since I so far can’t find good tutorials for OpenJMS and for this being time critical (I also have to implement this on my own so I really have to understand what’s going on). I also want to know if this api would satisfy the above requirements.

As I am pretty much new to network programming, any useful information is greatly appreciated.

#2

You’re new to network programming and you decided to start on a MMORPG?!?!?!?

Is this a academic project by any chance?

Kev

#3

Ok, MMORPG is a bad choice for your first network code, something with say 8 players would be better. For 8 players 10 updates a second is fine, and you don’t have to worry too much about your bandwidth usage. MMORPG on the other hand will probably need less than 10 updates a second (based on the number of objects moving in that time), also, you need to be really anal about performance and bandwidth. The world you are representing makes a huge difference on the number of updates you can afford to, as does the desired end user connection, are you aiming to support modem users or BB only?, is it a flying (space or otherwise) game, if so, you need lots more info, is it a ground based type game (or planet based, where you only need an x,y and an angle to define the players location), if so, you can afford to send more updates as you need much less information to work out where anything is.
For MMORPG you really need to look at using nio, especially server side, also, for character/ship/whatever movement, you might want to consider UDP rather than TCP, and ignore out of sequence packets, this will result in some jumping on slower connections, but will be better than TCP (player movement can be dropped as you will be updating it next time so you don’t need guarunteed connection, but latency is an issue)(see the nice long thread about UDP v.s. TCP) , other comms should be tcp.

Thats a very brief overview of the nightmare that is MMORPG network issues.

Enjoy

Endolf

#4

[quote]Ok, MMORPG is a bad choice for your first network code, something with say 8 players would be better.
[/quote]
Indeed. Some pro games companies have put non-network specialists to work on producing MMOG’s internally, and this accounts for a large number of those that were announced and never appeared. It’s not simply hard, it’s also unlikely you will ever complete it if you don’t really know what you are doing when you start - or have a LOT of time / money / patience to get it wrong lots of times.

[quote]is it a flying (space or otherwise) game, if so, you need lots more info, is it a ground based type game (or planet based, where you only need an x,y and an angle to define the players location), if so, you can afford to send more updates as you need much less information to work out where anything is.
[/quote]
Incidentally, flying is the easiest to write, ground-based is kind of in the middle, and space is extremely difficult (assuming real space physics - i.e. no friction etc). Of course, if you choose to make space flight just like flying a plane, it becomes easy too - probably the easiest of the lot when you come to load sharing. Looks stupid though :).

You should definitely read that UDP thread.

For an intro to NIO, have a look at:

http://www.grexengine.com/sections/people/adam/nio/Introduction_to_NIO_Networking.html

(nb: those articles are not complete yet, although I’ve had a couple of reports of people managing to fix their NIO problems after reading them, so they’re not too bad ;))

#5

Hmm, I think we might be talking cross purposes here, when you say easiest, which aspect are you talking about, I was talking in terms of the amount of data you have to shift, ie, ground based, map area, x, y, a bearing and maybe the angle looking up/down. Flying, map area maybe, x,y, altitude and then roll, pitch, yaw. Space, (non realistic) sector, x,y,z, pitch, roll, yaw. Of course, pitch, roll and yaw are no good as you can end up in gimble lock (I think thats what they call it), which is where your good old 4x4 matricies come from, which means more data across the link. Of course that is only a small problem, the biggest problem is keeping other players in sync with each other and the server, and keeping the server in sync with each client. This is where the nightmare begins. RTS and some RPGs (like the diablo and Baldurs gate) are simple (client issues command, server performs it), anything that requires constant input (mouse look or joystick) is ticky. So i can’t see how flying or unrealistc space based games are the easiest. Of course even if you have friction in space, you have the extra axis of translation that a plane doesn’t allow, which just adds to the fun :slight_smile: (especially when it cones to trying interpolation)

(Agree with everything else you said, which makes a change :P)

Endolf

#6

I don’t think so…

Exactly. With flying, your position cannot undergo abrupt changes. Hence, maintaining distributed state (distributed across all the clients that can “see” a relevant body) and all the servers (depending upon presence/abscence of clustering)) is easier. As you point out, maintaining this state is the hardest problem in the shifting of data.

Flying also reduces to the smallest amount of data transferred, on average. This is because the the number of bytes to store current position etc are irrelevant when it comes to amount of data to update postitions - what matters is how much data you will send post-compression / optimizations. With non-abrupt changes, you can compress very well (assuming the server knows what dead-reckoning system(s) the client is using, and so only needs to send out data to “correct” the predictions the client is making when the server KNOWS that that prediction will be wrong).

In space…more abrupt changes are the norm.

#7

Hmm
I’m not sure, if you update every visible object say twice a second, you will almost certainly have some degree of error (unless they were flying in straight line, not likely in say a WWII dog fighting game), so you will need to send a correction, in this case I can’t see how you can reduce a 4x4 matrix into anything less than 3 flaots for x,y,z and an AxisAngle, which gives 7 floats, which is exactly the same as for space. The velocities arn’t different either, in flying you need slip, rate of climb, and forward velocity, which are the same as you would need in space, giving a total of 10 floats. You prorably need a rate of roll/pitch/yaw too, adding a further 3 floats (otherwise your prediction for the next cycle will be even worse), so thats 13 flaots for flying or space. The prediction methods vary, but as long as the client and server are using the same method they have almost no effect, as anyone doing any prediction will be incorrect compared to the authority (the client probably).
Ground based (walking in this assumption) is not quite as bad, needing x,y, maybe a z depending on wether you are allowed in multi-storey buildings, a direction you are looking in (rotation and elevation), plus some flags for walking sideways, walking forwards/backwards, and running forwards/backwards forwards, which is 6 floats plus a short or something for the flags. I can’t see how, knowing that things need updating, you can possibly shift less than this amount of data, per update.
I’d like to know, i’d love to have 100+ ships in a fight even for modem users :slight_smile:

Endolf