So. I’ve heard that a client-sided hitbox system that sends information to the server so it can decide who hits who is the ideal hitbox system for a PVP-Centric game, allowing the responsiveness of the client and the anti-cheating measures of the server. (I could be explaining this VERY poorly, but bear with me here.)
Is that sort of system worth it in a server-authorative engine such as Luduvo, though?
I ask this since the server controls the position of the player, the physics, and a lot of other things that other platforms (such as Roblox and P*lytoria) simply allow the client to handle- such as one’s walkspeed, and the player’s position.
Seeing that the Luduvo client takes the server’s word as gospel, would it make more sense to ditch the client-sided hitboxes altogether in favor of the truth of the server? I don’t really have a lotta experience when it comes to server-client hitboxes.
Lag. It depends on the game and what you think is fairer (attacker-biased PvP or defender-biased PvP), but the main reason I’d still use client-sided hit/hurt boxes is that it would mean there wouldn’t be lag when you make or evade attacks. Even though positions and whatnot are validated (though not controlled) by the server, it still takes time for the validated move to be sent and replicated to all other clients. As such, an attacker with bad internet could “miss” hitting their victim even if it looked like they landed the hit on their screen. By the time the server catches wind that the attacker wants to attack their victim, the other dude could have already told the server that they aren’t in that attacker’s hurtbox/range anymore.
Of course that’s not necessarily a bad thing and can even be seen as a means of balancing depending on the kind of game you are trying to make. But generally, you’d want at least some protection against this sort of thing one way or another. Normally what competitive games do is have the server store some arbitrary number of “lag-compensation frames” by storing a movement/action history of every player in the game for the last X frames. Then, when the attacker attempts to attack the player and sends the server data their hitbox data, the server checks whether the attack would have hit the victim in at least one of those lag-compensation frames, rather than just checking the victim’s current position. That would be “attacker-biased” PvP. The reverse could also be true, where the server instead checks the victim’s previous frames to see if they did anything to dodge/parry/etc. the hit that they would have otherwise eaten thanks to lag messing up the timing of their evasion. That would be “defender-biased” PvP.
And then the other reason why I’d still want client-sided hitboxes is so that things like hit feedback happen immediately and there isn’t a long pause between it
Ahh, okay. I see! thanks for the clarification!
I forgot to link this, but if you want to read more about how competitve games do hit detection, Valve has a good writeup on it since they basically invented it.
1 Like
Valve being goated as always, I see. As are you.
It’ll be a while before I need to use this, but thank you as always, Jedi.