Different Clients sending packets faster than others - resulting in faster client speed

[turbodonkey]

First time I've posted an issue in github, so I'm probably doing it all wrong. I've noticed that running the client on my Windows machine, is always resulting in a client that moves faster than on my Mac. Both devices have similar lag (between 1 and 5ms) however my Windows machine gets around double the FPS than the Mac. I dont think FPS is the issue as you dont calculate FPS in any physics code.

So I went looking and the only thing I can really tell at this stage is that the amount of input (and thus input rate) coming from the Windows PC is about double (402 vs 258) that of the Mac client for a given set time. My counter was in game_core.prototype.process_input = function( player ) and was measuring the frequency of each individual client update.

And because the code doesn't have input rate limiting, those clients effectively end up with a faster moving client, as its all based on input rate to trigger the physics world updates in the Server loop.

I suspect this is less of a problem over real life scenarios that have at least a lag of 10-50ms, but even for a simple LAN game, there is unfair advantage here in the code.

I have ideas how to fix this, but I'm going to struggle anytime soon.

I'd also like to support a variable amount of clients (say max 32) per game, so I'd like to attempt to author the code to support this. But again, javascript is very new to me :(

[turbodonkey]

a little more on this... I can see the whole physics loop is based on the assumption that it will fire every 15ms. After debugging on my Mac (the slower of the machines) I can confirm the _pdt of the client game_core class is hovering into 0.16 and 0.17, where as my Windows machine client is a very steady and stable 0.15 never going into 0.16 and 0.17 times between updates.

So essentially the client on the Mac is running slower than assumed and send less updates, it would be good if we can compensate for this somehow, I can see in game_core.prototype.physics_movement_vector_from_direction we simply assume a 0.015 delta, so I'll try and use _pdt here and see what happens...

[turbodonkey]

ok finally fixed it but dunno how to put back into your code. basically your client input function is under the video rendering timer. which pegs the input rate to that of fps rate of client. not the best way.

i simply put the client input function under the physics timer, which is fixed, and hence, a faster fps machine does not generate more input events than a slower fps machine.

the fix was to basically take this.client_handle_input(); and remove it from game_core.prototype.client_update (which is FPS bound) and put it in game_core.prototype.client_update_physics (which is statically fired with setInterval callback timer).

[ruby0x1]

An interesting find, I will have a look at the code again (it has been a while) for why I might have done it that way. Might be related to input being immediate etc.

Thanks for exploring.

[turbodonkey]

Legend Sven, any tips as to how I should go about making it support a variable amount of clients?

On 16 May 2014, at 5:55 pm, Sven Bergström [email protected] wrote:

An interesting find, I will have a look at the code again (it has been a while) for why I might have done it that way. Might be related to input being immediate etc.

Thanks for exploring.

—
Reply to this email directly or view it on GitHub.

[dr3adx]

An interesting find, I will have a look at the code again (it has been a while) for why I might have done it that way. Might be related to input being immediate etc.

Thanks for exploring.

ok finally fixed it but dunno how to put back into your code. basically your client input function is under the video rendering timer. which pegs the input rate to that of fps rate of client. not the best way.

i simply put the client input function under the physics timer, which is fixed, and hence, a faster fps machine does not generate more input events than a slower fps machine.

the fix was to basically take this.client_handle_input(); and remove it from game_core.prototype.client_update (which is FPS bound) and put it in game_core.prototype.client_update_physics (which is statically fired with setInterval callback timer).

also i think anyone can speed hack right now by just changing FPS on client side, as far as I can see theres no built in protection on server concerning how many inputs can be processed per player basis?

pls correct me if i'm wrong underscorediscovery

also what would u do to prevent this speed hack?