Monogame Breakout Overview

Overview of Breakout

BreakoutPreview.png

In this tutorial, we'll take a look at the game of Breakout, and briefly describe the game we're going to be building in this set of tutorials. We won't write any code here, so if you're ready to just dive in, feel free to skip ahead.

This tutorial will serve as the blueprints for the game we're going to build.

In the "real world," a lot of times, you don't know all of the details about what needs to be built until you finish building it. You have vague, general ideas on what needs to be done, but the specifics take time to sort out. You build it one way, then learn that that way isn't any fun for the player. You have to rip it out and try a different approach.

That whole process can be quite time consuming.

If you're trying to do that at the same time as you try to learn how to program games, it's easy to get buried underneath it all.

It's for that reason that I usually tell people who are getting started to start very simple. It's incredibly easy to underestimate how much effort goes into game development (and software development in general). Usually if a game seems simple, it's not because it is simple to make, but rather because the creators took great care in making it easy to use, masking the complexity from the user/player.

I always encourage people to either clone a classic arcade game (like Breakout) or perhaps a simple casual game. Stay away from RPGs, FPSs, RTSs, and especially MMOs. Try to pick something with minimal physics and minimal AI.

I know you're probably thinking, "but you just took all of the fun out of it!" and, "but that's the kind of game I wanted to make!"

In time, young Padawan. One step at a time. You don't want to have to sort out swept sphere vs. oriented bounding box intersections, TCP headers, network latency, and A* searches on top of trying to figure out how to get stuff drawn on the screen. So for your first game, start with something simple, and then ramp up from there.

That's why we're starting with Breakout here. It's not too complicated. Almost everybody has had some experience with it. We'll skip a few of the trickiest details and get a game that works pretty well that you can use as a chance to start seeing how to put the pieces from the other tutorials together.

The Game Basics

If you've never played Breakout before, there are a million versions of it to play online. Some try to stick close to the original, others try to put their own twist on the game. If you' haven't ever played it, you should go play one right now, or go watch a YouTube video of it.

It's basically a game where you control a paddle at the bottom of the screen and use it to bounce a ball against bricks in the level. The ball bounces off of the bricks as well as the sides and top of the play area. If the ball falls off the bottom, you lose it. If there are no balls remaining, you lose a life and if you have any lives remaining, you get a new ball to start the game.

Most variations of Breakout will have some sort of powerup system, where you can get various upgrades like extra lives, a longer paddle, or a "sticky" paddle, where the ball will stick to the paddle until you launch it again.

Our version will contain all of these basics, and will give you a framework that you could use to build even more features in the future, outside of the tutorials.

The Game Requirements

In this section, I'll outline the things our Breakout clone will do in some depth. More details will be discussed as we implement the various features.

  • The game has a few fundamental requirements that we'll include upfront:
    • The game has a black background.
    • The game window is resizeable.
    • You can toggle between full screen mode and windowed mode.
    • The game supports various screen resolutions and window sizes.
  • The game world contains simple bricks that are defined by a position, a size (usually a fixed size for all bricks in the game, we'll use 2x1), and a color.
  • The game should have the ability to randomly generate a set of bricks to play in.
  • The game contains 1 paddle (but should allow for the ability to include more for other players or for other reasons). Paddles have a size (which can change throughout the game).
  • Paddles can be moved across the screen by a player.
  • The game should support a player that uses the mouse. (Other methods of controlling a paddle, including keyboard and AI should not be prevented by the design, but won't be implemented in these tutorials.)
  • For the mouse input player, the paddle's center should try to line itself up with the mouse's x-coordinate.
  • A paddle shouldn't be able to move any part of itself off the edge of the playing area.
  • The game can contain any number of balls.
  • A ball is defined by a position, a radius, and a velocity.
  • All balls move forward based on their velocity.
  • When the ball is about to leave the play area along the left, right, and top sides, the ball should bounce off of the edge.
  • When the ball leaves the play area along the bottom, the player dies.
  • When the ball hits the top of the paddle, the ball bounces off of it as well.
  • The ball should bounce in a direction that is determined by where on the paddle it hits. When the ball hits the very left end of the paddle, it should travel to the left, with a -80 degree angle from straight up. When the ball hits the very right edge of the paddle, it should travel to the right, with a +80 degree angle from straight up. When the ball hits the very middle, it should bounce straight up. Other angles should be interpolated along this depending on where on the paddle the ball hits.
  • When a ball hits a regular brick, the brick is removed from the game, and the ball bounces off of it as it does with the walls.
  • The player has a number of lives, defaulting to 3 at the start of the game.
  • When there are no balls left in the play area, the player loses a life.
  • After losing a life, if the player has remaining lives, the game "resets" with one less life. Resetting is defined as adding in a new ball to the game in the middle of the paddle, wherever it's located. As future features are added, this will be expanded to include the ball starting out stuck to the paddle, and all powerups removed from the paddle, the ball, and the player.
  • The player's remaining lives should be displayed in the top left corner.
  • The player has a score.
  • The score is displayed in the top right corner.
  • When a brick is destroyed, the player is given 100 points.
  • When a powerup is collected, the player is given 500 points.
  • The game should support a system where new levels can be loaded or generated in sequence.
  • A level is beaten when all bricks have been cleared from the game.
  • When a level is beaten, the game should advance to the next level.
  • The game should have a powerup system.
  • When a brick is destroyed, there is a small, configurable (default to 5%) chance of it producing a powerup of a random type.
  • Powerups show up as a green square with an icon in the middle, which varies depending on the type of powerup.
  • Powerups all accelerate downward, as though they are being pulled by gravity.
  • Powerups have an angle and an angular velocity (a rate of rotation), allowing them to have a cosmetic effect of spinning in circles as they fall down.
  • When the powerup touches the paddle, it is removed from the game, and the power is activated.
  • There should be a powerup type that gives the player an extra life when caught.
  • There should be a powerup that makes the paddle extend in length through several lengths, up to some maximum. (We'll do 4 sizes larger than the default.)
  • There should be a powerup that takes all of the balls in the game and "splits" them, creating a new one with an opposite horizontal speed.
  • There should be a powerup that makes the paddle "sticky".
  • When a paddle is sticky, balls that collide with it aren't automatically bounced, but stop updating normally and follow the paddle around.
  • When the paddle has balls stuck to it, by clicking the mouse, the balls will all launch and resume their normal movement.
  • When the player dies, the paddle loses it's stickiness state.
  • The game should indicate visually somehow whether it is currently sticky or not.
  • The game should be able to load a set of levels from a file.
  • As the round progresses, the ball should speed up, up to a certain maximum limit.