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!

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!

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.