Client-Sided Hitbox or Server-sided Hitbox for this combat?

I have a fireball that shoots, all the vfx is done on client using FireAllClients, should I do hitbox on server or client?

Can you be a bit more detailed?

Depends on who the fireball is being fired from. Typically, the detection should be done on whoever initiated the attack e.g. the one who shot the fireball. This may seem unsafe, as if a player initiates the attack they could just spoof the results and say everyone got hit, so you’ll have to do some checks on the server (which you’d have to do anyways to account for latency).

If your fireball is being shot from the server, do the checks on the server and account for uncertainty in position due to latency.

How would I do checks on server then? or What should I check

Simple magnitude checks to see if the player is actually within the fireball would do. You’d then let their position vary with respect to their given latency and see if they’re still in the fireball’s radius. If not, see if the distance is significant and deduce whether or not they should be counted as hit.

You should always do hitboxes on the server. It does cause a bit of delay, but doing hitboxes on the client exposes your game to a bunch of exploits. If you let the client manage hitboxes, but do a magnitude check on the server, you might as well do the hitbox on the server to begin with.

1 Like

then should I do my fireball vfx on server too because the server hitbox is not at the same position as the fireball

You should keep VFX on the client as much as possible.
If it’s because you are using .Touched as a hitbox, consider switching to something like Shapecast.

Definitely disagree especially with a projectile— youd be better off casting on the client and then just doing security checks

If you do the hitboxes on the server, you might get visual inaccuracies when players have high ping.
If you do the hitboxes on the client, but do checks on the server, depending on the strictness of the checks, high ping players will either have a huge advantage, or be unable to hit anything at all.

In what example? Ive never had this problem

First image shows a strict range check. The high ping player cannot ever hit the target player, because for their client side hitboxes to land, they need to aim at them, however if the server makes a check, the hit will be denied. If the high ping player aims ahead of where the player appears to be on their client, the client side hitbox will miss, despite them aiming at where the server considers the target to be.

Second image shows a non-strict range check, where despite the large difference between where the high-ping player is firing, and the actual location of the player, the hit still connects.

2 Likes

Couldnt you just check the range on the client and then if its valid u fire the event

The security check? On the client? That would literally achieve nothing, as you are comparing the client to itself. And it would also be insanely unsecure in regards to exploits.

1 Like

Honestly i dont really care about exploiting when byfron exists now, and even if it didnt, id still do it on the client and focus other directives towards anticheats— in other words, id sacrifice some security for the massively increased reactiveness. The case of “extreme ping offset” that u described would not be a good experience on either users side, really. The hit player would be getting hit from a ridiculous range in a serversided check :man_shrugging:

Just as you said, in the case of extreme ping, someone will have a bad experience.
If you do the hitboxes on the server, that person is the one with the high ping.
If you do hitboxes on the client, that person is the one with the normal ping.
And if you do it on the client, but do security checks on the server, it will still be the person with high ping, but their experience will be even worse.

Not caring about exploiters because of Byfron is a huge mistake, and extremely shortsighted. Exploiters very much do still exist, and you have no idea how Byfron is going to hold up in the future.

Seeing as players connect to experiences based on the serverlocation that will generally provide lower ping, im not sure why u would accommodate for the high ping player? Its unfortunate that their experience will not be as enjoyable, but is that not the case in 99% of all videogames on any platform? Casting on the client will be immensely more reactive and will, in most cases, be tailored toward the broader audience. It can be equally secure if checks are made on the server, and anticheats are in place. And trust me im fully aware of exploiting lmao

You are contradicting yourself.
I am not accommodating high ping players, you are.
Doing the hitboxes on the server will have very little effect on players with low ping.
Doing the hitboxes on the client is only ever done to accommodate high ping players.

Ok, no. Hasnt the premise of ur argument literally been, client-sided hitboxes and server-sided checks will be bad for high ping players? Or am i misunderstanding the diagrams you sent

And nonetheless the clientsided hitboxes are just better for user experience. Theres a 6-year old melee system that hundreds of people still use, that has a 12 stud range check and client sided hitboxes. Nobody complains, because the inputs arent delayed, and because, when your ping is 400ms compared the average 50ms, how can you not expect there to be some sort of drawback?

The entire reason anyone uses client-sided hitboxes, is to avoid issues when at high ping.
You are arguing against your own case.

Server sided hitboxes are secure, and have high responsiveness, for low ping players. Client-sided hitboxes are specifically used if you want to accommodate high ping players.

If your hitboxes are client-sided, with server-sided security checks. Depending on the strictness of the checks. Will either heavily favor high ping players, or have similar results as server-sided hitboxes, but with high ping players experience being worsened with no payoff.