Developers Corner

Though I'm a programmer when developing the framework and network code for my mmo I've been running into a few snares when it comes to I/O. I'm trying to find innovative ways at reducing how much info is sent from server to the client for movements, actions, and other data (character equip etc..)

For character move ment you need need to keep track of characters on a 3d plane with 3 verticies or the

x,y and z axis's.

now character location in the game is  stored via the following design in a branch system

SolarSystem -> Planet -> Region -> Area -> Zone -> xyz

Now using this system its capable to severly reduce the I/O needed to be continually updated

SS/Planet/Region/Area/Zone only need to be updated once  unless the character zones other than that you only really have to update the xyz continously.

to transmit ss-zone it will take 5bytes of data (can pack data into bits) - > 5 bytes

then you have to transmit the xyz which = 3 btyes of data                          -> 3 bytes

so every update you will send 8 bytes of data for just character location which seems like too much because say we update 100 times a second which is common of fps games so one character would generate 800 bytes of data every second times x amount of players and you get over spam to your servers.

with only 10k people online server will have to deal with 10-16MB of data every second. But we can't really lower the update rate because even though you can't get perfect (exact) location and its more of running the updates through a movement prediction algorithum to guesstimate your characters location and I know that the more updates creates a path closer to the actual path your character takes on the server.

one way I think I could reduce the spam is to again only update the data except xyz which will cut down the load from 8bytes to 3bytes per update.

I am also thinking of not transmitting the y coordinate because the y is most always the same as your virtual floor. So you don't have to update the y because you can go off the y + buffer zone for your characters height on the plane and only have to send it when your character does something special like jump, fall, fly etc.

with this when your character is not doing anything special it will only send 2 bytes of data.

one solution to this could be bit packing - 00001111 + 00001111 = 11111111 (then split when get back to servers) but I don't  know how much processing stress this will cause or even if you will end up sending more data just to let the servers know what its actually processing.

and not to mention all this but we have to load

Character data

Character Actions

Character viewplane (shows where other characters are looking up/down etcc..)

Character direction

which still adds to the massive i/o already.

any thoughts on how to further reduce? or critiques on if said above is feasible on a massive scale ?

going for 100 updates per second and 10,000+ simultaneous users if not a lot more.

again this is all without knowing how much Large server farms with gigabit internet lines can take every second or its maximum load capacity.

Firstly, you are NOT updating client position 100 times per second. FPS games don't update client position 100 times per second. I'm pretty sure I remember reading that DOOM3 updated the physics 30 times per second. In my mmo I am currently updating positions of mobs 10 times per second, although that might still be too high. What you want to have are both interpolation and prediction.

Interpolation works like this:
tick1, we get a packet that says someone is at x=2: we set that person's position to x=2
tick2, we get a packet that says someone is at x=3: we set that person's position to x=2.5
tick3, we don't get another position, we set that person's position to x=3.

Prediction works like this:
tick4, we don't get another position, but we assume the client is still moving because his velocity hasn't changed; we set his position to x=3.5
tick5, we get his position as x=4 and a velocity of 0, we set his position to 4
tick6, we dont get anything, so his position remains at 4

From this, clients will see somebody move smoothly from 2 to 4 at the correct rate. It can be complicated (much more complicated than this) but that's the general idea. The hard part is deciding at each point which controller of an entities position is in control, or how much control each part gets. What you don't want is each system fighting for where an entity really is.

Read up on how fps's do movement, it's enlightening. They have more techniques than the two I mentioned.

For the most part, the actual path someone takes between A to B REALLY doesn't matter. What matters is that when they are at A or at B on the server, they are pretty close to A or B on the client.

About not sending Y, I pretty much only send values that change, but if you are using udp you should probably send all the values in case packets are dropped. And in that situation, if packets are dropped you should just ignore them and move on. And if a message arrives out of order, you treat it like a dropped packet as well. But in the case of y, if you don't have jumping forget about it. If you have jumping, you could send the jump command instead of bothering with y, unless you are going to have accurate jumping sections like a platform game.

Most of the other data you can load once and cache on the client and not really have to send much at all.

Golden rule: send as little amount of data as possible as infrequently as possible, and caching is GOOD.

Good luck!