4 ms·

For an RTS game, you probably shouldn’t be sending unit positions over the network. Rather you should send events like “User A sent units X, Y, Z to position P

by rcme 4y ago

For an RTS game, you probably shouldn’t be sending unit positions over the network. Rather you should send events like “User A sent units X, Y, Z to position P at time T.” You can build your game as a simulation that plays back on both clients, so both clients compute the path of units X, Y, Z and locally play back the computer path. This allows you to perfectly recreate the state on both clients without needing to synchronize every single object. The best method of implementing this, that I know of, is called rollback net code.

Gigachad 4y ago
Then you can log the whole thing and implement replays.
- asvitkine 4y ago
  That's how Bungie's Myth worked.
eddsh1994 4y ago
What happens if you cancel the event on computer A but it takes 500ms to reach computer B and in that time B has seen their troops and attacked?
- rcme 4y ago
  You probably just accept that that’s possible. There are ways going to be conflicts in systems with distributed state. How you handle it depends a lot on the specific application and how often it happens.
- Centigonal 4y ago
  This post[1] talks about the mechanics of implementing this netcode. The scenario you're talking about would be a "desync," where in your simulation, the opponent never saw you, but in the opponent's sim, they did. You really don't want that, as that quickly makes the game diverge and become unplayable. What most games that use this technique do is "lockstep" - they send out a chunk of commands called a "frame" several times a second, and step the simulation forward to step n only when they have frame n from every player. So, in your scenario, if player A cancels before troops are visible to player B, then player B's computer won't ever show the troops, because simulation B will have paused during the 500ms of network lag, since it didn't have the frame from player A. [1] https://news.ycombinator.com/item?id=34395153 https://news.ycombinator.com/item?id=34395153
  - rcme 4y ago
    It’s worth noting that often lockstep is not appropriate. Fighting games, for instance, require frame-perfect inputs. Fighting games become hard to play perfectly if you introduce jitter into the timing by requiring frame synchronization. In a fighting you’d just unwind whatever happened and replay the simulation as if the “real” thing happened, which could mean undoing things a user saw in certain circumstances.
    - Centigonal 4y ago
      That's true - I haven't seen lockstep used outside of RTSs.
      - comex 4y ago
        Many fighting games did and do use lockstep; it’s only recently that rollback has started to become the norm, and some recent big releases still don’t have it. But fans actively clamor for rollback because it’s a far superior experience.
bigDinosaur 4y ago
Worth noting that this is a very common method and used by high profile RTS's such as Starcraft 2. It does require your simulation be deterministic, of course, which can bring challenges depending on what you're simulating. Supreme Commander had challenges with determinism and physics if I recall correctly due to CPU bugs, although they eventually worked it out.
AshleysBrain 4y ago
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.

by rcme 4y ago

Gigachad 4y ago

Then you can log the whole thing and implement replays.

asvitkine 4y ago
That's how Bungie's Myth worked.

eddsh1994 4y ago

What happens if you cancel the event on computer A but it takes 500ms to reach computer B and in that time B has seen their troops and attacked?

rcme 4y ago
You probably just accept that that’s possible. There are ways going to be conflicts in systems with distributed state. How you handle it depends a lot on the specific application and how often it happens.
Centigonal 4y ago
This post[1] talks about the mechanics of implementing this netcode. The scenario you're talking about would be a "desync," where in your simulation, the opponent never saw you, but in the opponent's sim, they did. You really don't want that, as that quickly makes the game diverge and become unplayable. What most games that use this technique do is "lockstep" - they send out a chunk of commands called a "frame" several times a second, and step the simulation forward to step n only when they have frame n from every player. So, in your scenario, if player A cancels before troops are visible to player B, then player B's computer won't ever show the troops, because simulation B will have paused during the 500ms of network lag, since it didn't have the frame from player A. [1] https://news.ycombinator.com/item?id=34395153 https://news.ycombinator.com/item?id=34395153
- rcme 4y ago
  It’s worth noting that often lockstep is not appropriate. Fighting games, for instance, require frame-perfect inputs. Fighting games become hard to play perfectly if you introduce jitter into the timing by requiring frame synchronization. In a fighting you’d just unwind whatever happened and replay the simulation as if the “real” thing happened, which could mean undoing things a user saw in certain circumstances.
  - Centigonal 4y ago
    That's true - I haven't seen lockstep used outside of RTSs.
    - comex 4y ago
      Many fighting games did and do use lockstep; it’s only recently that rollback has started to become the norm, and some recent big releases still don’t have it. But fans actively clamor for rollback because it’s a far superior experience.

bigDinosaur 4y ago

Worth noting that this is a very common method and used by high profile RTS's such as Starcraft 2. It does require your simulation be deterministic, of course, which can bring challenges depending on what you're simulating. Supreme Commander had challenges with determinism and physics if I recall correctly due to CPU bugs, although they eventually worked it out.

AshleysBrain 4y ago

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.