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.)

- 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

The model you described sounds more like "client server" and it is *not* used for most RTS games. It is used for FPS, MMO, and some MOBA.

RTS games typically use lockstep deterministic state simulation. You can google that for articles an info.

http://forrestthewoods.com/synchronous-rts-engines-and-a-tale-of-desyncs/

Here is a really quick description...

Every machine (client and server) runs an identical simulation in lockstep. For each simulation timestep, all clients send unit commands to the host. Once the host receives commands from all clients for the timestep, it sends them to all clients and everyone can run a simulation tick. Those commands are high level orders, such as "group 1 attack position x". The actual unit simulation must be deterministic to cause the same outcome on all simulations. This keeps network bandwidth low even for large unit counts.

The clients checksum their game state periodically, and send the checksum to the host. If the host had a different checksum for that frame, the game has desynchronized and must be fixed or ended.

If any client doesn't ack the previous frame, the host pauses the game, to assure lockstep. Since all requests must be received to maintain lockstep, the game can use TCP or reliable UDP.

To get deterministic results requires either fixed point integer math, or very careful FPU usage.

Because the simulation runs much slower than framerate (typically 8-20hz), unit positions are interpolated between the previous frame and the current frame.

Hi.

Let the game play out on all clients like spells and shooting and movement, But don't change damage sates and things until the server

sends a valid data flag back, so the game looks like its playing but no unit dies until the sever gets back to clients.

RTS game are not like FPS games for networking movement can all be client side predicted, All the server needs to do is damage value checks and upgrades.

See a client can only cheat on his system the other clients have the cheaters remote object set by server.

We released an RTS game earlier this year that is client/server, with the server-authoritative state being updated to clients. It's not the most common approach, but it works. The biggest advantage to client/server in this case is that the architecture is applicable to just about every type of game, even if it isn't typically considered the best fit for RTS, whereas a lock-step deterministic solution really only works well for the RTS problem space, and games with similar constraints and limitations. So what you sacrifice in specificity, you make up for in being able to use the same technology across multiple projects.

But that's the mindset of a larger, multi-project studio. As an indie with only a handful of developers and starting an engine from scratch, definitely use the best approach for your immediate project. If/when you start working on more games, you can write more tech... but I'd consider that a *good* problem to have.

Slightly offtopic question:

With lock-step deterministic architicture each client needs to know everything that other clients are doing.

Would it mean that this solution is inherently prone to "all map visible" type of cheats ?

You can't cheat if server says that player a hit points don't match server rules send less hit points and punish player a, and keep game running. You can have 800 units for 8 players on a 166 MHz CPU( back in the day) and no lag.