How do i handle Boss Fight Hitboxes? Client or Server?

I currently have a boss fight that handles hitboxes on the server, but even when i delay the hitbox and make it smaller to make up for the latency, the server still says the player got hit even though it clearly missed. I could make the hitbox further away but it would feel really unresponsive and inaccurate.

Although if i make it client sided instead of server it would be incredibly easy to bypass the hit detection, and this game will also be multiplayer/teamwork thing with progression so its kinda important to prevent exploiters

I have no idea how to make it feel smooth while having a way to prevent exploiters. Do i just accept the consequences for smooth gameplay or do i keep the server side hitboxes and let players deal with it? (it also feels so horrible to play when you have 300 ping)

Heres an example if you need more info, the green trail is the server position of the player

If you have a solution that helps both, please let me know :pray: or atleast give me an answer of whether i should choose client or server

3 Likes

Can I see the script? Are you changing position of the block every heartbeat to the player?

You can handle boss fight hitboxes however you want, just test it yourself personally to see if it works for you. There is no 1 way of doing things.

You should likely choose the server, as it can help prevent any exploiters from bypassing the hitbox system.

Although the server does have delays within the player’s movement, it is much safer, and can’t be controlled by exploiters.

Many games have similar issues like this, but many players have already adapted to this “delay” between the server and the client.

If you really want to not have this delay, a way to do this is you can set the hitbox parts’ network owner to the player, however this can be really wacky since if the player lags, everything in the part lags, including movement. This also gives control to exploiters, which is worse! So I don’t recommend this method.

2 Likes

On server, you can predict where the player will be by checking their velocity, this will help a lot in your situation considering your ping isnt that bad. Also you can just do hitboxes on client and apply proper sanity checks on server to prevent abuse but thats still possible to exploit.

Heyo!
Hitboxes are always a tricky subject. Do you prioritize security or smooth gameplay?

Let’s be real—no matter how tightly you lock things down on the server, your game will always be exploitable to some degree. An exploiter can still find ways to dodge hits, and most players end up stuck with laggy, frustrating gameplay.

I recommend a hybrid approach: client detection paired with server validation. Let the client report when it gets hit, and have the server validate that by checking the player’s position relative to their ping. Compare the client’s report with what the server sees, and if it lines up within reason, apply damage.

Most players aren’t exploiters, so don’t ruin the experience for everyone just to stop a few bad apples. That said, I’m not suggesting you hand the keys to your game over to exploiters—make sure you’ve got proper sanity checks in place to catch the obvious stuff.

7 Likes

also heres a very basic one, i might have messed up math behind this but it works?

hitbox.CFrame = CFrame.new(hroot.CFrame.Position + hroot.AssemblyLinearVelocity * 0.2) * hroot.CFrame.Rotation

hroot = character’s humanoid root part.
preview: (red = what server sees aka no prediction, green = formula up there aka prediction)


i’d only reccomend this if you are scared of your players all being exploiters otherwise use approach i mentioned before and @MapleTheParrot did 2 hours ago

5 Likes

I don’t have much to bring here sadly as I’m not that great at hitboxes, but I could say that if you decide to host the hitboxes locally you should add a remote event that fires every so often with the position according to the client, and then on the server do a quick check using some math with multiple infos about the player
(hrp is HumanoidRootPart and hum is Humanoid, my script was a bit rushed)
(also my math might not be the best, since it was pretty rushed but I hope it can give some sort of idea.)

1 Like

I can definitely try the hybrid approach but i feel like an exploiter can just remove the block of code that handles client detection, so im not sure how i can work around that. I wanna prioritize security but its probably for the best if i use your solution. Thanks!

It basically uses wait() to set the position in a loop and then delays another hitbox to create an illusion of them following. BUT If you mean the server hitbox then its basically like this

			while task.wait() do
				local part = Instance.new("Part", workspace)
				part.Color = Color3.new(0, 1, 0)
				part.Material = Enum.Material.ForceField
				part.Anchored = true
				part.CanCollide = false
				part.Size = chr.HumanoidRootPart.Size
				part.CFrame = chr.HumanoidRootPart.CFrame
					game.Debris:AddItem(part, .1)
end

I think you could check on the server how long the player stays waiting to have a hitbox or even use a remote event and if it exceeds a certain amount of time then flag that player, although you might want to take ping into consideration if you do it like this

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.