15-112
Summer 2022

Home

Syllabus

Schedule

Gallery

Staff

Piazza

Autolab

OH Queue

Forms

CMU 15-112: Fundamentals of Programming and Computer Science
Homework 9 (Due Wednesday 27-Jul at 8pm)

Important notes:
Here are the rules for collaboration:
  1. Everyone must read all of these rules, even if you opt out of collaborating.
  2. Collaboration is optional.
  3. Collaboration is in pairs of 2 people (and no more). You may pick who you collaborate with, or you may ask your TA for help in finding a partner (or you may work solo).
  4. If you do collaborate, you must email your recitation TAs to inform them who you are collaborating with.
  5. You may not change your collaborator or abandon them once you have chosen them (except with written permission from Mike or Emily Sands if your partner becomes nonresponsive).
  6. You may not begin writing code for the assignment by yourself and then join a partner. You need to decide if you are collaborating before making progress.
  7. You must list the andrew id of your collaborator in a comment just above your solutions to this assignment.
  8. You must be an effective collaborator, working together as much as possible. For example, you may not "divide and conquer," i.e. you can't split the tasks between the two of you and then combine your efforts. You must solve each part together, type your own code without copying, and be able to explain it.
  9. It is strictly forbidden for you to copy any code from your collaborator. That is not collaborating, that is cheating. Instead, you must type all your own code, without copying from others. You can discuss all parts of the problem with your collaborators. They can even help you debug. But still, you must write your own code, and you must type every letter with your own hands. (Note that this means you can't write the code in a single file on replit or one laptop even if you are taking turns typing.)
  10. While you may not copy, you are allowed to look at your partner's code on their laptop to help them debug, and it's fine if you and your partner's code are naturally very similar. If you are not copying code, and if you understand all the code you have written, you have nothing to worry about. If you aren't sure if something counts as copying, simply ask us before doing it.
  11. Here is our suggestion for how to collaborate effectively so that you both learn to solve the problem: You and your partner can read through one step of the tutorial together, discuss how you will complete this step by writing notes on the algorithmic steps together, write your actual Python code separately, and then move onto the next step in the tutorial. Detailed algorithmic steps can help you organize your code but it should look like normal English sentences rather than code.
  12. Reminder from the syllabus: when we say "do not copy" we always mean visually, verbally, electronically, or in any other way, even if you copy and modify it.
  • To start:
      • Create a folder named 'hw9'
      • Download these files into that folder:
        1. hw9.py
        2. cmu_112_graphics.py
        3. cs112_n22_week4_linter.py
      • Edit hw9.py using VSCode
      • When you have completed and fully tested hw9, submit hw9.py to Autolab. You may submit up to 5 times and, as usual, only your last submission counts.
      • There is no autograder for hw9. The TA's will manually grade your last submission sometime soon after the hw deadline.
      • You must each submit your own file to Autolab. One partner cannot submit for both of you, and no part of your solutions may be copied.
  • Do not use sets, dictionaries, or recursion.

    1. Tetris [100 pts] [manually graded]
      Reminder: Any collaboration must be earnest collaboration, and you must list your collaborator. If you submit code that you are unable to thoroughly explain, or if you could not rewrite Tetris from scratch without referencing your submission, you have not collaborated well.

      With positive collaboration in mind, write Tetris according to the design given in this step-by-step tutorial. 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 have to write code according to a specific algorithm, rather than writing code to solve a specific problem. This is also meant to keep you from hitting a dead-end with a less-thought-out algorithmic plan. If you wish to customize your implementation, see the note on bonus features below.

      To get full credit, you'll need to complete the basic implementation according to the design spec (up to and including step 7).

      If you decide to add some more bonus, which we do not require but we heartily encourage (not for the few points you might earn, but rather for the joy of learning and creating), then:
      • Have the code run normally, without any bonus features, so the TA's can easily grade your submission against the spec.
      • But if the user presses 'b', then the game switches to bonus mode, and the bonus features are activated.
      • When the user presses 'b' to activate the bonus features, a description of all the bonus features is printed to the console. Be sure to print enough of an explanation that the TA's can understand how to use and grade your bonus features.

      Have fun!