[If touching [color picker], bounce]: Block suggestion

Masquerola

So since I'm making a tank game, I want the bullets to bounce off of the walls at the perfect angle. However, I haven't worked out a mathematical way of finding the direction, but I noticed that a block (that I hardly ever use), “if on edge, bounce”, does exactly what I want. It turns in the perfect direction I want it to. However, in a tank game there are many walls that aren't on the edge and I'm suggesting a more usable “if touching color (color picker), bounce” block. In my game I randomly generate a maze with black walls, and if the bullets are able to bounce off the walls every time they touch them (because I would set the color picker to black), then the block would become much more useful. If I am not being clear, what I want is a “if touching (color picker), bounce” block. If this is in some way not possible in the near future, I would like help on finding the direction that the bullet should turn in. (This, though would be much more difficult to make that just a bounce block since I would need to sense which side the bullet is touching the wall on, which direction the bullet is currently in, etc.) Anyway, thanks for your time as always

What the block would look like:

If touching color [#DBA901] bounce :: motion

(block would be a blue motion block)

Links:
Example of the “maze generator”: Tank v3

Last edited by Masquerola (Oct. 8, 2014 10:44:06)

robosnakejr

Support, along with

if touching [ v] , bounce

Masquerola

robosnakejr wrote:
Support, along with
if touching [ v] , bounce

agreed!

AonymousGuy

There are a lot of issues with this foremost being that “bounce” is a vague term and a global “bounce” block would not know what the user would want.

Aside from that, even just doing a mathematical equation for a general bounce block is difficult because of things like curved surfaces. The walls are easy to bounce off of because they are straight.

Masquerola

AonymousGuy wrote:
There are a lot of issues with this foremost being that “bounce” is a vague term and a global “bounce” block would not know what the user would want.

Aside from that, even just doing a mathematical equation for a general bounce block is difficult because of things like curved surfaces. The walls are easy to bounce off of because they are straight.

What I want here is basically exactly the same as the “if on edge, bounce” block. I agree that curved surfaces would be difficult, but in my opinion the block would still do more help and hinder.

KingOfAwesome58219

I saw you suggest this on Paddle2See's profile

+1
Also, you can color your block their by adding :: motion to the end
If touching color bounce :: motion
becomes

If touching color [#DBA901] bounce :: motion

Last edited by KingOfAwesome58219 (Oct. 8, 2014 03:53:40)

KingOfAwesome58219

KingOfAwesome58219 wrote:
I saw you suggest this on Paddle2See's profile
+1
Also, you can color your block their by adding :: motion to the end
If touching color bounce :: motion
becomes
If touching color [#DBA901] bounce :: motion

Odd, the part that defines the color isn't showing up in the first part, quote me and you will see that it is there.

Masquerola

KingOfAwesome58219 wrote:
KingOfAwesome58219 wrote:
I saw you suggest this on Paddle2See's profile
+1
Also, you can color your block their by adding :: motion to the end
If touching color bounce :: motion
becomes
If touching color [#DBA901] bounce :: motion
Odd, the part that defines the color isn't showing up in the first part, quote me and you will see that it is there.

k. thanks for the tip!

MegaApuTurkUltra

The problem with this is that to bounce accurately you need to know the normal lines of the shape you're bouncing off of.

A normal line is exactly perpendicular to a surface at some point. Knowing the normal line and your current angle, you can calculate a reflection angle that's the same as the incidence angle so the bounce looks realistic. The sides of the screen are easy to calculate normals for. However, sprites are harder, especially bitmaps, where a bezier curve based shape connecting all the edge pixelsor something would have to serve as an approximation for the actual shape being displayed in the bitmap, so that normals could be caclulated based on the shape. And there's some complications too: do you calculate the normal for the entire sprite you're touching or just he normal of the shape containing the color you're touching? If the second thing, how much color tolerance would you allow?

Basically, it's way too complicated to actually implement, unfortunately. The scratch team might figure out some epic hack to make this work though, so I support.

stickfiregames

You can bounce off straight lines and circles quite easily, if it helps.

But no support for a general bounce block, it would be too complicated.

Last edited by stickfiregames (Oct. 8, 2014 18:04:02)

Masquerola

stickfiregames wrote:
You can bounce off straight lines and circles quite easily, if it helps.

But no support for a general bounce block, it would be too complicated.

thanks! that's exactly what i needed!

theonlygusti

You can bounce like this:

point in direction ((-1) * (direction))

Masquerola

theonlygusti wrote:
You can bounce like this:
point in direction ((-1) * (direction))

thanks

PinballX

Masquerola wrote:
So since I'm making a tank game, I want the bullets to bounce off of the walls at the perfect angle. However, I haven't worked out a mathematical way of finding the direction, but I noticed that a block (that I hardly ever use), “if on edge, bounce”, does exactly what I want. It turns in the perfect direction I want it to. However, in a tank game there are many walls that aren't on the edge and I'm suggesting a more usable “if touching color (color picker), bounce” block. In my game I randomly generate a maze with black walls, and if the bullets are able to bounce off the walls every time they touch them (because I would set the color picker to black), then the block would become much more useful. If I am not being clear, what I want is a “if touching (color picker), bounce” block. If this is in some way not possible in the near future, I would like help on finding the direction that the bullet should turn in. (This, though would be much more difficult to make that just a bounce block since I would need to sense which side the bullet is touching the wall on, which direction the bullet is currently in, etc.) Anyway, thanks for your time as always

What the block would look like:
If touching color [#DBA901] bounce :: motion
(block would be a blue motion block)

Links:
Example of the “maze generator”: Tank v3

I believe it is possible like this:

if <touching color [#ff0088] ?> then
point in direction ((direction) + (180))

end

theonlygusti

^^ nope. That just turns around, should be direction * -1.

RPFluffy

Semi-support as it would be glitchy…
Because you could have a tiny line it might not sense..

stickfire-test

theonlygusti wrote:
^^ nope. That just turns around, should be direction * -1.

That only bounces off a vertical line.

spike43884

robosnakejr wrote:
Support, along with
if touching [ v] , bounce

Support a lot, Back in the days when we all made pong games, we had a TERRIBLE problem with the ball either messing up on platform contact, or horrible bad bouncing…I Just abouts made a light bouncing script for a game which Ive put on hold for to long…But just a BOUNCE block would be incredibly useful…It would take the face that the object came in contact with, check the angle of entry compared to the direct outwards from that face (a perpendicular line to face going outwards) then create that angle on the other side projecting the object out there…Creating a realistic bounce!

AonymousGuy wrote:
There are a lot of issues with this foremost being that “bounce” is a vague term and a global “bounce” block would not know what the user would want.

Aside from that, even just doing a mathematical equation for a general bounce block is difficult because of things like curved surfaces. The walls are easy to bounce off of because they are straight.

Not that hard, you simple check the direction of the surface its come in contact with. Circles and curves are simply VERY SMALL straight lines in the universe of PC's. Youve never digitally drawn a circle, sorry

MegaApuTurkUltra

spike43884 wrote:
robosnakejr wrote:
Support, along with
if touching [ v] , bounce
Support a lot, Back in the days when we all made pong games, we had a TERRIBLE problem with the ball either messing up on platform contact, or horrible bad bouncing…I Just abouts made a light bouncing script for a game which Ive put on hold for to long…But just a BOUNCE block would be incredibly useful…It would take the face that the object came in contact with, check the angle of entry compared to the direct outwards from that face (a perpendicular line to face going outwards) then create that angle on the other side projecting the object out there…Creating a realistic bounce!
AonymousGuy wrote:
There are a lot of issues with this foremost being that “bounce” is a vague term and a global “bounce” block would not know what the user would want.

Aside from that, even just doing a mathematical equation for a general bounce block is difficult because of things like curved surfaces. The walls are easy to bounce off of because they are straight.

Not that hard, you simple check the direction of the surface its come in contact with. Circles and curves are simply VERY SMALL straight lines in the universe of PC's. Youve never digitally drawn a circle, sorry

Read what I said above about normals. Its very hard to calculate them accurately for an arbitrary bitmap.

FiveCubed

here's a link to something like this…

Discuss Scratch