Im so confused on what to do. Whenever i make hitboxes like meele hitboxes that use spatial queury like :GetPartsInParts it always ends up behind me and delayed. Example;
Client fires remote even and from the server it makes a hitbox and gets the characters hit and deals damage.
But if i make it on the client its exploitable. So i thought of making 2 on the client and server. The server is specifically for dealing damage and the client is for effects but the hitboxes wont be in sync. What do I do and what do those big games out there do?
I’d suggest you do the last idea you described, but on the client have a hitmarker (or form of it) that appears and plays a sound as feedback from the server verifying the hit. So you could have blood effects and stuff play immediately, but wait for the server to verify the hit before you display the hitmarker.
Because lag can cause the client hitbox and server hitbox to be desynced (in different positions, or other inaccuracies), so having verification that the server hitbox was successful indicates that that person actually got damaged. The client hitbox should only be for effects, not dealing damage directly.
I’d recommend making the hitbox on the client to keep gameplay smooth, then sending whatever is hit to the server for sanity checks. e.g: “Is Player1 Withing X Studs of Player2?”, “Was the last hit within a reasonable time frame?”, “Does Player1 Have the Weapon in their inventory?”, stuff like that, then only do damage if they pass those checks. Of course It wont be unexploitable but it’ll be more difficult for hackers and will be better than having nothing.
It depends on your system but usually It would only take 1. Just fire the event from Client to Server when they hit something then do your sanity checks on the server. If they pass then do damage, if they fail dont do any damage. If you then wanna tell the player their hit landed properly or how much damage they did you can fire the same event from the Server to the Client. Then display that info with .OnClientEvent
Hey, the way we handle hitboxes in Space battlegrounds for the rewrite is pretty simple. I am a math guy, so I decided to use a lot of math.
I wrote a lightweight entity system to deal with players and weapons. The reason I did this was to allow me to render just the humanoid root part on server and the effects, characterskins, weapons ect on client.
Now, at any moment I can detect any collisions around the hitbox by using some vector math. Simply put, form a box around the character on server using geometry, solve for their displacement and predict where they are going for better detection using calculus, and do the same for the weapon.
So, at that stage, all that is left is enabling collisions. Now, as for server, you can assume the client is always wrong, but using that logic, we can simply render anything and everything on the attacker’s client regardless of if it hit or not. I say this within limits, assuming you use standard raycasting on the sword, 9/10 you will have correct detection. If you don’t well, that isn’t really a problem because the server replicates the collisions. So, really, the only way to cheat is to fly around and swing your sword, but then again, you can detect that on server.
By the way, you can use UnreliableRemoteEvents to make the events fire with generally lower ping and less network usage. This comes with the tradeoff of the events not always going through, mainly on bad connections.
You can use this for the event telling the player that their hit was successful, since it’s purely visual and isn’t too important. This should help with that issue
I used to design games with the mentality of putting everything on the server-side to dodge exploiter cases, but that only makes your game look, and feel terrible.
Personally, what I’ve done, is trust the client for said inputs regarding their actions, and not server related ones. If you’re making a system that the server can totally handle on it’s own, and it won’t impact the players experience, you can stick with the server.
As for Player related inputs, it’s best to let the Players client take some more of the control so your game feels fluent, even if the results of their inputs end up slightly delayed. The visual feedback, and feel of the experience is what matters, and is what often leads to dislikes and such.
Do what you can to mitigate cheats, much like @St1zz has mentioned, but don’t go all out on safe guarding, because the purpose of a game is to be fun, and if it’s not fun, it’s not a game.
The way you update the hitbox on server is by recalculating the entities hitbox every frame. You would use the math I mentioned. You simply form a box around the character.
when you create a hitbox on the server and set its CFrame equal to your character’s, it appears with your character’s CFrame “on the server”
What you see on your screen (client) is your “local” character and the hitbox “on the server” therefore, they will never be synchronized.
However, other clients can only see your character with the server data, so for them your character will be coordinated (synchronized)
with the hitbox.
I invite you to carry out a test where you create the same hitbox from a localscrip and from a script. On your screen (client) you will see that the local hitbox will be
perfectly synchronized while the one on the server would be out of phase. But, if you see it from another client’s screen, you will see something different,
The server hitbox will be coordinated while the local one will not.
Please let me know if I’m wrong or not. I have already done these tests several times and always find the same result.
To do this you will need to publish your game and enter to play with two clients, it can be your PC and a mobile
Ive actually mastered this topic a while ago and ive gotten my answer. I made this post a long time ago when i was struggling with network communication but ive gotten the grip of it. Thanks for your answer.
There are 2 options you probably have either having hit detection on the server or client. Each have their pros and cons. Having hit detection on the client is way better and feels more responsive. But it comes at the cost of possible exploits but they can be protected by doing checks on the server. Having hit detection on the server makes it more reliable but comes at the cost of latency, janky feel, and in general not good for fast paced games or any in general.
Example of what games with fast shooting combat do when making a gun: when the player clicks the mouse it shoots a raycast on their client to their mouse position. If the raycast hits a character then the client sends the data of the hit character to the server where the server does a sanity check. For example the player is in range or their character is facing the hit character. If any of those checks dont go right the server can choose to end the function early and refuse to deal damage and replicate the bullet. But if it passes all the checks you can deem the clients hit detection as right and deal the damage as well as replicate the projectile to other clients via remote event
Basically:
Client: does the hit detection and then sends the server the hit character if any via remote event.
Server: recieves a hit character from the client via remote event which all go through a quick check to see if they are valid and can actually be hit.
Server: deals damage to the hit character and replicates the bullet to all clients via remote event or unreliable remote event.
In conclusion hit detection is better on the client since it saves performance and has a better feel. Roblox isnt a game engine which was made for fast action or combat in general but at the end of the day we have to make do with the resources we have.