15-112 Spring 2015 Homework 6
Tetris due Sunday, 22-Feb, at 10pm
Solitaire due Tuesday, 24-Feb at 8pm
Read these instructions first!
- This hw is partly COLLABORATIVE and partly SOLO. Be certain to understand which is which. Tetris is collaborative, and Solitaire is solo.
- Starting this week, you may use 2d lists and event-based animations, in addition to 1d-lists, tuples, strings, graphics, loops and conditionals, but (as usual) you may not use constructs we have not yet covered (sets, maps, recursion, etc), unless explicitly allowed below.
- This week there is no autograder. You may make up to 5 submissions of each part to Autolab. As usual, only your last one counts.
- Do not use global variables! Do use test functions! Do use helper functions!
- playTetris() [50pts] [manually graded]
[COLLABORATIVE]
This portion of hw6 is "hw6c", where the "c" means "Collaborative". This problem (Tetris), and only this problem, is optionally collaborative. You may work in groups of up to 2 currently enrolled 15-112 students (yourself included), so do not work with more than one other student. Each student should submit their own work individually, submitted as part of hw6c. Include the name and andrew id of your groupmate, if any, at the top of your hw6c.py file. And as always with collaborative work, you must be actively involved in every part of your solution, and you may never simply copy any code from anyone, nor electronically share your code (email, FB, texting, etc) even with your partner.
playTetris()
Write Tetris according to the design given in this step-by-step tutorial using our event-based animation framework (with eventBasedAnimation.py).
You may not use a different design, even if you think there's a better way to do it (there probably is, but you still have to do it this way). This may seem limiting, but sometimes you are given specs at Polya Step 1 (just indicating the problem to solve), and other times at Polya Step 2 (also indicating the algorithms to use). This is one of those second kind of specs. Your task is to do Polya Step 3, and write the corresponding code, and then using this week's eventBasedAnimation framework.
Important note #1 (recitation hint): This semester, we will provide two key hints in recitation. In particular, your CA's will review the solution to removeFullRows and rotatePiece. You may not take any notes in that time (we do not want to reduce this to a typing exercise), but you can and should pay close attention. This will make the Tetris portion take notably less time, which is essential given what lies ahead in this hw (namely, solo Solitaire).
Important note #2 (finish Tetris asap!): The Tetris deadline is Sunday at 10pm. However, we very strongly recommend that you finish it sooner than that, and as soon as possible in any case. Ideally, by Friday night. You very much want to be working on Solitaire on Saturday if at all possible.
Important note #3 (finish Tetris before starting Solitare!): As we discussed in lecture, Solitaire is more complex than Tetris in some ways. Also, it is solo whereas Tetris is collaborative. For these reasons, it is very important that you finish Tetris and learn all you can from it before diving into Solitaire on your own.
Have fun!!! - playSolitaire() [50pts] [manually graded]
[SOLO]
This problem is SOLO, not collaborative. You must work alone, as you have done on all previous hw's this semester.
For this problem, you will write the game of Solitaire. Specifically, the version available here. This is a version of Klondike Solitaire, where only one card is flipped from the deck each time. If you are unsure of gameplay, you should read the rules on the Wikipedia page here.
playSolitaire()
Your task is to write the function playSolitaire() that takes no parameters and which calls eventBasedAnimation.run(). The real work will be done by the functions you supply to eventBasedAnimation.run(), and playSolitaire() will be just a few lines of code.
Here are some specs and some important hints. Be sure to carefully read all of these before starting!!!!
Spec and Hints
- data structures suggestions
We highly recommend, though do not require, that you use the following data structures in your solution:- card: We recommend that each card be represented as a tuple: (rank, suit)
- deck (top-left pile): A list, initially of 52 tuples (rank, suit)
- discard pile (to the right of the deck): another list of tuples (rank, suit)
- foundations (top-right piles): A ragged 2d list of 4 lists of tuples
- Pile face-down cards: A ragged 2d list of 7 lists of tuples
- Pile face-up cards: Another ragged 2d list of 7 lists of tuples
- drag-and-drop not required
The game allows the user to select a card, drag it around, and drop it on a target location. You do not have to do that (though you can for bonus, see below). Instead, you can just click on a card to select it, and then click on the target location to move the card (and any other cards below it that should move with it) there. If you do this, be sure to provide some highlighting so the user can see which card is selected (and it's ok to highlight just the topmost card in a sub-pile of cards). Also, if the target is the same as the selected card, just de-select the card. - animation and snapping not required
Similarly, cards may just move immediately to their target, without any animation and without any "snapping". Those are bonus features. - viewToModel hint (finding card from (x,y) mouse press)
Here is a simple and efficient-enough-for-hw6 way to process a mouse click: go through every card and find that card's bounding box, and check whether the (x,y) location of the mouse press is in that bounding box. Stop when you find a bounding box that contains the click. Note that this is basically the same process as how you draw the cards, only instead of drawing, you simply check if the (x,y) location of the mouse press is in that card. However, there is one difference: you have to go through the cards in a different order for this to work, checking the topmost cards before the ones behind them (which is the opposite of how you would draw them). A less-simple and but more-efficient and not-required way: you can calculate the target directly based on where the user clicked (see example in notes for how to do this for a 2d grid of non-overlapping cells). - card images
Use the card images and the image loading code from the notes. When we grade your code, we will include the "playing-card-gifs" folder at the same level as your code (so loading will work the same way as in the example). - random.shuffle()
You will want to use random.shuffle() to shuffle your deck. - random.seed()
For debugging, you will want to use random.seed(). This locks down the random number generator so that you can get the exact same "random" numbers on each run, to help you debug using the same example. When you are done debugging, however, you should not use random.seed(), so that the game is different each time it is played. - no console (exept for debugging)
Do not use the console except for debugging (we will not look at it when grading). - dialog boxes
If you need a dialog box (which you really shouldn't), check out how the about or help dialogs work in the eventBasedAnimation framework. - empty rectangles
Don't forget to draw empty rectangles when a pile is empty. Also, they can be normal rectangles without rounded corners.
- data structures suggestions
- window height
Make the window 800 pixels high, and then conserve vertical space in your layout so that a pile can have up to a full 19 cards (which is the max possible) This is doable while still looking attractive, but you should plan ahead for this. Do not make your window more than 800 pixels high, however, as we need to easily grade these on screens with a max of 800 vertical pixels. - simplify game for partial credit
For partial credit, you can implement a simplified version of the game. For example, where any card or group of cards can be placed on any other pile or foundation. Or even just make every card the Ace of Hearts, but otherwise get most of the gameplay working. We will still grade you against this spec, but this is a hint for how you can basically sidestep any part of the spec that you cannot solve. - what to submit
For Tetris, you should submit hw6c.py by the Sunday deadline. For Solitaire, you only need to submit hw6.py. In both cases, do not include eventBasedAnimation.py (neither as a separate file nor inside your file) and also do not include any of the card images. Just submit your Solitaire code.
This problem is also SOLO, not collaborative. You can include the following features in your Solitaire implementation:
- Drag-and-drop [up to 1 pt]
- Undo (with Undo button as in demo) [up to 2 pts]
- Snapping animation [up to 2 pts]
- Hint generator (with a Hint button) [up to 2 pts]
- Full-blown self-playing AI mode (with an AI-Mode button) [up to 3 pts]