4 ms·

In the same blog series I point out that this seems to be an idea carried over from the days of modems and is no longer really necessary: https://www.construct.

In the same blog series I point out that this seems to be an idea carried over from the days of modems and is no longer really necessary: https://www.construct.net/en/blogs/ashleys-blog-2/rts-devlog-units-bandwidth-1603 https://www.construct.net/en/blogs/ashleys-blog-2/rts-devlog... 1000 units in intense combat can be synced with about 50 KiB/s - so why go to the trouble of deterministic gameplay, dealing with de-sync bugs, and making it diffiuclt to late join?

thworp 4y ago
It might not be necessary to get acceptable performance, but it is a fundamental countermeasure to cheating. If you send actual game state data over the network you make it very easy for cheat developers. If you add server-side sanity checks as a countermeasure, over time those checks will look more and more like the "old" architecture.
- saurik 4y ago
  There are tons of other ways to "cheat", including merely automatic behaviors faster than a human could ever do them (which is "within the rules" and yet is something people would consider "unfair") as well as snooping on internal hidden state (which is extremely common in RTS games due to "fog of war" mechanics", and yet would be needed for the simulation). Trying to prevent cheaters using technology is equivalent to Digital Rights Management and goes down the same paths of locked down computers with remote attestation and trying to use behavioral analysis to prevent unacceptable input... the entire concept ends up driving you insane at best and turning you evil at worst: if you suspect someone is cheating--whether online or in person--confront them, and, if you don't like their answers, just don't play with them anymore instead of insisting that cheating become structurally impossible.
  - thworp 4y ago
    Of course nothing can fully prevent cheating. But from a player enjoyment perspective it is a lot worse (and more obvious) if your opponent can teleport his units across the map or make his workers mine 50% more ressources vs just automating actions (which is hard to distinguish from just being a very fast player) or having full map vision. edit: The drm-like whack-a-mole is precisely the result of the architecture described in the blog, the "old school" way makes the most destructive and obvious cheating simply impossible.
- AshleysBrain 4y ago
  This has no bearing on cheating. You can do this approach and still have an authoritative server which clients only send their inputs to.
rcme 4y ago
> so why go to the trouble of deterministic gameplay, dealing with de-sync bugs, and making it diffiuclt to late join? The biggest reason is to remove the need for frame synchronization. In fighting games, it's important to get frame-perfect inputs. Even in an RTS, frame-perfect inputs matter, e.g. when kiting enemy units. You also get features like replays for free. Late joining really isn't an issue because the server can reconcile the state, deliver it to a late-joiner, and then continue on from there. You don't need to deliver the entire history of events to a late joiner.

thworp 4y ago

It might not be necessary to get acceptable performance, but it is a fundamental countermeasure to cheating. If you send actual game state data over the network you make it very easy for cheat developers. If you add server-side sanity checks as a countermeasure, over time those checks will look more and more like the "old" architecture.

saurik 4y ago
There are tons of other ways to "cheat", including merely automatic behaviors faster than a human could ever do them (which is "within the rules" and yet is something people would consider "unfair") as well as snooping on internal hidden state (which is extremely common in RTS games due to "fog of war" mechanics", and yet would be needed for the simulation). Trying to prevent cheaters using technology is equivalent to Digital Rights Management and goes down the same paths of locked down computers with remote attestation and trying to use behavioral analysis to prevent unacceptable input... the entire concept ends up driving you insane at best and turning you evil at worst: if you suspect someone is cheating--whether online or in person--confront them, and, if you don't like their answers, just don't play with them anymore instead of insisting that cheating become structurally impossible.
- thworp 4y ago
  Of course nothing can fully prevent cheating. But from a player enjoyment perspective it is a lot worse (and more obvious) if your opponent can teleport his units across the map or make his workers mine 50% more ressources vs just automating actions (which is hard to distinguish from just being a very fast player) or having full map vision. edit: The drm-like whack-a-mole is precisely the result of the architecture described in the blog, the "old school" way makes the most destructive and obvious cheating simply impossible.
AshleysBrain 4y ago
This has no bearing on cheating. You can do this approach and still have an authoritative server which clients only send their inputs to.

rcme 4y ago

> so why go to the trouble of deterministic gameplay, dealing with de-sync bugs, and making it diffiuclt to late join? The biggest reason is to remove the need for frame synchronization. In fighting games, it's important to get frame-perfect inputs. Even in an RTS, frame-perfect inputs matter, e.g. when kiting enemy units. You also get features like replays for free. Late joining really isn't an issue because the server can reconcile the state, deliver it to a late-joiner, and then continue on from there. You don't need to deliver the entire history of events to a late joiner.