4
\$\begingroup\$

I'm building a 2D multiplayer shooter game. I have singleplayer working and started working on multiplayer part (server code,...) and there is one thing I just can't get my head around.

When player shoots someone, who is moving, and he has high latency (>200ms or something like that) how to synchronize it with the other client? I thought that the shot vector could be sent relatively to targeted player (so when he would recieve the info about the shot, he could animate the shot hitting him).

Problem is, shots can destroy enviroment or hit other players. So when I shoot a target and there aren't any obstacles, he gets hit and the packet about shot hitting him gets sent. 200ms (+ other player latency) later, other player recieves the packet, but in that time, he moved behind an obstacle.

Problem rises:

a) If the obstacle is destroyable by the shot, clients will have different map (shooting player will have map with obstacle, while the other player will have the obstacle destroyed)

b) If the obstacle can't be destroyed, other player will either complain, because he got shot through impenetrable obstacle or the shot will be shot, so shooter will think that target got hit and target won't see any hit.

I just can't find a better way to solve this. Any ideas or examples how other games did it?

\$\endgroup\$
  • \$\begingroup\$ This can be solved with client-side prediction gafferongames.com/networking-for-game-programmers/… \$\endgroup\$ – Blue Wizard Jul 29 '14 at 4:04
  • \$\begingroup\$ The server should be controlling the things you are talking about. If player A shoots at player B and blows up a tree, the server should send down, Tree blown up, both clients Animate/render blown up tree. \$\endgroup\$ – Joe Swindell Sep 30 '14 at 16:07
8
\$\begingroup\$

When dealing with different frames of reference interacting with each other instantaneously, you have to compromise somewhere, you cannot have everything consistent everywhere; that's a fact of life. The scenario you have outlined is basically this: the shooter thinks she has hit her target, but the target thinks she has successfully hidden behind an obstacle.

Who is right? That's for you to decide, but I'd argue that games that emphasise shooting - with fast projectiles - should favour the shooter, whereas games that emphasise moving and evading - with slow projectiles - should favour the target. (You could of course do both in one game depending on factors such as the speed of projectiles.)

  • If you favour the shooter, then you can give instant feedback to the shooter on whether she has hit or missed, but the target's feedback on whether she was hit or not will be delayed.
  • If you favour the target, then the reverse is true.

In practice this tends to end up in the shooter's favour, as most FPS games have fast projectile weapons that require instant feedback for shooters, but keep in mind that anything you decide will be a compromise. Also, contrary to many gamers' complaints, it is the sum of latencies between shooter and target that determines the severity of the compromise, and in one-on-one encounters there is no inherent advantage to either player - both players experience the same degraded gameplay, irrespective of their individual latencies to the server.

Here are some general strategies and examples (the Gaffer on games article expands on some of these concepts):

Server authority (listed in the article as Client/Server): this is where the server is the ultimate authoritative frame of reference for everything, including whether one player has hit another. This was common in the early days of internet FPS games, when titles like Quake were most popular. This disadvantaged all players for the sake of the game, and disadvantaged high-latency players more, as no action begins until the server hears about it. For twitch-shooters such as Quake this was acceptable, as one needed a low latency to get the best experience anyway. The downside was that even modest amounts of latency - 100-150ms - was noticeable for human players, and they had to compensate by aiming ahead and so on.

Client-side Prediction: often goes hand-in-hand with latency compensation, this is where the client is the authoritative frame of reference (either the shooter or the target, as I mentioned), and the server maintains a buffer of previous state in order to validate the client's prediction. Games using this architecture became common in the early 2000's, especially for "realistic" shooters using fast projectile weapons such as Counter Strike.

Latency caps: to mitigate the harmful effects introduced with client-side prediction, many games and server admins chose to disallow high-latency players from playing. This ensures that the experience is consistent for the low-latency players. Although this seems harsh, with the spread of broadband internet and matchmaking services, the pain can be reduced.

Latency-capped client-side prediction: this is the same as client-side prediction, but where the compensation is limited up to a maximum latency. Any players above this threshold will only have their latency compensated up to that threshold, no more. This threshold should suit the nature of the game, but 200ms sounds like a good compromise. This means that for players with latencies below the 200ms, it's identical to normal client-side prediction, except it feels like no one has a latency any greater than 200ms. For players with latencies above the threshold however, it feels like a server authority game where everyone else has a latency of 0 but they have a latency of X - 200ms. I'm not aware of any games that do this but I'd be surprised if this has never been attempted before.

\$\endgroup\$
  • 1
    \$\begingroup\$ Just to add: Most shooters will give you instant visual feedback (muzzle flash, sound effects, own movement), but you won't see hit markers or blood etc. unless you actually hit. And in case your movement is invalid, you'll "rubberband" back. This is also the reason why most shooters allow you to still shoot (without bullets flying) once you're lagging or disconnected. \$\endgroup\$ – Mario Jul 30 '14 at 6:55

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.