RTS Server architecture

Jon Though · 2015-06-03T20:04:46

Hello there! I've been doing a lot of reading on the topic of multiplayer-servers, specifically on servers for RTS-like games. The basic idea as far as I can tell is: - The server runs the game and does all processing - The clients send the userinput, e.g Player X wants to cast spell Y - The server validates that request, and then broadcasts to all clients "Player X is casting Spell Y" - The clients run a copy of the gamelogic, and then handle what happens (create a new Spell(), move it over time, deal damage when it hits) - The server has the authority over the clients, validating their state of the world from time to time and sending corrections The problems that I can see with this are: - UDP packets are not reliable, therefore each packet has to be send until an acknowledgement arrives. This means even when a packet gets through first try, it'll still be send a few times due to latency. Not exactly optimal, and after using wireshark on some popular RTS games, I figured that this is not what they are doing. - Every player is always behind the "true state" of the world by his latency. The only way to work around this is by predicting what is going to happen. This is only viable in 1st or 3rd person games like an FPS or an RPG, and it is only done for the users input, not for the rest of the game. (When a client recives "player X starts moving to X,Y", it is supposed to handle that movement on its own. But since it got that command for example 100ms late, player X is always 100ms behind where he actually is at the moment ... But then again, if you resend the "correct" information, the player already has traveled 100ms further. So you again had to do predicting, which you want to avoid in an RTS scenario.) This is, however, acceptable for an RTS. - But how would it be possible for the server to validate any current state of a client, since every client is behind the server by its latency anyway, and by the time the "to-validate" data arrives, its already old. Also, latencys change constantly. - Also it feels like if a player has "lagspikes" (his latency going up and down again suddenly), there would be huge problems. Since you can't wait for packets, you might have to process them in the wrong order. With little delay not that big of a deal, but when a packet suddenly gets stuck and arrives 500ms late while the rest got through, everything would get messed up really fast. And to get everything back in order you'd, again, need some kind of validation. I can't send a snapshot of everything on screen 64 times a second like FPS games can, since there is way to much going on. I'm clueless what to do here, any piece of advice or thought is highly apprechiated. Thank you for your time and have a nice day! -gnomgrol

Networking and Multiplayer Programming

Started by gnmgrl May 30, 2015 11:38 PM

9 comments, last by jeskeca 9 years, 5 months ago

jeskeca

676

June 03, 2015 08:04 PM

Yes, "map hacks" which reveal the whole map are a problem with lockstep deterministic simulation.

Also, while tehnically you don't need a dedicated server, there is a host, and it is easier to have a dedicated server than solve host DDoS hack based cheating.

Grey Goo is another RTS using client/server instead of LDSS. It has notable lag, especially in 2v2, and no 3v3 or 4v4 modes. It is important to remember that even if datacenters and links are fatter, consuming 10-100x more bandwidth can easily increase latency.. Especially when players are spread around the globe.

IMO LDSS is still the way to go for RTS.

RTS Server architecture

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

RTS Server architecture

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines