Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


gfxgangsta

Member Since 06 Dec 2011
Online Last Active Today, 02:52 PM

Posts I've Made

In Topic: Planetary Annihilation networking

09 December 2014 - 04:24 PM


The situation where t=0.67 when the latest receipt from the server is t=0.5 shouldn't happen in the general case. The client will try to keep itself at the server time + the average latency + a bit extra. Most of the time you're playing you will be interpolating toward the latest receipt from the server. Occasionally with a network hiccup you might accidentally catchup and overtake, I don't know what they do in that case. Probably they allow a little bit of running ahead with extrapolation, but if you end up too far ahead the time on the client probably slows then stops so you're not seeing too much made up stuff.
 
This also answers questions 4, 5, and 6, I think.

 

Thanks for shedding some light into this. I guess that makes sense... if the client gets too far ahead of the server values, that's when you could start seeing strange behavior or harsh corrections.

 

For question 4, then I guess stopping could happen naturally when you've reached the endpoint of your curve (or the "not too far ahead" point).


In Topic: Game server frame rate

29 October 2014 - 04:00 PM

hplus0603, thanks for that first detailed reply. It helps me a ton.

 

At some point, I won't be able to bring down my "upper limit" anymore. So, assuming a frame rate value that works without tunneling (i.e. 30Hz)... there will come a time when my server won't be able to handle more clients because I won't be able to guarantee each frame takes 1/30s. That's when I would need to add servers, correct?


In Topic: Game server frame rate

29 October 2014 - 10:33 AM

The game is very simple at this stage (and will probably remain simple). The player clicks to go somewhere, so it's given a velocity, and the simulation step on the server computes their position at the current time. Then, 10 or 20 times per second, the server sends the client its new position, and the position of other clients. The client can do prediction by checking the last few positions to compute a velocity estimate, or by using the last received velocity value(s) (if sent).

 

So, assuming that the server ticks as fast as it can (with an upper limit)... I can make that upper limit as low as possible (as long as I'm not "seeing" tunneling or other artifacts on the server, it should be fine), right?

 

Because clients will tick as fast as they can (and therefore, process packets at different times), they will see different things. But if the difference in latency between the different clients is not too far off, then it shouldn't be a big deal (depending on the game), right?


In Topic: Difference between bandwidth measurements

10 December 2013 - 05:08 PM


possibly, 3g/4g can have fairly insane latency and packet loss though.

 

Agreed, so that's what I think I'm seeing... 1 to 1.5 seconds of round-trip latency on every request. If the browser is using a cached copy, I would expect to see much lower latency (0ms pretty much).


In Topic: Difference between bandwidth measurements

10 December 2013 - 01:22 PM

Thanks for your reply. I had turned off the phone's wifi when doing the tests (unless the iPhone overrides this when a known connection is available). I'll try the datetime variable in the URL, however, I would think the round-trip time (as measured in javascript) would be much lower if the browser cached the requests.


PARTNERS