4 ms·

This is an unsolved problem in a very high profile AAA competitive game: Starcraft II. In Starcraft II, when 2 Protoss players order one of their templars to m

This is an unsolved problem in a very high profile AAA competitive game: Starcraft II. In Starcraft II, when 2 Protoss players order one of their templars to move/cast a particular fatal spell to the other templar, then wait, you do not get the expected double kill. Instead, when they get in range of each other one templar casts the spell first, kill the other, and survives. Which templar lives and which dies depends on the order the units are processed in the frame —arguably an implementation detail. To the players, this is just plain unfair. Not a deal breaker for a hosts of reasons, but still no good.

ajuc 12y ago
This also happens with (quite common) high templar vs ghost duel. Both have ability to instantly kill the other type, with the same range. When you move them further than that range, and order both to use that ability on each other - the unit that was produced earlier always wins. It's not game breaking, but players noticed this. To avoid such problem with marines shooting (this would be game-breaking, because marines make up bulk of terran armies for most of the game) - there is miniscule random factor added to delay between shots for each marine. If it was important enough - they would fix the high templar/ghost problem the same way. BTW in e-sport games (like Starcraft) - finding such bugs and abusing them creatively is part of game. For example mineral-walking is legitimate techinque to micromanage your workers, used even in low-level matches, and it's caused by workaround of bug in Starcraft 1.
zak_mc_kracken 12y ago
This is a pretty standard multithreading problem that has nothing to do with mutability or immutability.
- agumonkey 12y ago
  Mutability implies caring about order. I think that's why GP used this example.
  - loup-vaillant 12y ago
    Indeed. This problem arises even in a single thread setting. Let's say 2 units aim at each other, and in frame N, they are at range of each other. Here's what should happen: - Unit1 kills unit2 - Unit2 kills unit1 If you double buffer your actions properly, both unit will be dead at frame N+1. If however you modify your data in place, this may happen: 1. Unit1 kills unit2 => delete unit 2 2. Unit2 no longer exists. Unit1 lives. Or, this may happen: 1. Unit2 kills unit1 => delete unit1 2. Unit1 no longer exists. Oops. Oops. What definitely does not happen is the double kill. StarcraftII can live with that, but other games, like Frozen Synapse, would be broken.
    - agumonkey 12y ago
      What you call double buffer, other call transaction I believe, and it's a system design. You have clear steps where information is gathered and rules are applied. In that case you take all the attacks, computes the damages, apply them and prune the dead.

ajuc 12y ago

This also happens with (quite common) high templar vs ghost duel. Both have ability to instantly kill the other type, with the same range. When you move them further than that range, and order both to use that ability on each other - the unit that was produced earlier always wins. It's not game breaking, but players noticed this. To avoid such problem with marines shooting (this would be game-breaking, because marines make up bulk of terran armies for most of the game) - there is miniscule random factor added to delay between shots for each marine. If it was important enough - they would fix the high templar/ghost problem the same way. BTW in e-sport games (like Starcraft) - finding such bugs and abusing them creatively is part of game. For example mineral-walking is legitimate techinque to micromanage your workers, used even in low-level matches, and it's caused by workaround of bug in Starcraft 1.

zak_mc_kracken 12y ago

This is a pretty standard multithreading problem that has nothing to do with mutability or immutability.

agumonkey 12y ago
Mutability implies caring about order. I think that's why GP used this example.
- loup-vaillant 12y ago
  Indeed. This problem arises even in a single thread setting. Let's say 2 units aim at each other, and in frame N, they are at range of each other. Here's what should happen: - Unit1 kills unit2 - Unit2 kills unit1 If you double buffer your actions properly, both unit will be dead at frame N+1. If however you modify your data in place, this may happen: 1. Unit1 kills unit2 => delete unit 2 2. Unit2 no longer exists. Unit1 lives. Or, this may happen: 1. Unit2 kills unit1 => delete unit1 2. Unit1 no longer exists. Oops. Oops. What definitely does not happen is the double kill. StarcraftII can live with that, but other games, like Frozen Synapse, would be broken.
  - agumonkey 12y ago
    What you call double buffer, other call transaction I believe, and it's a system design. You have clear steps where information is gathered and rules are applied. In that case you take all the attacks, computes the damages, apply them and prune the dead.