If one were to use client side hitboxes and server side validation, I understand server side validation for melee, you could use magnitude or something.
However, what if this was a projectile?
The client shoots, hits something on the client, and sends an event to the server to verify it. How does the server make that verification? What information does it need to validate it?
use the client to signal, use the server to validate
a skid can and will tell the server: yeah so i fired infinite projectiles and hit everyone and win the game
I mean more specifically, how does a server validate a projectile in this example?
projectile touch player = projectile hit
Yeah.. but if its client side.. hit detection there aint gonna be a projectile on the server is there..
How do you do sanity checks for that
Server needs origin, direction and velocity of projectile.
When client says a hit, calculate the position the projectile should be at based on these statistics and the time passed. Include the player’s ping to account for latency.
Check if the hit part/player is relatively near the server position of the projectile.
Couldnt i technically simplify this further more by sending only origin and hit locations.
Then i could check if the client is within a specific magnitude of origin
And if the target is within a specific magnitude of hit location?
And (optionally) a raycast between the points to see if theres anything obstructing view (assuming its hitscan)
i dont know if i understand what you’re saying but the projectile should be created by the server not the client, a common rule is to never trust the client, while the client will tell the server it wants to fire a projectile (through a remote event), the projectile shouldn’t be created on the client and controlled by the client
edit: oops didnt mean to send
from what im gathering you want to make the projectile on the client then tell the server when it hits and where it hit but this isnt a good idea since an exploiter can just pretend that their projectile hit anyone. you can set network ownership but im not sure if this is what you want
So long as you aren’t like using gravity this will work. If the bullet shot can change though for any reason then this is insufficient for perfect accuracy.
As for detecting hits on players. A lot of games actually will record the position of every player over time, and when a client shoots it will look at the latency of the client and look at where the people were at the time of shot and check against a copy of their outdated position which should very closely match the state all the players would have been in on the clients side when they pulled the trigger. Then as for what the player sends, it’s just the shot origin and direction and the full hitscan is ran on the server while playing back the motions that already happened to account for time (if applicable).
The client can send malicious hit location and fire hit instantly without needing the projectile to travel. AntiCheat will be better with Velocity and Direction.
Ideally don’t bother with client sided projectiles, while it might sound nice and feel responsive on from the perspective of the client that fired it, replicating a fired projectile will take two pings to transmit to other clients when and where you fired it, on top of all the sanity checks and risks it brings. I suggest just doing it all server sided, all clients see the same thing and theres no worries about extreme validation. The difference is almost negligible from the moment you click to when the projectile is fired as long as you’ve optimized the rest of your games network usage ofc.
You can do this, too. The server could handle all hit detection and the client could predict things instantly with a visual. Its the method that games like BedWars use, and it works fine unless the player’s ping is just abnormally high (think 800 - 1000 ms)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.