Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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. – Mike C Feb 18 '12 at 22:46
oh, I think i'll remove it. I probably didn't understand component-based very well. – user717572 Feb 18 '12 at 23:08
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? – Nicol Bolas Feb 18 '12 at 23:41
This question might contain some valid approaches:… – bummzack Feb 19 '12 at 0:00
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. – amitp Feb 19 '12 at 17:56
up vote 3 down vote accepted

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 */
share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.