Planning Your Game

Planning Your Game

So you’re ready to make your first game, or you’re ready to make your 33rd game. The first steps are the same, plan it out into discrete peices of work that you can complete it in your spare time.

For the purposes of this article, we’re going to be making a game I just made up. I call it Breakeven. In it, you have a paddle that you move left and right on the bottom of the screen, just like in Breakout. However, you don’t break blocks in this game, instead, you are trying to hit little coloured circles. Big circles are worth a small amount of points, small circles are worth more. The smaller the circle, the more points you get if you hit it.

There’s a time-limit, so a player only has one minute to score as much as possible. The circles are placed randomly at the start of the game.

To make things a little harder, there are some rectangular blocks that our ball will bounce off of. The ball also bounces around the edges of the screen, except the bottom. If you fail to hit it with your paddle then the game is over and you get as many points as you’ve scored so far.

Sound good? Great! Let’s plan it out.

Feature List

So, as per my article on how much you can do, let’s list out our games core features:

1. Player controls paddle with arrow keys on the keyboard
2. Ball shoots directly up when player starts by pressing spacebar
3. Ball bounces accordingly to reflection with no friction, rotation, or angular velocity
4. When the ball hits the paddle directly: If the ball lands on the left-hand third of the paddle, it bounces off at a 45 degree angle to the left. It does a similar thing on the right-hand outer third of the paddle. Centre third is a bounce directly up.
5. When the ball hits the paddle at an angle, it bounces off as a reflection regardless of where on the paddle it hits.
6. Game has n number of blocking rectangles inserted randomly within the top two-thirds of the screen
7. Game has n number of big, medium, small, and tiny circles distributed randomly in the top two-thirds of the screen
8. If the ball intersects any circles, the player gains some points. Big circles are worth the least amount of points, tiny are worth the most.
9. Ball bounces off of the sides and top of screen
10. Ball bounces off of blocking rectangles
11. If the ball hits the bottom of the screen, the players run ends and they are given their score
12. If the 1 minute time-out runs out, the players run ends and they are given their score
13. If the player collects all the points, the players run ends and they are given their score
14. Main Menu has four options: Run, High Scores, Exit
15. High Scores allows you to see the top 10 scores of all time
16. When the game ends, if the player reaches a new high score, they enter their name
17. When the game ends, the player is taken to the high score screen, where a “game over” message is displayed. Player is given option to return to main menu, or run again.
18. Bounce sound is played every time ball bounces
19. Point collection sound is played every time points gained
20. Current score is displayed at the top of the screen
21. Electrified music track is played throughout the entire game, it doesn’t change from menu to game

That seems like it might be a pretty fun game. Notice how we’ve thought about as much as possible? I’ve probably forgotten some stuff, but we can come back and add to it when we think of other things. From my article about managing scope, I can guess it’ll take about 12 hours to deliver each of these features… though looking at the list some will be pretty quick. Let’s say maybe 6 hours per feature, I’m feeling ambitious.

That means the game as above will take me about 132 hours to complete. Or because I know I can do about 18 hours a week on my game (that’s my spare time I can dedicate), that means it’ll take me about 7.5 weeks to complete. Two months in total? That’s not bad. At this rate I’ll be making six small games a year.

This is a good and realistic measure of how long our simple little silly game will take.

Now let’s add some stretch goals. These are features that would be nice to have.

1. Music becomes more paniced as time starts to run out
2. Game over music is different to menu music and in-game music
3. Options menu that allows player to change audio settings and what rendering device to use
4. Options menu that allows player to set the colours of the paddle, ball, background, blocking rectangles, and circles
5. Some special-effect circles are present that can hinder/help you:
   • Enlarger Cirlces makes your ball bigger
   • Diminisher Circles makes your ball smaller
   • Slow-mo Circles slow the ball’s velocity (hey we forgot to mention the balls velocity in the core features, it should be a constant value)
   • Hasten Circles makes the ball faster
   • Upside Down Circles flips the screen vertically for ten seconds so you’re suddenly playing upside down!
6. These circles should have some icons so the player can identify them and try to avoid them, there’s always one of each in the run.

That makes the game sound pretty super-fun now. Now let’s move on to the technical features we need to address the above.

Technical Features

A good starting point here is the game engine. Are we using an existing free engine, or are we going to roll our own? Maybe we can just use a library like SFML or SDL?

I personally roll my own libraries and engines because I have more fun doing it that way. But it also means that if I were to make this Breakeven game, the starting point I have is close to an existing engine, and is at least a fairly full-featured library. So you might want to start with an existing engine and ignore the way I do things.

In any case, our library or engine, at a bare minimum, needs to be able to:

1. Play Sound
2. Render circles and rectangles in a colour
3. Render text
4. Handle keyboard input

Good news is that pretty much every game engine or library in existence can do all of that. But we still need to build our systems on top of this. What else do we need?

1. Collision detection
2. Vector math
3. Buttons that a player can click

Maybe your library or engine already has the above. Maybe you need to code these up. If you need to make them yourself, here is your starting point.

Now if we think of the game in terms of Object Oriented Programming, or at least in terms of encapsulation and responsibility, what we can break the game down into is:

1. Game Objects – these are the things that can collide. The paddle is one, the ball bounces, bounces off our blocks as well. The ball also collides, but doesn’t bounce, against the points-circles. If all of these things are, at their base, game-objects, it will allow us to store them in a single array. More importantly, it should mean we will have less code-repetition (the ball bouncing on the paddle is almost identical to it bouncing on the rectangle).
2. Messages – “the ball has bounced” is one message, another is “a points circle has been hit”. The messaging system is often important because we don’t want to litter our collision code with calls to increase points and calls to play sounds. Instead, we’ll just post a message that says “ball bounced!” and our other systems can deal with what messages they want.
3. Game State – The game is sort of it’s own state machine. It’s either LOADING, in the MAIN_MENU, in the GAME, or getting HIGH_SCORE_INPUT. The menu itself is it’s own little state machine as well, you could be in the main menu, or in the high scores.

So we’ve got a bit of architecture going here, let’s start drawing it out. I use UML, and I use it fairly loosely, especially at this stage.

This may not make sense to you, but it doesn’t need to. It’s just to illustrate the amount of planning to do. I would continue the above until I’ve fleshed out exactly what each of these classes will do, and what data each of them will contain.

This leads you to…

Sequencing your build

So now you know exactly what you need to code. You also know exactly what images need to be made, and exactly what sounds and music you’ll need.

So the final step is to simply order these based on what is required by what. So for example, there’s not much point is setting up your audio system if you haven’t got any sounds to play.

You’ll find that there’s whole streams of work that can be independent of the others. This is fantastic because it means if you get bored of doing what you’re doing, you can change into one of the other streams. Sick of programming a messaging system, cool, let’s work on collision detection. Oh your eyes hurt? Let’s make some music instead.

I hope this helps someone in planning and successfully completing their own little game.