Indie-Resource.com

As some of you may know, I am currently working on a Multiplayer TD, and yet again i need some advice .

This is how the game works as of today, when a new game is created, the server initialise a master game, basicly all logic happens here, it tell clients what to visualize. But this being my first MP game, i need some advice about how to keep players in sync with the server game, my questions could be. "What to do, if a player looses contact to the server for several seconds, therefore getting out of sync" "What to do, if a player plays with a poor internet connection, and having a latency jumping from 400ms to 3000ms"

I thought of sending data to each client 4 times every seconds, containing information for all entities on the board. This data i would then compare to the client data, and overrule entities that is out of sync, there would then be a tolerate value, so the users would't experience changes on the board, because of small game delays.

However i can imagine this would be a lot of work, and i wanted to ask if there was a smarter solution, i've looked at some post around the net, but could't find any which would apply for my game, feel free to throw links my way.

That is about the only solution. To have meaningful play, they must be at least approximately in sync at least most of the time. If a player's latency begins to increase through the roof, you just do the best you can, and then disconnect them when it reaches an unworkable level (that will depend on the game type). Just be sure that latency can't actually be used as an advantage. I am not sure how your TD game is structured, but in heavily PvP MMOs, if someone's latency spikes or they get disconnected, their character is left in the world on purpose, defenseless. This is to prevent players from disconnecting or manually spiking latency to get out of a bind in-game. If your TD game is more instanced than that,with the bulk of the game occurring in game sessions, it should work fine that the DC'd player is given a little bit of time to get back on or fix their latency while the connected player can play freely before the server declares the remaining player the winner.

Jackolantern wrote:That is about the only solution. To have meaningful play, they must be at least approximately in sync at least most of the time. If a player's latency begins to increase through the roof, you just do the best you can, and then disconnect them when it reaches an unworkable level (that will depend on the game type). Just be sure that latency can't actually be used as an advantage. I am not sure how your TD game is structured, but in heavily PvP MMOs, if someone's latency spikes or they get disconnected, their character is left in the world on purpose, defenseless. This is to prevent players from disconnecting or manually spiking latency to get out of a bind in-game. If your TD game is more instanced than that,with the bulk of the game occurring in game sessions, it should work fine that the DC'd player is given a little bit of time to get back on or fix their latency while the connected player can play freely before the server declares the remaining player the winner.

Thank you for your input Jacko. I was thinking of doing position checks on Tower/Creep positions, Creep Health, Creep effects (DOT, Slow etc.), Player health/gold. So if i were to tolerate ping of max 1500ms, i would have to calculate exactly how far a creep may be, and sync if they are too far behind, syncing all creeps and towers with server information.
I guess i would have to kill all projectiles as well, as flying projectiles may hit after the sync, therefore causing inconsistent creep health. If players should have a latency of 2000+ i would cause a disconnect.

How does that sound? Also Jack, do you know if there is a way to disable, browsers javascript pause, when a user go to another tab in the browser?

Honestly, 1500ms is typically intolerable (imagine you could only react in a game after a second and a half lol). 700ms is high for most games. 100ms is the ceiling of optimal, but still should work great.

The real trick to multiplayer game programming is in predictive and interpolation algorithms. They aren't always easy, since they vary so much from one game to another. As a basic example, if a player starts heading north, all the client has to send the server is that they started going north. The client can then just start moving the character that direction. You could get fancy and also do some checking on the client so that you won't display the character walking through a wall, only to pop back to the wall when it syncs with the server. But basically the server will check if the wall is there, and the client can just happily animate the character walking that direction. Then the client sends another message that the player has stopped pressing the button to move north, and it hits the server, stopping the server character representation from moving north. The server then sends a move termination notice to the client that also includes where the player ended up at, syncing it with the client. You are basically trying to send the minimum amount of data, since syncing on each game frame isn't possible (frames go by at typically around 34ms, which isn't realistic to keep up with latency).

Its called a heartbeat in the sever client structure and is a great way to keep track of players.

Jackolantern wrote:Honestly, 1500ms is typically intolerable (imagine you could only react in a game after a second and a half lol). 700ms is high for most games. 100ms is the ceiling of optimal, but still should work great.

Alright, maybe this was setting it too high, still you won't feel that affected in a Tower Defense game, as you don't have a moving character, it might take some time to place a tower thought.

Jackolantern wrote: The real trick to multiplayer game programming is in predictive and interpolation algorithms. They aren't always easy, since they vary so much from one game to another. As a basic example, if a player starts heading north, all the client has to send the server is that they started going north. The client can then just start moving the character that direction. You could get fancy and also do some checking on the client so that you won't display the character walking through a wall, only to pop back to the wall when it syncs with the server. But basically the server will check if the wall is there, and the client can just happily animate the character walking that direction. Then the client sends another message that the player has stopped pressing the button to move north, and it hits the server, stopping the server character representation from moving north. The server then sends a move termination notice to the client that also includes where the player ended up at, syncing it with the client. You are basically trying to send the minimum amount of data, since syncing on each game frame isn't possible (frames go by at typically around 34ms, which isn't realistic to keep up with latency).

I agree, but this really don't apply i a Tower Defense game. Basicly the server tell client to spawn creeps, these creeps does the same on client, as on the server, they follow the same path.
The targeting of the towers all happens on the server, every 250ms, tower instructions are send to the clients, all shots are put in a firequeue in each tower, which then shoots with the right frequency. Also damage, effects are stated in this damage, leaving nothing for the client to calculate. I guess a problem here could be, if player plays with high latency, the shot instructions may be highly delayed, therefore a creep could already have escaped, when the shot instruction arrive. Solution here could be, not to remove a escaping creep, before the server says so.

Come to think of it, if the creep path is the same on both server and client, the shot instructions comes from the server, and server approves escaped creeps, latency might be sufficient to check on. The question is then, what to latency to tolerate, and at latency to do a rebuild (Sync)? You could make a waiting screen like in Warcraft 3, if a player get to far behind it pauses all players, you could then rebuild the laggy player's map, with data from the server. You would't even need to send sync data every 250ms, if the server just keeps track of the players latency, it could send sync data when a players gets too far behind.

Woow i just got a lot smarter by writing this post LOL.

True, if the main player interactions being synced are just selecting locations to play objects, and if then the creep spawning and movement are mostly predetermined, you probably could deal with a fairly high latency.