Hi! I had a simple question as to how did some people approach the problem of ping in multiplayer. To be more clear, let's look at a simple scenario: We have two players: you and a foe. Your ping is 100 and foe's is 300. You're going to try to hit foe with a sword and your foe will try to block it with a shield. The animation is 500ms. The old model (1) would work like this (numbers in the beginning are milliseconds): 0: You click on your foe to attack him. A packet is sent to the server. 50: The packet arrives at the server and it sends the "play animation" packet to you and your foe, and starts the count down. 100: You get the animation packet and your animation starts playing. 200: Your foe gets the animation packet and he sees you attack *(your graphics are out of synch by 100ms already) * let's assume it takes your foe 300 ms to react 500: Your foe clicks to raise his shield to block. The packet is sent to the server. 550: Server finished the "attack" countdown and sends the "player has been attacked" to you and your foe. 600: You recieve the successful attack packet. 650: Server gets the "block" packet from your foe and disregards it. 700: Your foe gets the attack successful packet... The problem with this model is that it's extremely jerky, and the higher the ping the worse... Your foe will think he blocks the attack when he actually doesn't becaue of the ping... Also, the frames aren't syncrhonized which also adds to the confusion... There are quite a few other approaches and techniques that I know/have thought of such as rolling back the packets and gradually speeding up/slowing down animations to accomodate ping... But I'm pretty sure this topic has already been worked over and I wanted to know if anybody knows about that... The thing is that there are many MMORPGs out there that still use the very oldest and crappiest model which keeps the FPS crowd away... But then again the FPS crowd also doesn't have a very good model - they pretty much rely on good player pings, but it still beats MMORPGs... So can somebody shed some light here? Thanks!

You have to design your entire system to take latency into account. Settle on a maximum latencly allowed for each player, and design for that.

If you want 300 ms max latency, and 300 ms reaction time, and you want server-autheticated combat, then you need at least 1200 ms (hit cmd + hit notify + reaction time + block cmd), and if you want to also show the block before the end of the attack on the attacker's machine, you need 1500 ms. This means that all your attack animations need to be at least 1500 ms, before a result can be shown.

Note that you're describing one-on-one real-time combat, like a Street Fighter game; this is pretty much the worst case for being latency sensitive. There's a reason most online RPGs only use skill-based defense, rather than letting the player "react".

There are also clever game design tricks you can play, such as showing a hit even when you find out something misses, and then the next time you actually hit, showing a miss to even it out...

are you saying there are no public implementations or discussions of this subject? I have to build from scratch? :(((

Well that "unlagged" stuff is a very easy implementation but it won't work in my case...

It works in games like quake, where combat is only interactive for one person. Meaning your oponent can't do anything to stop you from shooting them (except for run).

In my example I actually have an oponent who's trying to block, so there needs to be some sort of frame synchronization that compensates for ping delay... Something that will stretch out animations favoring the faster connections...

Anybody knows of that?

I completely understand what you mean by that instant actions can be buffered. Yes that section is easily covered....

Now actions/reactions is where my problem is.

Your proposed solution has one fundamental problem:

When client B recieves the message about attack and puts it back at 0, the animation would be on the 350th frame or whatever... So everything around would be jerky as hell...

So what I kind of thought was that ever animation could be actually slowed down or speeded up depending on the latency.

Something like that, but that would be hell with other people running around... because it means they'd run slower when somebody's lagging out close to them, which would be very dumb...

Any ideas?

Unless you can find a way to travel faster than light, this is a fundamental latency problem with two-party interactions.

You can adjust time frames so that everybody except for one person sees something reasonable (our company has some licensable IP in this area, btw). In your case, it'd probably be the attacker who would see an animation "succeed" but then, when the result comes back, notice that the attack actually didnt' succeed.

If you want everybody (attacker, attackee, viewers) to see a 100% consistent result for two-party interactions, then you have to wait for the round-trip delay; this is simple information theory.

This is horrible!

I'm telling you, there's gotta be some clever way to cheat lag!

And what's that thing with licensable IPs you're talking about?

If there was some clever way to cheat lag, then lag wouldn't have been such an important issue :P
Also, although quite effecient, the unlagged implementation will open new doors for cheaters! So beware of that.

Regards,
/Omid

There's a reason why you rarely ever see any network-multiplayer games like this where reaction is as important as action - because it's very hard, if not impossible, to do with sufficiently little lag. MAYBE on a fast LAN...

Well people say that if you really put your head to it, you can do anything...

But is this one of those "physically impossible" moments?