Your final project will consist of a BlueJ project folder containing your entire program. You should hand it in using the usual process. Please name your project "final".
You may work alone or with one other person from the class.
The takehome exam includes a question asking you to provide a description of your final project and an "incremental development plan" (see the exam for details). Take that question seriously, because it will help you get off on the right foot with your project.
You've spent a fair amount of time this term making graphical fish do things. Now that you know a lot more Java than you did before, you're ready to do a more detailed simulation of life in an aquarium. You could, for example, design your Fish class to include data and methods to represent and control the size, type (sharks, anyone?), or speed of the fish. You could include a notion of "hunger level," so that fish that get too hungry will die and float to the top of the aquarium (and that hungry fish who encounter smaller fish will eat the smaller fish). You could include a Plant class whose instances randomly generate instances of a Bubble class, which in turn float upwards. Go ahead and use your imagination.
Your simulation can include pretty much any features you can cook up, but it must include:
Write a game program.
There are lots of ways to approach this problem. You can choose an asymmetrical game like Mastermind, where the computer doesn't have to be too bright, but the game is still fun for the person playing it. You can choose a simple game like tic-tac-toe (2D or 3D) or dots and boxes, and make the computer play well. You could even take a harder game like Boggle, and make the computer generate a random Boggle board and then search the board for words and print them all out. In the end, the approaches can be: make the game fun, make the computer smart, or both.
You only have two weeks, and you have an exam in the meantime, so pick a game that's simple enough that you can get the job done in time. Tic-tac-toe is simple enough, but Hearts probably is not. A text adventure (like Zork, if you've ever heard of it) is manageable. Chess is not.
I'll bring a longer list of game ideas to class on 3/1.
Does it compile? I can't test it, and thus I can't grade it, if it doesn't compile.
Does it work? Correctness is the most important thing, though by no means the only thing. Your program should work. If it doesn't do exactly what it was intended to do, you should provide a discussion of that fact in your documentation.
Is it well organized? We talked in class a few days ago about principles to use when designing a class. Think about those ideas as you develop your code.
Is it well documented? Your code is a piece of writing directed to two audiences--human readers and compilers. You need to make the code readable to both of them, and clear commenting is an essential part of what you do for your human readers.
Is it written with good style? Descriptive variable/function/parameter names, consistent indentation and placement of braces, and appropriate comments are the fundamentals of good coding style.
Ambition. If two projects are well documented, functional, and exhibit good style, the one that does a more interesting or ambitious thing is likely to get the better grade. A good version of Battleship will probably get a better grade than a good version of tic-tac-toe. An aquarium with fish, sharks, plants, bubbles, and barnacles will probably get a better grade than an aquarium with three fish. On the other hand, a really outstanding tic-tac-toe program can get an A.
Hand in the usual stuff--a BlueJ project folder--with one slight addition. As you know, whenever you create a project, BlueJ automatically generates a README.TXT file. For your final project, I would like you to summarize the status of your program in the README.TXT file. Tell me what your program does, what isn't working, how to use it, what bugs you know of, etc. Anything you want me to know about your program should go in README.TXT.
Start early, have fun, and keep in touch.