[smegma2]

Hi Gluten, I never wrote a real-time game, so I'm curious about a lot of things.

* Does the server have a tick rate and it updates clients at a set interval, or does it only update when things happen?

* Did you ever run into any issues getting enough throughput from the server? e.g. maybe too many events happening at once to update everyone?

* Do you have to manage situations where two clients have a different view of the game state (due to extra latency for example)? If so, how do you resolve it? For example, I know that Team Fortress 2 follows the rule for guns that "if the shooter thinks it hit, then it hit", which means that people get shot around corners sometimes.

I'm working on a turn-based game using websockets which has been hard enough, a real-time game seems much harder to make! Thanks for sharing!

[mizzao]

It's probably a completely different architecture, see the classic article "1500 archers on a 28.8":

https://www.gamedeveloper.com/programming/1500-archers-on-a-...

[smegma2]

This is interesting, thanks! So sounds like there is too much data to send the entire game state every time.

[rnd420_69]

In 2022 the bandwidth requirement is actually easily doable with some compression of the sent data. But an architecture that uses prediction (cool kids seem to call this 'rollback networking' nowadays) has other benefits, like zero latency for player input.

[mizzao]

For folks who are reading, the "simultaneous simulation" architecture used in almost all RTS games is still a very different beast than the "rollback networking" architecture used in some FPS (and fighting) games referred to by the above post.

[Gluten]

The server runs at ~100 FPS, but things like worker updates and attacks happen at a 1.5 second interval. Only the changes (like walking a step, collecting a resource) are sent to the client(s). There is no client side prediction. There is no specific aiming on targets like in FPS games, just need the opponent id, so don't really need to do that Team Fortress thing.