If they were highly responsive then nobody cast their hitboxes on the client lol there’s a reason people have to offset the hitbox instance they cast when they do it serversided
People do client side hitboxes to accommodate ping.
Huabauwhekeusuakakw wowowkwowkw Womp
Just because byfron exists, doesn’t mean exploits are impossible. As of currently, I still am seeing mobile exploits.
Mobile exploits are useless lol
I know its a bit late to reply to this thread, but I am going through a process of reworking hitboxes and came across this post. I agree with what you stated earlier about latency on the client. The two types of hitboxes create common issues like allowing players to hit opponents that would seem out of range on their screen, and server sided hitboxes not registering a client’s position properly when they have high ping. I believe the solution is to use client sided hitboxes when a client’s ping is under 100ms and then use server sided hitboxes when ping is above that threshold. To make server sided hitboxes more accurate, you could also try to use latency compensation by using GetNetworkPing() and a character’s velocity at the time of spawning the hitbox, and then calculating where they would have been at the time of the attack.
Using client sided hitboxes when on low ping would be redundant. Server sided hitboxes are more accurate at lower ping, so reserving server sided hitboxes for high ping situations would be counterproductive.
Respectfully I would say it comes down to the type of combat being used, your statement may be true for a slower paced combat game, but in a game with high paced combat where players are moving very quickly, such as a superhero game where players could be flying at high speeds, having client sided hitboxes on high ping players will seem as though low ping players are being hit out of nowhere. Wouldn’t it make more sense for server sided hitboxes to be for high ping players with added lag compensation (i.e. taking the hitbox and moving it forward at the player’s current velocity with limitations to how far it can go) ?
I stand by my previous statement. Generally speaking, client-sided hitboxes are useful for getting a better player experience regardless of ping. However if a player already has a low ping, the difference between a client-sided hitbox, and a server-sided hitbox is very small. While I don’t recommend using client-sided hitboxes for high-ping players, for the same reason you mentioned. If your goal is to improve user experience, it doesn’t make much sense to use server-sided hitboxes for high-ping players, as the hitboxes will be significantly delayed.
Server sided hitboxes are WORSE
That sounds unnecessary and not a good idea in general
When ur faced with the dilemma of ping, which is an issue for any game, i will always cater towards the larger portion of the playerbase, meaning low ping
Moreover using serversided hitboxes are just not performant
Its spamming remote events and running unnecessary functions on the server
Bu hao bu hao
You may get a slightly better player experience with client-sided hitboxes, but you open up yourself to various vulnerabilities. Server-sided hitboxes are not worse.
“Better player experience” is all i needed to hear meow
Krampus shutdown and its pretty easy to detect client abnormalities, plenty of games have anticheats that detect as soon as you even attach an injector
But sure u can take the easy route and have a worse user experience (and worse optimization, with a host of other cons) i don’t really care
Arguing that plenty of games instantly detect exploits upon being injected is silly.
Yes, some games detect some exploits upon injecting. This is however not the case for all exploits.
The key note in my comment is that you get a slightly better user experience, in return for making yourself vulnerable to exploits, that may, if exploited, worsen the user experience far more than you improved it to begin with.
Whether you use client- or server-sided hitboxes is not only a matter of preference, but also heavily depends on the type of game, and the type of hitboxes. The point was, neither is inherently inferior to the other, both are valid choices in their specific use-cases, however server-sided hitboxes are a safer recommendation if you don’t have the details of what context they are going to be used.
Server-sided hitboxes are not the “easy route” either, as both server- and client-sided hitboxes are effectively the exact same implementation.
client side, do sanity check in server, it gives it more accurancy, it puts less stress on server. Trust me its worse feeling to see your projectile hit someone and deal no damage just bec of lag or just pass through them.
if its cheap to use like raycast using guns then server is fine.
So for example if you had a game like block tales, where the combat system which is PVE, you’ll use serverSide checks?
you always check things serversided; it makes no sense to do it on the client
thats the only way to make things balanced
and just to go back to this whole argument:
theres a time to use client-sided and a time to use server-sided hitboxes
lets say you have a sword-fighting game where many players are fighting at once in a dense area-- client sided hitboxes would generally be the route to go here because itll put exponentially less load on the server and would still feel reactive to players
now lets say you have a dueling-game, where your servers might only be hosting 4-8 players fighting at once at a single time-- server sided hitboxes are definitely a possibility in this case; server sided hitboxes are objectively the most fair hitboxes, but they are less performant and for the most part, less reactive