https://scratch.mit.edu/projects/715159971/
when the ball touches the players or the edges it sometimes glitches out and stuff
(ps. this is not fully finished i still haven't done the scoring or if the ball touches the x position edges it doesn't do anything)

Swilb_coders wrote:

https://scratch.mit.edu/projects/715159971/
when the ball touches the players or the edges it sometimes glitches out and stuff
(ps. this is not fully finished i still haven't done the scoring or if the ball touches the x position edges it doesn't do anything)

You might be able to fix it by making separate sprites for the collision, or you could try making the bouncing a little less random

I hope this helps

Hi Swilb_coders,

This glitch happens when one sprite touches another and “can't get out”. It happens more often when step sizes are large and when move angles may not take the sprite directly away from the obstacle it contacted.

I tried making a custom block to break the movement into small steps and backed the ball away from a paddle when it touches, before turning or taking more (small) steps. It solves your glitches:

when green flag clicked
...
forever
set [degrees v] to ((1.8) * (direction)) // from the original code
Move (15)::custom // the rest goes in the custom block

// Check the Run Without Screen Refresh box
define Move (steps)
repeat (steps)
move (1) steps
if on edge, bounce
if <<touching [PLAYER 1 v] ?> or <touching [PLAYER 2 v] ?>> then
repeat until <not<<touching [PLAYER 1 v] ?> or <touching [PLAYER 2 v] ?>>>
move (-1) steps // back up until not touching
end
turn::custom
end
end

It's important to check the “Run without screen refresh” box when you make the Move block, so it all happens in the single tick that you previously moved 15 steps. If you don't check that box when you make the Move block (or right click and edit to check the box) then it will move 1/15 the speed you had before.

I think the odd angles it sometimes bounces at are cool. If you want to see how to do “natural angles” for bouncing, I did a demo of that a while back (using change x, change y, instead of move blocks):

Sample Pong (natural bouncing) - Horizontal and Vertical
https://scratch.mit.edu/projects/690905887
Explained more here: https://scratch.mit.edu/discuss/post/6300280/

I hope this helps. Happy to answer any questions,

– RT_Borg

Thanks so much RT_borg when i share it ill put you in the credits

Oops, silly me, I changed how I did the loop and left the (no longer needed) variable “step”. Editing it out of the code above now (since it does nothing).

Glad I could help.

oh lol

can you look at it again and play with a friend or yourself and see whats wrong with the scoreing code ‘blue goal , red goal’ i tried using sprites but then i tried using colour

only sometimes it works

Looking now (so far I just see that it has trouble for scores over 10).
Edit: I just looked at the score code and costumes. Only 0-10 are supported. So you must mean something else is happening to the scores.

By the way:
- Right click the “define Move Steps” block and edit, choose “Run without screen refresh”
- In that definition, change "move 10 steps“ to ”move 1 steps“

That'll give you the fast motion you wanted in your pong game.

Up in the green flag script, change ”Move 15" higher or lower to change the speed.

Occasionally, when the ball is on a really steep angle, so it's coming almost down onto a paddle, it seemed like it scored (because it was touching the goal color) when it felt like I could still have returned. it.

I set the goals back a bit. In the sprite controls under the stage, I set the red goal to x = -10 and the blue goal to x = 10. Still looks nice, and I didn't see that problem any more.

Are you seeing anything other scoring problem, or does that fix it?

– RT_Borg

RT_Borg wrote:

By the way:
- Right click the “define Move Steps” block and edit, choose “Run without screen refresh”
- In that definition, change "move 10 steps“ to ”move 1 steps"

I should make sure you understood the reason for adding the custom Move Steps.

The original code had “move 15” (that happened all in one Scratch tick 1/30 second). Moving by 15 steps at a time is fast, but it's coarse grained, and you can end up “inside” obstacles, because you may have only been 1 pixel away and then moved 15 in their direction.

The custom block splits that single 15-step move into 15 separate 1-step moves. “Run without screen refresh” tells scratch not to slow down (and allow the next screen redraw) for things it normally would (like all the little 1-step moves inside the define). So the custom block can run so fast that it all happens in a single 1/30 tick, just like the original “move 15” did.

Then, because the movement is actually going on in 1-step increments (just without screen redraws between each one) we can see each pixel whether we touched a paddle, and if we did, back up just a little and do a turn. Normally for something like this, you would just undo the last single 1-pixel step, but I backed up by 2 just because some of the turn angles were back toward the the paddle.

– RT_Borg

I'll just point out now that I'm entering a topic that already has a bit of discussion so it'll be a bit confusing as to what suggestions have already been implemented or whether our suggestions clash with each other.

That being said, I'll point out what I've noticed and try to explain my solutions.

First of all, do this: Play the game, and move the right paddle upwards so that it completely misses the ball. What happens?

You'll notice that even though it hits the blue goal, it doesn't detect it at all, and bounces right off it. Why is that? It's because of when it detects the goals:



While it detects whether it's touching the paddles every time it moves, it only checks for a goal after the “Move” custom block is finished. In the “Move” custom block, you move 10 steps 15 times, meaning the script only checks for a goal every 150 steps. That's quite a lot of room to completely miss a detection. I'm not sure if you're in the middle of making a custom script, but as it is there's no need to repeat 15 times, just once is fine.

You may be repeating 15 times like this because it makes the ball faster, which when I was trying I found it *might* be slower if it's repeated just once, though that might just be my computer. The “touching colour” block is one of the most inefficient blocks to use so you may want to consider doing a different kind of check, such as checking if the ball x position < -200.

As for the paddle detection, it's fine as it is, although you'll want to use a custom block without screen refresh so it doesn't take as long as RT_Borg said. Alternatively, make it move backwards by 10 steps, not 2. There's no need for surgical precision.

It is at this point I'll explain how to bounce off a paddle. The method you chose is a nice estimate and has some chaos to it but it sometimes bounces the ball backwards into the goal which is not preferable. Let's briefly go over sprite angles:



From this we can learn a simple rule: Going right means you have a positive angle, and going left means you have a negative angle. More importantly, if you get any angle, and reflect it left to right, all you're doing is changing the angle from positive to negative (or negative to positive).



Therefore the solution to finding the angle after hitting the paddle can be split into two cases (negative angle and positive angle) that are very similar to each other. Let's understand the logic behind bouncing:




The key point is that when you are bounding off an object, the two orange angles are the same. If you know a little trigonometry, you can discover another place where we can place the orange angle:



The orange angle can be found between the line pointing straight up (which is an angle of 0), and the line the ball is moving. In other words, the orange angle used to bounce off a wall is exactly the same as the angle the ball is moving at. How can this information be used? By moving the trajectory line a little:



As you can see, the angle we are supposed to bounce is just the mirror of the angle we are already moving at. And as we established, this mirror angle is just the negative of the current angle.

Hi Alberknyis,

Very detailed description of natural bouncing!

(BTW, when Swilb_coders had the move 10 inside the custom Move definition… my suggestion in #3 had move 1. Swilb_coders implemented the idea, but forgot to check “Run without screen refresh”, and I suspect changed it to move 10 because it crawls too slowly that way (the whole point of turning screen refresh off). I pointed out the implementation error in #9 and again in #11.)

You're absolutely right that I should have relocated the rest of the touching/scoring part of the script into the custom Move, thanks for pointing that out! I never saw that particular problem when I tested it out, but at speeds over 15 (or with thinner goals) I'm sure it would have shown up. (Maybe there's also some slight variation running on different computers that could cause it to show up on one and not another, if 15 is just barely too fast.)

– RT_Borg

I’m so sorry I have been replying these last 27 days or so I was taking time of scratch and rn I’m on holiday and I didn’t bring my computer only my phone so I can’t rlly edit easily

I’ll try doing very little though

also check my project again ive used my mums laptop to edit