How do I make a hitbox?

zantman1000

I understand everything there is to making a hitbox, just not how to make it move with my character.

AonymousGuy

Just do this:

go to [thespriteyouwant v]

or,

go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v])

And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.

Brutexx

AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.

What about the hiding part? won't the hide comand cancel everything?

footsocktoe

Brutexx wrote:
AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.
What about the hiding part? won't the hide comand cancel everything?

The HIDE block does not affect the GOTO block. A hidden sprite can still be moved.

If you need to use “touching” then set the Sprite to 99% ghosting instead of hiding it. It will still be invisible, but can detect touches.

Last edited by footsocktoe (May 9, 2017 22:00:17)

Brutexx

footsocktoe wrote:
Brutexx wrote:
AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.
What about the hiding part? won't the hide comand cancel everything?
The HIDE block does not affect the GOTO block. A hidden sprite can still be moved.

If you need to use “touching” then set the Sprite to 99% ghosting instead of hiding it. It will still be invisible, but can detect touches.

Thanks!

Birdlegs

Small note, but 100% ghosting works the same way. It won't make much difference, though

gtoal

In the old days a hitbox was entirely a software check against the corner coordinates of a rectangle to quickly approximate detecting a hit on an irregularly-shaped sprite. Now that we can cheaply detect hits on sprites at the pixel level, why do you want to do the approximate test instead and especially why would you do it by creating a rectangular sprite and testing for a hit against that at the pixel level??? It really doesn't make any sense to me!

Can someone explain it to me? Why would you ever use a sprite-implemented hitbox?

thanks

G

RedThumb

gtoal wrote:
In the old days a hitbox was entirely a software check against the corner coordinates of a rectangle to quickly approximate detecting a hit on an irregularly-shaped sprite. Now that we can cheaply detect hits on sprites at the pixel level, why do you want to do the approximate test instead and especially why would you do it by creating a rectangular sprite and testing for a hit against that at the pixel level??? It really doesn't make any sense to me!

Can someone explain it to me? Why would you ever use a sprite-implemented hitbox?

thanks

G

I dont completely understand the question. Do you mean a “Start” button doesnt make sense? Or making a code using “mouse down” at any point of the stage has more sense. Correct me if Im wrong.

Birdlegs

gtoal wrote:
In the old days a hitbox was entirely a software check against the corner coordinates of a rectangle to quickly approximate detecting a hit on an irregularly-shaped sprite. Now that we can cheaply detect hits on sprites at the pixel level, why do you want to do the approximate test instead and especially why would you do it by creating a rectangular sprite and testing for a hit against that at the pixel level??? It really doesn't make any sense to me!

Can someone explain it to me? Why would you ever use a sprite-implemented hitbox?

thanks

G

Determining hits based on a mathematically defined hitbox naturally involves plenty of additional headaches, though it's faster for the hardware to run. Generally, new users learn the sprite method first because, among everything else they often need to learn, this method allows them to take care of learning that first and then learn mathematical hitboxes later. Divide and conquer, sorta. (Or, at least, that's why I encourage learning the sprite method first)

I still use sprite hitboxes myself, just to avoid all that!

RokCoder

gtoal wrote:
Can someone explain it to me? Why would you ever use a sprite-implemented hitbox?G

With regards to regular, early-out, hit boxes, I use them in my Scramble game because I got a massive performance boost from doing so - especially when I was checking collisions against screen sized sprites for the scrolling backdrop but even after I replaced that with a tiled system the performance boost was tangible. And I use them in New Rally X as it has to deal with on-screen and off-screen collisions.

But sprite-based hit boxes? I've seen plenty of cases of people using them in Scratch as “sensors” for collision detection in platform games. It's not an approach I would likely take but I can see that it's a quick and easy method to implement.

ScriptedAwesome

zantman1000 wrote:
I understand everything there is to making a hitbox, just not how to make it move with my character.

I'm not sure what you mean.

ScriptedAwesome

Brutexx wrote:
AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.
What about the hiding part? won't the hide comand cancel everything?

No it will not. I use this method for sprite teleportation all the time.

Uniquename1

gtoal wrote:
In the old days a hitbox was entirely a software check against the corner coordinates of a rectangle to quickly approximate detecting a hit on an irregularly-shaped sprite. Now that we can cheaply detect hits on sprites at the pixel level, why do you want to do the approximate test instead and especially why would you do it by creating a rectangular sprite and testing for a hit against that at the pixel level??? It really doesn't make any sense to me!

Can someone explain it to me? Why would you ever use a sprite-implemented hitbox?

thanks

G

Not to hijack the thread but a tutorial example uses the scratch cats tail, would also help for a sword or other irregular shaped sprite. If just checking the sprite he can stand on the edge of a platform by his tail or sword which looks weird. Having a core hitbox allows these extremities to go into walls n such.

Another note about hitboxes for the op. If scrolling and the character never moves from the center of the screen then you don't need to have the hitbox travel with them just put it in place and they both stay there as the world turns.

17157-Mac

Brutexx wrote:
AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.
What about the hiding part? won't the hide comand cancel everything?

You use ghost effect 100%

ParadoxScratching

switch costume to [hitbox]
all sensing done here
switch costume to [normal]

TClord

Brutexx wrote:
AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.
What about the hiding part? won't the hide comand cancel everything?

change [ghost v] effect by (99)

Cladriel

ParadoxScratching wrote:

switch costume to [hitbox]
all sensing done here
switch costume to [normal]

Is it more efficient to switch costumes or have two sprites stacked on each other?

Birdlegs

Cladriel wrote:
ParadoxScratching wrote:
switch costume to [hitbox]
all sensing done here
switch costume to [normal]
Is it more efficient to switch costumes or have two sprites stacked on each other?

In my projects, I use sprites stacked on each other (The hitbox can be ghost effect 100 and still detect hits). Since costume changes can be a little bit laggy, I think this way is faster

Oh, and in case this issue comes up, you can use a broadcast after your hitbox is done making its movements on each frame to tell the “costume” sprite stacked on top to update to its position. If you tell the costume sprite to just forever go to hitbox, it'll lag behind a little

Last edited by Birdlegs (Sept. 14, 2018 17:47:03)

TheCodePro123

To simply say this: make a hitbox with all of the scripts needed to function then add a sprite with a clear visible character to teleport to the hitbox constantly.

mastery4

AonymousGuy wrote:
Just do this:
go to [thespriteyouwant v]
or,
go to x: ([x position v] of [thespriteyouwant v]) y: ([y position v] of [thespriteyouwant v]) 
And, if you use the second method, you can also make it go slightly higher, lower, to the right, or to the left of the sprite.

+1. This will definitely work. But you also need this:

change [ghost v] effect by (100)

Last edited by mastery4 (Sept. 22, 2018 03:28:30)

Discuss Scratch