600.102: Foundations of Computer Science

Fall Semester 2005: September 8, 2005 - December 12, 2005

Assignment 10: Final Project

Out on: November 28, 2005
Due by: December 12, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration: Teams
Grading: Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%

Overview

The final project for 600.102: Foundations of Computer Science covers material from Weeks 11 to 13 and the corresponding reading; actually, it covers much more than that, I can't be very specific since the assignment is very much open-ended. This is a team assignment, and all of you should know which team you're in (I hope). Each member of a team will receive the same score for the product you submit together.

Arcade Game

For your final project, you will develop an arcade game in the style of Capcom's 1942 classic shooter. Actually, you can depart from the original game quite a bit according to what you think is "cool" but some of the basic game play should be as in the original. For example, there should be some special maneuver to avoid enemies, there should be power-ups of various sorts, and there should be a notion of enemies coming in stages and formations.

Your game should be written in Python using the PyGame library. You can use additional libraries as you see fit, for example PyOpenGL or the Python Imaging Library. However, please try to minimize the number of external libraries necessary, otherwise your game will harder to test (and therefore grade!). Your README file should contain all the following information:

How to install and run the game (including dependencies on external libraries besides the standard Python library)..
The basic rules of the game, unless you include "How to play?" instructions inside the actual game (probably better).
Notes on the internal design of your game, i.e. what classes there are, what their responsibilities are, how the collaborate with other classes, how the overall "game loop" works, etc. Be sure to discuss any difficulties you ran into during development as well as what you decided to do to overcome those difficulties.
For all "external artifacts" such as graphics, sounds, code examples, etc. you should "cite" the source and indicate the "status" of the artifact, i.e. whether it is copyrighted or public domain or available under some other license, etc.

It would be great if you work towards getting the game "published" as an example on the PyGame website. If you want to do this, please keep in mind that all the artwork you use must either be created by you or "free" in the sense that nobody will be "offended" if you use it in a free game. Regardless of what your plans for the immediate future are, a published game, even a simple one, looks good on a resume. :-)

Deliverables

Please turn in a gzip compressed tarball of your assignment (the extension should be .tar.gz). The tarball should uncompress into a directory cs102-assignment-10-teamname with teamname replaced by your team's name (as used for the repository and the mailing list); uncompressing should not create any other files in the current directory. Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading (and of course anything else required above). Make sure you include contact information for each team member as well! This file should be a plain Unix text file (not M$ Word, not PDF); it should be formatted in a decent way and it should contain your contact information.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to programming style, including things like consistent indentation, appropriate identifiers, useful comments, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization and the proper choice of algorithms and data structures. Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your programs do not run because of syntax errors you will get no points whatsoever. If your programs fail miserably, i.e. terminate with an exception of any kind, we will take off 10%.