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

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?

2 Likes

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.)

1 Like

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

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

1 Like

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

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.

1 Like

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

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.

1 Like

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.

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.