I’ve just had another go…
The particles looked better in the previous version I think, but just got in the way, the little red ones you have now don’t stand out that much, so they don’t get in the way, but they aren’t that interesting either. I think the rotation approach may have worked well, e.g. if you hit the brick on the right, they fly out to the left, if you hit the brick on the left, they fly out to the right, that would potentially keep them out of the way of the player too.
A middle ground option you might consider, if you grab the colour from the sprite rendered component on the block, just before you destroy it, you could set the colour of the particles to that colour. So if I destroy blue blocks I see blue particles, red blocks I see red. That would at least allow for some variety and not raise the “Why when I destroyed that blue block did I see red bits” question
Sorry, I know you will hate me for the above, but I need to keep my feedback honest.
The buttons look much better, well done, really like those now.
The boring loop issue seems more prevalent now. I hadn’t experienced in the other version, but my first game in the new version has it.
There are a few approaches you could take to resolving the issue, its been raised quite a lot of times on the forum in the passed for the original version of the course. One of the issues with the tweak is that the change on the Y axis is fairly small, when the ball is near the bottom of the player space this doesn’t matter too much, it will gradually climb its way up the screen and, probably, hit a block and off it goes again… but if the issue occurs when there isn’t anything left to hit, it flat lines as the tweak can’t cause a rebound. You might be able to fudge it by making the tweak a negative on the Y, that way all of your boring loop rebounds would be coming down the screen, and eventually make contact with the paddle, assuming nothing else was in the way first. The problem is though, it takes a lot of time and creates a really boring experience for the player.
Blasting it is one option. Something I applied was a count of the last n objects the ball had hit, this was to detect if it the ball had entered a boring loop. For example;
WALL
BLOCK
WALL
BLOCK
WALL
WALL
The above seems ok…
WALL
WALL
BLOCK
WALL
WALL
WALL
WALL
Would probably indicate an issue. Note, these would be the types of objects it had hit, so four WALLS in a row could be the left wall, the right, the left and then the right. A good ricochet would probably only have a maximum of 3 WALLS before back to the paddle, a miss, or a block. It would depend on the angle the ball was travelling on. You could experiment.
What I did, and I’ve checked but I no longer have the code this, was to then hit the ball with the tweak, but significantly. So, if the ball gets stuck in a loop, it will then suddenly fly off in a direction that was unexpected, but at least the game moves on.
Once you have the detection in place, how you handle it is then up to yourself, you could have a little robot fly across, grab the ball and return it to the paddle, would look quite cool. You could make a feature of the issue, once you detected the boring loop place a count down in the middle of the screen for a few seconds, and then once it reaches zero, blow the ball up and place it back on the paddle - perhaps don’t deduct a player life for this though, it could just be a dud ball