Since I could not really find my answer on Googles, I'll try asking here.
Right now I am working on a multiplayer game. So far all of my testing is done either on localhost, or LAN, so bandwidth is not a matter right now - but it is something I am worrying about.
As of this moment, the player sends information about input change - be it a keystroke, or mouse movement (yep, the game's a shooter), limited to 100 packets/second. The server then broadcasts this change to all players. Simple and nice, but given 16 players sending 100 p/s, with a 64-byte packet, that gives 100KiB of information sent per second.
I was wondering about a different way to do it. My thought was to use a request - response behaviour, that is, the client sends an information request to the server - server answers it - client receives the response and instantly launches another request. However, this approach has one great weakness - the request packet may get lost in the vast jungle of the internets. So, to counter this - what about the client resending the request if, say, 3x average ping has passed with no response?
Bookmarks