Final Project
The final project is the culmination of this class. You will demonstrate your expertise in graphics by creating a compelling project that is beyond the scope of previous assignments. It can be an extension of any previous assignment or a completely new project. If you would like, you may also work in groups of up to 3 people, but your groups must be set by the proposal deadline (no switching groups after the proposal is turned in).
Note that slip days may not be used for any part of the final project. In addition, attendance at the final project presentations is required unless cleared with the instructor with sufficient advance notice.
Basic Requirements #
Your group will have flexibility for this assignment, but it must meet certain base requirements listed below:
- Keyboard interactivity. The project must support keystrokes, which trigger some interesting functionality.
- Multiple GUI systems. The project must have at least two GUI systems. This could be a “main menu” screen with buttons and display information, and at least one other screen that includes buttons and display information.
- Class objects with animation hierarchies. The project must include objects with at least two levels of animation hierarchy (similar to what you created in the animation projects).
- Data input/output. This can be data from a data set, user-created data to provide settings (e.g. a map-builder that generates a level map based on a JSON or text file), or data saved from the application (e.g. high scores).
If you have a project idea which does not meet these requirements, but you believe is a similar amount of work, you may ask the instructor if it would be acceptable.
You may check the showcases at https://showcase.p5js.org/#/2022-All for an idea of how other are using Processing.
Project Proposal #
Submit a project proposal to Canvas by July 19 (see Canvas for exact time) with the following information:
- You and your group member’s names, if applicable.
- A high-level overview of what your final project will be
- How you are going to meet the requirements placed on your final project
- (If applicable) How you will apportion the work among your group members
Please submit as a plaintext format, e.g. Markdown or .txt. You only need to submit one proposal per group, though multiple members are allowed to submit if you are concerned.
Project Presentation #
On either July 26 or July 29, you will present your project to your classmates. You should plan on your presentation being between 5 and 10 minutes (the exact duration will be announced once all groups have been locked in on July 20).
Your presentation should explain enough background that someone who has taken the class can understand what you’ve done and how/why you’ve done it. It should also contain some sort of demonstration of your project—this can be a live demo, or you can pre-record the outputs of the program if it is too slow to run live.
Finally, your presentation should contain a short discusson of one issue you ran into while implementing your project, and a retrospective on how you could have avoided it. This issue should be related to either graphics or software development (e.g. you should not discuss running out of cell data while working at the coffee shop).
Suggestions for Working in Groups #
Since this will be your only group project in the class, here are some tips for working in groups:
- Communicate who will be working on what. I highly recommend making some sort of shared chat that you can contact each other in, just to check to see if anyone has made changes to X before you start working on it.
- Don’t work on the same thing at the same time. This may seem obvious, but sometimes it’s not always obvious which parts of the project are related. For example, one of you might want to work on the display of a simulation, and the other on the physics, but you each realize you need to make some changes to your underlying simulation to make the changes you want. You both do so, and bam, you now have conflicts which need to be resolved.
- Use some sort of archive/backup system. Git would be ideal, since it is explicitly designed for this use case, but if you don’t know how to use it, store your code on OneDrive, Box, Dropbox, or some other file storage system which provides you version history for 30 days. That way, if you accidentally screw up your code beyond all recovery, you can still get an old version back.
- Finally, be patient! Code is a very complex construct, and something which feels like it took you ten minutes to come up with might be buttressed by weeks or even months of experience. Be prepared for the possibility that you might need to explain your ideas to your groupmates a few times (or with some time off in between the explanations) before they fully understand it.
Report #
Submit a project report along with your final submission that includes the following information:
- Summaries of the functionality and implementation
- What the included classes do
- Any unexpected challenges compared to your proposal
- What group members worked on which part of the assignment
Submission #
Your submission should include the following:
- All the files that comprise your project, including any necessary classes, subclasses, and libraries.
- A README text file that tells us the exact steps necessary to run the project and how to use its controls
- Any other files necessary to run your project (e.g. images, sounds, etc.)
- A project report, as described above
- If applicable, a language model log in plaintext format.
Place these files into a directory named yourgroupname_final
, zip it, and
submit to Canvas.
Slip days may not be used for any part of the final project.