Lag compensation and client side prediction

[robaldred]

The problem i'm experiencing is that the player initiates and action, but the users input doesn't do anything until it has been actioned by the server, and the server for example moves an entity. The delay could be as much as a few hundred milliseconds especially on a lossy mobile connection.

Making my game feel a bit unresponsive to the player.
Do you have any suggestion of how to improve this, maybe with some sort of client side wizardry?

I've been reading about lag compensation here
https://developer.valvesoftware.com/wik ... Networking

Seems like the solution but complicated i'm sure.

Thanks

[hallsofvallhalla]

Hmm the article seems to explain more on how to fix lag on detection and position more than actual response to inputs which isn't much help. I wonder if you could have the client initiate the player then the server syncs it on its return?

[robaldred]

Yeh, in that article under "Input prediction" it explains basically I have to run the simulation both client-side and server-side.
Therefore the client can react to user input realtime by running the simulation itself then correcting based on information received from the server later.

[hallsofvallhalla]

Ah i missed that part

[coolbloke1324]

Basically there is no easy solution to this. If you are not able to rely on fast connections you will obviously suffer a lag on the control system if you are doing a simulation server-side because as you say, the control command up to the server may have a large lag time.

Actually though, even at 200ms latency it is almost unnoticable. You need to go past 200 to start noticing a lag for most players.

Have you tried to tweak the stream interval and send latency settings?

If your players are on a mobile signal you are not going to get good latency anyway, and no amount of engine trickery can solve this which is why you don't see any realtime multiplayer games on mobile where the games rely on low latency to be playable.

All of that said, you *could* do client-side movement prediction based on the user's input but it would be more complex if you have box2d running and you also then use considerably more CPU and memory to do the physics sim on the client device as well.

Its kinda difficult to advise further without knowing the game mechanics you are looking to provide the players with.

[robaldred]

Thanks for your reply. I hear what you're saying.
Mobile is not a huge requirement, I guess a nice to have.

I'm currently working on a couple of games, with the lag in mind, I'm thinking specifically about a 2d/isometric racing game.
Similar to MicroMachines

A multiplayer example I quite like is Reckless Racing, It has realtime multiplayer, and plays brilliant over a 3G connection. I don't know much about how it works but I know it's built on Polarbit's Fuse platform which is native (and im sure they have large budgets) but I was hoping I could achieve something with reasonable playability.

What render latency / send frequency settings would you recommend?

Thanks for your time.

[coolbloke1324]

If you are targeting a purely 3g platform then I have no idea what to set the values to, it will be a trial and error process I think, but on normal broadband you can get good performance in twitch-based games by going with lower render latency (the delay in ms that is used when rendering the simulation to the screen) such as a value between 50 and 100 ms. Basically, take the longest ms that you expect a packet to take from client to server and then double it. Usually on good connections clients will have anything between 10 and 50 ms. Bad connections will have ~100ms or higher.

Stream interval (the number of ms between stream updates) can be tweaked as well and the higher the value the less your client connections are saturated but the less accurate the overall client-side simulation will become. This is dependent on how much is going on during the sim but if we assume a micromachines style game then 4 players? You can set this value quite low and get away with it. 4 players generate about 22 bytes of data each per update packet (assuming only translation changes) so around 88 bytes per update total. You can calculate the total bandwidth per second required to handle 4 players based on the number of bytes and updates you are sending each second to work out saturation levels.