I am working on a brick breaker style game (i.e., like Arkanoid) in C#/XNA. As I add more features such as powerups, special brick types, etc I am running into problems figuring out how the whole game should be structured. For instance, I have a static CollisionManager class that my ball objects call each update to check if they are hitting something like a brick. While this works, it also puts the ball object in charge of updating other objects (such as letting the Brick know it has been hit, or some other game function not directly related to the ball).

Every powerup or feature I add keeps forcing me to re-evaluate how everything is pieced together. Are there any types of standard layouts I could use to help minimize problems like this? I like the idea of having my CollisionManager just manage collisions, and my ball objects just managing stuff related to the ball, and bricks managing brick stuff; however, some cases require updating multiple things. This leaves me trying to figure out just which part of my app I should put in charge of the dirty work of handling these specialized tasks.

  • 2
    \$\begingroup\$ This is exactly why people always say 'start small' when someone asks how to make the next DooM as their first game project. \$\endgroup\$ Oct 30 '11 at 9:50
  • \$\begingroup\$ Now that I am into it I can agree. It started out as Pong, then I decided to add some bricks, and now I've moved on to fleshing it out a bit. I don't really think the game is complex or a huge undertaking (i.e., like the next Doom :), but it's mostly me being anal about doing things the right way. \$\endgroup\$ Oct 30 '11 at 22:42

I think it's a good design to encapsulate functionality within a given class. The ball knows about ball-related stuff, while bricks mind the brick-related business...

Your problems seems to be how these components communicate and how you can easily add new features. The best way (architecture-wise) is to have very generic components that are as loosely coupled as possible. A good architecture would be components.

For a simple game like Breakout, a component based architecture might be overkill. Instead, you could do something like this:

Game: (or Level?) keeps track of all entities and performs the update method on all of them.

CollisionManager: Detects collisions and notifies bodies/entities that were part of the collision. You could do this by implementing a messaging system or by invoking a method like handleCollision on the entities.

Ball: has velocity and direction and updates its position. For greater flexibility, you could make the Ball a state-machine, so you could easily implement different behaviors as different states. This could come in handy for behaviors of power-ups.

Brick: Could also be implemented using a state-machine to implement different brick-states.

Probably the biggest gain for your game would be some kind of messaging. The Brick could send a message when it gets destroyed (eg. hit by the ball). The score-manager could listen to that message and update the score accordingly. The message could also trigger a power-up to appear randomly etc.

The benefit of having a messaging-system (or a similar pattern like "signal and slots" or the observer-pattern) is that you can have loosely coupled components that communicate with each other. So you can easily add more components later on by having them listen to messages and perform some tasks. Imagine you got the messaging system in place as described above and your Brick sends out a message when it gets destroyed. Listeners will make sure the score is being updated and there's a random chance that a power-up will appear. Now you could simply add another listener for that message that will play a special sound whenever that brick gets destroyed...

  • \$\begingroup\$ It's almost eerie how you described my current setup (near 100% accuracy). This is the first I have heard of a messaging system between objects, and it sounds exactly like what I need. The links are also greatly appreciated, they cover some subjects I have had a hard time finding info about. \$\endgroup\$ Oct 30 '11 at 22:37

If your collision manager is managing collision, then that means it has access to your bricks and your ball(s). So shouldn't your collision manager be managing collision and updating your ball(s) and also the bricks that it hit?

If that is the case then your collision manager would need to be passed the bricks that the ball could possibly hit.

I would create a helper function that would split the screen into quadrants. This helper function can then detect what quadrant the ball(s) is in and then check against the list of bricks and detect which ones are within the same quadrant. If any are in the same quadrant as the ball, I would then put all of those bricks into a new list, and pass that into the collision manager and do the collision checks on those. (Make sure to pass the list as a ref so any changes done on any bricks passed in gets reflected on the original brick).

That should take away the updating responsibility from the ball.

As for a general structure, I like to contain everything within a GameManager. So this game manager would contain the ball manager and brick manager. I would make the collision manager a singleton. That way you don't have to ensure that every other manager or class has an instance of the collision manager within it.

So the game manager would call the ball and brick managers update methods and within those updates, collision checks would also be done.

Hope that helps. Good luck.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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