Advertisement

What data to send for player positions

Started by July 14, 2017 11:05 PM
1 comment, last by hplus0603 7 years, 4 months ago

Hello

I am learning networking at the moment and just in the middle of sending client positions to the server every x amount of milliseconds. But this is a fair bit of bytes to send quite a lot.

So i wondered about sending just keyboard and mouse inputs to the server instead of the position updates, since this would be a lot less bytes. Yet it seems most games don't use this method, they tend to send position updates instead. I am curious what pros and cons there are between these 2 options? I feel like i might be over looking something here because sending the keyboard and mouse inputs seem to be at first glance a simpler approach and less bandwidth too. 

The game is an FPS so it needs to be real time aswell.

 

So is there some issue with just sending keyboard/mouse inputs rather than positions that i am not fully grasping due to lack of experience with this?

Sending position updates from the client means that the client can cheat, and send a position that's further away than it should be, and thus make the client run faster.

The generally accepted solution is to send inputs (logical inputs: movement speed and turning speed, not explicit keyboard events) to the server, and the server then sends position to each of the clients when it sends snapshot updates of the entity states.

Separately, typical send rates for games are 15-60 times a second. A typical update packet might be 10-20 bytes. Add 28 bytes for IP/UDP overhead, and you still end up with at most 48*60 bytes per second sent to the server, which even a dial-up modem can deal with, so when you say "a lot of data," what measurements have you actually been taking?

 

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement