It’s been a little while since I’ve posted anything, but to put it simply: one of my games (entitled DEAD) took off. I’m a somewhat popular game developer now and it’s mind-boggling. But that’s not the point.
We recently had a pretty massive exploiter/hacker outbreak, using mass Touched events to make zombies tag every single player in the game to farm massive cash / be annoying. I fixed this with a band-aid .Magnitude check whenever a tag occurs, but it made me think a little bit further about changing things up.
We’ve had overall very positive feedback with the game (which is an infection tag / zombie tag-inspired match-based game) but we keep seeing one recurring negative: “the hitboxes”. I don’t actually use hitboxes, as I started making this game years ago and TouchedEvents seem to be working just fine for the most part. The problem people are encountering is that Roblox’s server lag is just totally destroying the fun. When you tag someone, both players are frozen for a few seconds, but on the screen of the person who was tagged, it often looks like the zombie tagged them from miles away. On the zombie’s screen, they definitely touched them.
I wanted to find a solution to this, so I started researching into a hitbox-based system, and I’m still a bit stuck. Will hitboxes actually fix my specific problems? Will they make the game any better? How would I go about implementing them?
Any help is greatly appreciated, thank you.
short answer: it depends
it is abnormal for a .Touched event to simply lag out the server, unless you have heavy code running with every single touch with disregard for simple return checks
hitboxes can indeed improve performance as well with gameplay, but id recommend you use them for checking for collision during an action, not waiting for an action (etc, sword collision)
otherwise you will have to do a hitbox scan every heartbeat or frame, which i’m not too sure on performance since i have not tested this
if you are doing for action: hitboxes
if you are waiting for action: .touched
id recommend you research deeper into what your .touched events are doing first, as it seems to either be a connection or function issue
(if there is an underlying performance issue from the function, changing to hitboxes won’t fix the issue anyways)
I don’t think you quite got it. .Touched isn’t causing any lag, it’s simply the lag between the server updating and the client receiving the updates that is causing trouble. People aren’t thinking they were caught when they actually were, and it’s making people quit because they think the “hitboxes are broken”.
Would introducing real hitboxes help with this? Can I fight this in another way?
PlayerA moves. The packets telling the server pA moved takes .15 second to arrive due to latency. So server updates pA pod 0.15 seconds behind. pBs screen shows pA move when it gets the packet 0.15 seconds after the server gets it. This means pA has moved 0.3 seconds before you start seeing it. This means at default walk speed they are 4.8 studs away. This is unfixable. In the sense you can’t send data faster so player positions will always seem off. The best way to reduce this is to use the server as the source of .touch connection which will cut the latency down to a one way trip on both sides. Worst case rn it can be 4 message lengths or 0.6 seconds between the relevant events if you do this on the chasers client.
I’m doing .Touched on the server-side, which means… I guess it can’t get any better. Oh well. Thanks for your help!
What you’re looking for is lag compensation
It wont perfectly solve the issue, but it’ll probably lessen the “unfair” feeling players get.
Basically:
Switch to using hitboxes so you can handle the lag compensation part better by allowing you to better move/adjust where the hit could occur.
Basically:
Get what the player sees using a remote event or something
Get what the server sees (on the server side)
Compare and confirm
Get the differences between them, “interpolate” between a bit to give some leeway, and check if the player might’ve probably gotten hit or not gotten hit, then use that as your conclusion.
Simplified:
Blue is what client sees
green is server
red is other client
Blue sends info to server saying “i’ve hit the player”
green sees that it doesnt look like that
green tries to verify your claim by looking back at your previous position of where you claimed you hit the player and where the player is, comparing it to what the server has as well, and seeing if it roughly matches up
if it does, confirm a hit
Now if you really wanted to for some reason, you could try factoring in red player’s estimated ping as well and shift about priority of who is “correct” and who isnt.
.Touched events can trigger multiple times in a short time span if there’s no debounce. Generally using .Touched is not that good of a practice, as it’s quite unreliable and has worse performance. There’s nothing you can’t achieve without using it.
Your best bet would be using spatial queries (like GetPartBoundsInBox)/magnitude hitboxes.
like I said before, I’m very open to the idea of switching to hitboxes, but .Touched isn’t giving me any trouble right now lag-wise. my problem is that the lag between one client and another is too extreme, and many players feel that it is unfair.
thank you! it has become apparent to me that most of the game systems need a full rewrite anyways. I will factor this in when that happens. I can’t thank you enough!
This issue should be addressed by Roblox’s Server Authority update in the future, but it’s in early access right now. You can request early access btw if you are interested and wanna get prepared!
Link to the post
Adding to posts above, you can research the “rollback netcode” topic, should be helpful.