ICS 32A Fall 2019
Project #5: The Fall of the World's Own Optimist (Part 2)

Due date and time: Sunday, December 8, 11:59pm

This project is to be done individually


In the previous project, you implemented a Columns game with a fairly primitive user interface that ran within the Python shell, in the spirit of the user interfaces we've been building all quarter. This didn't make for a particularly fun game, but it did let us focus our energies on the precise rules of our game, so we could get all of the various mechanics right, before turning our attention to making a playable game out of it. In this project, we'll switch over to making the game playable.

In recent lectures, we've been learning more about PyGame, a third-party library — not one built into Python, but nonetheless one that is easily downloaded and installed for your use. This project asks you to take the program you wrote for the previous project and replace its user interface with a graphical one. You'll build your game using the PyGame library, as we've been doing in lecture. Rather than simulating the passage of time by pressing the Enter key, the game will move on its own; this will add the key elements of challenge and fun to it.

The program

This project asks you to build a graphical, playable version of Columns, based on the game mechanics from the previous project. However, we'll need to make a couple of minor changes to it:

Which rules must be implemented?

The only game mechanics that are absolutely necessary — for full credit on this project — are the mechanics of creating fallers, moving and rotating them, and having them land and freeze. All of the other mechanics — matching, particularly — are optional. If you already completed Project #4, you'll want to include them here. But we do want those of you who have only partial implementations (within bounds of reason) to be able to proceed with this project without penalty.

What should it look like?

You have a fair amount of leeway about how the game looks. The basic feel should be similar to the 1990 Sega version, in the sense that you would display the jewels in a grid, and you would see them move one grid cell at a time. Jewels should be displayed with different colors, and you can opt to use different shapes, though that is not required.

Additional challenges

You are certainly welcome to add new features to your game, though they are not required (and extra credit is not offered in this course). Some ideas of what you might add include:

Approaching the problem

Reusing your game mechanics

If you have a complete set of game mechanics from the previous project, you'll find that your task this time is primarily one of visualization and taking input. Your game mechanics, if designed appropriately before, should be largely usable without modification. In some ways, it may not (e.g., if your game mechanics made assumptions about the user interface running in the Python shell, or about the specifics of the input and output like EMPTY or F 1 X Y Z); in the areas where your game mechanics aren't as good of a fit lie learning opportunities. Reflect on what changes you had to make and why, and understand how you could have avoided making those changes.

Note, too, that you are eligible for up to full credit on this project even if you don't have absolutely perfect game mechanics, though there are some requirements that do need to be met, as described above.

What to do if you didn't complete your game mechanics previously

If you did not complete your game mechanics previously, you will need to complete the most basic requirements now — see above — and I would suggest focusing your energy on just what's necessary, since it will be somewhat easier to implement than the full rules. Since implementing only the necessary rules leaves open the possibility of receiving full credit on this project (i.e., there are no deductions for not implementing more than this, and there are no bonuses for implementing everything), there's no benefit — from a grade perspective — in implementing the full rules (though, of course, you're welcome to do so, if you'd like).

It should go without saying — but prior experience has shown otherwise — that you are required to submit your own game mechanics in this project, not someone else's. It's certainly true that the focus of this project is on building the graphical portion of the game, but one of the learning objectives here is becoming accustomed to reusing your own code to satisfy new requirements, so you can determine which parts of your own design worked well in the new context, which ones didn't, and reflect on why.

Module design

As before, you are required to keep the code that implements the game mechanics entirely separate from the code that implements the graphics and input handling for your game. To that end, you will be required to submit at least two modules: one that implements your game mechanics and another that implements the graphical portion. You're welcome to break these two modules up further if you find it beneficial, but the requirement is to keep these two parts of your program — the logic and the user interface — separate.

At least one of your modules should be executable (i.e., should contain an if __name__ == '__main__': block), namely the one that you would execute if you wanted to launch your game.

Using classes to implement your game

Because your event handlers will need access to the game's current state, the graphical portion of your game should be implemented as one or more classes, in the style we've been discussing in recent lectures, with (at least) an object representing the game itself; you may also find it useful to have additional kinds of objects that represent parts of your graphical implementation, but this is up to you to decide and is not a requirement.

Drawing the state of the game and resizing the window

You'll need to draw the game board using PyGame, which you can do programmatically using something like pygame.draw or by using small images and "blitting" them on to the display instead. Additionally, your game window must support resizing, and resizing it must cause the area in which the board is drawn to change size correspondingly, with the game's graphics redrawn to fill the available space in some reasonable way, so the user can decide how large of a window he or she would like to play the game on.

How we will be running your program

Because we will be using the third-party library PyGame, it is important that we all agree on how the various files and configuration will be done. This is what we're going to do when we run your program:

You'll want to be sure, before you submit your work, that this technique for setting up your project will work properly.

Where to find more information about PyGame

When you want to know more about the PyGame library, a good place to start is the Notes and Examples on the course web site, where I've tried to outline the big-picture concepts and demonstrate a few examples. Most likely, though, there will be things that you run into that don't happen to covered in those notes, so you'll also want to be able to navigate PyGame's online documentation, which is actually extensive and quite good. You can find that documentation at the link below.

The documentation is organized into sections for each part of the library; you'll see links to those sections listed near the top of the page. For example, if you're unsure about some part of the pygame.display library, you'll find a link titled display. I generally find myself using those navigation links near the top when I want to jump around and look at the details of things I don't remember or haven't seen yet.

There are also some tutorials available, though you'll find that they can take you into a lot of places where we won't need to go for our work.


The only third-party library you are permitted to use is PyGame — which, in fact, you're required to use. Otherwise, you're free to use modules in Python's standard library to the extent that they're helpful to you.

There is a hard limit of 256KB on any additional files — images, sounds, and so on — that you want to submit above and beyond the Python source code for your game. This will allow you to spruce up your game to some extent, but disallows something like a large MP3 file for background music, a video that plays when the game start, and things of that nature. (This limitation is mainly motivated by the fact that this is a very large course, yet we're all sharing the same submission system and working to the same deadline, so we can't have hundreds of megabytes of data being submitted to Checkmate.)


Put your name and student ID in a comment at the top of each of your .py files, then submit all of the files to Checkmate. Take a moment to be sure that you've submitted all of your files.

If you have additional files — images or sounds, for example — that are also part of your game, you'll need to submit these, as well; there will be an additional area within the Project 5 dropbox on Checkmate to submit them. (Note that we will be assuming that we can copy these files into the same directory as your source code in order to run the game; see above.) We aren't kidding when we say that there is a limit of 256KB per student for "assets" like these; unfortunately, we're not going to be able to allow massive sets of files to be submitted, since there is a very large number of students enrolled in this course.

Follow this link for a discussion of how to submit your project via Checkmate. Be aware that I'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of the project that you want graded. We won't regrade a project simply because you submitted the wrong version accidentally.

Can I submit after the deadline?

Yes, it is possible, subject to the late work policy for this course, which is described in the section titled Late work at this link.