Renoria
|
 |
«
Posted
2008-12-22 07:46:37 » |
|
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
|
 |
«
Reply #1 - Posted
2008-12-22 13:33:39 » |
|
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
|
 |
«
Reply #2 - Posted
2008-12-23 08:49:42 » |
|
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
|
 |
«
Reply #3 - Posted
2008-12-23 11:52:47 » |
|
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!
|
<i8b4uUnderground> d-_-b <BonyNoMore> how u make that inverted b? <BonyNoMore> wait <BonyNoMore> never mind
|
|
|
Renoria
|
 |
«
Reply #4 - Posted
2008-12-23 23:09:32 » |
|
Actually, your wrong. 1 KB = 1024 bytes.
|
|
|
|
sunsett
|
 |
«
Reply #5 - Posted
2008-12-24 03:20:33 » |
|
Actually, your wrong. 1 KB = 1024 bytes.
Well, that really depends these days who's counting. 
|
|
|
|
Renoria
|
 |
«
Reply #6 - Posted
2008-12-24 05:47:50 » |
|
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
|
 |
«
Reply #7 - Posted
2008-12-24 07:02:06 » |
|
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.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
Renoria
|
 |
«
Reply #8 - Posted
2008-12-24 07:06:12 » |
|
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
|
 |
«
Reply #9 - Posted
2008-12-25 02:43:38 » |
|
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
|
 |
«
Reply #10 - Posted
2009-01-26 16:49:47 » |
|
yeah sunsett an mp3 may say 2 GB you actually get 1.8 GB lol:/
|
|
|
|
donmc
|
 |
«
Reply #11 - Posted
2009-01-26 17:14:07 » |
|
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
|
 |
«
Reply #12 - Posted
2009-01-31 20:23:59 » |
|
And don't forget a conn.setTcpNoDelay(true); on your connection.
|
|
|
|
Renoria
|
 |
«
Reply #13 - Posted
2009-02-03 11:31:22 » |
|
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
|
 |
«
Reply #14 - Posted
2009-02-03 13:47:25 » |
|
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
|
 |
«
Reply #15 - Posted
2009-02-04 14:03:03 » |
|
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
|
 |
«
Reply #16 - Posted
2009-02-04 15:34:10 » |
|
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
Senior Newbie 
|
 |
«
Reply #17 - Posted
2009-03-23 14:37:19 » |
|
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.
|
|
|
|
|