Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Player movement.  (Read 4131 times)
0 Members and 1 Guest are viewing this topic.
Offline Renoria

Junior Member




...


« Posted 2008-12-22 08: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?
Offline sunsett

Senior Member




ribbit!


« Reply #1 - Posted 2008-12-22 14: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.
Offline Renoria

Junior Member




...


« Reply #2 - Posted 2008-12-23 09: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!
Legends of Yore - The Casual Retro Roguelike
Offline hejfelix

Junior Member


Projects: 1



« Reply #3 - Posted 2008-12-23 12: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
Offline Renoria

Junior Member




...


« Reply #4 - Posted 2008-12-24 00:09:32 »

Actually, your wrong. 1 KB = 1024 bytes.
Offline sunsett

Senior Member




ribbit!


« Reply #5 - Posted 2008-12-24 04:20:33 »

Actually, your wrong. 1 KB = 1024 bytes.

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

Junior Member




...


« Reply #6 - Posted 2008-12-24 06:47:50 »

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

okay okay, 24 bytes don't matter =/ but when it adds up, your bill gets $10 bigger...
Online Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2008-12-24 08: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
Offline Renoria

Junior Member




...


« Reply #8 - Posted 2008-12-24 08: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.
Offline sunsett

Senior Member




ribbit!


« Reply #9 - Posted 2008-12-25 03:43:38 »

I was referring to the hard drive companies that report drive space where they register in 1,000s instead of 1,024s. Shocked
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline h3ckboy
« Reply #10 - Posted 2009-01-26 17:49:47 »

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

Junior Member


Projects: 1



« Reply #11 - Posted 2009-01-26 18: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
Offline EgonOlsen
« Reply #12 - Posted 2009-01-31 21:23:59 »

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

Offline Renoria

Junior Member




...


« Reply #13 - Posted 2009-02-03 12: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..
Offline Roquen
« Reply #14 - Posted 2009-02-03 14: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. 
Offline sunsett

Senior Member




ribbit!


« Reply #15 - Posted 2009-02-04 15: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:

Quote
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.
Offline Roquen
« Reply #16 - Posted 2009-02-04 16: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.
Offline bison

Senior Newbie





« Reply #17 - Posted 2009-03-23 15: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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (50 views)
2014-04-15 18:08:23

BurntPizza (46 views)
2014-04-15 03:46:01

UprightPath (62 views)
2014-04-14 17:39:50

UprightPath (44 views)
2014-04-14 17:35:47

Porlus (61 views)
2014-04-14 15:48:38

tom_mai78101 (85 views)
2014-04-10 04:04:31

BurntPizza (143 views)
2014-04-08 23:06:04

tom_mai78101 (242 views)
2014-04-05 13:34:39

trollwarrior1 (201 views)
2014-04-04 12:06:45

CJLetsGame (208 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!