Parameters

Usually, "parameters" are values that are passed to a method. For that reason I've tried to avoid referring to altitude, velocity, etc. as parameters, but that is really the correct name for them. More generally, "parameters" are variables whose values need to be adjusted. For Lunar Lander you need to find some appropriate values for these variables, but they will be "hard-wired" into the program.

Here are the parameters I'm talking about:

initial altitude

How high the Lunar Lander is at the start of the game.

initial velocity

How fast the Lunar Lander is moving toward the moon (0 is a good value).

initial amount of fuel

How much fuel you have at the start of the game.

acceleration of gravity

How much to add to the velocity at each step. You may want to use the moon's actual acceleration of gravity, 1.62 meters/second/second (the Earth's is much higher, 9.81 meters/second/second).

fuel factor

How much to reduce your velocity for each unit of fuel that you burn. (Optional: you can assume that 1 unit of fuel decreases your velocity by 1.)

safe landing speed

The maximum speed at which you can impact the moon and still survive (it's almost impossible to make a perfect touchdown.)

This is a game, not a careful simulation, so you can choose whatever numbers seem to work well. A good set of numbers will make it difficult but not impossible to win the game.

Hint: The way to win is to burn your fuel as late as possible. And that reminds me of another parameter you should have:

maximum burn rate

The maximum amount of fuel you can burn at any step.

Since I did not put this in the original assignment, it is not required--but I do recommend it, since it makes the game a lot more interesting.

These numbers should be hardwired--that is, built into the program itself, not read in from somewhere. There are two ways to do this:

Good style:

double acceleration = 1.62;
...
velocity = velocity + acceleration;

Poor style:

velocity = velocity + 1.62;

There are two problems with the second approach. First, it uses a magic number--an anonymous number with no obvious meaning or reason (the first approach gives it a name and this helps to explain what it is doing in the code). Second, if you need to use the value in more than one place in the code, you have to search for every place you used it, rather than just changing it in one place.

You don't have to worry about what units (meters, miles, etc.) these numbers are in. Java doesn't have any convenient way to specify units.

Improved IOFrame class

I've made two changes to IOFrame.java. The new version is upwardly compatible with the old version--that is, it won't break your program if you replace the old version with the new version.

First, in order to avoid the error message,

BlueJ configuration error:
text not found for message ID
compile-while-executing

I have added a method exit() to the IOFrame package. You can use this method to close the IOFrame window and exit the program.

Second, I've improved the display so that when you resize the window, the output area resizes properly.