3
\$\begingroup\$

I am programming a multiplayer game and I am concerned about the bandwidth dedicated to player movement. Imagine a 2D top down game where players can move towards any angle using the joystick. The way I do it currently is to round directional vectors to the nearest 0.25 and send a new movement packet when the vector is different. (meaning a player moves into a different direction) Rounding to nearest 0.25 provides a fairly good approximation and the position is synchronized on every new movement packet because these packets contain the new x,y of the player.

This scheme works well for keyboard controls because this directional vector changes a lot less often than with a joystick. However, when a joystick is rotated quickly, this ups the bps up to around 500 bytes per second. Imagine 100 players packed together in a map, where everyone is quickly moving around using the joystick: 500 bps per player becomes 50000 bps because it has to be sent to every other players. Multiply this by 100 for each players, and you have about 5 megabytes of just movement packets being transferred every second.

Is there any way I can do more prediction on the client and greatly reduce bandwidth?

\$\endgroup\$
2
  • \$\begingroup\$ Great article about bandwith in 2d games: joostdevblog.blogspot.no/2014/01/… \$\endgroup\$
    – Sturlen
    Nov 8 '15 at 16:40
  • \$\begingroup\$ One optimization would be by using "zones" of players - unless all of your 100 players will be in the same spot. This way you update each players in the same zone, not "globally", and players outside the zone might be updated less often and/or with less precision (eg. if you want them on minimap). \$\endgroup\$
    – madneon
    Nov 9 '15 at 18:04
3
\$\begingroup\$

Reduce the send rate of packages. I would suggest you to set a fixed rate (say, 3 times a second - actually this is a great rate of sync if you do client-side predictions correctly), rather than a rate that depends on input change rate.

But of course, this will reduce the precision of sync. So you will need to send velocity info with position too, and make extrapolation or interpolation (for a 2d top-down shooter, i would prefer interpolation) to move local representatives smoothly.

And implement an algorithm to sync data only when player moves or rotates.

I believe these two optimizations will dramatically reduce the amount of data being sent.

\$\endgroup\$
2
  • \$\begingroup\$ I'm not sure if 3 updates per second is a good idea, as for fast modern games tickrate 64 is considered "medicore" rather than "good". \$\endgroup\$
    – madneon
    Nov 9 '15 at 17:58
  • \$\begingroup\$ @madneon I don't think so, since OP is making a 2D top-down game, interpolating is even more easier and more preceise than 3D. No need for high send rates in such situation imho. \$\endgroup\$ Nov 9 '15 at 22:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .