CSSE 120 Final Python Project—Spring 2008-2009

Project Requirements

The final project for the Python part of this course is to implement the game FallingBlock. Rules for the game are given below.

Your project must satisfy these core requirements:

1. You must design and implement a working FallingBlock game that includes the following:
   1. Rising platforms, both good and bad.  If the falling block (see (b) below) hits a "killer platform", it immediately costs the player one  life.
   2. A falling block that can be controlled by the left and right arrow keys.  We provide an enhanced version of zellegraphics in your project folder.
   3. If the falling block leaves the playing area by either falling off the bottom of the window, being carried off the top of the window by a rising platform, or being moved off of either side of the window by the player's key presses, it costs the player one life.  If the falling block ever falls off the bottom of the window, it is immediately repositioned at a random x-position at the top of the window.
   4. Special pieces called "goodies" that sit on some good platforms.  Goodies either give extra points or an extra life when touched by the falling block. 
   5. A running total score that is based on a combination of elapsed time and "extra point" pieces touched by the falling block.
   6. An additional life is added for every hundred seconds that the player survives or every hundred points accrued.
1. Display of the current score and current number of lives remaining.
2. Game play that becomes progressively harder as the game progresses (for example,  by speeding up the velocity of the rising platforms).
3.  "How to play" instructions for the user.
2. Your project must use a GUI for game play, on a window that is smaller than 1024 rows by 768 columns (the screen resolution of the projector you will use to present to the class).  zellegraphics should suffice for developing this, but you are welcome to explore and use a different library if you wish. For example, the screenshot below was taken from a project developed using pygame.
3. You must define your own collection of classes.
4. All team members must contribute to their project and understand all of the code in it.

Most of the work on your project will be translating the above rules into a working design and implementation. If you are having trouble planning or getting started, get help. It is much better (and easier) to get help early and start off with a good plan than to try to hack a poor design into a semi-functional program in the final days before it is due.

Milestones

To make sure that you are on-track to complete your project, you must meet the following milestones. Each milestone will contribute to your overall project grade. Each milestone must be done before the specified class session unless specified otherwise. For each milestone, you must commit your work to your team's repository and include a clear commit message stating that this milestone is completed.   Your team's repository is named csse120-200930-teamXY, where X is your section number, and Y is your team number within that section.

• Session 17  (mid session) -- Checkout the project. The location of your team's repository is 

  http://svn.cs.rose-hulman.edu/repos/csse120-200930-teamXY

  where X is your section number and Y is your team number as announced by your instructor.

  Check out the FallingBlock project, and find the module fallingBlock.py within it. Each team member should independently add his or her name to the comments at the top of the file. This involves each of you editing the file, so it requires careful use of SVN. Detailed instructions for how to do this were given for the Tic-Tac-Toe project.  The slides for that session are located here.

  Follow the SVN cycle of update-edit-commit whenever you make changes to your program. You should definitely commit your work after each milestone beginning with the milestone for session 18.

• Session 18 (start) — UML Class Diagram Sketch: A neatly drawn UML class diagram showing the user-defined classes for your program including instance variables and methods. This does not have to be (and likely won't be) your final design, just your initial plan. For each of your classes, you should ask yourself, "What instance variables need to go in it? What operations must it support?" as a start. The diagram can be hand-drawn or you may use a program to draw it. We strongly suggest that you draw your initial design on a whiteboard. Regardless of the way you choose to draw the diagram, you must turn in a single plain white 8½ × 11 inch sheet of paper showing your final design. This format is non-negotiable as we will be photo-copying your design.
• Session 18 (by end of session) — Moving Platforms: Your game play window must include a collection of platforms that appear one at a time in random positions at the bottom of the window and move upward until they disappear off the top of the window. You must write the code in such a way that it is easy to adjust both the speed at which the platforms move and the frequency with which they are added to the board. HINT: defining constants for these makes this easy.
• Session 19 — Removed platforms: The platforms must be removed from the collection once they disappear; if not, they will eventually slow down the game.

• Session 19 — Controllable falling block. Your program must include the "falling block" whose horizontal motion can be controlled by the keyboard. You must also detect when the block hits a platform.

• Session 20 — Game Finished, including enhancements (below). Note: there will be no 24-hour extension for this, since students will present their work in class. So please plan ahead.
• Session 21 — Team Evaluation of Your Partners. This will be made available in Angel under Lessons.

Example of a very similar game developed using the pygame library:

Here is the executable.

Your program does not have to be so fancy, and your falling object can be a square block instead of a ball.

Grading

Project grades will be based on both individual and group results. We will check off each project milestone, to make sure you are making steady progress. The final project program will be graded based on both the proper functioning of your program and an evaluation of your design, coding style, and documentation (including SVN commit messages). The grade will also depend on the enhancements that you add (see below).  "Playability" is an important factor; it's hard to define precisely, but we all know it when we see it.

Each team member will be required to complete an evaluation survey about his or her own performance and that of each of his or her teammates. We will use these surveys and our own observations to assign individual project grades. Individual grades will be based on your contributions to the project, how well you work with your teammates, and your understanding of all parts of your team's code.    If is not obvious from our work with you that you understand the code, we may ask to meet with you before assigning a grade.

Rubric (in progress)

Suggestions

• Plan first! Use top-down design and object-oriented design. Get help early if you need it!
• We suggest that you do your programming as a group, with one person driving and the other people looking on and making suggestions rather than splitting it up and working on it separately.
• We also suggest that the person who is the best programmer is not the usual driver.  Of course we want you to have an excellent working program, but it is even more important that you all learn from doing it and that you all understand the code that you submit.  If your teammates "leave you in the dust," ask them to slow down and explain things. 

Enhancements

Once you are done with the basic version, you will be required to add some enhancements. You will earn a higher grade for doing more challenging ones, and the more, the better (as long as your game is still playable). Here are some suggestions, to get you thinking.

• Have the falling object be a ball, and have the collisions (or non-collisions) with platforms and "goodies" be consistent with that shape.
• Enhance the appearances of the falling object, platforms, and goodies by using images.
• Allow the game to be pausable and restartable.
• Save the highest scores, and let the person who obtains a new high score record his/her moment of fame.
• Add sound effects using the winsound Python library.
• Occasionally have a "rogue" block fall randomly from the sky in hopes of hitting your falling object and killing it.
• Add "motion trails" behind the falling object, as in the Falling Ball program that we demonstrated in class.
• The default is that the falling object falls at a constant rate when it is not on a platform, and that holding down a key moves it right or left at a constant rate.  Perhaps you can explore having the object accelerate as it would under the influence of gravity, and with having the right and left arrow keys provide constant acceleration instead of constant velocity.  Can you do this and still make the game playable?
• Be creative: what's cool and challenges you?