PLANNING!
A business teacher of mine used to have a favorite saying about planning, that "failure to plan is planning to fail". This couldn't be more true in the programming world. No matter how badly you want to just get down to business and start putting stuff all over the screen, PLAN AHEAD! I don't know how many projects I've started prematurely, only to lose interest a quarter of the way through when I realize I have to completely redo a large portion of my work. Now that I think of it, my teacher had another saying: "Proper planning prevents piss poor performance." He was really into planning for the same reason, because if you just up and start a business without some sort of plan you may as well just start throwing money in a fire instead. PLAN! Here are some questions you should run through before you hit a single key on the keyboard:
- Does the platform I've chosen provide the tools/technologies I need to build this game to its full potential? If not, can I work within the limitations?
- What are the objects in my game? What are their properties and behaviors? Do any of them interact with each other?
- How can I prevent my game from being too easy or hard? Should I implement a difficulty system?
- Is this game even fun? Who would play this game? Is anyone listening to me? Where am I?
Since Breakout is already an established game that we all know is very awesome, let's focus our planning on breaking the system down into the properties that each play object has.
Game properties
- Game state (intro screen, running, game over)
- Number of lives remaining
- Score
- Playfield
- Paddle, ball, and array of blocks
Playfield properties
- Bounds (size)
- Shape and color, or sprite graphic
Paddle properties
- X/Y coordinates (x is variable, y is fixed)
- Shape and color, or sprite graphic
- Movement speed
Ball properties
- X/Y coordinates (free-moving within playfield)
- Shape and color, or sprite graphic
- Movement speed
From this little breakdown, I ended up with this code. An exercise like this as a first step is great, because I wasn't thinking about variables for ball/paddle speed, or the high-level game variables until I started jotting things down. To add to these skeleton classes, I focus on each of the objects and ask what they need to do as part of the game.
- Game: increase score, take away/add lives, change levels, manage game state.
- Playfield: be the boundary for ball/paddle, not sure what else yet.
- Paddle: move left/right, check collision with ball.
- Ball: move, check collision with paddle/blocks.
Click here to see the updated code where I have added some of the behaviors listed above as public methods of the game objects. You'll notice a Level class that I didn't mention above, which I only realized was necessary once I started breaking this stuff out. See? PLANNING! Some of the methods have placeholder arguments where they're easy enough to determine, like numOfPoints to add via Game.increaseScore(). Even though the majority of the code is comments explaining functionality, the idea is to create building blocks of code that eventually can be pieced together as the game is built.
I get it, PLANNING - Now let's make a game already!
Okay, FINE! It's obviously impossible to account for *every* issue you'll encounter while developing your game. However, the more you plan ahead the less hair you'll pull out when you need to reconsider the work you've done!
Next up: The next article should come quickly, as I'm eager to start putting all of this together and creating something playable. In the next article, we'll get our Game object rolling and start drawing on some canvas!
No comments:
Post a Comment