To get us started, I want to make sure that we revisit the project requirements that we talked about with the final proposal process:
Final Project Requirements
As much as I’d love to let you have free reign on the final project, I do want you to have a few guidelines in place. With that in mind, plan your final project knowing that I’ll want to see you:
- Create a visual composition with your assignment (you don’t have to build a visualiser, but I do want to see that you’re using what we’ve learned about working with pixels… if you’re not sure if what you’re thinking about counts, ask me)
- Create a control panel for user interaction / programmer interaction.
- Perform in real time, or close to it (I don’t want to see projects that crash or hang).
- Be organized and modular in your programming (I want to see that you know how to use encapsulation to make sure your projects are organized and reusable).
- Comment your code – it will make you all the happier when you’re building something over the course of several weeks.
With the above in mind, your final project, at it’s heart, is an opportunity for you to practice the techniques that we’ve gone over this semester. Remember that you’re building an application from scratch – it doesn’t need to be perfect, but the toe file that you submit should include:
- An originalProposal DAT – include a text DAT with the text from your original project proposal – you don’t need to include the system diagram, just the text from your original project proposal.
- Congruence with proposal – Your project should have some congruence with your original proposal. Your final doesn’t need to be exactly what you proposed, but it should feel related to the idea you were originally considering exploring.
- Performance – Your project should perform at at least 25 frames per second.
- Organization – Your project should be well organized. We’ve spent a significant amount of time in class talking about organization and modular approach. Make sure that you’re making use of encapsulation to create tidy networks that are easy to read.
- Visual Component – Your project should include a visuals component.
- Control Component – Your project should include a control component.
- Comments – Your project should be well commented
- Use of Storage – Your project should make use of storage in at least one container.
- Perform Mode – Your final project should be configured to begin in perform mode.
- A selfReflection DAT – include a text DAT in the root directory of your network that outlines your successes and lessons.
- On a scale of 1-10 (1 – your project is totally different than you expected; 10 your project is exactly what you set out to make) how close did your final project resemble your originally proposal?
- What challenges were you prepared to meet?
- Where did you get lost along the way?
- What are you especially proud of?
- What were you especially frustrated by?
- If you were going to do this project again, what would you do differently?
If you’re submitting a project that uses photos, video, audio, or 3D object files you’ll need to make sure that you zip those files together into a single folder.
- Especially large project folders can be submitted by posting a link in your submission to a cloud storage platform – the 200MB folder is going to take a long time to upload to Blackboard, you can submit a link to a file on google drive, dropbox, etc. if you have a large project.
- I might not have access to the unique equipment that you used for your project – if you’re using a midi keyboard, an OSC interface, or another input device you’ll need to have a switch in your network that toggles between live and static inputs (this is the same process that we used in project 2 when thinking about default values).