Hello! you read the title right, I have a theory for hitboxes and I felt like sharing it with you guys. First, you will need to get the players coordinates for this to work. now my theory for hitboxes are to create 4 points around the player, and any coordinates within the shape the points make, are in the hitbox. we can make these points by using addition and subtraction on the properties to set a property to, so we can easily get these points for later use.
for example
playerX - 2
and
playerY - 2
we would make 3 more of these that result in a rectangle around the player. now we have a framework for the raidus of the hitbox. now we just need a way to find out if a point is within a hitbox or not. we can do this using some if thens checking if the x of the point is greater than the points on the left’s X but also less than the points on the right’s X.
then we do the same for the Y coordinates. if both are true than this point is within the hitbox.
note that this is all theory and I haven’t tested it yet but I’ve put some thought into this and have come to the conclusion that it most likely should work in practice. however if it doesn’t we can always try and fix it.
Thank you for reading this, I took quite a bit of time to come up with this. toodles!
For hit detection you will need a lot of triggers with blocks and such. I wish this would work but I see a problem with using a lot of blocks. 1 that uses a lot of memory for triggers and blocks and the coordinate device costs sooo much and you can only have 1 coordinate device in your game but you may be able to avoid that using teams and wire repeaters/triggers
it ended up only taking 2 block code scripts, 1 coordianate device,
and 1 trigger and a few properties. that’s pretty low memory wise.
yes that does mean I tested the system and found out that it works.
(also this does work, although I’m going to keep this up Incase anyone has questions about the basic idea)
The issue was that it probably wont work with multiple players, like if you wanted to see if two players are touching. Did you try that? I hope I’m wrong
also, this theory is for Psuedo projectiles or real projectiles once someone figures out how to detect them, or Psuedo melee attacks. I will note that the hitboxes do NOT need to be around the player, this can be used to make placeable turrets that slow players down that players can place.
you can adapt the theory into code in whatever way you choose, I might go about making a guide on how I personally did it for those who are stuck on how to implement this.
This is a great idea, but would hit detection actually work? With a projectile?
The problem is, if you’re spamming projectiles, you’ll need a pseudo hitbox for EVERY SINGLE ONE. That’s really memory consuming, but you could use this for like a dynamite launcher or such. It’s still really annoying, though.
You could use this for something like a marker on one player or something.
… and have a small arena with a stationary aim lock.
Overlays will be in the bottom corners, turning left and right, respectively. This requires barriers to be copy-pasted every 2x2 square. Then you have blocks detecting which of those barriers are activated, and then those barriers disappear once the game knows that they’ve fired.
The system in question I hope you can figure the blocks yourself but I got the idea
(3 assignments are due today that I haven’t completed ;-; )
Gosh I haven’t focused on this in 5 months
Anyway thanks for mentioning that people are getting close, and now I have it done!
But players can activate it to stop projectiles so that’s a problem
I made a system similar to this. It was exactly like the hit box you set up, but if a player was in your hitbox and clicked a game overlay it would damage you. Pseudo projectiles could just be fired in the way the player is running, unless you want something more like actual GKC projectiles. After that implementing the code for a projectile hitting a player wouldn’t be too hard.
TLDR; For pseudo projectiles, hit detection is easy, actually firing it is some what limited.
