How do I make the blocks in a brick breaker esque game?

Questions
#1

I know there is an example on the app but it is hard for me to really see how it works without an explanation. Could anyone explain how I would make the bricks? Thanks in advance

#2

Check for the rect() function in the documentation. :-w

#3

I understand how to make rectangles :wink: . I want to know how to use the level array and for loops to make them in pattern.

#4

Check out the levels tab of the brick breaker example to see how the levels are defined (any try modifying them to see the affect it has), and look at the makeBlocks function in the main tab to see how they are read. It has a few confusing numbers, but those are mainly just for spacing the blocks apart from each other.

#5

I’m also messing around with the sample project, and am wondering how to optimize the draw() function in the main tab, as it says there are many unneccessary checks occurring.

Any ideas how to optimize the collide() function? obviously the collision is based on a rectangle with coordinates:

(a,c)    (b,c)
 _________
|_________|
(a,d)    (b,d)

and a ball at (e,f). so, if:

a < e < b 
and
d < f < c

then the ball is inside the rectangle.

I guess the unnecessary check is that if you have detected one collision, you don’t need to continue checking. I noticed a slowdown/delay right before a collision occurred with any surface, be it a wall or block, and i’d love to know how to fix that. I was toying with the idea of changing it from a table that gets resized every time a block is removed to a 6x10 grid where you just change the state of each block from display to not displayed. I don’t know how slow the table.remove() function is, but it would remove that, because you’d just be changing a flag on the block object.

#6

The collision doesn’t work by detecting when it collides - rather, it detects when it DOESN’T collide, using the separating axis theorem. Essentially, if you can draw a line between the ball and the box they aren’t colliding.

Anyways, the collision detection there is already as fast as it can be (ignoring a broad-phase stage in the physics, but that’s beyond the scope of this thread…)