How should I make hitboxes?

Help and Feedback Scripting Support
#1

So I am about to work on combat for my game and was thinking about a couple of things.
As we all know ping is a thing, so if I fire a raycast on the server, and the thing Im trying to shoot was moving, it’d probably miss, which makes aiming hard ig.

So I was thinking, heck we do it on the client, and then do it on the server, to ensure that it went about the same way ig.

And same thing for like melee weapons, I got a hitbox on the client, and if a player is in it (cause I use GetPartsBoundInBox), then I check on the server to see if the player is actually that close ig.

Anyhow just wondering how I’d go about the server checks, do I check to see it what the client hit is in a certain range of where the client says it is? What are your thoughts? Thanks!
~ Frodev

2 Likes
#2

A magnitude check will be enough, maybe on the server raycast between the plr and hit to check if there’s geometry between

What would be more difficult is making sure the player isn’t spamming the damage remote, just check the tick between attacks when the attack starts I.e

ComboStart.OnServerEvent:Connect(function(plr) --something like this
    if tick() - plr.OldComboTick > 0.1 then 
        PunishExploiter(plr) 
    return end

    plr.Secure = true
end)

Damage.OnServerEvent:Connect(function(plr)
    if plr.Secure = false then
        PunishExploiter(plr) 
    return end
   --then damage the hit player
end
2 Likes
#3

Luckily enough Im ready for anyone who dares try spamming such greatness!
Anyhow yeah a magnitude check would probably work, how close should I check to see if the hit thing on the client is to the hit on the server?

1 Like
#4

it depends on the weapons range. Have the magnitude amount in a value in Server storage and have it be based off the weapon

1 Like
#5

You ask for hit boxes and then hit us with the double whammy of how to secure the attack

Hit boxes can be achieved by just welding a collide-able invisible box (except for the player themselves) to the players humanoid that contains the size of the player. Make sure for a combat game especially PVP that all players are the same height no matter what! UGC can make this kind of tough, but I believe you could iterate through the meshes and rescale them/delete them. Unless you’re using a custom character then great!

Putting a hit box to check if other players are in it (not a hit box but a query box) is an interesting move for melee attacks, but there is an exploiting concept called nuking. This will essentially allow any player to do that without exploiting
Thank you
I an Steve

1 Like
#6

Ah thanks for the pointers! Dont worry about ugc, I have complete custom characters so its no big deal lol

1 Like
#7

So this post is actually asking about server checks, not how to make hitboxes? Well, in that case, there’s two main things to do:

First, you want to watch when the client calls their hitboxes. If you user serverside attack logic (C. Input → Server Logic → Client Hitbox, instead of C. Input → Server Damage), then you have the advantage of knowing exactly how many hitboxes to watch for at a given time. Just disconnect whatever’s listening for the damage function once it passes through. You could also try creating new remote events for each active hitbox, but I haven’t tried that method myself.

Then there’s a magnitude check to make sure the client isn’t trying to hit a target from a billion miles away. Ideally, you’d take what their velocity should be (not what it is, incase they’re speedhacking), leniency you think is fair, the time it took to recieve the event, and the size of the hitbox to create the perfect radius for your sanity check. But most games settle for just double the attack’s radius.

1 Like
#8

I agree, but I recommend doing the hitbox immediately on client input instead of making it go to server logic.

#9

That would depend on the type of hitbox. If it needs to be (or feel) instant, like shooting a gun, server logic should be skipped and hitboxes should be done immediately. However, if it is like a shooting a gun, then the effects must be replicated and from there you can essentially deny the request.

But for an attack with even a small (0.2s or longer) windup, you can actually negate some of the latency using a specific method. Essentially, you fire the remote event that tells the client to create the hitbox early, but you also include an argument that tells the client the time to wait and the clocktime. Using the clocktime, you can figure out how long it took for the event to reach the client and subtract that from the time to wait, effectively eliminating one unit of latency.

#10

There’s no point to process it through the server if you’re gonna use the client for hitreg anyways (Client should be used for hitreg unless you implement a perfect hitbox-rewind lag compensation solution)

#11

The attack may change depending on values that can only be read by the server or functions that can only be preformed on the server. For example, a wand shoots a random attack that must be determined on the server otherwise exploiters can always fire whatever spell they want.

Also, server logic makes it far easier to know how many active hitboxes a client has at once. Your attack tick solution only works if all attacks hit instantly. What if two or more projectiles happen to hit at roughly the same time? It also fails if an attack rapidly hits a target multiple times.

#12

The attack tick system is simply for cooldowns, nothing more.