Hitbox in Client or Server

What do you think is better?

Client Sided Hitbox

  • Hitbox is more accurate with positioning and hit detection (I think)
  • Being vulnerable to cheaters
  • Needs to be verified more
  • Removes some weight for the server
  • boost performance (I think)

Server Sided

  • Inaccurate sometimes with positioning and hit detection
  • More protected against exploiters
  • Takes more resources of the server
  • Much more easy to validate

Just want opinions and if you want, explain me what’s your process to this forum

Neither is inherently better.
It really just depends on your specific use case for your game.

1 Like

i would use a client sided and during any like interaction or whatever just send the data to a server sided script

1 Like

Client is better, it’s smoother and more performant, also you can simply security check it for distance and weapon stats like ammo, cooldown ect. no matter if cheater can do 180 no scope 1 kilometer shoot, because they still can adjust their camera and gain advantage, making hitboxes client side is way to go

1 Like

I have made guns for a while and I’ve done server and client systems and find client sided more reliable.
Client is the way, Almost every popular game has client hit detection. (CombatWarriors)

Just use a module script and send the data to the server and do checks on like a weapons firerate, bullet amount, or distance / range.

I am using this system.

The real issue with server-sided hitboxes is that you have to aim for where your enemy is on the server, not where they are on your screen. Any kind of time you need precision when attacking (basically any given game), well, it’s going to suck.

Client & Server hitboxes both have their drawbacks. Use client hitboxes if you want mediorce security (you can only do approximate checks on the server) & seamless gameplay smoothness. Use server hitboxes for high security, at the expense of accuracy. (laggier players will have a major disadvantage)

For your question, I’d recommend going with client hitboxes, because:

  • Attackers get a WYSIWYG (What You See Is What You Get) experience.
  • Depending on your implementation, they can also be quite secure. Trust the client as little as possible.
  • Most roblox games do it, and on the most part, they have no exploiter problems.

However: if you care A LOT about security and seamlessness, and willing to spend a medium-to-large amount of time, consider this:

Lag compensation

In short, lag compensation plays around with the 4th dimension (time) to calculate what your client should’ve been seeing at an x timestamp, fully on the server. This is done by interpolating between snapshots.

Various AAA games use this method, such as COD, Valorant, Fortnite, CS, etc.

I’m not the best teacher to explain you how it works, but there are countless articles and youtube videos on how it’s done.

I am doing something similar in my roblox game too, but I don’t recommend doing this if your game is already big, as it will require a lot of rewriting and studying.


Summary

Don’t do server hitboxes. It’s insanely inaccurate & massively nerfs laggy players. Either try to mix client hitboxes with alot of server sanity checks, or consider adding lag compensation.

Leaving this here to save anyone who would try to do this on Roblox some time. I have been working on a Lag Compensation system myself using this exact method. Sadly no matter how many snapshots you save (meaning no matter how accurate you make getting the player’s CFrame based on a timestamp), this system will never work because of one specific reason:
Considering you would get the timestamp based on Unix in ms and subtract the players ping, this would be inaccurate since there (currently and as far as I know) is no way to get the exact raw replication ping of other players’ movements, but instead only the player’s rough replication ping. This of course, from my experience working on this system, returns varying results where sometimes the system works very well and other times not so much. Now maybe you could just pass the server’s timestamp using workspace:GetServerTime() from the client to get the exact timestamp you need, except that wouldn’t work either since Roblox’s interpolation system for replicating player movement is not at all linear and mainly velocity dependant. Usually you would be able to calculate this interpolation, if it were any other game engine, but at the moment we don’t have access to any data on how movement replication is interpolated either, so that wouldn’t work.
There still is a few things that this system would be useful for though: Doing hitbox detection on the attacker’s client then checking if the position of the hit is close enough to the attacked player’s lag compensated position, at least in my use case it produced more accurate results than just using the attacked player’s server position.
Another thing would be using it for larger hitbox detection, the lag compensated position would always be pretty close to where the player actually was at that point in time, so it would always work for large hitbox detections, such as close combat punches and so on.

TLDR: Don’t waste your time making a lag compensation system using the roblox engine, unless you are going to use it for large hitbox detections, given its inaccuracy due to some engine limitations.

2 Likes

Actually, if you use custom replication then the lag compensation system will be 100% reliable (and actually really secure as well), since you know exactly what snapshots the client is interpolating from.

You can send the timestamp1 + (timestamp2 - timestamp1) * alpha, where the 2 timestamps are the 2 snapshots the client is currently interpolating from. To combat exploiters, you can set a serverside margin of a few hundred ms for the maximum lag compensated.

Here’s more info about custom replication in Roblox that could help.

That’s a pretty interesting approach, I guess it would be the simplest fix, as far as it goes for a custom positional replication system, I think it would be a pretty feasible approach to fixing this problem.