But doing a paper design doesn't help all that much when you've never seen the language before and
don't actually know what to write, or when
Ah, that's probably not what he meant though. When programming a game such like this, it's best to first approach this like a game designer (who don't need to know how to code) before diving headfirst into the cold lake known as programming.
For instance, a game designer would do this: First, draw a representation of the beginning of your game on a piece of paper. So you'll draw a rectangular box (representing your window screen the program will run in), your hero ship on the bottom of that screen along with the enemies on top and any other stuff such as score or lives remaining and whatnot.
Second, begin scripting. What I mean by that is visualize what's supposed to happen when an event occurs. For instance, hitting the left arrow key moves the spaceship some amount of space to the left. Draw that. When you left-click, the ship fires a projectile. Draw that. When a projectile hits an enemy ship, the ship explodes/disappears and your score increases. Draw that. If an object hits the boundary of your drawn rectangular box, it "bounces" in the opposite direction. Draw that. And so on. (you actually don't have to draw ALL states of the game, but it's good to keep it in mind).
Once you've drawn or thought about the different states of the game, you can now pseudo-code. This is when you start thinking about how you're going to attempt to put this into code without actually putting it into code. Basically, you'll write down a bunch of algorithms that make up specific states of your game. You should also at this point recognize and write down any classes and objects that you see you will need (NOTE: again, no need to code this. Just write down that you need a Class called Enemies that will store these variables and might need such and such methods - no coding required yet!)
***********************************************
Here's an example of the above process related to your boundary question of making sure things don't go offscreen. You've drawn your game screen as a rectangular box. Let's pretend that box is a 640x480 window screen on your computer. Let's also pretend it's a 2-D grid of pixels (each one having x, y coordinates) and that every object on the screen can be shown as existing at some particular point in the grid. The (0,0) point is located at the
top left corner of your drawn box. This means X increases going right and Y increases going down. With this information, you know an object has hit a boundary when its coordinates are any one of the following:
1)it's x coordinate is ~0 (hit the far left side of the screen).
2)it's x coordinate is ~640 (hit the far right side of the screen)
3)it's y coordinate is ~0 (hit the top of the screen)
4)it's y coordinate is ~480 (hit the bottom of the screen).
(I'll save why I put approximations for another day to keep this example simple
So the questions here are 1)how do I keep track of the present coordinates of my ships at all times and 2)how to resolve boundary issues.
Well, the first question should immediately tell you that every class object on the screen (Hero class, Enemy class, projectile class, and so on) will possess two float variables that store each object's X and Y coordinates (or you can use a vector, array, etc). From this, you'll also probably figure out that you'll need a couple methods to initialize these coords, change these coords, return these coords at any time, and another method to calculate how close to the edges each variable is (and here we lead into the 2nd question). Again, no need to code what each method will do. Just simply write down its "signature" - that is, write down the return variable if any and its parameters if any, like so:
void moveShip(float X, float Y)
float getXCoord();
boolean hitBoundary();
Now that you have a method that calculates how close to the edge of your game screen an object is, you can have another method that corrects a boundary event. That too is simple to realize now. If the x coordinate is ~0, you simply
increase X to move object in the opposite direction. If that X coordinate is instead ~640, you
decrease it. Same for Y coordinates.
So that's basically it for the boundary portion. From here, you can move onto breaking down another part of the game, such as figuring out how you know when a projectile has hit a ship (hint: very similar process to figuring out how you have hit a boundary) or how to move an object diagonally.
So the gist here is that it's always beneficial to start out with a pen and paper (or maybe a tablet and stylus in this day and age). No programming required. It sounds like a lot of workr, but once you get into the groove, you'll realize that it's really simple and will go by fast; and most importantly, will help you figure out how to approach coding your program
