# How do I implement Breakout's "multiball" powerup?

I'm just starting out and making a breakout clone as my first game. I'm implementing all kinds of powerups, but I'm stuck on multiball. The powerup adds additional bouncing balls to the game.

So far, I've implemented powerups by just adding them to the Ball class as states. This is easy for increasing speed, making the ball sticky, changing sprites and such. When the ball is in one state it behaves in only one way.

Now, how do multiple balls fit into this? I suppose having more balls is more of a function of the game itself than the Ball, so it seems logical to make it a game state instead of a ball state. How would I do this?

• Hey, welcome to GD:SE. Glad to have you on board. This could be very open ended as a question and we try to make questions as specific to a problem as possible so others can benefit when searching later. Have you actually tried anything yet? If you have edit the question to let us know, we might be able to help you more. Feb 24 '14 at 9:34

## 3 Answers

I think you are stuck on trying to implement utterly dissimilar powerups using a unified system. That seems like a mistake, and it might become obvious if you thought about the idea of multiple balls outside the context of a power-up: multiple balls are simply more instances of a Ball object.

Handling multiple balls in code would not require a "gamestate", and it would not conflict with or complicate your existing "ballstate" logic. There are just more objects in play.

The only difficulty in this method is that you might need to change your update and draw logic slightly. If you have built your code around a single, global Ball instance, a good first step would be refactoring to make that code operate on a method argument. For example:

/*  the old
Ball globalBall;
void Update() {
globalBall.Move();
globalBall.Collide();
}
*/

// the new
List<Ball> allBalls;

// this old code is useful for a single ball; leave it mostly intact.
void UpdateBall(Ball ball) {
ball.Move();
ball.Collide();
}

// new code to deal with multiple Ball objects
void Update(){
foreach (ball in allBalls){
UpdateBall(ball);
}
}


The gist of it is, don't force your previous solution onto this new concept. Although sticky- and multi- might both be triggered by powerups, they are very different concepts. It's ok to create independent code paths to accomplish different game features.

If you have further difficulties, please edit your question to specify them. That will allow more helpful answers.

TL;DR: Summary is that Multiball should not be a state that you need to track so all you need to do is react when you 'collect' the power up. But no states, game or ball, really need to be changed.

I have two assumptions, first is that you have a system already capable of rendering more than one ball. If that is not the case then see @SethBattin's response. Secondly, I assume multiball in your game works like it does just about everywhere else in that you simply release more balls into the game but the game play keeps on going as it normally would.

In this case then this is a power up that you do not need to track the state of. All you need to do is when a ball is 'given' the multi-ball power up (or in place of the state change), create X number of balls and give them their starting location/direction or whatever else they need (If you hit a multi-ball while doing a speed powerup do the new balls also need to have that powerup for example).

If Multi-Ball is timed then you are going to get into quite a few more issues and this is probably why it is not done this way... (Or that this comes from pinball games where you could not track which ball was the original ball really). However, you would want to put the new balls that you create into a multi-ball state so you can track which ones have to go away. The reason I would suggest Not doing this is because what happens if they lose the original ball? Is the game just over? Should the game just end when the original ball goes away then instead of when all the balls are one? All of this is up to you if you are doing it this way.

Hope this helps.

I would add all the powerups as game states rather than ball states. If your board/level/game object has references to your ball&paddle objects, it could delegate further if necessary. For instance, a typical powerup would be increasing/decreasing width of paddle, and it will be much easiar for you to generalise it as game-wide states, instead of having powerup A as a state on Ball, powerup B as a state on Paddle, etc.