CS 117: Introduction to Computer Science

Final Project

Brief description of project due 11:10 AM Monday, March 5 as part of your takehome exam
Final code and documentation due 5:00 PM Wednesday, March 14

Your final project will consist of a 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.

Choice #1: Graphical simulation

One of the things computers are good at is simulation of systems that evolve over time. Consider, for example, a computer model of the solar system. You can give the computer the initial positions, masses, and velocities of the largest objects in the solar system, plus a computational mechanism for simulating the effects of Newton's law of gravitation. Then you can set the system running, and your solar system will go through its motions. You could then try adding a comet with a mouse click or two, and watch how the comet's orbit is perturbed by close encounters with planets or asteroids. If the simulation takes relevant physical laws into account, the evolution of the system will be a good representation of the workings of the real solar system.

If you choose this project, you will simulate some time-dependent system that can be represented effectively in a rectangular display. You could show a top view of the solar system, or a side view of an aquarium, or a landscape with rain, clouds, plants, and birds. Your system will need to be animated, and there will need to be a diverse enough collection of elements to your system that the objects will have interactions of some kind. Planets, for example, interact gravitationally, big fish eat little fish, and raindrops cause plants to grow.

Your simulation may include pretty much any features you can cook up, but its minimal features must include:

• More than one type of moving object.
• Interactions between objects.
• Some feature that allows either mouse-clicks or keystrokes to affect the simulation in some way (click to create a plant, or hit the "+" key to speed up the simulation, or click on a fish to see a window pop up containing the fish's vital statistics, etc.)

Choice #2: Game

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 simple text adventure (like Zork, if you've ever heard of it) is manageable. Chess is not.

If you want some more ideas of appropriate games, let me know.

Grading criteria

• Does it run without crashing? If not, I can't test it, and thus I can't grade it.
• 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 have talked about principles to use when designing a class or a function. Early in your work on this project, you should think carefully about what classes to create, what data fields and methods they should contain, and how objects of the various classes will interact.
• Is it well documented? Your code is a piece of writing directed to two audiences--human readers and the Python interpreter. 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, well-designed functional interfaces, 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.

What to hand in

By 11:10 AM Monday, March 5: Along with your takehome exam, you will submit a piece of paper with the following information:

• A description of the project you intend to do.
• Whether you plan to work with a partner, and who it is, if so. You may work alone or with one partner--no groups of three or more will be allowed.
• An incremental development plan as discussed in class. This plan should consist of a list of roughly ten steps that will take you from a blank slate to a completed project. Each step should yield a testable program.

By 5:00 PM Wednesday, March 14: Hand in your source code and any other files your program needs. Also hand in a file called readme.txt, containing a summary of the status of your program. 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.

Have fun

I'm not kidding.

Need help? Let me know.