FAQ: Unregistered Hits & Splash Circles

**I'm posting this solely for a discord discussion. This was the first part of a series I was planning to do, but have since decided to put my time to better use elsewhere. Oh, and I've borrowed the relevant parts of a few technical articles for this post.**


FAQ #1 - WHY ARE MY HITS NOT REGISTERING / NOT DOING ANY DAMAGE?
What is an "Unregistered Hit" (URH)?

A URH occurs when a shot appears to hit an enemy ship (generating that weapon's hit animation) but the game fails to register any damage to the target.

All fast-twitch online multiplier games have issues with unregistered hits to some extent. This is a huge issue in Fortnite right now.

Why? Other than your own ship, everything you see in-match has already happened, and everything your opponents see has already happened .. It's a trippy concept but I'll try my best to explain how this works in most games (without going into every minut detail).

Technical Explanation:

Spoiler: Expand for details

The game server ("server") is a dedicated host that runs the game and is authoritative about world simulation, game rules, and player input processing. A "client" is a player's device that is connected to a game server. The client and server communicate with each other via small data packets at a high frequency (measured in tickrate).

In a match, the client receives the current world state from the server and generates video and audio output based on these updates. Clients communicate only with the game server, not between each other.

In order to make the game playable across a broad spectrum of devices and internet speeds, the server must make certain adjustments.

Player A shoots at a Target B at client time 13.5. The firing information is packed into a user command and sent to the server. While the packet is on its way through the network, Target B moves to a different position. The Player A command arrives at server time 13.6 and the server doesn't detect a hit based on current locations, even though Player A was aimed directly at Target B when the fire command was issued. This time delay has to be corrected by the server-side "Lag Compensation".

Lag Compensation and Hit Detection Errors:

Spoiler: Lag Compensation

Most Lag Compensation systems keep a history of all recent player positions for about one second. When a user command is executed, the server estimates at what time the command was created (based on data transmission speeds). Then, the server moves all players - typically only players - back to where they were at the command execution time. The user command is then simulated to determine whether there should be a hit recorded or not.

The Lag Compensation system is never perfect. Client and server hitboxes rarely match exactly because of small precision errors in time measurement (e.g., due to transmission speed fluctuations). Even a slight difference of a few milliseconds can cause an error of a ship length against fast-moving targets. Moreover, multiplayer hit detection is not pixel perfect and has known precision limitations based on the tickrate and the speed of moving objects.

The question arises that if hit detection is so complicated for the server why isn't hit detection done at the client-side (more accurately and with pixel precision). The client would simply tell the server there was a hit, which player was hit and the amount of damage.

Unfortunately, this creates more issues than it solves. A game server cannot trust the clients with such important decisions. Even if the client is restricted by anti-cheat software, the packets could be still modified on a 3rd machine enroute to the server. These "cheat proxies" could inject "hit" messages into the network packet without being detected by the server (a "man-in-the-middle" attack).

How does this apply in Battlebay?
1) Battlebay has a uniquely dynamic (always-changing) environment with its waves. Consequently, accurate hit detection becomes exponentially more difficult than in other games.

Spoiler: More technical stuff

Presumably, the Lag Compensation calculations not only have to rewind player positions to the point of where the fire command was issued but also rewind the environment (or waves) to the time the command was issued THEN simulate the projectile's flight path through the dynamic environment until it reaches its final destination to calculate hits. Moreover, some projectiles take far more than a second to reach their destination.

I am not sure if the BB does all these extra calculations (or to what extent), but it's easy to see how this would make hit detection less accurate than game consoles with client-side hit detection or mobile games with static environments.

Side Note: I haven't worked out exaxtly how they deal with waves. Are they live or a split second in the past? Are some shots not counted because they hit the top of a rewound wave (when they cleared the client, or live, version of the wave)?

2) There will always be slight errors in hit detection in any game, but which conditions cause larger and more frequent errors?

Spoiler: Expand for answer

To briefly recap: the slightest miscalculation in lag compensation (e.g., due to data transmission speed fluctuations - 80 ping to 90 ping) can cause an unregistered hit with any weapon on any target.

These slight miscalculations can turn into large miscalculations when:

• Slower projectile speed weapons are used (e.g., missiles, flares, explosive cannons), particularly at longer ranges;
• Targets have a lower margin of error (i.e., faster, smaller, more agile ships); or
• Target abilities or items allow sudden and unpredictable changes in location.

Unsurprisingly, the most frequent errors are caused by items or attributes that are designed to make ships more difficult to hit under perfect conditions.

A moderately-leveled nitro can create a burst of acceleration significant enough to cause a fair number of legitmate misses - and a fair amount of unregistered hits as well.

The speeder's small hitbox and high base speed combined with nitro makes it the most obvious and frequent beneficiary of unregistered hits. To a lesser extent, the enforcers agility and smaller size are attributes that were designed to allow it to dodge shots under perfect conditions. With this ability to suddenly change its location, the slightest miscalculation in lag compensation can send a shot meters in the wrong direction. The enforcer cyclone (rapid, full-speed circles) is a prime example of this.

How could the number of reduce Unregistered Hits be decreased, while also increasing game mechanic reliability?

Spoiler: Answer

I've included my thought process in anticipation of some of your responses.

1) How many unregistered hits do you see on Defenders? Very few, if any.

If every ship was the same size, speed, and agility as the defender, the vast majority of lag compensation errors would be slight enough to still register as hits. The 1-2 tenths of a second lag would not be much of a factor.

Would that be a fun game to play? Probably not.

However, there is probably a 4-500% difference in surface area between the hit box of the defender and smaller ships. Smaller boats could be scaled slightly larger, receiving hit points in trade, to lessen the number of unregistered hits and make the game mechanics more reliable.

Is this likely to happen? Probably not.

More realistically, hit boxes of nitro-capable ships could be expanded slightly beyond the visual dimensions of each ship to reduce the number of unregistered hits occuring on the outer most borders of those ships. I.e., if you see a "hit" animation, the damage is more likely to be registered.


2) Obviously, it would reduce the number of unregistered hits if the ability to suddenly change your location was reduced. The enforcer agility could be slightly toned down to prevent cycloning and the nitro blast effect could be cut in half and doubled in duration (i.e., think overboost with a shorter, more powerful effect).

This would be a logical step - to better match the ship abilities with the game's capability to properly register hits. However, yellow ships would require some durability adjustments to maintain proper balance. **THIS IS NOT A NERF YELLOW SHIP SUGGESTION.**


3) If slower projectiles (or projectiles in general) were significantly sped up, the game would become far more mechanically sound.

I understand that the ability to dodge slower moving shots is a great part of the game, but this aspect of the game has already all but been removed from the larger ships since the agility nerfs so it's not that terrible of an idea from a balance (and reliability) perspective.

 

Is there anything I can do to reduce unregistered hits (in the game's current state)?

Spoiler: Answer

A stable connection is the best way to reduce miscalculation errors and unregistered hits - and, assuming developers have the most direct, stable connection to their servers, this is likely the reason why they might be slower to recognize these types of issues.

Otherwise - in game - it helps to use faster projectile or splash weapons, or to get closer to targets before firing so there is less flight time to be miscalculated. Likewise, aiming for the mid section of the ship reduces your chance of a miscalculation or pixel variation causing an unregistered hit on the outer border of the target hitbox.

Unfortunately, the best thing you can do is accept that it's a part of the game (or all games some extent).

If it continues to bother you, I suggest using faster/more agile boats and items, and prioritizing attacking larger, slower boats to take full advantage of the unregistered hits they'll have on you and to reduce the number you'll have on them.

FAQ 2: SPLASH CIRCLES
Two things:

1) Even if all lag compensation calculations were perfect, the lag would explain some of the difference between the visual you see and the damage caused by the item.

Spoiler: Answer

Remember that everything you see actually happened in the past? When you see a projectile explode, keep in mind that the actual detonation took place a fraction of a second before; the actual fraction depends on your latency. It may appear that you've cleared the splash radius, but the damage was calculated at the server time it detonated - not when you see it explode.

Why can't they adjust the visual so it matches perfectly?

Prediction modeling of when and where things will occur before they happen is hardware intensive on the server and often leads to more inconsistent results (e.g. players would appear to teleport or skip each time the prediction model was slightly off, and small calculation errors would still cause inconsistent visuals for the exact moment of detonation). As a practical matter -- you're not likely sitting in a blast circle until the last second, so more accurate visuals aren't likely to reduce the amount of damage you take.

2) The splash circle isn't always accurate - by design.

Spoiler: Answer

Player are shown the splash radius at the time of launch .. but waves move .. as does exact location of the projectiles detonation.

If the splash circle is generated on the crest of the wave, then the projectile hits at a lower point, the projectile will have traveled further than the splash circle suggested - and vice-versa. Also, the further away the shot is launched, the flatter the flight trajectory, the greater the chance of crashing early, and the less accurate the initial projection of the splash circle. Why? All flight times are a set duration (unless they detonate early on a ship or wall).

In other words, you should view the splash circle as more of an "incoming projectile" warning rather than an exact depiction of where you'll take damage.


This screenshot was borrowed from a thread where someone took issue with the amount of duration taken from a FB. This screenshot is a split second before impact, but, you can see that the FB is not going to land in the center of the projected splash radius - even from this less than ideal camera angle.

Grenades are the best example of this. They have some of the most noticable, least accurate splash circles due to their smaller splash radius and more variable flight trajectory.

Random Side Note:
FBs, mortars amd napalm have different mechanics than explosive cannons and grenades.

Spoiler: More..

If a FB, napalm or mortar shot hits a wall or obstacle, splash damage is rarely recorded, whereas the grenade and explosive cannon still register splash damage after a wall impact. I haven't the faintest idea as to why (other than if some splash is calculated in two-dimensionally and some in 3-D).

Likewise, it's a curious choice to have mines and napalm disappear if they barely touch an overhang rather than deflecting or dropping into the water below .. Perhaps the physics calculations were too complicated to code.

Random Side Note 2: Missiles users.
Have you noticed how your missiles are OP at times and utterly worthless at others?

Spoiler: More ...

If you've used them enough, you've probably figured out ways to somewhat reduce the randomness intentionally coded into the missile spread .. but I'm sure you've also seen perfect missile shots directly on target that do minimal or zero damage.

Why?

Missiles are susceptible to lag compensation errors (like all weapons), but there can also be lag compensation errors in the missile spread.

Other than seeing the targets take zero damage, the best way to see this is in the server replay. You may have had a perfectly tight missile grouping in your live version, but the server recorded 3 missile shooting off to the right and 2 to the left of the target for little to no damage.

Long story, short: The randomness coded into missile spread should be removed. It's fine to have a set spread that increases with range, or to reduce their damage if they're too powerful, but these types of compounding errors should be removed from the game.

 

That's all from a game mechanic predictability and reliability standpoint - to reduce the number of hit animations that register no damage.


But, otherwise, I actually prefer my T2 epic nitro over my L1 legendary nitro on my speeder for maneuverability. It still allows me to dodge shots and mortars but doesn't send me careening into walls or mines.

Obviously, on open maps, I prefer the leg nitro (or the 4 cooldown slots on a T4 epic) to cover distances .. but I don't think it would necessarily be a nitro nerf to reduce the burst and extend the duration. It would probably be a welcome change.

 

Excuse the tangent, but you can actually mute the Nitro distance by dragging reverse as you hit it. I use that a lot while fighting against torp users, so I don’t get flung out too wide when I Nitro past them (which can obviously put you beyond their minimum range.

 

That was a very good explanation of the basic mechanics of the working game...
My hats off to you... Bravo... and Thank You,