user’s score. I guess that it’s the video version of grade inflation.

I then displayed the version of the lander with no flames in the picture box by copying the appropriate image (number 0) from the ImageList. I did this because no flames should be the default setting. I’ll add the flames later if I discover that the user is pressing a key.

The last three lines of the tick() method call other custom methods. The timer has three more important jobs to do, but each is detailed enough to merit its own method. I gave the methods names indicating the main jobs that need to be done. Leaving the details of (for example) moving the lander, updating the score, and checking for collisions to other methods is a good idea because leaving all that code in the tick() method would make the method extremely complicated and difficult to read and fix. With the custom methods, it’s very easy to see the main flow without getting bogged down in details. Of course, you need to worry about the details at some point, but they’re easier to work with in isolation.

Trick Whenever one method starts to be more than one screen long, consider breaking it into multiple methods. This way, you can break the work into smaller chunks that are easier to manage.

The moveShip() Method

The moveShip() method handles all the movement of the lander on the screen. The code should look familiar.

private void moveShip(){

//change x and check for boundaries x += dx;

if (x > this.Width − picLander.Width){ x = 0;

}// end if if (x < 0){

x = Convert.ToDouble(this.Width − picLander.Width);

}// end if

//change y and check for boundaries y += dy;

if (y > this.Height − picLander.Height){ y = 0;

}// end if if (y < 0){

y = Convert.ToDouble(this.Height − picLander.Height);

}// end if

//move picLander to new location picLander.Location = new Point(Convert.ToInt32(x),

Convert.ToInt32(y));

} // end moveShip

The process of modifying dx and dy is probably routine for you by now, but this routine has one twist. Because I’m working in double values, I can’t simply copy the screen location to x when I want to move to the right or the bottom of the screen. The compiler complains about the conversion from integer to double. I simply used Convert.ToDouble() to get past this problem.

Likewise, when I was ready to place the lander in its new position, the values of x and y were doubles, but I needed ints. Again, the Convert class came to the rescue.

196

The checkLanding() Method

The interesting moments in the game occur when the lander gets close to the platform. When these two components are in proximity, it means either a crash or a landing. The checkLanding() method determines whether the lander is near the landing pad and, if so, whether it is a safe landing or a horrible crash:

private void checkLanding(){

//get rectangles from the objects Rectangle rLander = picLander.Bounds; Rectangle rPlatform = picPlatform.Bounds;

//look for an intersection

if (rLander.IntersectsWith(rPlatform)){ //it's either a crash or a landing

//turn off the timer for a moment timer1.Enabled = false;

if (Math.Abs(dx) < 1){ //horizontal speed OK if (Math.Abs(dy) < 3){

//vertical speed OK

if (Math.Abs(rLander.Bottom − rPlatform.Top) < 3){ //landing on top of platform MessageBox.Show("Good Landing!");

fuel += 30; score += 10000;

}else {

// not on top of platform MessageBox.Show("You have to land on top."); killShip();

}// end on top if

}else {

//dy too large

MessageBox.Show("Too much vertical velocity!"); killShip();

}// end vertical if

}else {

//dx too large

MessageBox.Show("too much horizontal velocity"); killShip();

}// end horiz if

//reset the lander initGame();

} // end if

}// end checkLanding

This code might look long and complex at first, but it is not difficult. The hardest part of writing this method was figuring out what constitutes a safe landing. I determined that a safe landing occurs only when all the following criteria are true at the same time:

∙The rectangles for the lander and platform intersect.

∙The horizontal speed (dx) of the lander is close to 0.

∙The vertical speed (dy) of the lander is smaller than 3.

∙The lander is on top of the platform.

197

The easiest structure for working with this kind of problem (where you can proceed only when several conditions are met) is a series of if statements nested inside each other. This structure is named (not surprisingly) nested ifs. I decided to turn each of the criteria in the list into an if statement and nest them all inside each other. In other words, I started by checking to see whether the platforms intersect. If you look back at the code, you see that the first if statement checks whether the rectangles intersect. If that condition is true, something has happened. If all the other conditions are true, the player has landed successfully, but if not, there has been a crash. If the rectangles do not intersect, there is no point checking the other conditions.

In the Real World

The nested if structure is commonly used whenever a programmer needs to check for several conditions. In more traditional programming (the kind you’re more likely to get paid for), you commonly use nested ifs whenever you want to do some sort of validation. For example, if you write a program that processes an application form, you probably won’t allow the program to move on until you are sure that the user has entered data in all the fields and that all the data can be checked. Validation code usually uses the same nested if structure as the Lunar Lander game. However, there are not as many cool effects when the user doesn’t submit a valid email address. (I’ve always been tempted to add explosions in that sort of situation, but so far, I’ve been good.)

Checking the Horizontal Speed

If the rectangles do intersect, another if statement checks what the horizontal speed (measured with the variable dx) is. I wanted to require that the ship be nearly motionless along the X axis because the legs of such a craft can’t handle much sideways velocity. (Also, this rule makes the game more challenging!) I figured that a value between –1 and 1 for dx would be a good range. However, testing for a value greater than –1 and less than +1 is a little ugly. I decided to take advantage of the built−in absolute value method of the Math class, Math.Abs(). As you may recall fondly from math class, the absolute value of a number strips the sign off a number, so the absolute value of –1 is 1, and the absolute value of +1 is also 1. By using the Math.Abs() method on dx, I was able to determine a very small horizontal velocity with only one if statement.

Checking the Vertical Speed

The vertical speed is calculated much like the horizontal speed. You might be surprised that I still used the absolute value function here because the lander will always approach the platform from the top and will always have a positive dy value if a legal landing is possible. This is true, but I seriously thought at one time about allowing landings from the bottom (maybe you’re attaching a balloon to a floating platform). This would greatly change the strategy of the game and allow for interesting piloting situations, so I left the absolute value in here, just in case. (Does that sound like a dandy end−of chapter exercise, or what?)

Ensuring That the Lander Is on Top of the Platform

The last requirement for a healthy landing is that the lander must touch the top of the platform (at least for now). This turned out to be an easy thing to check. I just used properties of the picLander and picPlatform picture boxes to compare the bottom of picLander and the top of picPlatform. I used the absolute value method again to ensure that the bottom of the lander is within 3 pixels of the top of the platform.

198

Managing a Successful Landing

If the player passes all four landing tests, the program sends a congratulatory message, loads up more fuel, and adds significantly to the player’s score. If the player fails to pass any of the landing criteria, but the rectangles intersected, the program responds with an appropriate message and calls the killShip() method, which handles the details of lander destruction.

Handling User Crashes

If the rectangles intersected (regardless of the rest of the consequences), the method calls the initGame() method to reset the positions of the lander and platform.

The theForm_KeyDown() Method

The player interacts with the program through keyboard commands. The up arrow fires thrusters that slow the effects of gravity and can eventually push the lander upwards. The left and right buttons fire side−pointing thrusters that allow side−to−side mobility. The keyboard handling routine is familiar if you investigated the Mover program earlier in this chapter:

private void theForm_KeyDown(object sender, System.Windows.Forms.KeyEventArgs e) { //executes whenever user presses a key

//spend some fuel fuel−−;

//check to see if user is out of gas if (fuel < 0) {

timer1.Enabled = false; MessageBox.Show("Out of Fuel!!"); fuel += 20;

killShip();

initGame(); } // end if

//look for arrow keys switch (e.KeyData) {

case Keys.Up:

picLander.Image = myPics.Images[1]; dy−= 2;

break;

case Keys.Left:

picLander.Image = myPics.Images[2]; dx++;

break;

case Keys.Right:

picLander.Image = myPics.Images[3]; dx−−;

break;

default:

//do nothing break;

}// end switch

}// end keyDown

Every time the user presses a key (even non−arrow keys!), the program uses up one unit of fuel. As I’ve said many times, if you increment or decrement a variable, you should test for boundary conditions. Because I’m decrementing the amount of fuel, checking for an empty gas tank is

199