CS 124, Fall 2011
Lab 7: Work on Project 2 (plus Final Project, Phase I)

In view of Fall Break, the due date for Lab 6 has been postponed to Friday. For this week's lab, you can continue work on Lab 6, or you can work on Project 2. However, there is one additional, non-programming exercise for this week: You should write two short proposals for final projects, as described later on this page. Here are the due dates for all this:

• Lab 6 Exercises: Will be collected at 2:00 PM on Friday, October 14. You should copy your lab6 directory into your homework directory before that time.
• Final Project Proposals: Due in lab on Thursday, October 20. You should turn in your proposals on paper at the lab. They can be hand-written or typed. You will get a few lab points for doing this (5 points for a serious effort, but possibly less if it is clear that your effort is less than serious).
• Longer Project 2: Will be collected at 2:00 PM on Friday, October 21. You should copy your proj2 directory into your homework directory before that time.

Style Rules For Subroutines

Here are a few new style rules, relevant to writing subroutines and using member variables. You are expected to follow these rules, starting with Project 2.

• You should always use meaningful names for variables and subroutines.
• The name of a subroutine should begin with a lower case letter.
• Subroutines and member variables should be private, unless they are really meant to be part of the public interface of the class where they are defined.
• A subroutine should always have a single, well-defined task.
• Member variables should be used to save information about "state" that has to be saved between calls to subroutines. They should not be used for simple communication between routines; use parameters and return values for that.
• Every subroutine should have a comment that describes the task performed by the subroutine, the purpose of each of its parameters, and the meaning of the return value, if any. It should also describe any important exceptions that can be thrown by the subroutine. For non-private subroutines, at least, the comment should be in the form of a JavaDoc comment. That is, it should come just before the definition of the subroutine, and it should start with /** and end with */. (It is recommended, but not required, that you use the @param, @return, and @throws tags in the comment. These tags must always come at the end of the comment.) Note that if you type /** on the line before a subroutine and press return, Eclipse will put in an outline of a JavaDoc comment for you.
• Public member variables should be rare. But if you define one, you should provide a JavaDoc-style comment just before the declaration of the variable.
• The main comment on a class should also be in JavaDoc format.

Final Project Proposals

One of the requirements in CS 124 is a final programming project, which will count for 10% of the course grade. The project will be due at the end of the semester. There is no assigned topic for the final project -- you will have to select a programming problem on your own. As a first step, you should write up proposals for two possible projects that you might like to work on. The proposals can be short -- a paragraph or two. The proposal should describe what the program will do and how the user will interact with it. For this first-stage proposal, you do not have to write about the design of the program or about the algorithms that you will use; that will come later.

We still have to cover many things that could be useful in your project, including objects, arrays, and various aspects of GUI programming. You should not limit yourself to programs that you know how to write at this time! (In the end, in fact, your program must include several classes, and it must use objects created from those classes. You won't even learn about such things until Chapter 5.) You should come up with ideas for things that you would like to work on, and not worry too much about whether the project would be feasible. You do not necessarily have to be original; if you have a project idea that interests you, you can propose it even if it's been done many times already by other people. Some possible ideas are given below, but you are not restricted to choosing from the list given here.

The point of this exercise is mainly to get you thinking about final projects. You will not be required to use one of the project ideas that you turn in next week, if you think of something better later.

Note that for the final project, you can choose to work with a partner. If you do this, your project must be more ambitious than a one-person project.

Remember that you should not give help to or receive help from any other member of the class (except for your partner, if you have one). You can get help from me or from the computer science TA's, but not from anyone else. You should not copy code from the Internet or from any other source, unless you get my permission to use that code as a basis for further development.

Although you will probably want to write a GUI program, a command-line program is also acceptable. You should try to design a program that will be useful, interesting, or fun. Write a program that you would like to use yourself. Here are a few ideas, but remember that you are not restricted to choosing from the list given here:

• An arcade-style game, along the lines of the SubKiller applet from Section 6.5, but with more action. Something like Tetris or Space Invaders would be challenging, but not impossible. Or you could design your own game.
• A two-person arcade game. Typically, one person uses the arrow keys while another uses the W, A, S, and D keys. You could, for example, try to do a version of "Tron".
• A strategy game such as MineSweeper.
• A Casino-style game such as Roulette or Craps, where the user can place bets. Or a video poker slot machine, or some other type of slot machine.
• A Hi-Q solitaire game. (The wooden version has a bunch of pegs in holes, with one hole left empty to start with. The user removes pegs by jumping over them.)
• A solitaire card game.
• An old-fashioned text-based adventure game.
• A painting or drawing program, based on something from Chapter 6 but with some more advanced features.
• A miniature spreadsheet, where the user can enter some numbers and have some useful calculations done on them. Or a program that does some statistical tests on data sets read from a file.
• Some sort of fantasy sports simulator, based on real statistics.
• A more realistic program for administering math (and/or other) quizzes, with a greater variety of problems, the ability to save the user's results to a file, and other features.
• A "random art" program, much more ambitious than the Mondrian example from Lab 4, with several types of art, perhaps with animation for some types.
• A program that you think you might actually find useful in some other course, especially if you can get the idea from one of your other professors.
• A Java program for Android smart phones. (This would require learning the Android API on your own, which is certainly not something to be undertaken lightly.)