**CS 111 w20 -- Final Project** # Overview To complete your CS 111 experience, you will take on a project of your own design. ## Objectives - Practice all the skills and concepts you learned this term to design a significant program. - Show off your creativity and interests. - Have fun! ## Collaboration The project is to be done in a partnership of your choice. Unlike with pair-programming assignments from the course so far, you are not both required to work on all aspects of the project, but you are all expected to do your fair share. I will allow individual projects if you have a good reason that you wish to work alone. I encourage you to work in a partnership! It will let you accomplish more and have more fun. ## Deadlines - **Project proposal and design** -- due 9pm Monday, March 2 - **Demo session** -- You'll need to have working code by 3:30pm Sunday, March 15, when we'll have a demo of all the projects in CMC 102 - **Final submission** -- The project will be due 9pm Monday, March 16 See the [What to Turn In](final-project.md.html#whattoturnin) for more details. --- # The Project For the final project, you have two options. ## OPTION #1: A SIMULATION One of the things computers are good at is simulation of systems that evolve over time. Consider, for example, a computer model of the solar system. You can give the computer the initial positions, masses, and velocities of the largest objects in the solar system, plus a computational mechanism for simulating the effects of Newton's law of gravitation. Then you can set the system running, and your solar system will go through its motions. You could then try adding a comet with a mouse click or two, and watch how the comet's orbit is perturbed by close encounters with planets or asteroids. If the simulation takes relevant physical laws into account, the evolution of the system will be a good representation of the workings of the real solar system. If you choose this project, you will simulate some time-dependent system that can be represented effectively in a rectangular display. You could show a top view of the solar system, or a side view of an aquarium, or a landscape with rain, clouds, plants, and birds. Your system will need to be animated, and there will need to be a diverse enough collection of elements to your system that the objects will have interactions of some kind. Planets, for example, interact gravitationally, big fish eat little fish, and raindrops cause plants to grow. Some other simulation ideas: fishtank simulations, biological simulations (diseased vs. white blood cells, change of seasons), agricultural simulations (given a set of initial conditions, a choice of crop, etc, will you be able to harvest your crop and get it to market?) Your simulation may include pretty much any features you can come up with, but its minimal features must include: - More than one type of animated object. - *Interactions* between objects (one object causes another object to react in a certain way). - Some feature that allows either mouse-clicks or keystrokes or some other form of user input to affect the simulation in some way (click to create a plant, set the animation speed, etc.) ## OPTION #2: A COMPUTER GAME Write a game program. The game should be either fun for the user, or one in which the computer has some basic intelligence, or both. Your game can be entirely text based, or you can use `pgl.py` or `vpython` if you’d like to make it more visually appealing. No graphics are required, though. Some possible games to implement: Boggle, Scrabble, Dots and Boxes, Battleship, Go Fish, Bejeweled, Connect Four, Mastermind, etc. Another possibility is Bagels, which is described at the bottom of the assignment. Some games to be wary of: a text-adventure game (these can be done well, but they usually devolve into a morass of nested if statements that aren’t interesting to write or read); Hangman, Tic-Tac-Toe, etc. (too simple); Go, your favorite German board game (too complex). The requirement of *some level of computer intelligence* means this: the computer should play against you or manage your game in some kind of intelligent way. You don’t need the computer to be a world-class player at your game (or even close!)---but you should make an effort on this front. If you have questions about the suitability of a particular game, feel free to discuss it with me. # What to Turn In ## Project Proposal -- turn in via Moodle by 9pm Monday, March 2 You must submit to me a one-page written proposal for your project. The proposal should include your partnership (or an explanation of your plan to work alone), what game you’re planning to write, and a list of pieces that you plan to implement, in order, to create your game. This should be a plan of attack for your project, so that you can think through what steps you will need to take to make your game work. Let me know if you have questions about the rules or suitability of a particular game or simulation. I recommend talking to me about your thoughts about the project early to make sure that you haven’t picked something too easy or too hard. The biggest trap on this assignment that students often fall into is picking something too complex and not having the time to finish it. Consult with me. [This is an example of a good design plan](sample_proposal.txt); feel free to model your own project proposal after this one. ## Project Demo -- demo session 3:30--5pm Sunday, March 15 **By 9pm on Saturday, March 14, each group will send me a Google slide deck link via email with two slides that describe their final project.** This can be as simple as one slide describing your idea, and another slide with a picture of any graphics you used, or some sample output if you're creating a text based program. We'll be doing a quick lightning round of presentations where each group talks about their project for ~2 minutes. Then we'll hang out and play with each others demos. ## Final Submission -- turn in via Moodle by 9pm Monday, March 16 You must submit the following: - The complete code for your final project - Any additional files your project requires in order to run (data files, images, etc.) - The appropriate documentation in the form of a readme file (see the Project Documentation point in the [Evaluation section](final-project.md.html#evaluation) below for detail) # Evaluation + **Project proposal (15 points)** + Does your proposal clearly describe the game or simulation you will create? + Is the implementation plan specific enough that I can tell you've thought about how to approach your project? + Are the names of all team members included? + **Program execution (45 points)** + Does the program run? Does it run without crashing or unexpected behavior? + Is the output unambiguous? + For simulations, is there more than one moving object? Do objects interact? Does user input affect the simulation in a non-trivial way? Are the "rules" of the simulation followed correctly and consistently? + For games, does the game have unambiguous and clearly-stated rules? Does the gameplay consistently follow these rules? Does the game contain some amount of computer "intelligence" and/or randomness? + **Style/Python elements (18 points)** + Are the tasks in your code appropriately divided among functions and classes? + Are your classes well-designed, with appropriate instance variables, a well-designed constructor, and appropriate methods? + Are your functions well-designed? Do they utilize appropriate and well-chosen parameters and return values? Do they tackle appropriately-sized tasks? + Is your code logically organized, with proper use of whitespace and comments to indicate what the code is doing? + Do your variables, methods, functions, and classes sport appropriate and unambiguous names? Have you followed proper naming conventions with them? + Does your program use Python elements, such as lists, strings, other libraries, etc. appropriately? + **Complexity (18 points)** + How complicated is your game or simulation? + For simulations, how complex are the interactions and user input? + For games, how sophisticated is the computer intelligence? + **Project documentation (9 points)**: you will include a *readme* file with your project submission. A readme file is a simple plain text file that describes your project in more detail. The readme should include: + The name of your project + The name(s) of the project submitters + Whether your project is a game or a simulation + How to play the game (game rules) and/or how to run the simulation (simulation rules). This should include information such as what extra files, if any, are needed to run the program. (If your program requires extra files, such as images, please include these with your project submission.) + If there are any known bugs or issues with the program, please indicate them here. A note on correctness vs complexity: **correctness is the most important factor**. A simple text-based program that runs correctly, is error-free, and achieves the above specifications will get a better grade than an incredibly smart chess program that crashes and produces unreadable output. *To reiterate: It is most important to submit something that works. Set modest goals and achieve them first, then enhance your program later. Get the basics of the simulation working before adding user input. Only work on getting computer intelligence working after you have the basic game working with human player(s).* --- # Bagels Bagels is a two-person paper-and-pencil game that is similar to but simpler than Mastermind. One person thinks of a 3-digit number, and the other person tries to guess it. The 3-digit number is not allowed to have repeated digits, but it may begin with a zero (so 012, 987, and 361 are legal, but 112 and 303 are not). The Guesser makes a 3-digit guess. The Responder compares the guess to the actual mystery number, and responds to the guess by some combination of the words "Pico", "Fermi", and "Bagels". The Guesser keeps guessing until the guess is the mystery number. Here are the response rules: - If the guess has no digits in common with the mystery number, then the answer is “Bagels.” - If the guess has a digit in common with the mystery number, and the common digit is in the same position in both numbers, then the responder says “Fermi” (once per match). - If the guess has a digit in common with the mystery number, but that common digit is not in the same position in both numbers, then the responder says “Pico” (once per match). - If there are multiple matches, all the Picos should be reported before all Fermis. (So you’d never say "Pico, Fermi, Pico"; if there are two Picos and one Fermi, you’d say "Pico, Pico, Fermi" regardless of which digit was the Fermi.) For example, suppose the mystery number is 395. Here are a few guesses and responses:

246 Bagels
037 Pico
105 Fermi
309 Pico, Fermi
395 Fermi, Fermi, Fermi.

If you choose this project, your program should will play Bagels with you, both as the Guesser and the Responder. Having the computer act as Responder is fairly straightforward. Having it act as Guesser is trickier, but fun. --- Acknowledgments: This assignment description is modified from previous ones written by Amy Csizmar Dalal, Sneha Narayan, and David Liben-Nowell.