The final project in CS 108 is an opportunity for you to showcase what you have learned in this class, and begin applying your newfound knowledge and abilities to a problem that interests you personally.
The final project can be done individually or with a partner (groups of 2 or 3 are encouraged; maximum group size is 3). In either case, I hope you consult with others in the class and with professors for help in design, implementation, and debugging.
Timeline (Milestones) ¶
There will be six milestones for this project, designed to help you make steady progress. Due to the tight schedule, late submissions will be penalized per the course policy.
| # | Milestone | Due | Weight |
|---|---|---|---|
| 1 | Project Proposal | Sat Mar 28 | 10% |
| 2 | Progress Report & Initial Code | Sat Apr 11 | 20% |
| 3 | Code Check-in 1 | Sat Apr 18 | 10% |
| 4 | Code Check-in 2 | Sat Apr 25 | 10% |
| 5 | Final Code + Report | Thu Apr 30 | 45% |
| 6 | Showcase (see below for times) | 5% |
All submissions are due by end of day (23:59) on the date listed. Milestones 4 and 5 do not accept late submissions.
Instructor check-in (required): Sometime around Code Check-ins 1–2, you must meet informally with the instructor (e.g., during lab) to discuss your project. You should be able to show what you have working and discuss your plans. Code submitted without a check-in will not be graded.
Details for each milestone are below:
Milestone 1: Project Proposal ¶
If you are working with a team, list all names. Only one submission is needed per team.
Write a document (Word, PDF, etc., not Python code) of at most 2 pages that includes the following:
-
A specific and informative title for your project.
-
Motivation: Why is this project interesting or useful?
-
Goals: A high-level description of the project and what it will accomplish.
-
Specifications: What you expect the input and output to look like. If it is text, then a quick sample of what it will look like. If it is graphical, a description or sketch of it.
-
An implementation plan: What might be some of the different pieces of the project that you can work on developing one at a time?
- What parts of the project could you get working first, to see if you’re on the right track?
- How you might know whether each part is working?
- What data will your project store? What data types will you use, and how? Sketch out a few examples of what the data might look like (e.g., the state of a game, the objects in a simulation, etc.)
-
What Python modules you expect to need.
It’s okay if you don’t have everything fully designed; expect the project to take shape as you go. But note that the more work you do on your design, the less time you’ll have to spend writing the code (because you’ll implement more of it correctly the first time).
Checklist:
- A specific and informative title
- Motivation
- Goals for the project
- Specifications for the final app
- An implementation plan
- Python modules required
AI Policy:
- Yes to AI for coaching: You are encouraged to use AI tools (ChatGPT, Gemini, Claude, CodeHelp on Moodle, etc.) to brainstorm ideas, explain concepts, help you debug, and refine your project design.
- No to AI for coding: Do not use AI to generate code for your project. All code you submit must be written by you. If you want to use code from an AI, a blog post, StackOverflow, or any other source, you must send it to the instructor for approval before you use it.
- You must be able to explain every part of your code during the check-in. If you can’t explain it, you should rewrite it.
Why this policy? Last year, students who used AI-generated code often had trouble explaining what it did, which showed they didn’t really understand it. Writing the code yourself is how you learn. Use AI to help you think, not to think for you.
What kinds of projects can you work on? ¶
Almost anything, as long as it involves writing Python code! Games, simulations, tools, data analysis, education, art — it’s all fair game. The project should not be too easy or too difficult and should be completable by your team in about 6 weeks. Start small and grow it gradually. It’s better to finish a not-so-difficult project well than to not finish an ambitious one.
If you think you need more advanced user interactions than we’ve studied in class (print(), turtle, brython), talk to the instructor about options. Prefer simple tools.
Previous projects ¶
Here are some examples of what students have done in prior offerings:
- Games: Connect Four, Battleship, a card game web app, Hangman (or Evil Hangman) with difficulty levels and statistics, Rock-Paper-Scissors against an intelligent player, …
- Simulations: Maze solving, maze generation, predator/prey population dynamics, bouncing particles, solar system simulation
- Tools/utilities: Dynamic task management system, electronic component analyzer, budget planner
- Music/art: Audio signal-processing module, drawing application, generative art
- Education: Tree identification tool for Calvin’s campus, teaching punctuation through text analysis, nutrition education game
- Data/recommendations: Restaurant review sentiment analysis, movie recommendation based on text descriptions
- Algorithms: Cribbage best-hand algorithm, Conway’s Game of Life, cellular automata
Ideas ¶
-
Take something we did together (class, lab, etc.) and extend it. Some assignments have “optional extensions” — do a few of those!
-
Make a game! e.g., Hangman (teach us about letter frequency and effective guessing strategies), Minesweeper (teach us about reasoning under uncertainty), Tic-Tac-Toe (implement a minimax algorithm), a quiz game for a topic you’re studying.
- In prior years, students have built games including Evil Hangman, Connect Four, Battleship (using turtle graphics), Minesweeper, etc.
-
Make a simulation of a physical system: a solar system, a ball bouncing in an environment, a predator/prey ecosystem, traffic flow, a cannon with wind and gravity.
-
Teach a concept from an area of interest to you. e.g., find a YouTube video that explains something (like one of the excellent 3blue1brown videos), and make an interactive version of that explanation.
-
Make some generative art! For inspiration, see #genuary, Generative Art at ObservableHQ, or Truchet images.
-
Do something with music: transpose a chord chart, generate random melodies, etc. Here’s an example of music generated from the Collatz sequence.
-
Run a psych experiment, like a Just-Noticeable Differences test or a Stroop test.
-
Work with a dataset: analyze trends, visualize data, or build a simple recommendation system.
-
Get some inspiration from Peter Norvig’s pytudes or solve a few interesting problems from projecteuler.net.
Milestone 2: Progress Report & Initial Code ¶
Submit two items on Moodle:
Progress Report (document) ¶
Submit a document (at most 5 pages, Word/PDF/etc.) that includes:
- An updated title.
- Updated goals and specifications for the final app.
- Design of the solution:
- Describe the data in your project. What kinds of Python data types will you use?
- What are the main challenges in your project? What is your plan to tackle them?
- A (partial) list of functions (and classes/methods if using OO) in your program design.
- Acknowledgments: detail any help you received from other people, including links if applicable.
Initial Code ¶
Submit your code on Moodle. If you have more than one .py file, consider naming the main one main.py. Compress all files into a ZIP.
At this point you should have:
- A main program written
- The signatures of all functions defined (including docstrings)
- A meaningful amount of code written (use
passfor unfinished function bodies) - Code that runs without errors
Include acknowledgments at the beginning of your main program in a docstring.
Checklist — Progress Report:
- Updated title
- Updated goals
- Updated specifications
- Design: data and Python types described
- Design: main challenges and plan
- Design: list of functions/classes
- Acknowledgments
Checklist — Initial Code:
- Main program written
- Function signatures defined with docstrings
- Meaningful amount of code written
- Runs without errors
- Acknowledgments in code docstring
Milestones 3–4: Code Check-ins 1–2 ¶
Submit your code on Moodle in the same format as Milestone 2 (if you have more than one .py file, consider naming the main one main.py; compress all files into a ZIP).
Each code check-in will be evaluated based on the improvement over the previous submission (e.g., additional code, bug fixing, better documentation). List the improvements at the beginning of your main program in a docstring, for example:
"""
Improvements in this submission:
- Added the scoring function
- Fixed a bug where the game crashed on invalid input
- Added docstrings to all functions
"""
Checklist:
- Improvements listed in a docstring at the top of the main file
- Meaningful new code added since last submission
- Code runs without errors
Milestone 5: Final Code + Report ¶
No late submissions accepted.
Final Report ¶
Submit a report (PDF, at most 8 pages) that includes:
- Title and author(s): An informative and concise title, and your name(s).
- Goals: What problem are you solving? Overall goals and specific subgoals.
- Data and Python data types: What kinds of data are relevant? What Python data types do you use?
- Algorithm design: Describe the algorithms you use to solve the core problems.
- Program design: A table of functions/classes you designed and their relationships.
- How to demo: Specific instructions for running a basic demo of the main functionality.
- Testing: What steps could someone do to check that your code works correctly? (e.g., if your program used to have a bug but now you fixed it, describe how you can test that it’s fixed. If you use
assertstatements, running the code may suffice.) - Highlights: A few parts of the program that you’re proud of — something tricky you got working or how you organized your code.
- Process: A one-paragraph summary of your process for creating the code. Include at least one specific difficulty that you encountered and how you overcame it.
- What you learned: Techniques or Python topics beyond what was covered in class.
- Acknowledgments: Detail any help received, including links if applicable. (If none, say so.)
- Sharing: Would you be okay with sharing your project, and if so, how? Ideally we’d make a public gallery with all projects, screenshots, and code, but you could choose to go anonymous, share only screenshots or just the title, or restrict to future students.
Checklist — Final Report:
- Informative title and name(s)
- Goals
- Data and Python data types
- Algorithm design
- Program design
- How to demo
- Testing
- Highlights
- Process
- What you learned
- Acknowledgments
- Sharing preference
Final Code ¶
Submit a ZIP file on Moodle that includes:
- Your code
- If any data is needed to run the code, please either include the data in the ZIP file or provide specific instructions for how to obtain it (e.g., go to a certain URL).
- A screenshot or very brief video of your project in action.
Checklist — Final Code:
- Correct and free of crashes
- Uses what you learned in class
- Code is readable and well-documented
- Includes something you learned on your own
- Shows meaningful coding effort
- Easy to use (clear instructions, stated purpose)
- Data or instructions to obtain it included
- Screenshot or brief video included
Milestone 6: Project Showcase ¶
During our final exam time, you will demo your project to the class:
- Section A: Thursday, May 7 at 9:00 a.m.
- Section B: Tuesday, May 5 at 6:30 p.m.
We will divide up by rows. Each person will demo their project to others in the row. Each row will then nominate one project to show to the whole class. We’ll vote for the best project!
Although this event will feel pretty informal, you should still:
- Be there! Attending and presenting counts for 5% of your project grade.
- Be prepared to show your code running. (It doesn’t have to be perfect.)
- Be prepared to answer questions about your project.
For a team project, each team member should be present and contribute.
Grading ¶
Each milestone is graded by the checklists given above.
General advice ¶
It is better to choose a project that is not overly complex and get it right than to choose one that is too complex and not finish it. I recommend finding a project you can implement in stages, so that at multiple points you have a “finished” project and can then decide whether to proceed to the next stage. Document these stages in your design document.
Testing ¶
You can use assert to test your functions. For example:
def double(x):
return x * 2
def is_close(x, y):
return abs(x - y) < .001
assert is_close(double(2), 4)
assert is_close(double(3), 6)
Reuse vs Plagiarism ¶
It can be very helpful to find an example we did in class (lab, homework, etc.) that is similar to what you want to do and adapt it. This is highly encouraged. Just note that you did so in your code documentation.
If you intend to use code from other people outside of the class, talk to us first and remember that we’ll grade you on the code you write, not on what other people write. If you do make use of existing code and libraries, be sure to clearly indicate who wrote what parts of the code; using code without proper attribution is a form of plagiarism.
Feel free to discuss ideas with us or with your classmates, but don’t copy code (i.e. plagiarize). Here are examples of what plagiarism looks like:
- You find a program online and copy the entire contents of the file into your submission without attribution.
- You find code online, and change the variable names.
- Your roommate writes some code, which you add to your program. You add documentation that shows you understand the code, but never indicate the source of the code.
- Your older sibling sends you a function that will help your program. You add it to your submission without attribution.
Consider these rules of thumb:
- If you found it efficient to use copy/paste to create some portion of your application, you must supply documentation that indicates the original source of the code.
- If the moment you figure out how to do something occurs while you are looking at a website, you should document that website.
Note that these rules of thumb apply to the code supplied in this course’s materials as well.
Resources ¶
- Project Code Samples
- awesome-python — a curated list of Python packages
- Real Python — tutorials for learning more Python on your own
Please feel free to ask the instructor for help in finding good quality resources for your project.
Datasets ¶
- Kaggle Datasets
- data.gov
- Our World in Data
- CORGIS Datasets Project (“The Collection of Really Great, Interesting, Situated Datasets”): https://think.cs.vt.edu/corgis/
- NOAA climate data
- US Geological survey live feeds, including recent earthquakes
Acknowledgments ¶
These instructions were based on project guidelines by Dr. Victor Norman, Dr. Keith Vander Linden, and Dr. Rocky Chang.