A printable PDF is available.

CSC 100 Final Project

Over the final four weeks of this class (leading up to the Thanksgiving break), you will work on a project of your own design. Students will team up to produce some creative software product, such as a game, educational program, tool, interactive animation or sound application, etc. Groups can be either two or three students, and three-student groups will be expected to do proportionally more work than two-student groups. You can use BYOB, Python with SnapPy (from Lab 8), or Python with simple turtle graphics (you probably can't make a decent game this way, but you could make some sort of interactive art project).

The goal of this assignment is to give you some experience with developing a reasonably complex application. Your experience with programming so far has been limited mainly to guided labs and homework assignments; whether you realize it or not, you've already gained a lot of programming knowledge over the course of the semester. This project is designed to let you use all of this new knowledge to produce something that is interesting, useful, and challenging for you. We want to unleash your creativity as much as possible, so the purpose of your project will really be up to you (as well as either one or two other people on your team). But keep in mind that this is a computer science class and not an art class: your first priority is to spend time designing algorithms and writing code, not just making cool graphics and sprites. See below for a list of basic project requirements.

At the last lab meeting of the semester there will be a "project showcase" in which students present and demonstrate their projects for the class. Students will vote on the projects, and the winning project will receive a "Student's Choice Award."

Timeline and Due Dates

The project will proceed in stages, with regular deliverables and activities. For all major deliverables there should be one submission per group, but make sure all project team member names are included on any written submission. The one exception is the teamwork reflection that is due from each student individually (see below under "Final Deliverables"). The following table summarizes due dates. Note that all deliverables are due before class or lab, so should be turned in before 10:00 AM on the due date.

*Date(s)*	*Activity/Deliverable*
Oct 22-24	Initial team organization
Fri, Oct 31	In-lab project presentations and discussion
Wed, Nov 5	Written project proposal due
Fri, Nov 14	Progress report due
Fri, Nov 21	Final project demos and presentations
Wed, Dec 3	All project materials due (due before Final Exam at noon)

Details for each part are described below.

Project Proposal: Presentation and Written Proposal

We will spend some time in class organizing students into groups with similar interests, and the first major thing that teams must do is a proposal presentation. Each team will have a total of 7 minutes, and should plan for 3-4 minutes to present their ideas and about the same amount of time for discussion/feedback. The purpose of these presentations is to help you focus your ideas, and get good and creative ideas from other students. All students are expected to be engaged in these discussions – you will get a small participation grade during these presentations, so if you don't contribute to the discussion of some other group's project you will not get any of these points.

A written project proposal is due Wednesday following your presentation. This will give you the opportunity to incorporate any good ideas you get from the proposal discussions. This document should be one to two pages, double-spaced. Start with two or three paragraphs that describe the overarching purpose of your project. Is it a game? Educational software? A utility? A sound-based application? After describing the main purpose, discuss the "scope" of the project: the types of things users will and will not be able to do with it. This can include a basic plot line for a game or animation, a list of options for a utility, and so on. Finally, prioritize your project scope: list things that it must do, and things that you'd like for it to do. You need to submit something that works, so prioritizing this way will ensure that you can submit something even if you don't get to all of your (hopefully a little ambitious) plans.

This is generally a non-technical document and should describe big ideas more than the technical details of how it will be done. We will discuss your project proposal with you if we have questions about feasibility: in particular, we're interested in gauging the level of difficulty of the project, the estimated workload, design choices, and potential pitfalls. Note: although you will be able to tweak your project idea after your proposal has been submitted, the gist of it should stay the same. Make sure that you're happy with your idea since you'll be spending a good bit of time with it.

Progress Report

This document should again be one to two pages, double-spaced. You should describe what progress you have made towards completing your project – among other things, you should include:

the general breakdown of work among the members of your project group,
what kind of milestones you have set and which have been met,
what problems you have encountered and how you overcame them,
whether (and how) your project has changed from when you first described it in the project proposal, and
what is left to be done.

This should be a reasonably technical document. Feel free to talk about particular blocks if it helps you communicate your solution. You can also briefly discuss your algorithms for particularly complex problems. Bear in mind that by this point, you should have completed approximately two thirds of your project.

Final Project Demo and Presentation

Your project should be finished and working before the project presentation. You should create a presentation and demo for your project. Each team will have approximately 7 minutes, and each team member must have a significant (at least 2 minutes) speaking role in this presentation. In addition to demonstrating how your program works, you should talk about individual responsibilities within the project, what challenges you encountered, and what you learned.

You should save your project code and presentation PowerPoint on a USB flash drive so that you can efficiently bring up your materials during your presentation. While you are not required to use the following format, it is strongly suggested (if you want to deviate from this, it would be a good idea to discuss your ideas with the instructor first):

Title Slide – Project Title, Team Members, Date
1 Slide on project purpose and why you chose it
1-4 Slides with an overview of the implementation design
1 Slide summarizing what challenges you encountered, and how you dealt with them

And then demonstrate your project! Note that due to the number of projects that must be presented, your time is limited – if you create a long animation, you might have to create a special version for the presentation that extracts some interesting smaller pieces that can fit into the time limits.

Project Submission

The official deadline for the project is Wednesday, December 3, 2014 at noon. Note that this is the time for the final exam, so plan ahead! Each team will submit three items in Blackboard

All the files associated with your project. For most projects, this will simply be the program file (Python or BYOB) containing your project, but you should also include any auxiliary files needed for your project to work.
The PowerPoint slides from your presentation.
A report that includes one page with basic instructions for how a user would run and interact with your program, and 2-3 pages that give a summary of significant programming components of your project. This second part should describe your basic design: how you partitioned the work between program pieces (sprites, blocks, functions, ...), what functions or blocks you defined and why they made sense as abstractions. How did you use lists in your project? Talk about how your project works on an abstract level, in terms of programming components working with each other. You don't need to go into specifics.

Only one person should submit these three items for the team, but make sure you have all team member names on the report. Some of your projects may be huge in terms of file size. Make sure that you use efficient, compressed formats for things like images and sounds whenever possible.

Finally, each individual should submit a short report (1/3 to 1/2 page) describing how you felt your team functioned. Did you think there was sufficient and effective team communication? Did everyone contribute a fair share of the work? What lessons did you learn about teamwork that will affect how you approach team projects in the future?

Basic Project Requirements

There must be a clear way to start your program. In Python, it is recommended that you have a function named run(), so that typing run() in the Python Shell runs your program. In BYOB, using the green flag is the recommended approach.
If you create a game, it has to either be very creative, or should be a game with a purpose (a mind-expanding puzzle game, training game, educational game, etc.).
All programs should be interactive. If you do an animation, it should involve significant user interaction – it's a program, not a movie!
"Style" points will be awarded for things like well-commented and nicely structured code. Poor structure can include things like duplicated code, needlessly complicated organization or program flow, and so on.
Create some of your own functions and blocks. Proper abstractions are a must!
Use lists in your project in some way.
You cannot work alone, but can either work in pairs or groups of three. Expectations will be higher for larger groups.

Project Ideas and Sources of Inspiration

Here are some ideas of both types of projects and specific ideas that should get you thinking about possibilities:

Game-based AI Agent: Write a program that can play a game involving chance, like Yahtzee, Monopoly, or poker.
Puzzle Solver: Write a program that can solve and/or generate sudokus, word searches, crossword puzzles, etc.
Tutorials: Write a program that teaches the user about some topic (a topic from computer science, music, math, ...)
Art Generator: Write a program that can generate images, music, etc.
Modeling Algorithms: Write a program to simulate and analyze different strategies for solving a problem, such as different ways to serve customers at a store (one line for multiple registers vs multiple lines?), ways to board a plane (front to back or window to aisle?), ways to pack a truck (as packages come in or order largest to smallest?), ...
Planning Algorithms: Write a program that can recognize flow patterns (traffic on streets, people waiting for elevators) and adapts controller behavior (traffic lights, elevator destinations) to reduce delays.

Please don't use another person's project to start creating your own -- we want this to be entirely your own creation. Nevertheless, getting inspiration from other projects, programs, etc. is encouraged. Here are some Scratch projects that may be good for generating ideas.

Simple:

http://scratch.mit.edu/projects/hippiegirl/497628 (good for basic game-making ideas)

http://scratch.mit.edu/projects/taco/329214

http://scratch.mit.edu/projects/herey/594058

http://scratch.mit.edu/projects/filo5/561786

http://scratch.mit.edu/projects/kgordon/544638

Ambitious:

http://scratch.mit.edu/projects/Comcastc99/366076

http://scratch.mit.edu/projects/DrSuper/599528

http://scratch.mit.edu/projects/wwjd3/411036

A Word of Warning

Getting to design projects of your own can be exciting, and it is very easy to underestimate how long it will take to accomplish a particular goal. Remember: although we are happy to help you bring your idea to life, you won't have lab-like guidelines for making this happen. It may take a lot longer to make your project than you think! That being said, don't hold back if you think you can make something truly grand. We're here to help you if you've got an idea that you love.

Project Tips

Save often. If you use BYOB, use "Clear all Variables" under the "Edit" menu before you save to speed up the process. Be aware, however, that this will clear all of your lists, too (see #3 below).
Backup often. This may entail creating multiple versions of your project to act as backups. Making copies from your desktop is much faster than saving under BYOB with a different name!
Begin with functionality, and then start adding assets (custom-made sprites, imported lists, sounds, music, etc.) only after you've gotten your scripts working correctly. For lists, define test lists in your program that you can use for testing. In Python these can just be lists assigned to a variable, and in BYOB you could create a "delete all, add, add, add, ..." script for use while you are testing (see #7 below).
Test each of your functions/blocks thoroughly. You don't construct a skyscraper and then start checking the first floor for structural problems. Test each part as you go along, and build from a solid foundation (see #7 below, too).
Choose descriptive variable, function/block, sprite, etc. names. Follow sensible naming conventions, and if you work independently with the intent of merging your work, make sure you plan out names of objects so that the merging goes smoothly.
Follow the Principle of Least Scoping, and in particular minimize the number of global variables that you have (variables that can be seen and/or modified by all of the sprites). These tend to cause hard-to-track-down bugs. Use local variables or script variables whenever possible.
If a complex block isn't working correctly, start pulling pieces out of it and test each one individually (aka "Unit Testing"). Give the isolated block a set of known inputs, determine what the output should be, and then compare the results.
One more time: save and backup often!