altitude netcode

[MagneticDuck`]

The "netcode", the method used to synchronize the state of a game over a set of clients separated by inevitable network latency, is an integral part of the construction of any multiplayer system. Its job is a difficult one; given the impossibility of corresponding every client's screen with the server's representation of the game, we must create a sort of illusion: make every client display a slightly different game, while displaying (fairly) consistent game mechanics in each.

For consideration in solemnsky's development, I'd like to hear some community opinions on altitude's netcode -- from a player's perspective, which aspects were best, and which were worst?

The method I have sketched out in solemnsky -- a sort of hybrid authority model -- has the following characteristics:

• There is no control lag, and there are no jumps in your position regardless of what weapons / items are used against you. Your flight is completely consistent with what you see on your screen.
• Weapon fire delay equal to your latency. Sorry. This is related with my decision to make modding exclusively server-side. This is how things are in teeworlds though, so it can't be too bad. I promise, you'll get used to it.
• When weapons hit an opponent on your screen, the effects are real.
• Weapons that hit the position you were at before an interval of time equal to your latency passed may register an effect on you. (Unlike in altitude, this interval is equal to your, not you assailant's, ping.)
• It will appear to take the sum of your latency with an opponent's latency for a position-altering weapon you deployed to have an effect on them.
• Mainly due to reasons listed above, players with high ping suffer severe handicaps, not game-breaking bonuses.

We'll see how effective this approach is in our (ever-nearing) public alpha, but in speculation, how does this sound? Does this address any of altitude's issues? Does it introduce new ones?

[Aki1024]

Originally Posted by MagneticDuck`

1. There is no control lag, and there are no jumps in your position regardless of what weapons / items are used against you. Your flight is completely consistent with what you see on your screen.
2. Weapon fire delay equal to your latency. Sorry. This is related with my decision to make modding exclusively server-side.
3. When weapons hit an opponent on your screen, the effects are real.
4. Weapons that hit the position you were at before an interval of time equal to your latency passed may register an effect on you. (Unlike in altitude, this interval is equal to your, not you assailant's, ping.)
5. It will appear to take the average of your latency with an opponent's latency for a position-altering weapon you deployed to have an effect on them.
6. Mainly due to reasons listed above, players with high ping suffer severe handicaps, not game-breaking bonuses.

1) Con: This can cause opponents to fly though your recently placed wall, as they haven't yet registered that the wall is there. (This is an acceptable con imo)
2) Does weapon fire delay == powerup fire delay? (I don't want to make assumptions.) Does the location of attacks originate from where I will be once latency's time has passed, or where I was when I clicked?
3) This feels great as the attacking player, knowing where you actually need to hit. As the defending player against packet dropping opponents, this can feel terrible. "He shot me around a wall?" If they (attacker) get to packet drop at the right time, and their view of you is flying out into the field when you actually turned back to base, this can get killed quick.
#4 is an awesome result of #2 <3

Wall lag: I'm not sure exactly how much this system alters wall lag, but I think it does decrease it. Wall lag occurs when the ball bounces off a wall powerup on some clients but not on all clients. This problem is also seen when the ball is shoot at a small rounded object, and the small amount of change between client's initial bounce position from that object greatly changes it's bounce direction. I think the ball should have a jump in position on some screens to keep the ball on the same side of a wall.
Also, if a ball's initial send message has the first expected bounce point and direction, the amount of uncertainty between clients can be greatly reduced. This adds two more variables per shot ball. I don't think this is important on ball carrier death, as ball speed is so much lower.

[MagneticDuck`]

1) Con: This can cause opponents to fly though your recently placed wall, as they haven't yet registered that the wall is there. (This is an acceptable con imo)

Yeah, this is one bonus lagging players would get. For the time being I feel like a smooth, solid experience is more important than giving position-altering weapons faster action.

2) Does weapon fire delay == powerup fire delay? (I don't want to make assumptions.) Does the location of attacks originate from where I will be once latency's time has passed, or where I was when I clicked?

Yes; weapons, powerups and the like are decided by server-side logic. Until this changes, it takes <latency> for any command to trigger logic on the server and indirectly cause its results to arrive on your screen. (The location of the attacks originate from where you were when you clicked.)

3) This feels great as the attacking player, knowing where you actually need to hit. As the defending player against packet dropping opponents, this can feel terrible. "He shot me around a wall?" If they (attacker) get to packet drop at the right time, and their view of you is flying out into the field when you actually turned back to base, this can get killed quick.

Here we have some confusion; my statement suggesting that projectile hits against opponents on your screen are real may be the culprit.

With arbitrarily high sampling and network consistency, the projectiles and opponent states on your screen match those registered by the server exactly, ~<latency>/2 ago, so hits that you see are hits that happened. However, packet drops, fluctuating pings or significant changes effected within the packet sampling interval can break this correspondence. Meanwhile, the actual decision of whether the weapon hit or not is decided by packets you send to the server indicating your state combined with packets the assailant sent to the server requesting to press the fire button -- if you get hit with a shot that wasn't on your screen, it's because of your connection, not an opponent dropping packets.

It's worth saying that the great majority of modern multiplayer games decide these scenarios in favor of the shooter, and the strategy I'm using leans towards the moderate side of the spectrum.

#4 is an awesome result of #2 <3

This system is much more favorable to careful players with low pings.

Wall lag: I'm not sure exactly how much this system alters wall lag, but I think it does decrease it. Wall lag occurs when the ball bounces off a wall powerup on some clients but not on all clients. This problem is also seen when the ball is shoot at a small rounded object, and the small amount of change between client's initial bounce position from that object greatly changes it's bounce direction. I think the ball should have a jump in position on some screens to keep the ball on the same side of a wall. [...]

Yeah, wall lag will be totally solved in solemnsky's current networking strategy. Walls and balls (if we use them ^^) will be server authoritative.

[Bof1]

How will you deal with players whose ping fluctuates wildly? My suggestion is for the server and client to enforce that the delay not shrink too quickly, and maybe always provide a buffer so that the delay is as constant as possible.

For the client, this would be because an honest player will be trying to predict when his fire button will register at the server, and unpredictable network hiccups will throw that off. You can also mitigate packet loss by preemptively sending each packet several times, but I guess everyone already does this.

For the server, the delay shouldn't be allowed to shrink too quickly because otherwise cheaters could use this to their advantage by piling up some fake lag and then releasing a burst of it to jump their plane into a new position.

The hardest position to take would be to have each client decide its delay ahead of time and have the server disconnect or reset them if they exceed it. Players would then be motivated to pick a safe delay buffer or get a better connection.