CSSE 120 Final Python Project

Project Requirements

The final project for the Python part of this course is to implement the Game of SET. At the following URL, you can find

A tutorial that explains the concepts
Rules of the original game
A SET On-Line Daily Puzzle that will help you get used to the idea of selecting SETs.

http://www.setgame.com/set/index.html

Your team must design and implement something like the SET On-Line Daily Puzzle:
1. Displays 3 x 4 grid of twelve cards chosen randomly from a shuffled SET deck
2. Allows user to select three cards by clicking the mouse, determines whether they constitute a SET that has not already been found
3. Dispays all sets that have already been found by the user
4. Counts how many distinct sets the user has found, and congratulates the user for a WIN when all sets have been found
Your project must use a GUI for game play. Your game's window(s) should be no larger than 1024 x 768 pixels, so your game can be easily displayed to the class using the projector. zellegraphics should be sufficient for developing the your GUI, but you are welcome to explore and use a different library (for example, pygame) if you wish.
We strongly encourage you to use top-down design, define some new classes (more on this below), or consult with your instructor on alternative design choices.
All team members must contribute to and understand the project code. Exam 2 may include questions about your project.
At the end of the project, each team member will evaluate the other members in terms of how well they contributed to the project; different team members may earn different project grades.

Most of the work on this project will involve translating the rules provided into a functional design and implementation. There are not many requirements on how you must do this. This can be a double-edged sword. On the one hand you have a great deal of freedom in designing your solution; on the other hand we are giving very little specific guidance. 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 the project is due.

Project Teams

The project teams and repository information is posted here. Each member of your team should checkout your team repository at the start of the project. To minimize SVN conflicts, follow this routine with each editing session:

update your local copy from SVN
make a small number of edits to complete a single task
update your local copy from SVN again, in case a teammate committed while you were working, and
finally, commit your work back to your repository. Be sure to include a comment indicating what you changed and why.

Using this cycle will minimize conflicts. If you get a conflict, get help from a member of the course staff to resolve it.

Remember to provide appropriate commit messages. We’ll be grading your proper use of SVN.

Each team member should contribute significantly to the code for your project.

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.

Before Session 17 — (this is a big milestone because you have 6 days for it)
1. Top Level Structure Diagram: A neatly drawn structure diagram showing the top-level functions that you plan to use in your program including a few formal parameters and return values. You should start thinking about the objects (instances of classes) you will need. This does not have to be your final design, just your initial plan.
  
  Consider the subsequent milestones in your design! In particular, the next milestone has specific requirements for top-level functions.
  
  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, first. 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 scanning the designs, and may share it with other teams.
2. At least one of the following (If you do both, you'll have an easier time finishing the project):
  1. a GUI that displays 12 cards and "knows" which card has been selected when the user clicks the mouse, or
  2. a function that determines whether or not three given cards form a SET.
Before Session 18 — Both of the "either ... or" items from Session 17 milestone, plus significant work on the game's interaction with the user. You can defijne what "progress" means, based on your design and implementation plan.

You will be asked to demo your progress to your instructor or TA during session 18.
Before Session 19 — Basic GUI Implemented: By the start of this session, your program should allow a player to find sets, to keep track of how many different sets have been found, and to let the user know when all possible SETs from the current collection of cards have been found.
Before Session 20 — Project Finished. Should include a graphical indication to the user of which sets have been found and how many more sets there are. Should allow the user to abandon the current puzzle and start with a new random puzzle. Should look nice and be easy to play. Include your team's custom "bells and whistles"
During Session 20 — Final Presentation in class. Should demo your SET program and also discuss a few technical details of the program's design and implemenation.
By 5 PM on the day of Session 20— Fill out the peer evaluation survey for your team members and yourself.

Grading

Project grades will be based on both individual and group results. We may grade each project milestone, plus the final project program and presentation. Grading will include both the proper functioning of your program and an evaluation of your design, coding style, documentation, teamwork, and proper use of SVN.

Each team will be responsible for presenting and demonstrating their work to the class.

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.

Some thoughts on Implementation

Displaying symbols on cards

You can duplicate the SET game's concepts without necessarily duplicating its exact appearance. For example, the game's squiggle and oval shapes may be difficult to draw and fill. Feel free to substitute other distinctive shapes.

IN the on-line game, the shaded shapes are done by a bunch of diagonal lines. Looks nice, but not easy to do. (an interesting challenge for a motivated team). You may want to simply fill the shape with a lighter version of the color that is used for the filed shape. You may find this page about available colors in TK (which zellegraphics uses) to be helpful.

Some classes that you might want to implement

Card: Attributes of a card object might include where it is on the board, as well as the four attributed of a SET card (symbol, count, color, shading). You will definitely want it to have a draw() method.

Deck: Represents the cards that have not yet been dealt out to the board. Initially this wil be all of the cards; as each card is placed ont the grid of 12 cards, it is removed from the deck.

A separate class for each kind of Symbol, for the purpose of drawing and shading that kind of symbol: Attributes of an object from one of these classes may include its color, degree of shading, and where it is to be drawn. Perhaps each of these classes should have a draw() method.

PossibleSet: Includes a collection (probably a list) of three cards. This class should have a method that tests to see if the three cards form a set, and perhaps gives an indication of why they are not a set if they are not. In addition to testing, objects from this class may be used to keep track of the SETs that the user has already found.

Use names instead of numbers in your code

You will probably want to have a number to represent each card attribute (e.g., 0 for red, 1 for green, 2 for purple. You should establish this relationship at the beginning of your code, and then use the names, not the numbers in subsequent code. This will make it easier for you, your teammates, and your instructor/lab assistants to understand what your code is doing. Here are some possible definitions that may help.

NUM_CHOICES = 3 # number of different colors, shades, shapes, symbols

NUM_CATEGORIES = 4 # the categories are colors, shades, shapes, symbols RED = 100 GREEN = 101 PURPLE = 102 EMPTY = 200 SHADED = 201 FILLED = 202 OVAL = 300 # You may want different names if you use different symbols. DIAMOND = 301 SQUIGGLE = 302

Suggestions

Plan first! Use top-down design and possibly other design strategies (one example is object-oriented design). Get help early if you need it!
You may want to follow the model-view approach that Zelle uses in section 12.3
When designing your GUI, think about how your users will perceive your game. Try to make it as easy as possible for them to interact with your program.
Test your code often! As you are implementing, make a small enhancement that can be tested, and test it until you are sure it works. Don't wait until you have added 100 new lines of code before you test it.

Enhancements

You are allowed to do enhancements for extra credit. For example, you could implement the full two-player game in which SETs get removed and kept by players, and the cards that are removed get replaced from the deck. You could animate some aspect of the game. Talk to your instructor about potential enhancements that you may want to do, to get an idea of how much extra credit they could earn for your team.