Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 22 Jan 2012
Offline Last Active Jul 23 2013 03:10 AM

Posts I've Made

In Topic: Figuring out the cause of jitter

12 May 2013 - 01:39 PM

I think I'm making some progress with queueing up the updates in case they are early, and applying them at their designated time. It definitely removed the worst of the jitter. However, there's some inherent problems with this:

* Queuing up = introducing latency. Not much to do about this.

* How large queue should one allow? I've set an arbitrary number right now (3!) but I think it needs some more thought...

* What happens to packets that are too late? I think I'll try extrapolating the position in case this happens.

In Topic: Player prediction across clients, minimizing latency

19 April 2012 - 10:56 AM

Article along those lines.


Maybe contains some extra stuff that would be useful to you.

Yup, read them all. It's a good link though!

In Topic: Player prediction across clients, minimizing latency

18 April 2012 - 11:11 AM

Do you actually send three game states per packet bunched together?

No, you probably send three sets of simulation inputs, and perhaps one game state.

You don't generally want to just dump full network states across the wire at full frame rate, because of the bandwidth usage. However, by sending the inputs, you can get a very good replica of what the entity is doing, without using much bandwidth. Typically, you can get away with sending a baseline/checkpoint for an entity only once every few seconds, and do inputs for all the simulation steps in between.

To avoid burstiness, you could send the inputs for all entities for the three steps, and a state dump of one entity, per packet. Keep a queue of entities, and rotate through which one gets state-dumped per packet.

From the server, I send only the latest game state and all queued (and not yet used) inputs. I decided to fix this and yes, it did improve the responsiveness of the game.

In Topic: Player prediction across clients, minimizing latency

14 April 2012 - 02:52 AM

You have to be careful about your "frames." There may be render frames, physics frames, and network tick frames. The latency in question will be a combination of network tick frames.
For example, if you have three physics frames per network frame, then the batching of commands will add three physics frames' worth of latency.
Also, if the data for a player arrives "early" on the server, then the server has the choice to immediately forward it to the other clients, or to only forward it after it's been simulated and verified. How much latency there is from player A to player B depends on this choice as well.

Yes, one of the problem is that network ticks run slower than physic frames, which is why I have to queue up the inputs.

Good idea about forwarding inputs immediately, but I'm a bit worried over the overhead in a situation where lots of player inputs arrive spread out over different frames, this would trigger a lot of data sending. I guess I could also let clients send this kind of info directly to all other clients in the game, but that would complicate things a bit I think.

Anyhow, am I being paranoid about this thing or is it something you generally need to deal with?

In Topic: Different script solutions, performance and security

29 February 2012 - 02:51 AM

Won't it be easier to have a black-list of namespaces like System.IO - find the references and just inform user "uknown class".

U can also explore how Unity3D is doing..

Hrm, I don't trust that solution. It seems like a very fragile defense, easy to poke holes in - especially since the "hackers" would have full access to the black listing code through reflector. I'd assume Unity just trusts the scripts, or perhaps the Mono implementation allows for extra security settings that are easier to use. It seems to me a different thing having developers making scripts in Unity vs users making scripts in my game, where the former can be trusted more or less (you implicitly trust every developer you install a game from) and the latter can't be trusted at all.

Right now, I've gone with the sandboxed C# script. I realized that I only have to make a few calls to the script per frame if I keep most of the game code in the script. Even though the state data sent between the sandbox and primary domain will be large, further testing indicated that you can send several megabytes before there's any real performance impact there.