Is this a good way to do client-sided hit detection?

Help and Feedback Scripting Support
,
#1

I’m experimenting with client sided hit detection, as I hear it’s better for performance reasons. My current plan is this:

  1. Client input, fires to the server
  2. Server does cooldown checks and whatnot, and I set a variable as a Vector3, as the hitbox’s intended size.
  3. I fire to the specific client, and they make the hitbox and do hit detection, firing to the server once if the hitbox detects someone.
  4. The server opens up a temporary event so the client can tell the server if the hitbox hit anyone, and closes it at the due time (to prevent like, a hitbox that stays active forever).
  5. The server compares the two positions of the characters based on the size variable mentioned earlier, using magnitude.

Would this be a good way? What faults could there be? And are there better ways?

3 Likes
#2

Why can’t you just handle hit detection on the server?

Performance would probably be better, but it could be better.

You should use the server to handle important stuff. (i.e, hit detection.)

2 Likes
#3

Along with the other things the server has to handle, server sided hit detection could cause a bit of lag. Take a look at the game Black Magic II as an example. I’m confident they use client sided hitboxes, and yet it’s still quite laggy there. More lag could make the game less interesting and reduce the amount of people who play.

1 Like
#4

What are you using the hit detection for? A sword? A rocket launcher? Are you using .Touched?

1 Like
#5

No, I’m using that one :GetTouchingParts() trick, as well as magnitude for spherical hitboxes. The game I’m making is a class fighting game, similar to the game Black Magic II, or Strife.

1 Like
#6

The way I track everything client side is > Client fires to server > server checks which request it is ( which is looking for the specific skill) > Server then fires to client > client sends information to a module and in the module I create the skills. You cant use touched client side obviously so I use a combination of raycast and magnitude > I wouldn’t recommend region3 due to hitboxes always being super unreliable with specific detection. An basically I use a spawn function and loop through the workspace to check for anything matching up with the magnitude then raycast the distance between the person and part thats supposed to be damaging. After that if the part is in range I either do 2 things. 1 ill fire a remote to deal the damage, or ill damage client side and then fire a remote after damage has taken place checking the humanoids health to see if its equal to 0. I mean theres a lot of ways you could go about it. I’m not saying this is the best in any way, but thats how I typically do things.

2 Likes
#7

Important stuff should always be handled on the server, hit detection usually doesn’t cause lag unless it’s optimized poorly.

Just handle hit detection on the server, anything client-sided can be exploited.

1 Like
#8

Having Client #1 > Server > Client #2 > Server will have some flaws.

Issue one is latency. If everyone had a ping of 0 ms communicating between 2 clients and the server would not be an issue. But since players will have a delayed connection every additional player in the chain of a high paced combat game will make for inconsistent hit detection. Their is a good chance when Client 1 inputs a hit, Client 2 will already have moved away from the location.

Issue two is exploiters. If you give 100% trust in the client to determine what hits and what doesn’t hit expect a “God Script” to be one of the first things exploiters will be using in your game.

3 Likes
#9

Exactly, which is why I’m using the server to do sanity checks? I’d like the best performance possible, and doing hit detection on the server causes some wacky things to happen. If the client were to attempt and increase the hitbox size to a ridiculous amount, the server would know. I honestly do not see how this can be exploited in any way.

#10

Many people are unaware that Network Owned parts which have touch transmitter’s touches are sent from client to server unfiltered. Exploits that locally resize parts with touch transmitters are common. For example, you could have a .Touched connection on the server, but if the connection is applied to a Network Owned part, an exploiter can resize that part locally and expand the hitbox of that part. They can also resize any part in the game locally and their touch transmitter will fire upon their network owned part locally touching the resized part. (.Touched is probably the most insecure aspect of all of roblox’s engine). Thus, your system is most likely fine.

3 Likes
#11

I believe my module would be perfectly suited for your use case, as you want the client to calculate collisions but server to validate.
Link: ClientCast - A Client-based, Idiosyncratic Hitbox System!

1 Like
#12

As much as I love your modules, I’m afraid raycasting hitboxes aren’t exactly what I’m looking for. Will definitely bookmark this for future use!

2 Likes
#13

First of all, having client hitboxes will make gameplay smoother.
Second, server sided hitboxes will make those who have 220+ ping cry.
Third, having client sided hitboxes doesnt matter if you do magnitude checks on the server.
Fourth, it is encouraged ti have client sided hitboxes to increase server side performance, this is because if 10+ players are firing attacks at the same time, expect the server to cry constantly detecting hitboxes for 10 players

1 Like
#14
  1. client inputs
  2. client checks there local cool down to see if there allowed to hit
  3. client uses GetPartBoundsInRadius to find out who it has hit
  4. client sends a event to the server saying that it hit target
  5. server checks the players cooldown
  6. server uses a antihack to check if the position of the player is correct
  7. you could also use the antihack to check the targets position as well
  8. server checks if the player is close to the target
  9. server deducts health from target

if your not sure how to make a anti hack in this video i show how to make a antihack to validate a players position

5 Likes
#15

Hello! Sorry to bump.

I really liked your explanation and the video, but I’ve got some issues now:
Take in mind this is for a class-based fighting game.

  • How can I make a hitbox system for projectiles? I haven’t yet made the projectiles but I’m going to in a few days deeper in development so the method to handle the projectiles is not defined - you can tell me which would be best for this scenario (like using beizer curves / tweening)

  • And how could I validate that hitbox? Currently, if I do a distance check, it would have to be a huge distance. Exploiters could fake the hit that way, right?

  • antihack.GetPosition() wouldn’t work if my player teleports with an ability. How would I work around this? I plan on having certain abilities that can make the player go from one position to another really fast. Perhaps I could make certain abilities check for part.Position instead? Would that make exploiters able to abuse it?

Thanks a lot for your attention,
Masak1

PD: I saw your channel and your content has be really useful! For once I’m happy about a Roblox Studio developer. GJ!

#16

I personally like using physics with touch events

I have a video showing how to calculate the force needed to make a part move to a target

And here is a little demo
BulletDemo.rbxl (36.8 KB)

to validate a hit is very difficult let me try to explain why

lets say there are 2 players player A and player B
and lets say it takes 1 seconds for the players to send there characters position to the server and it also takes 1 second for the server to send that position to other players

so player A moves from position 0, 0, 0 to 0, 0, 16 then sends this position to the server after 1 second the server gets the message and then sends this position to all other players so after a total of 2 seconds player B gets to see player A move from position 0, 0, 0 to 0, 0, 16 but by the time 2 seconds has past player A has already moved to 0, 0, 48

so what this is explain is that player B is seeing where player A was 2 seconds in the past
and the server is seeing where player A was 1 second in the past
and the same is true the other way around player A is seeing where player B was 2 seconds in the past

so when player A shoots a projectile and hits player B the projectile is not really hitting player B its hitting where player B was 2 seconds in the past and to player B it might look like the projectile never hit and missed

and if the server does a check to see if the projectile really hit the server might thing the hit missed because there not taking into consideration that player A is seeing player B 2 seconds in the past

now a difficult way to do this is for the server to keep track of the players position history lets say the server remembers the players positions up to 5 seconds in the past then when player A hits player B the server can check based on where player B was 2 seconds in the past and this check would be more accurate but not 100% accurate

the reason its still not 100% accurate is because up until now we have assumed it take exactly 1 second for the data to be send from the player to the server while the real time it takes is variable meaning is constantly changing

we can use GetNetworkPing to see how long it takes but this is also not 100% accurate because events are not sent every frame to the server

if we look here Task Scheduler | Roblox Creator Documentation

image
image1386×1494 335 KB

we can see that outgoing property updates and events does not happen every frame

so what this means is if a player shoots a projectile closer to a send job then the information will get to the server quicker and if they shoot a projectile just after the previous send job then it will take longer for that information to get sent to the server

I don’t have a good answer for you unfortunately if we make projectiles be handled 100% by the server then it will feel unresponsive and inaccurate to the shooter and the player getting shot

if we make the projectile handled by the shooter then it will feel responsive and accurate to the shooter but will be inaccurate to the server and the player getting shot

this is the reason why tab targeting is a common method of doing fighting in online games

so if your going to make projectiles be handles by the client the best the server can do is guess ruffle the area where the projectile hit

you might also want to make each player handle the projectiles separately so that when player A hits player B on the hand the server sends a event to player B saying player A hit you on the hand then player B will make a completely different projectile that looks like it hit there hand to them

if you make projectiles like in the video i sent above you might need to know where a projectile was along the path so here is a demo on how to do that

Projectile_Path.rbxl (35.4 KB)

if you have a anti hack to stop players from teleporting but you have a skill that teleports a player then you will need to send a event to the server and the server would need to validate the skill and then teleport them forward bypassing the anti hack

12 Likes