Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client network throttling #2

Open
cha55son opened this issue Nov 16, 2013 · 8 comments
Open

Client network throttling #2

cha55son opened this issue Nov 16, 2013 · 8 comments

Comments

@cha55son
Copy link
Member

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

@dylan
Copy link
Contributor

dylan commented Nov 30, 2013

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
Copy link
Contributor

dylan commented Dec 1, 2013

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
Copy link
Member Author

cha55son commented Dec 1, 2013

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
Copy link
Contributor

dylan commented Dec 1, 2013

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
Copy link
Contributor

dylan commented Dec 1, 2013

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

@cha55son
Copy link
Member Author

cha55son commented Dec 1, 2013

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
Copy link
Contributor

dylan commented Dec 1, 2013

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
Copy link
Member Author

cha55son commented Dec 1, 2013

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.

@dylan dylan mentioned this issue Dec 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants