[#SomeChanges Suggestion] World of Warcraft Modern Responsiveness and Fluidity

[JamminL]

Description

There are some remnants of original code that have been kept in the game (some still present on retail) that limit the game's fluidity and responsiveness, causing uncharacteristic deaths and unexplainable situations for players since it's inception.

In this post I'll try to address each one and give both pros and cons of these remnants as well as suggestions on how to fix/address them.

Most private servers have addressed a lot of these issues and the benefits are very clear - often characterized by players as to why private servers feel more fluid. Understandably, these solutions are very easily applied when we're talking about a very small sample of population, and so there might be scalability concerns over network bandwidth usage. Acknowledging that, it’s still my opinion that these issues merit load tests and proper adjustment. Any change is improvement

Note: It is my belief that a lot of these issues haven't been addressed because most of these examples are easily blamed on latency or ping issues. However, this is not the case, none of the issues listed below are symptoms of latency.

1. Client-side Movement Throttling (Movement Heartbeat)

EXPLANATION

The WoW client doesn't send movement packets instantly. By smart design, if a player is moving and doesn't change directions or speed, there's no need to regularly send movement packets, as both the server and other clients can extrapolate the player's position using speed + direction + time since last packet.

Since release, movement packets sent from your wow client work like this:

• If direction or speed changes
  • Immediately send position update to server
• If walking in the same direction and no speed change
  • Only update the server with position every 0.5 seconds

This means that there's a literal desync between your character position and the server of 500ms if walking in a straight line.

The following showcases how the server perceives player position if they are walking in a straight line (blue sphere = the server gets new position information):

1. At normal player movement speed (Click to Expand)

2. With a 100% speed mount (Click to Expand)

3. Video of real-time server updates when moving straight (Click to Expand)

heartbeats.1.1.mp4

EXAMPLES

So why does all of this matter?

In theory, it wouldn't if the server used predictive position calculations when evaluating line of sight conditions or if a player is inside or outside a particular AoE. However this is not the case, as exemplified in the following clips:

1. Naxxramas Ooze Death Example (Click to Expand)

Source : Original Naxxramas (https://www.youtube.com/watch?v=KoHJk_kLCFU)
Explanation: Because he was walking straight, his position was desynced from the server by up to 500ms and so the server thought he was hit by the ooze slime when in reality he wasn't.

Naxxramas.Slimes.mp4

2. Missing your AoE Spells(Click to Expand)

Source : WOTLK BETA
Explanation: The player starts moving left while they are still out of LOS from the enemy. The next movement update the client sends will be 500ms after that initial move because the player never changed directions or increased his speed. So when the player casts arcane explosion when he's now in line of sight, it will not hit the enemy because the server still thinks he's behind the door, out of LOS.

LOS_movementHeartbeat_Trim_Trim.mp4

2. Hitting your AoE Spells behind LOS (Click to Expand)

Source : WOTLK BETA
Explanation: The player starts moving right while still in line of sight of the player, because he is walking in one direction and doesn't change his speed, the next update will be 500ms later so if he presses an aoe ability during that interval, the server will still think the player is still in his initial position and allow the cast to land.

LOS_movementHeartbeat_SelfAOE_Trim.mp4

3. Getting hit by direct spells behind Line of Sight (Click to Expand)

Source : WOTLK BETA
Explanation: The player starts moving right while still in line of sight of the player, because he is walking in one direction and doesn't change his speed, the next update will be 500ms later so when the enemy cast ends, the server still thinks the player is in line of sight and allows the cast to complete successfully. Upon polymorph landing, the player is teleported back to the last position known by the server, which is 0.5sec behind.

LOS_movementHeartbeat_EnemyPoly_Trim.mp4

4. Getting hit by AoE spells behind Line of Sight (Click to Expand)

Source : WOTLK BETA
Explanation: Same reasoning as the above examples. The server still thinks the player is in line of sight of the enemy and allows the AoE to land.

LOS_movementHeartbeat_EnemyAOE.mp4

Note: None of these examples are due to latency effect, the same practical tests can be done and if the character is turning (changing directions) or speed changes then they will not work and everything will be responsive as it should be`

CONCLUSION

• Reasons to keep this:
  • Reduces computing time by not using predictive movement for these spell checks
  • Reduces network bandwidth by not sending constant movement packets in case the player moves in a straight line without speed changes
• Reasons to adjust/change this:
  • Adds constant, unavoidable, 500ms position desync
  • Makes the game feel laggy and unresponsive
  • Affects pve, pvp and just normal players doing day-to-day tasks
• Suggested Change:
  • Option 1: Reduce the 0.5 value on the client
    This option is the simplest and would require only one value change in the client. Basically, the code that adds this 500ms delay (which has been reverse engineered) can be reduced to a more appropriate value for modern times.
    The consequence of this will be an increase in movement packet per second for each player online, but any delay reduction is an improvement.
  • Option 2: Start using predictive movement when doing spell checks
    Unsure if feasible but this would be the optimal option, where the server calculates player actual position (using speed + curr position + time since last position + direction), instead of using the last position sent by the client, which can be delayed by up to 500ms.

2. AoE Aura Batch

EXPLANATION

Classic WoW brought back a particular batch that affected AoE auras. This batch is one that checks whether or not a particular player has left or entered an area that should give a particular aura.

For example, if a paladin uses Divine Sarcrifice, all party members in 30yard range should receive an aura that reduces their damage taken by 30%. If the players are outside the 30 yard range when the spell is cast and then move in, it might take up to 5? seconds for them to receive that aura.

The 5 seconds is a ballpark number as we only have guesswork for how long the batch is.

From a player's perspective, it's easy to blame this on lag and it'll be easy to miss because there's no visual indication of range for this particular Divine Sac case. However, this example pales in comparison to more "visual" examples - when the AoE in question has a visual indicator of range like a flare or a frost trap

When you leave or enter an AoE area, you shouldn't have to wait up to 5 seconds for an inconsistent server update, if the game is showing you when you're out of a particular AoE, you expect the game to respond in the same manner.

EXAMPLES

1. Leaving Flare AoE Area (Click to Expand)

Source : WOTLK BETA
Explanation: You can see the enemy rogue leave the flare area and it takes an exceedingly long time for the flare debuff to disappear, he's about 60 yards away from the flare when the buff is removed. For a rogue this is obviously one of those frustrating cases where the game just feels laggy and unresponsive and you're not able to stealth even though you're clearly outside of the flare range.

22e738bbe8789f99a247c5300e5a4374.mp4

2. Entering Grounding Totem AoE Area (Click to Expand)

Source : WOTLK BETA
Explanation: You can see the rogue in the party leave the grounding totem range, the buff after awhile disappears, and then the rogue enters the grounding totem range and almost leaves it again before the grounding totem buff is re-applied. Again showing a complete lack of response from the game.

0ccb275da80f78d45d9fc614cfb73b0c_Trim.mp4

CONCLUSION

• Reasons to keep this:
  • ?
• Reasons to change this:
  • Makes the game feel incredibly unresponsive in every sense of the word
  • Has very visual and real implications ingame
  • Has no known technical limitations considering this is not present on retail WoW
• Suggested Change:
  • Heavily reduce the batch so that the checks for when a player is inside or outside the AoE area, the auras updates accordingly more often. - Port the change from retail?

Issue associated: #53

3. Visibility Update Delay

EXPLANATION

While the other issues affect both PvP and PvE, this particular issue is mostly pvp related.

What we're calling visibility update delay is the time it takes for the server to make a player invisible to another player, after an invisibility spell has been cast.

For example, when a rogue vanishes, the time it takes for the rogue to become invisible to players, after he gains the vanish aura, that's what we'd call Visibility Update Delay.

Now, this delay is totally fine and justifiable and a big part of wow, it gives time for animations to finish, and gives some leeway for enemies to see the rogue that went past them - otherwise the rogue would be visible for 0.1 seconds while they're in range and then instantly disappear.

What we argue is that this delay, with spellbatching heavily reduced and modern latency, is a bit too big and should be adjusted. It allows people to break vanishes quite easily as they have more than enough time to react to this event and press a spell to break said vanish before the rogue goes invisible.

EXAMPLES

1. Entering Stealth (Click to Expand)

Source : WOTLK BETA
Explanation: This is a batch, so results will be inconsistent, but here you can see the enemy rogue stealths, and there's a delay until he becomes invisible, causing himself to be de-targeted by other players

rogue.visibility.update.-.Entering.Stealth.mp4

2. Vanishing (Click to Expand)

Source : WOTLK BETA
Explanation: This is a batch, so results will be inconsistent, but here you can see the enemy rogue vanishes, and there's a delay until he becomes invisible, causing himself to be de-targeted by other players

rogue.visibility.update.-.Vanishing.mp4

3. Leaving Visibility Cone (Click to Expand)

Source : WOTLK BETA
Explanation: This same delay can be seen, as explained above, when a rogue stops being visible because he went outside your visibility clone (affected by stealth detection). In this example, after the player character turns, depending on batch, there's a delay before the enemy rogue becomes invisible again. This again is a good mechanic and we should keep it - we just advocate it should be reduced..

rogue.visibility.update.-.Breaking.visibility.Cone_Trim.mp4

1. Breaking Vanish using Visibility Delay (Click to Expand)

Source : WOTLK BETA
Explanation: Because the visibility delay is so big, it allows players to react to a vanish being used and use a spell to break it instantly. Before this wasn't so easy because of spellbatching, but with that gone this is incredibly easy to do. This is a good mechanic and we should keep it, we just advocate that the time players have to break vanish is reduced, so it becomes a skill-related thing rather than a very easy thing to do.

rogue.visibility.update.-.Breaking.vanish.mp4

CONCLUSION

This batch is one that is actually good for the game, it allows PvPers to counter rogues by being able to stop the vanishes before they turn invisible, a lot of wotlk movies have examples of this e.g An enemy rogue saps another rogue's vanish.

That said, with spellbatching heavily reduced and general latency also heavily reduced, this thing that was once rare and considered a skilled move by having fast reactions is now a grievance because you have up to a full global to react to that vanish and use a spell.

We argue that this mechanic is reduced, as it has been tested and accepted by private servers throughout, with a delay of ~200ms.

4. Spell Batching

✔️ Fixed!

• I still advocate that should be a bit higher than 10ms because of the fun interactions it introduced. (see [#SomeChanges Suggestion] Adjusting batching slightly to preserve the ability to counter CCs #120)

[Homerjayx]

Adored every word I read.

[Ninemmglocks]

<3 <3 <3

[avizura7]

Perfectly explained, amazing.

[caccavale]

Please keep support to reactions on the post and comments for further info / sources for the ticket 🙂