Approaching syncing between client and server, in a Tower Defense game

Question

I am currently working on a Multiplayer TD, players can join games, and place towers on a map, so far so good.

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.

Answer 1

My suggestions are:

You are using the web, so you have to use TCP (websockets, I assume?). Therefore you do not need to worry about retransmission, TCP does this for you (this will probably create a bit of lag, then catch up though).

Run the game in ticks with a fixed and fairly low timestep (e.g. 200ms). The client can interpolate if you need smoother animation.

Each tick the server sends an "update everything" to all connected clients. A client sends any commands that the user may have made on the user interface, but DOES NOT ACT ON THEM LOCALLY!

If the client gets disconnected from the server, it can reconnect and tell the server the number of the last frame it's processed, to "continue from X". The server needs to keep some history of frames sent so that a client can "catch up".

If a client gets too far behind, it needs to resynchronise - reload the game world (this also happens initially). The server needs to keep timestamped old copies of the game world around for this purpose, or generate one on-the-fly. Each serialised copy of the game world needs to have a timestamp so that the client can "catch up" after download from the correct point in time.

This is broadly similar to the "1000 archers" technique (from Age of Empires and others)