3

In electrical engineering class we learned that signal lines are not ideal, so it takes time for the signal to reach the other end of the cable, and if we doesn't take this into account, it can lead to crazy phenomenons like:

enter image description here

Imagine we have a tank game, where tank1 (played from Europe) shots tank2 (controlled from the USA). In tank1's monitor he sees that tank2 is destroyed, but it takes some (very small but not negligible) time for the signal to reach tank2's monitor. So while the signal travels, he can fire his virtual cannon too, destroying tank1. The signal of this act starts his journey to tank1, before the data that tells to tank2 that he is dead, arrives. This causes the weird phenomenon, that tank1 destroyed tank2, but tank2 still can destroy player1 (despite that tank2 doesn't even exists).

They told us, that we cant solve this problem in the hardware way, we have to prevent this in the software side, but they didn't tell us how should we do this, but I am courious, so how do we/they solve this problem?

The problem is not about the time that elapse while the bullet flies in the air, it is about that the first tank should be destroyed, so it shouldn't be able to shot (or be able to do anything), but in our problem it is able, because the information that he destroyed doesn't arrived yet. In this case we should interpret the word shot as: the bullet impacted and it destroyed the tank. So the actual signal that is going to be sent to the other client is that he is destroyed. Not the event that the enemy tank fired its cannon.

  • 4
    You might find Transaction Models for Massively Multiplayer Online Games a good read. – user40980 May 13 '13 at 17:25
  • This is a pretty deep problem to solve when programming a multiplayer online game, so I don't know if I can answer it fully. But I think what might be very important to the answer is whether this is using a centralized, master (trusted) server, or if the logic is decentralized, using only those two computers to figure out the result. – Katana314 May 13 '13 at 21:05
3

Actually, you CAN'T prevent this, and you shouldn't. Double kills can and do occasionally happen in reality.

Think of this as simulating time-of-flight of the projectiles.

You got a shot off. SO DID HE. You didn't see his muzzle flash, because you were blinded by the flash and smoke from your own shot. You see your round hit him, and destroy him. At that moment, you are already dead, from his incoming round, but you just haven't gotten the memo yet.

  • 3
    I think the OP was concerned about cases where Tank1's projectile should have hit Tank2 before Tank2 fired their projectile, which is slightly different from both tanks firing at the same time and striking each other at the same time (which I think is what you are discussing). – FrustratedWithFormsDesigner May 13 '13 at 19:19
  • then they both win since both objectives were completed. – hanzolo May 13 '13 at 19:29
  • At T0, A shoots at B. Because of lag in the system, it takes longer for the information of a kill to reach B than it does for the bullet. B shoots A during this period of lag. Now the server has T0, A fired at B, T2 A killed B, and now T3 B fired at A. Consider how a server (or even more fun, p2p) should reconcile updates from inconsistent client states. – user40980 May 13 '13 at 19:46
  • 1
    The server is its own, self consistent universe. Clients request action, and for the sake of appearances pretend that action has started. Clients do not simulate the reaction and instead wait for the server to tell them what happened. The reason you cannot solve this in most hardware is that there is no central nexus (ie. the server) where transactions happen. – Patrick Hughes May 13 '13 at 21:25
  • @FrustratedWithFormsDesigner I mean the same you wrote. I also added some plus info to clarify the question a bit. – totymedli May 13 '13 at 21:37
1

You can't program the delays away. They are a fact of nature.

But, you can incorporate the delays in the game in various ways:

  • The easiest is that the delay represents the time-of-flight for the projectiles and for the player to register the results. In this case, the player fires, but does not see the enemy tank destroyed until a message is received back confirming its destruction. As there now is a (slight) delay between firing and destruction, it is no longer impossible to be hit by the tank you just fired upon.
  • Another way to factor the delays in is to use larger time-steps, where everything happening between t0 and t1 is regarded as having happened at t0. If the step is large enough to cover the delay, then the two shots are considered to have been fired at exactly the same time.
  • If there is a central server, the delays could also be factored in at the controls side. The player is not inside the tank, but at a central control location remotely operating a tank.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.