Im doing a mental experiment to design a gameplay system including a sort of multiplayer real time combat, but considering that our internet service and VPSs have an average ping of 140ms.

So, lets say that a player attack takes 1.2 seconds to complete, and can be blocked before 1s (blocking after 1 seconds is too late ad doesnt counts). I started to calculate that 140 ms means that the notification of attack action takes around 70 ms to reach server, and then 70 ms to the player B (target of attack). A normal person can take 200ms to react, and then another 70ms for the server to get the notification of block action. That means that I have, 340ms, plenty of time to react and block/evade attacks, even if ping raises to 160, or my reaction time is larger than 200 ms. Sounds good to me, in fact, too good to be true, so Im sure there are factors Im not considering, technical issues Im not aware, and many others. What do you think about this? Is it possible or not?

The block needs to get back to the server from B, too, but that's not a particularly large addition in time.

Things you have not listed, that do add to latency:

• frame rate – typically network packets are sent/received at the edge of frames
• net update rate – typically network packets are not sent at each frame
• animation latency – the user is unlikely to react to the very first frame in the attack animation

hplus0603 said:

The block needs to get back to the server from B, too, but that's not a particularly large addition in time.

Things you have not listed, that do add to latency:

• frame rate – typically network packets are sent/received at the edge of frames
• net update rate – typically network packets are not sent at each frame
• animation latency – the user is unlikely to react to the very first frame in the attack animation

Thanks! I didnt count the notification to player B because I tought that server was the one to decide that the block was valid. The net update rate worries me, I would like to reduce it as much as possible to keep the traffic low. Many players wont have the usual internet (most homes in Cuba still dont have ADSL), they will be connected using their phones. The third element is an important miss, I think it would introduce another 200 ms or more.

FPS gamers start to get annoyed around 50ms latency. 200ms is s-l-o-w.

There are some tricks for shooting games, so that what each player sees as bullet vs target may not be consistent but whether there is a hit is consistent. Ask FPS devs about those tricks.

Also, fighting game players are even more annoyed than FPS players at latency.

Gambettas “GGPO” description of network engine design talks about ways to work around this specifically for fighting games.

Beware, though, that the author claims the approach is generally useful for everything, but in practice it makes a large number of assumptions about game and simulation state, cost of simulation, determinism, etc. It wouldn't work at all in practice on a typical first-person shooter with 10-100 people and possibly hundreds to thousands of simulated boxes/crates/etc. (Might not even work with 10 crates, if they can all pile in one place.)

Still, because you're talking about “attack" and “block,” it's a useful article to read!