Hi everyone,

I'm working on a game where players fight as wizards. The issue I'm facing is detecting hits on entities from spells.

There are two scenarios I've been thinking of:

Scenario 1 (client detects hits): Player 1 has 10 second latency, he hits an entity on his screen, the hit is sent to the host and the hit packet is sent to all other clients. These clients render the hit on the entity.

The issue with this scenario is that if the entity moves on the host while the hit is being sent from player 1's machine, the spell with go past the entity on the other clients screens, but the hit will still register. This would look weird. Think of a bullet going past a guy but the guy still takes damage.

Scenario 2 (host checks client hit): Player 1 has 10 second latency, the player hits an entity and sends the hit to the host to confirm it. If the projectile hits the entity on the host, a packet is sent to all players and confirmation is sent back to player 1.

The issue with this is that players with high latency will not be able to hit entities, but it solves the previous issue of spells flying past entities and still effecting them.

So it's either improve combat for all users but have users be unimmersed by "ghost" hits, or have harder combat but hits actually collide on screen.

I was wondering if there is a work around for these issues or if I just have to take one as a trade off?

Hi, the way I do it is that when a client receive the information that a "firebal" for example has been triggered by playerA to playerB, the projectile will be spawned on each client and will be forced to travel toward the moving playerB. THis is not perfect but is effective. So projectile will not really travel in a straight line and it's not barely noticable in combat. I just have a loop that updates the project position and make sure it will visually hit the target even if it has moved since. Not entirely sure if this answers your question. Good luck!

Evil_Lootly said:
Player 1 has 10 second latency

That's not latency. Latency of 30-100 milliseconds are typical across a continent, Tokyo to London is generally under 300 ms, Earth-Moon-Earth latency is under 3 seconds.

If it is taking 10 seconds for your messages to go through, that is due to problems other than latency.

Evil_Lootly said:
Think of a bullet going past a guy but the guy still takes damage. … I was wondering if there is a work around for these issues or if I just have to take one as a trade off?

The keywords for search is “latency mitigation” and “lag compensation”. Removing buffers, immediately processing data rather than scheduling, and rewinding server time are all typical techniques. Having an authoritative server handling disputes between machines is pretty common.

For projectiles specifically using non-instant firing is a common approach because it mirrors real life. A real-life high power sniper bullet can take a long time, even multiple seconds, to reach a distant target. Muzzle velocity is the moment it leaves the barrel, but because bullets start out traveling faster than sound -- faster than air can move out of its way -- they quickly drop to sub-sonic velocities. Plus weapons have something called “lock time”, a few milliseconds between when the trigger hits the spring-activated click and when the explosive starts detonating, and another chunk of time while the bullet is accelerating due to all the pressure. And there is the action of actually squeezing the trigger, often animated in games that buys up a few graphics frames, which can be the round trip communications time. Depending on the game some players complain about guns not being instantaneous but others understand the realism that bullets don't teleport to targets instantly. Drawing an image of a traveling bullet or moving fireball also helps players visually interpret the world, which many players appreciate, especially when they're on mic and see a bullet barely miss them, and hear the cursed missed shot on the headset.

In the end no techniques can make it “perfect”, you can't beat the speed of light, nor the speed of electric signals.

Ahh, a good solution may be according to me is to use client-side prediction with server reconciliation. This allows the client to detect hits immediately for responsive gameplay while the server checks if the hit was valid based on its authoritative state. If there's a discrepancy, the server sends a correction to ensure accuracy. Additionally, lag compensation can help by "rewinding" the server state to account for player latency when checking hits, allowing hits to still feel fair for high-latency players.