I am making an arkanoid type game and have it mostly working. I can destroy the bricks when hit by the ball, but I am adding a twist. I want to have a object on top of the bricks that will interact with the bricks but not destroy them. It needs to still be affected by gravity and collisions because when you collect them all you win the game(you collect them by getting rid of the bricks below them. Everything is pretty much working except for when this object collides with the bricks it triggers the destroy function within the brick script. I am using C# and unity 4.6.9. Thanks in advance! I can give pictures and scripts if people want, IDK what would be exactly relevant here though because I'm not sure if this is something done in unity, in the brick script, or in the falling object script.


1 Answer 1


There are two ways to attack this.

1) The ball breaks bricks

Create a "Breaker" component and attach it to your ball. This component's OnCollisionEnter method should check if the other collider is a brick (depending on your style, you can do this by checking whether it's in the "bricks" physics layer, or has the tag "brick", or has a "Breakable" component attached, etc) and if it is, destroy it.

(Or, ask that object's "Breakable" component to TakeDamage() or Shatter() - which might involve playing some VFX & sound specific to each kind of brick)

Something like...

public class Breaker : MonoBehaviour {

    // Tune this if you want a "superball" that breaks bricks faster...
    public int damagePerHit = 1;

    void OnCollisionEnter(Collision collision) {
        // Request a Breakable component from the thing we collided with.
        var breakable = collision.gameObject.GetComponent<Breakable>();

        // If it gave us a Breakable component, deal damage to it.
        if(breakable != null)

public class Breakable : MonoBehaviour {

    // Tune this to adjust how many hits each brick type takes to break.
    public int hitsRemaining = 3;

    public GameObject breakFX;

    public void TakeDamage(int damageAmount) {
        // Apply damage to our hit counter.
        hitsRemaining -= damageAmount;

        // Add code here if you want the brick to show a damaged state,
        // like changing colours or becoming cracked.

        // If we have no hits remaining, break this brick.
        if(hitsRemaining <= 0)

    public void Shatter() {
        // Here we do whatever the brick needs to do when broken.
        // Spawn VFX, sound, shake the screen, increment score, etc.
        // We can also farm this out to other components if we want lots of
        // different brick behaviours (eg. explosive bricks, money bricks...)
        var fx = (GameObject)Instantiate(

        // Now we'll destroy ourselves as requested.

Don't put this Breaker component on the new objects you're adding on top of the bricks, and now they won't break the bricks, because there's nothing to trigger the break action. That capability lives solely on the ball object.

I prefer this method because it puts the onus for triggering the action on the object that, from a player perspective, visibly causes the action. That makes it intuitive for me & other team members to know where to look if we want to tweak the trigger conditions (say, changing the damage done on each hit, or only dealing damage on collisions above a certain velocity, or only when the ball is in a "supercharged" state, or...)

2) Bricks are broken by the ball

As an alternative, you can invert this logic. Have a Breakable component on each brick that, OnCollisionEnter, checks whether the object that collided with it was a ball (as before, using layers, tags, or a component check), and if so it destroys itself.

Personally, I don't like this second style as much, because if I add a new type of thing that should break bricks (say, I introduce shrapnel objects spawned by hitting explosive bricks), then I need to go back and edit the brick's script to make it aware of this new thing.

I'd prefer to keep such changes centralized to the new content I'm adding. ie. putting a Breaker component on the shrapnel object: then the existing brick-breaking behaviour will be triggered by the shrapnel without needing to update each breakable thing. This keeps the code less coupled and easier to iterate on, especially for level designers on the team who can add/remove components and change inspector parameters but aren't necessarily accustomed to making code changes.

See this question for more exploration of these two styles.

Last note: remember to change this to OnCollisionEnter2D etc if you're using 2D physics!

  • \$\begingroup\$ I'm going to try this tonight when I get home and update when I come back into town for internet. I think I'm going to use the second method because I want the bricks to count how many times they have been hit so they explode after x hits and with my low understanding of code it seems more strait forward in the second method. Thanks! \$\endgroup\$
    – Isak Jones
    Sep 8, 2016 at 0:37
  • \$\begingroup\$ In a case like that, I'd recommend the first style even more strongly. I've edited the example to show how you can incorporate it fairly simply. This lets the thing doing the damage determine how much damage it wants to do (great if you later want to introduce a "superball" that destroys bricks in one hit), without hard-coding every possible case into the brick itself. \$\endgroup\$
    – DMGregory
    Sep 8, 2016 at 1:15
  • \$\begingroup\$ I spent the weekend trying to get it to work but I couldn't figure it out. I think it's because I'm just getting into coding so I decided to leave this feature out of the game, at least right now. Thanks! \$\endgroup\$
    – Isak Jones
    Sep 13, 2016 at 22:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .