Client network throttling

[cha55son]

Need to throttle certain messages to the server like mouse movement, etc.

[dylan]

Kind of relevant, this is considered required reading for multiplayer games: http://gafferongames.com/game-physics/networked-physics/

It pretty much goes over the idea of determinism/dead reckoning, making the clients feel super responsive, sending relevant info to the server, and updating/correcting the clients when the server broadcasts new info.

[dylan]

Another thing I'm noticing crawling through the plugin, I wouldn't send mousemove. I'm assuming that you're doing it because you want to move turrets in your tank game, however considering how many events mousemove can fire you will choke things out in short order.

If this is your use case I'd just watch the mouse on the client and when the mouse pauses for sufficient time (.5s?) I'd make a target entity at the mouse location, send it to the server, and have the turret point to that entity.

[cha55son]

Good point,

In my game I have implemented a throttle for any "quick firing" events on the client such as mouse move and screen move. I haven't migrated that over yet but i'll be sure to do that sometime soon.

My use case is I have multiple players driving tanks around a map and it's important that other players be able to see where there enemies are facing, but not important enough to send every event only one every 100ms or so.

[dylan]

Yeah, If you write the client entities so that the turrets point at the correct target entities, and then move the target entities around you should have a highly accurate/correct view of where everyone's guns are pointing without the hefty bandwidth requirement.

[dylan]

You'd also keep the impact-crater codebase to a highly general framework which would be nice. :smile:

[cha55son]

Hm, that's a tricky one. I don't think the client should be allowed to tell the server to spawn an entity. That would create a number of security issues. I'm thinking of the client as just a "controller" that way the server can't be "hacked" by spawning entities, changing it's position, etc.

With the mouse/screen throttling there will be at most 10 socket.io per second, and the server entities can still react accordingly. This would be consistent with the impactjs development paradigm.

[dylan]

Well even if it's not actually using an entity, if you make it general enough, you can essentially just pass a 'target' event with coords. Rather than hammering on or artificially limiting an event that has no business on the network. :P In say, WOW or other clients, the mouse movements never factor into the equation, rather the results are (clicks, focus events, etc.) Make sense?

Another way to handle this (and maybe the most correct way) may be to let the project using impact-crater pass event bindings to the plugin at setup and instead of just baking them into the architecture?

[cha55son]

Agreed, to be fair i'm biased since my game needs mouse movement. Although, it would be easier for someone to get started if it was baked in. Then give them the ability to turn it off and use their own method once they are used to the plugin.