Jump to content
  • Advertisement
Sign in to follow this  
IvanJ

About ping and synchornization in multiplayer...

This topic is 4806 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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...

Share this post


Link to post
Share on other sites
are you saying there are no public implementations or discussions of this subject? I have to build from scratch? :(((

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There are suchs implementations in FPS games: check the insta unlagged mod of Quake 3 Arena. The typical implementation would be that the server. Typically, the server should have an event stack for the last xxx milliseconds and then mix events results to achieve the right result.

Unlagged ref:
http://www.planetquake.com/alternatefire/archive.html

There another method: the vector compensation method. Upon connexion, the client is getting a time frame from the server (ping compensated value) and send along each message the event time. The server handle then the message, and replace it into the right timeframe.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Well i'm pretty sure that the unlagged code could work. If the server can reorder the message in the correct way, the "block" message would be processed before the "show damage on client".

0: client A "attacks" at 0

50: Server receives the message "attacks" at 0

350: client B receives the "attacks" message, put it at 0. Quasi Instant reply with a "block" message at 10. Client B show the attack and block animation.

650: Server receives the message "blocks" at 10. The attack has been blocked! send two messages "attack blocked" to client A and B.

700: client A shows the attack and then the block animation. There you could optimise things be starting the attack animation a bit before (say the attack last 250 ms, you could start playing it at 450, and client B could block the action at 700).

This only work when you "buffer" the world on both servers and clients. The clever thing to do is to know what to buffer: instant actions with reaction needs should be buffered on caster, reactions shouldn't be buffer. It's a bit complicated to explain, altought, and i'm not so fluent with english, so most words are missing when I explain complex things :P.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!