I know i already made like 2 posts just like this, but those are locked now (solutions were found) but im just now realizing that those were not solutions.
I have been looking everywhere for a decent hitbox system, Youtube, DevForum, Toolbox, anywhere you can find Roblox resources.
I have found no good hitbox systems, Apart from Muchacho Hitbox, RayCast hitbox, and a few others, But i found problems with those.
Muchacho hitbox (and any other spatial query hitbox):
Good, Very accurate, And was definitely what i was looking for.
Spatial querys don’t have parenting systems (obviously) So you cannot deactivate muchacho hitbox hitboxes when a character is destroyed without having to use a bindable event for an independent thread (i used this before, but i just want my game to be as optimized as possible.)
Raycast hitbox:
Recommended alot. Very popular, and i think was used in a popular Roblox game (or a system like it)
Relies on Animations for swings.
Not much freedom. All you can really do is choose where they are.
I am making a fast-paced fighting game, And i cannot find a good simple hitbox, I just want a module that can place a part wherever you decided (while follow the cframe you set it to, if it was an instance, like muchacho hitbox)
Basically, You can ignore everything i’ve said.
My only question is:
What is the best, most optimized, performant, and accurate hitbox that uses boxes?
(sorry if this seems like a rant, i’ve been unable to work on weapons for my game because of this, and cannot find any good hitbox systems)
You could just try having an invisible cylinder around the players to act as a hitbox. Only 1 part, and 1 weld, plus you can easily adjust the size of the hitbox too.
Having a hitbox like this also means that animations don’t affect it, which is good if you plan to add emotes or use roblox ones.
I did some research on this as well and also struggled to find a good answer. I ended up creating my own solution using a part on my weapons for the hitbox + touched event. I know, I know… this is not “supposed to be” performant but it works well for me and my servers only carry 8 players max so I’m not (currently) concerned with the performance. And it has worked well through 100’s of hours of play (AFAIK).
I have a solution that supports
player damage and kill attribution (i.e. who killed whom and who did most damage)
easy to toggle damage off for team games
knockback with a scale factor
custom sound affects for “what was hit”
I’d be happy to share it with you with these understandings:
I would never claim it is “best”
I doubt it is “the most performant” (mostly based on speculative comments I’ve read)
It is bespoke/customized for my particular needs - my code is well-written but you’ll need to do some figuring to make it useful for you i.e. if you’re a beginner I won’t be able to walk you through it.
I understand if you’re looking for something better/different but happy to help if I can
I appreciate your response, But unfortunately this is exactly what i was doing before i changed to muchacho hitbox, The reason i stopped using Touched was because it was said to be a bad method, And also because it would only let me hit 1 player.
Mine does not have this limitation… in fact, there’s no reason inherent to a touched solution for this limitation. It all depends on how you’re doing the debounce. Mine is setup per “thing hit” so it hits as many things as the weapon does, only once per character.
Here’s how I do that debounce… player.UserId is the player swinging the weapon - you debounce by tagging the humanoid with that players id. This lets the hitbox hit multiple characters/things while only doing damage to each one, once per swing:
local humanoid = character:FindFirstChild("Humanoid") :: Humanoid
if humanoid then
-- this is the debounce so humanoid is only hit once per swing
if humanoid:HasTag(player.UserId) then return end
humanoid:AddTag(player.UserId)
task.spawn(_onMeleeHit, player, character, humanoid, tool, hit, dmg, hitSfx, knockbackScalar)
-- reset the debounce a bit early so it is definitely ready to go on next swing
task.delay(debounceSec - (debounceSec * .1), function()
-- may have died
if humanoid then
humanoid:RemoveTag(player.UserId)
end
end)
end
Fair enough, I’m always looking for performant solutions myself
Last thought, not trying to convince you of anything - just sharing from experience…
Many a developer has spent countless hours avoiding performance problems before actually encountering them. That is, unless you have actually used a hitbox/touch solution on a 30 player server, profiled it and found the hitboxes eating up resources, then you don’t really know if it will perform or not. Testing that hypothesis may be difficult… but perhaps not as difficult as finding a different solution that works for you
I can say with certainty that far to often I’ve seen a SW dev speculate on a theoretical performance problem that never materialized when tested.
Of course we should always strive for good peformance and look out for potential problems. But we also should be certain a problem is a problem before spending to many resources addressing “the problem” that doesn’t actually exist.
Well actually, There is nothing at all wrong with my current hitbox system, the only reason i wanted to change was because i thought that having a bindable event fire everytime a hitbox was activated (I still dont know if this is bad or not)would be bad for performance, Though i’ve never tested it (mostly because i dont have 30 friends lol)
In that case, I guess i will stick to my hitbox system, and if it eats up resources, Then i’ll change it (or at least try to)
You’re right though, I always think “this probably isnt good for performance” But it really doesn’t hurt at all.
I’ve just done some research, apparently no, bindable events only lag depending on what its used for (but thats kinda like with everything) So i think im set for now. Thank you for your help again!
