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.
![Laughing :lol:](./images/smilies/icon_lol.gif)