Hello.

Following another thread of mine that was about a reliable udp implementation I now have a question about the number of packets that are send by the client to a server in online gaming.

I'm programming a bomberman clone and currently trying to make it onlinecapable.

The gameloop runs 60 times a second with a fixed timestep ( that's called tickrate, right? because it is often confused with the games fps, which for me is refering to the rendering, which in my case is also 60 fps, since rendering and logic aren't separated. I will however separate them in the future, so rendering can be done as many times as possible, though I think anything beyond 60 won't actually have a visual effect ).

My problem now is, that since the tickrate of the game is 60, this means that 60 times a second the game is updating and answering to user input ( keyboard, mouse etc. ). Now I think sending 60 packets a second is a very huge amount and I think less will also do ( also considering it's just a cheap bomberman clone ). What I first thought was to send multiple commands in one packets, so for example 3 movement commands in 1 packets, therefore I only have to send 20 packets, but I am now thinking that maybe I can do even less, like 10 or 15 and I was also thinking that I may not even need to send multiple commands and just adjust the walking speed ( the walking speed isn't deltabased, so it's not the walking speed for 1000ms or something, it's just the number of pixels you move in one tick ), for example if I will only send 15 packets, then my walking speed now has to be fourth as much than before.

Now some questions: Is this the right understanding? How many packets are usually send in an onlinegame? I read in a tutorial by Valve that they also send multiple commands in one packet but maybe reducing the actual tickrate and therefore also sending less packets will also do just fine? Player movement will of course look less smooth when the player changes his position only for about 15 times a second, but interpolation will hopefully do the trick there.

Thanks for reading and for your time!

I havent done networking but:

-What does your walking speed have to do with the packet send rate? You should implement it so that you can send any number of packets and dont need to change walk speed etc. You could do this by either making the packets carry velocity instead of displacement, or by making the packets send the displacement since the last position sent.

-Im fairly sure that the common practise is to gather all your data to a single packet (multiple messages in a single packet) so you always send a single packet at a time. Of course there might be reasons not to eg. if you want to run something completely independent of your other networking or if there is a packet size limit or if there is some reliability benefit in sending multiple packets instead of a single one.

-The rate at which you send packets, well, im certain that the best answer is that it depends. Do whatever works. 20 packets per seconds sounds familiar, but for a simple game I dont see anything wrong with 60 packets per second, since it would be simpler to implement. Might as well make it manually adjustable to some degree if it doesnt hurt gameplay so people can adjust the default rate if it for some obscure reason doesnt work for them.

I suggest two things:

1. Make it possible to adjust the rate without having to change anything else (so the game will work at 1 packet/s or 60 packets/s)

2. Set it to whatever value gives smooth gameplay after some testing.

Now some questions: Is this the right understanding?

Yes, you are on the right track.

How many packets are usually send in an onlinegame?

It depends, but I guess 5-20. Fast paced shooters needed more per second, whereas a slower paced MMORPG could be 10 or less, depending on the general loadout of the servers.

I read in a tutorial by Valve that they also send multiple commands in one packet but maybe reducing the actual tickrate and therefore also sending less packets will also do just fine?

Yes, it is always good to maximaize the packet size. There's a mechanism , where you gather data until either a timeout occurs (X milliseconds) or the gathered information surpass a certain size (eg. the size of a udp packet). A tickrate of 15 fps would result in a timeout of ~65ms.

interpolation will hopefully do the trick there.

Interpolation and extrapolation. In general dead reckoning is used to hide latency.

If you want to extrapolate, then you can look at the Entity Position Interpolation Code library: http://www.mindcontrol.org/~hplus/epic/

When it comes to sending less than 60 packets per second, this is totally possible, if you use queued inputs. This means that, input events are queued for some tick into the future. So, when the server receives three separate input events in a single packet, those would be queued for execution in the next three ticks.

The main problem with Bomberman is to make sure that everyone agrees on what the simulation is. The easiest way to do this is to send inputs to the server, and then not actually display the update for the player until the data comes back from the server (which will then be synchronous with the data from all other players.) This will lead to some amount of control latency on the client, but this is often acceptable, and the gain in robustness and "no special cases" is significant.

My problem with a packet containing multiple commands was, that it was waiting for 3 commands and then send the packets, the problem was that a player may not move for some time and the last actions weren't sent because the client was still waiting for another command to reach 3. A solution to that would of course be to always send packets, even if they aren't filled up to the fullest or definitely send the packet after a certain amount of time, like 65milliseconds.

Thanks for your answers!

Yes, it is very common that packets are sent on a fixed schedule, with whatever data accumulated since last time.

My problem now is, that since the tickrate of the game is 60, this means that 60 times a second the game is updating and answering to user input ( keyboard, mouse etc. ). Now I think sending 60 packets a second is a very huge amount and I think less will also do ( also considering it's just a cheap bomberman clone ). What I first thought was to send multiple commands in one packets, so for example 3 movement commands in 1 packets, therefore I only have to send 20 packets, but I am now thinking that maybe I can do even less, like 10 or 15 and I was also thinking that I may not even need to send multiple commands and just adjust the walking speed ( the walking speed isn't deltabased, so it's not the walking speed for 1000ms or something, it's just the number of pixels you move in one tick ), for example if I will only send 15 packets, then my walking speed now has to be fourth as much than before.

Now some questions: Is this the right understanding? How many packets are usually send in an onlinegame? I read in a tutorial by Valve that they also send multiple commands in one packet but maybe reducing the actual tickrate and therefore also sending less packets will also do just fine? Player movement will of course look less smooth when the player changes his position only for about 15 times a second, but interpolation will hopefully do the trick there.

Thanks for reading and for your time!

Client Bits:

The client in a network game only ever sends requests. You should make sure that's all your thinking about when doing client code.

I'm a client, I can't send ANY commands, but can send requests whenever I want!

So, I press the "D" button... I request to move right, (So send a PlayerRequestRightPacket )

The server receives it, updates it's physics system and then get's on doing other server stuff. (Perhaps the player is near a wall? It can't move any further, the server knows this and when it send's it updates back it, the player hasn't walked through the wall, he's just stood there next to it.)

So, I let the "D" button go... I request to stop moving right (So send PlayerRequestStopMovingRightPacket )

For all of these requests there is perhaps 50ms-200ms I have to wait before I start seeing updates. If this is fine, we stick with it.* (Humans find anything under around 100ms to be 'responsive')

Or else we could run physics on the client, interpolating the results, constantly updating our values from those sent from the server.

I suspect you won't even need to do this for a plat-former.

*this is not just an excerice of network programming, it's about hiding this lack of knowledge (which will always exists, you cannot eliminate it, just hide it!). You could have the player start an animation before walking, a little dust cloud around his feet? Anything so that it doesn't look none responsive.

Server Bits:

First thing, make sure the server sends updated velocity figures that you can feed into the game client.

You should be running the same physics loop on the client and the server, but the important thing is to ignore your values whenever the server sends it's update figures. (This may have to be done retrospectivly, i.e. go back 100ms, quickly run physics again up to now, then lerp the position over another 20/40 ms.)

Either way, infomation may take 50-200 ms per round trip, you just need to hide that from the player.

Another thing we do, is slow/increase the update packets sent out depending on the activity. If people are playing a fast paced mini-game, we thrust it up, if everyone is sat around doing nothing or we have 30/40 players in a small area etc.. , we slow it down.