Player movement.

[Renoria]

Right now I send a player move packet ever 130 MS, but that lags the server like hell, how could I send them less frequently, but still keep the synchronization between clients?

[sunsett]

a message every 130 ms lagging your server means one of a few things:

• Your messages are WAY too big
• Your server is crap
• Your bandwidth is crap
• Your networking code is crap

Games very often send messages much more frequently that every 130ms and on a larger scale.

[Renoria]

a message every 130 ms lagging your server means one of a few things:

• Your messages are WAY too big
• Your server is crap
• Your bandwidth is crap
• Your networking code is crap

Games very often send messages much more frequently that every 130ms and on a larger scale.

Well, all I write is

writeInt(x)
writeInt(y)
writeByte(frame)
writeByte(direction)
writeByte(stance)

That is 4 + 4 + 1 + 1 + 1 bytes = 11 bytes per MS. This is for a monster, so 100 monsters in a map means 1100 bytes per 130 MS. Some GMs on my server spawn about 1000 monsters. Is that why it lags so much? 1000 * 11 = 11000 bytes per 130MS! =/

Games published by our own members! Check 'em out!

[hejfelix]

Well, all I write is

writeInt(x)
writeInt(y)
writeByte(frame)
writeByte(direction)
writeByte(stance)

That is 4 + 4 + 1 + 1 + 1 bytes = 11 bytes per MS. This is for a monster, so 100 monsters in a map means 1100 bytes per 130 MS. Some GMs on my server spawn about 1000 monsters. Is that why it lags so much? 1000 * 11 = 11000 bytes per 130MS! =/

11000 bytes = 11kb
every 130 ms, that means
1000/130 = 8 (rounded up) times sending the data.
so you are sending 8*11kb = 88 kb/sec, is your upload this big?

If I were you I would do a benchmark on your server. Try sending a normal data-package and time it. Do a kind of "ping" test with your standard package to see how much your server would actually support!

[Renoria]

Actually, your wrong. 1 KB = 1024 bytes.

[sunsett]

Actually, your wrong. 1 KB = 1024 bytes.

Well, that really depends these days who's counting. 

[Renoria]

Well, that really depends these days who's counting. 

okay okay, 24 bytes don't matter =/ but when it adds up, your bill gets $10 bigger...

[Riven]

Way to derail your own thread!

Anyway, you will only get 2.4% higher, so you'll oinly be paying $10 extra if you'd be paying over $400 in the first place.

[Renoria]

Way to derail your own thread!

Anyway, you will only get 2.4% higher, so you'll oinly be paying $10 extra if you'd be paying over $400 in the first place.

I think 2.4% is a lot, especially for companies like Blizzard and Jagex.

[sunsett]

I was referring to the hard drive companies that report drive space where they register in 1,000s instead of 1,024s.

Games published by our own members! Check 'em out!

[h3ckboy]

yeah sunsett an mp3 may say 2 GB you actually get 1.8 GB lol:/

[donmc]

2 other things to look at:
are you sending these tcp or udp and are you sending 1 large packet or many small packets?  If you are using tcp then part of the "lag" might be retransmission of packets.  Remember also that each packet includes overhead.  You might only be sending 11 bytes per mobile, but the packet headers is much larger than that!  If you are sending many small packets a bulk of your bandwidth is being eaten by the headers alone.  I guess we could use some more info about your specific situation.

~don

[EgonOlsen]

And don't forget a conn.setTcpNoDelay(true); on your connection.

[Renoria]

hmm, is it possible to send a list of the last movements in the last seconds, then write it to the other client and then the client can somehow interpolate/calculate the x/y of the other character? If that's possible, then I'd send a packet every second that has 10 frames in it..

[Roquen]

This is sometimes called "Dead reckoning".  The client updates entities based on previous info and the server calculates actual and the estimated and only sends an update packet when the difference between the two is beyond some threshold. 

[sunsett]

This is sometimes called "Dead reckoning".  The client updates entities based on previous info and the server calculates actual and the estimated and only sends an update packet when the difference between the two is beyond some threshold. 

That's not really an accurate statement. Dead-reckoning is the adjustment made between positional synchronization based on direction and velocity to keep a continuous flow. This follows Newton's First Law:

Every body perseveres in its state of being at rest or of moving uniformly straight forward, except insofar as it is compelled to change its state by force impressed.

An object continues to move at the same rate of motion until told otherwise by the networking code.  You can see this in action in games like Battlefield 2 if you ever see major lag and see tanks sliding by you at the same speed they were going when the connection issues began.  Sending a list of movements seems a ridiculous thing when just sending the most up-to-date positional information should be all that's required, right?  This is a reason UDP is often used in synchronization since you have a potential to lose packets, but it doesn't really matter because the next packet that picks up puts you back on track so the previous messages can be discarded.  As opposed to TCP, which after a period of lag, you'll potentially get a massive flow of messages coming through that then cause additional lag in your game while it tries to catch up with all of the messages that are now out of date.

[Roquen]

Yeap, it is a misnomer. That's why I said "sometimes called", since it was the common term at some point..not sure if that is still the case.  And I should have mentioned that there's no need to send any list, each packet contains full info and is slightly bigger for params needed for the prediction. And you also need a smoothing routine on the client for when you're off for lost packets.

It's more of a pain than always sending full info, but can (YMMV) really lower the network traffic (shrug).

Simpler option is write your batched packets in some variable length coding (or just pack the bit).  Also toss any unneeded low bits.

[bison]

if your client can't see the whole map at once, you should try and implement a sphere of influence system (or circle for 2D). Only send updates for the monsters within the clients sphere of influence.
If you're not already doing so you should also apply some sort of delta compression. If there are 10 monsters within a clients sphere of influence, but 5 of them are standing still, you only
need to send updates for the 5 which are moving.