Will try to take a look this evening. Any indication of events up to this point, so I can try to replicate without having to play test all levels?.
- which scene did it occur on?
- was it the last brick on the scene to be destroyed?
- was the ball bouncing off of lots of bricks rapidly?
That kind of thing. 
Updated Sun Oct 01 2017 08:48
Hi Lenny,
Ok, so I’ve just ran the game and almost immediately received an error regarding the crack sound effect and the Inspector also showed two audio clips.
I am fairly confident the reason they are not being destroyed is that the code is erroring and halts the execution of code before it gets the chance.
Here’s a screenshot of what had happened at the time;
As you can see, Bob has collided with a diamond block. Whilst these are indestructible, they are still detecting a collision, and the collision code in Brick.cs says “Play the crack sound”, which isn’t referenced in the Inspector for the indestructible bricks…
void OnCollisionExit2D (Collision2D col) {
AudioSource.PlayClipAtPoint (crack, transform.position, 0.6f);
print ("Crack sound created");
if (isBreakable) {
HandleHits ();
}
}
So, in the above, it would seem reasonable to move the top two lines of code to inside the if statement.
void OnCollisionExit2D (Collision2D col) {
if (isBreakable)
{
// only play the cracked sound if the brick is breakable
AudioSource.PlayClipAtPoint(crack, transform.position, 0.6f);
print("Crack sound created");
HandleHits ();
}
}
That change resulted in the first scene being played on autoplay without error and the console shows corresponding output messages for each brick;
Note, if you want to do something a little more fancy, you could change the code so that if the collision is with an indestructible brick, a different sound clip is played, by using the other tag. Alternatively, you could add a different AudioClip to the indestructible brick prefab/instance, if you do this, it might be worth changing the name of the exposed AudioClip field on Brick,
public class Brick : MonoBehaviour {
public AudioClip crack;
to something more like;
public class Brick : MonoBehaviour {
public AudioClip collisionSoundEffect;
That way, the name of the field would be relevant for all bricks when viewed in the Inspector.
I won’t look any further until I hear back from you, as getting some reproduction steps would be handy (as above), or, maybe this was all the issue was.
Hope this helps
p.s. Just looked at your screenshot again, whilst Bob hasn’t collided with an indestructible brick in that case, I suspect that another brick has. To test this theory, pop a Debug.Log statement in the collision code Brick.cs and output what collided. I think you are going to find that it was a brick colliding with the indestructible brick which then tried to play it’s cracked sound effect, and couldn’t because it doesn’t have one associated. The above code change should resolve this also, but it would be good to see if this is the issue before fixing it, just so you can see exactly what is going on
Example;
void OnCollisionExit2D (Collision2D col) {
Debug.Log("Collision with object named : " + col.gameObject.name");
AudioSource.PlayClipAtPoint(crack, transform.position, 0.6f);
print("Crack sound created");
if (isBreakable)
{
HandleHits ();
}
}
