Better way to do hitbox validation?

So, I’m working on a project similar to Super Smash Brothers, with abilities, dodging, air-jumps, knockback… etc. I have the current game structure as:

  • animations, hitboxes, and visual effects are done on the client
  • hit validation, cooldowns, etc… are done on the server

As far as I know, Rollback Net-code seems to be the best method for most of combat games that are somewhat fast paced. I have a basic implementation of rollback net-code in my project, but it seems to be inaccurate…?
I have the client create the hitbox and check for characters inside of that hitbox, once it detects a character, it sends a signal to the server and pass in the time of when that client detected a character (using workspace:GetServerTimeNow, I have no idea if it’s the best approach, but it works). The server takes snapshots of every single player ingame, recording their positions, bounding boxes, etc. After receiving the signal from the client, the server will get the closest snapshot to the one that the client sent, check if the hitbox from the client is intersecting with another player’s bounding box, if it intersects; deal damage and broadcast it to every player to simulate visual effects. The issue is; when playtesting on 100ms ping (or 0.04 “Incoming Replication Lag”) since that’s about the average ping I usually play at, the validation just keeps missing when either player is moving fast and is playing on high ping (shown in the gifs below).

BLUE IS SERVER HITBOX
RED IS CLIENT HITBOX
PINK IS DUMMY HURTBOX
[1]:
m1_delay_mishit
[2]:
dashing_mishit

Now because Super Smash Bros is a fast-paced game, this might happen a ton of times.

I was wondering; is there a better or more efficient method to validate client hitboxes?

1 Like

maybe just do a distance check using the player’s ping

either way, YOOO SMASH BROS GAME EPICCC

1 Like

What do you mean by a distance check?

Sanity checks are hopefully already covered by the rollback net-code, but it seems to be inaccurate to a point where it’s almost unplayable. Just trying to find a way to make it more accurate haha

Hello there!

Watching the video i saw that you have a tiny delay between pressing the attack button and creating the hitbox. I think the server is creating the hitbox at the position when you pressed the button, not when the hitbox should spawn.

If i’m right about the delay, I think you can fix this by sending the request to the server when you spawn the hitbox (I imagine that the actual code sends the request at the moment that you attack)

Another thing that might help is to make the server weld the hitbox to the player, so it follows the rotation (as the red hitbox)

Hope it helps ;]

Hello!

So, the signal is sent right when the client detects a character inside of the hitbox, and the hitbox is spawned upon reaching an Animation Event (which is a moment after the animation starts in this case).
Welding the hitbox to the Attacker wouldn’t be ideal since the server’s job is only to validate that the hitbox actually hit any character, at all.

Thank you for your help, greatly appreciate it! :+1:

I asked not so much time ago about cheaters using getNetworkPing() and i’ve found solution to this cheat

See, you can’t predict if player is facing in specific direction without doing heavy math and without making your anti-cheat false flag every move, so you can do other sanity checks

Getting Player’s ping

Instead of checking for player ping every time we hit, we only use saved value, this value will be saved each random interval (30-60 seconds is best) so that cheaters couldn’t spoof their ping that easily

Because cheater can’t predict when the next save will be, and even if he managed to detect call of the event, it might be simply too much work to do it, thanks to random interval, cheater also cannot set their ping to high and then low instantly, making it even harder to perfectly calculate moment to change ping

Now you can use ping-compensation

Simple distance check

This one is obvious one

Anti cheat

Create anti-fly, anti-speed, anti-jump and anti-noclip to make cheating harder, this helps other anti-cheats to be more effective

Use State Machines

Although they are mostly used for NPCs, they are also great for anti-cheats, let me explain

Let’s take a gun system as example:

  • We have rifle
  • Rifle loads ammo bullet by bullet
  • Player can’t sprint when reloading

Now, if we had animation that loads bullet, we had to listen to keyframe reached on client, and send remote to the server, let’s say there is a remote in gun system that sends specific data, but it might be not that secure, this is why apart of value checks like ammo and if gun exists, we perform state check

First of all, player can’t add ammo if he isn’t in loading bullet state, but he can’t load bullets if he isn’t in loading state

Also player can enter loading state only if he had opened the breech and isn’t in sprinting state or aiming state

Reloading also stops when player sprints

And at the end, player can only sprint if he is in “none” state or in aiming state, but when there is aiming state it will stop

This way if cheater had ammo and gun, but was sprinting or aiming, ammo wouldn’t be added, because he need to press R to reload, and when R is pressed the reloading starts, we can add Action/State system, so that after each action another happens

In sword case, you can check for attack state, and then check if action is swinging sword or maybe returning (idk how to name it) and determine if damage should be done, because state will be changed instantly from swing to return when damage was dealt, player wouldn’t be able to spam requests, avoiding unfair advantages

Perform value checks

This one is also obvious, check if player sword isn’t on cooldown, have enough points or isn’t nil (you can save os.time every time you switch from idle to attack state, and have condition so that attack can be only dealt when debounce ended, easy to do with OOP)

With those 5, you can pretty much avoid cheaters, or make them gain little to no advantage over normal players, and making your game better

I wish i have helped, good luck with your game

1 Like

Hi!

Thank you for the help, I’ll be sure to note them and try to implement them in my project!

Although what you listed was good, it still didn’t solve my issue which was the inaccuracy of ping-compensation which caused hitboxes to miss on the server, even though it should’ve hit on the Attacker’s client.

Cheers!

1 Like

Your problem is that you validate hitbox on server, by validating it on the server

See, you can’t predict when client will be without heavy math, this is our main problem, but you really don’t need server sided hitbox validation, as there are other methoods, such as those i listed above that will work and provide you with the same results

Don’t Trust The Client is outdated, instead you should aim to nerf cheaters as much as possible, so cheating is simply useless

1 Like

So, what I should aim for is just adding anti-cheat on the server, instead of relying on it entirely to check for hits?

use security checks + some basic anti cheat instead of relying heavily on server

Remember that cheaters have patience too, and if something is too hard to cheat or give them little advantage, they wouldn’t attack it, even client-sided anti cheat you’ll update frequently can do well against exploiters who write scripts, who wants to change one line of code every week only to do it again and again?

1 Like

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