0
\$\begingroup\$

Considered a typical lockstep implementation, what's a solid rate to send packets at for UDP protocol that games can start with in the beginning?

If anyone has experience in this field, I'd like to know the general optimal packet sends per second for a lockstep RTS game.

\$\endgroup\$
1
\$\begingroup\$

This is rather broad and vague question.

Lockstep requires at least one command sent per tick to indicate there is no actions happened. Also you need to send a packet to verify to other clients that the client has received their packets.

Each step every player needs to send his commands (wrapped into one packet for simplicity) and confirmations of receiving other players commands to each client. Without optimizations, general approach formula can start at:

((Commands_per_step * Player_count) + (Confirmations_per_step * Player_count)) * Steps_per_second

2 * N * Player_count * Steps_per_second

For 8p game at 10 ticks a second that is around 160 packets per client per second. Not including utility packets like ping or text, they can be bundled with commands.

Is 160 too much ? For the number in you exact circumstances, you best off at writing a test app that spews packets and measure how much is too much. Ask your friends around the world to test it and collect the stats.

However there is a place for optimizations. In best case, you can optimize by bundling everything client needs to send into 1 packet (per step or even more rare), sent to the game server and making it replicate and spew packets to all clients as needed. That will increase lag slightly, but save you packet count.

\$\endgroup\$
5
  • \$\begingroup\$ My original idea was to use the Actions_per_second rate but thought this would create quite a bit of command lag (waiting for 2x rates for ping confirmations to arrive). I think I'll end up wrapping a packet for every single step. Thanks for the ideas. I'll try to post some empirical data after the tests are conducted. \$\endgroup\$ – JPtheK9 Feb 2 '15 at 6:10
  • \$\begingroup\$ Plz read the addition, it slipped my mind, but it's important. \$\endgroup\$ – Kromster Feb 2 '15 at 6:15
  • \$\begingroup\$ I use a different system where clients only communicate with servers for confirmations and command initialization. Also, I never saw the need in sending the unnecessary empty packets. I just contain a small byte about the frame to run inside every command wrapper. \$\endgroup\$ – JPtheK9 Feb 2 '15 at 6:29
  • \$\begingroup\$ Empty packets are needed to handle ping spikes and out-of-order packets arrival. If you don't send empty packet, server might decide the tick had no actions and move on to the next one. When the packet finally arrives late it's impossible to restore the game state. \$\endgroup\$ – Kromster Feb 2 '15 at 6:35
  • \$\begingroup\$ I send a periodic 'ping' packet every second to make sure the clients and server are never more than X (the latency delay) steps apart. It took a bit more work coding, but it reduces the bandwidth by a lot. Syncing everyone back up is just a matter of a synchronized start for everyone on the next ping packet. \$\endgroup\$ – JPtheK9 Feb 2 '15 at 6:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.