# Implementing Power-Ups in a game

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:

• 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?

• 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. Feb 18 '12 at 22:46
• oh, I think i'll remove it. I probably didn't understand component-based very well. 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? Feb 18 '12 at 23:41
• This question might contain some valid approaches: gamedev.stackexchange.com/questions/13916/… 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. Feb 19 '12 at 17:56

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);


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 */
<powerup>
<effect>
<value>2.0</value>
<operator>*</operator>
</effect>
</powerup>

{
assume we store the list of effects loaded in an instance variable
PowerUpEffects */
}

{
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.