I'm making an Arkanoid or Brick Breaker game, but I got confused when I wanted to implement power-ups. The idea is that when you destroy a brick, a powerup-block falls down, and if you catch it you'll get the powerup. -for example:

  • Wider Paddle (change dimensions of the quad)
  • Change ball speed (variable)
  • Ball goes through blocks (no reflection on hittest)
  • Shoot lasers from the paddle (change in input handling)

Now I pretty much know how to affect the code to achieve these effects, however not in a clean, flexible way. I have my ie my ball and paddle hard-coded in java (GameObjects), and my Levels/BlockTypes in xml.

One terrible way to do it is to have like a flag telling which powerup is active, and by that alter the code with loads of if- statements.

Could anyone help me with how this is done?

  • \$\begingroup\$ One of your tags is confusing me: if you're using a "component-based" system then each powerup would just be a component that you could apply to your Paddle or Ball entities. But you say they're hardcoded. If they're hardcoded, it's hard to tell you what to do since I don't know how you've structured your objects in relation to one another. \$\endgroup\$
    – Mike Cluck
    Feb 18, 2012 at 22:46
  • \$\begingroup\$ oh, I think i'll remove it. I probably didn't understand component-based very well. \$\endgroup\$
    – user717572
    Feb 18, 2012 at 23:08
  • \$\begingroup\$ Define "clean, flexible way." How "flexible" do you want things? Do you intend to script these things? Do you want the script to be able to do anything, or only a fairly enumerable set of possibilities? \$\endgroup\$ Feb 18, 2012 at 23:41
  • \$\begingroup\$ This question might contain some valid approaches: gamedev.stackexchange.com/questions/13916/… \$\endgroup\$
    – bummzack
    Feb 19, 2012 at 0:00
  • \$\begingroup\$ I'd recommend using the flag + if statements for now (it doesn't seem so terrible to me), get it working, and then later evaluating what advantages you might get from a different approach. Sometimes the right abstraction won't be clear until after you've coded it the simplest way. You'll start seeing patterns and repetition, and that'll tell you what abstraction to use. And sometimes even if there is an abstraction, it's not worth the cost. \$\endgroup\$
    – amitp
    Feb 19, 2012 at 17:56

2 Answers 2


The simplest solution I can think of to solve this problem would be to add accessors to whatever objects you would to be modified by power ups. For instance, your paddle would be an instance of the paddle class and have the accessors:

public void setPaddleWidth(int aWidth);
public int paddleWidth();

The accessors would define the public interface that your power ups will have access to. To your power ups class, you would have this method:

public void pickedUp(Paddle targetPaddle);

However you go about detecting that a power up is picked up, you call that instance method on the appropriate power up. The purpose is to put your effects code in that method; so a power up that doubles the width of the paddle would have this in its pickedUp method:

targetPaddle.setPaddleWidth(targetPaddle.paddleWidth() * 2.0);

If the effects of the power up are loaded from an XML or other data file, instead of being hardcoded to the power up, you can do this (psuedocode):

/* Data File Example */
    <name>Double Paddle Width</name>

public void loadFromFile(String aFilePath)
    /* Do whatever you need to load your data here; 
    assume we store the list of effects loaded in an instance variable 
    PowerUpEffects */

public void pickedUp(Paddle targetPaddle)
    for (Effect anEffect : PowerUpEffects)
        /* Modify targetPaddle based off the effect 
        name, value and operator. In this case, we would change 
        the paddle width, by multiplying by a value of 2.0 */

I implemented sth similar for an open source MORPG, where we needed infrastructure to make any attribute of players or creatures temporary modifiable, while avoiding to persist the actual modified value to the database.

The basic idea, we had in mind, was to store the modifying values in objects that are separate from the actual modified objects. For instance a player that gets a health points (HP) boost would get added a Modifier-object that tells on HP-calculation on how much to adjust the HP (i.e. HP raises by 50%).

Out of this we came to the following class structure: class diagram of draft for modifiers

The yellow classes denote the actual game entity hierarchy. In blue we have the full infrastructure for handling the modifiers. (You can ignore the TurnNotifier)

The ModifierHandler classes and the AttributeModifier help with managing those modifying objects. The Handler is delegated to whenever a possibly modified attribute's actual value is needed and the handler then calculates the actual value based on the "normal" value and the modifiers that are known to him.


You must log in to answer this question.

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