I’ve been researching this topic for as long as I’ve been making stuff on studio. I’ve made a server hitbox game, which while It feels secure and manageable. It’s very slow, delayed and annoying. Because of ping of course. And I’ve recently been working on a client sided hitbox.
In everything I’ve found about hitbox registering/communication. People have always said, “Do the hitbox on the client and conduct sanity checks on the server.” Yeah ok. How? “Create a hitbox and send the hits to the server.” Okay, also how. I get the create the hitbox and fire the hit info to the server. But on the server handling different things feel way easier. Like dealing stun, checking if no one was hit when the hitbox stops, doing different things if different people were hit, handling special events. And what not.
A main issue I get is how my hitboxes are handled. Certain hitboxes will conduct multiple hits, or fire in quick succession. Which I’m very much assuming can overload the server with info and cause lag. On the server on the other hand all It is, is creating the hitbox itself from one event fire, and handling the rest itself.
To get to the end quicker, I want an explanation on how to handle hitboxes, what’s the best way to do so, while also maintaining the manageability of handling hitboxes on the server. Usually when I approach this I either do it TERRIBLY wrong, or forget a crucial factor. Which is, usually, unbeknownst to me.
(For anyone wondering my hitboxes typically use a getPartBoundsInBox() approach to actually detecting contacts.)
You probably aren’t going to overload the server or cause any significant impact on latency unless you are returning very large amounts of data frequently. And by large, I mean dozens of instances.
Detect the hit and run quick large-gap sanity checks. For example, if the max range a person should hit is 10 studs, do a distance check for 15 - 30 stud range. If it is greater than that don’t do anything for the hit.
Play initial hit effects such as VFX and SFX
Send relevant data to the server (hit position, hit object, time of hit, etc)
Only use RemoteEvents
Server Side:
Provide additional sanity checks. On Server you will first want to protect your Remotes. Simple thing to do is create a table and add the player that called the event to the table. After a very small delay (such as 0.1 seconds) remove player from table. Only proceed if the player isn’t already in the table. This will keep a bad actor or super lagger from somehow overloading your system with mass-event calls. Other sanity checks will be distance checks, checks on frequency of ability use (cooldowns?), and anything else you can think of.
Proceed with dealing damage and if your game does this, provide a visual effect showing the damage dealt. Also provide the standard visual and sound effects for all other clients (remember they didn’t see the effects yet). You will do this by sending signals to their clients. Do not make the Server actually handle those extra effects. Doing it only on clients helps reduce load on server and allows you to make settings for Players to hide effects they don’t want.
All damage modifiers should be handled by Server; basically the amount of damage dealt should be decided on Server
Extremely Quick Combat System Procedure
If you have a very fast combat system where hits are going to be in rapid succession and fear this lagging the server you will want to add all these hits to a batch system and send entire batches to server at once.
Summary
Your system will put all or most of the visuals and sounds on the Client. All the server should do is sanity check, dictate damage dealt, and finally apply damage