CS10 Final Project Specification

Introduction

We want you to show off everything that you have learned this semester in a final project of your choice and design. Just like the midterm project, you can design anything you want, using all of your programming knowledge to produce something that is interesting, useful, and challenging for you. You are welcome to either develop your midterm project further, or create an entirely new and interesting project: if you are doing the former, however, we ask that you add a substantial amount of code, rather than simply adding new levels or enemies. Ultimately, you should spend time designing algorithms and writing code, as opposed to developing sprite graphics.

Important Dates

Coming soon.
Fri, July 27 Project proposal due
Mon, July 30 Project work in lab
Tue, July 31 Progress report due
Wed August 1 Project work in lab
Fri, August 3 Project due

Project Proposal

This document should be two or three paragraphs that describes the overarching purpose of your project. Is it a game? 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 movie, a list of options for a utility, and so on.

This is generally a non-technical document and should describe big ideas more than the technical details of how it will be done. You can submit this document via the Google form. 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.

We are more worried about the content of your proposal than the length of it. Make sure that you give us enough detail to judge the difficulty of your proposed project.

Only submit ONE per group. Submission Form

Project Progress Report

This document should be around a page or two (depending on the complexity of the project) and should describe how your project has progressed since the beginning. Among other things, we would like for you to talk about:

This should be a reasonably technical document. Feel free to talk about particular blocks if it helps you communicate your solution. Briefly discussing your algorithm for particularly complex problems is welcome as well. You will also be able to submit this via a Google form.

Only submit ONE per group. Submission Form

Project Submission

The official deadline for the project is Friday, August 3rd, 2012 at 11:55PM: five minutes before midnight. You will submit four items on bSpace:

  1. All the files associated with your project. For most projects, this will simply be the BYOB file containing your project, but you should also include any auxiliary files needed for your project to work.

  2. A file named README: this is a document (we recommend PDF documents) that is essentially a manual for your code. The README is directed to any user who is looking at your project for the first time and wants to know what the project is about, how to interface with the project, and what the various lists, scores, and figures mean. It shouldn't be too long: around 1 to 2 pages (ignoring pictures) will be fine. You can sprinkle your document with pictures, if you think that these pictures will explain better. (After all, a picture is worth ... what is it? A thousand bytes?)

    Also, in your README, talk about the significant programming components of your project. For example, how did you partition your work between sprites and blocks? What can each sprite do and respond to, and what are the major blocks in your project? What are the major lists and what are their purposes? In short, 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.

  3. A document called Partners that contains only the names of the people in your project group.

Only one person needs to submit the entire project. Some of your projects may be huge in terms of file size. We recommend that, before you turn in your project, you use the Compress Sounds and Compress Images options in the Edit menu to reduce the file size. The sound quality should be Normal or Low, and the image quality should be 60.

Requirements

  1. There must be a clear way to start your program. Using the green flag is the recommended approach.
  2. If you create a game, it has to be a game with a purpose, in the broadest sense of the term. It could be a training game, or an educational game, or one to test an HCI question you want to answer (e.g., whether it is more efficient to use the QWERTY keyboard versus the DVORAK keyboard), or for some other purpose. It can't be for purely entertainment purposes.
  3. "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.
  4. Create some of your own blocks.
  5. Use lists in your project in some way.
  6. You cannot work alone, but can either work in pairs or groups of three. Expectations will be higher for larger groups.

Grading

Project specification 10 pts
Project progress report   5 pts
Meeting your specification 20 pts
Style 10 pts
Meeting technical requirements 15 pts
Total 60 pts

Tips

  1. Remember that you have slip days! At the beginning of the semester, we gave you three slip days for homework and projects, which means that you can use these slip days to work on your projects beyond the deadline, without detriment to your project grade. However, these slip days are cumulative: this means that for all the assignments in this semester, you can only use a total of three slip days. Since you are working in groups, the slip days don't accumulate: every person loses a slip day for each day that your project comes in after the deadline. 25% of your project grade will be deducted for each day beyond the deadline once you run out of slip days.
  2. As you work through your projects, we ask that you comment your code to make it easier for us to grade, and also to make it easier for any person who wants to know how your code works.
  3. Please save copies of your projects frequently. In particular, if you think that your project is at a stable state, save a backup copy elsewhere, before you make any substantial changes to it. This will allow you to "roll back" to a stable copy of your project if you make a substantial buggy change.
  4. If you had performance problems with your midterm project, think about the components that made it slow down. Plan that into your work so that you can get core stuff working before bogging your entire project down. We've noticed that huge lists, lots of sprites, and a crowded stage can slow things down so try to control those elements as much as possible.

Extra Credit

A small amount of extra credit will be available for the project if you choose a socially relevant topic (education, health, etc). The amount of extra credit will be based on the intensity of impact (how much it affects the targeted population) and the range of people that it impacts (the size of the population).

A small amount will also be available by making a short youtube video explaining and demonstrating your project (more details to come).

Other projects

You're welcome to work on almost any project that interests you. Here are some ideas of projects that have been successful in the past to fuel your thinking, but feel free to do something totally different if you'd prefer.

Game-based AI Agent

Write a program that can play a game involving chance like Yahtzee, Monopoly or poker.

Game Solver

Write a program that can solve and / or generate sudokus, word searches, crossword puzzles, etc.

Art Generator

Write a program that can generate images, music, etc (automatically or with human input).

Alternative Input

Write a program that puts one of our Picoboards or our Kinect to work in interesting ways.

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.

more to come soon...

Tips

  1. Remember that you have slip days! At the beginning of the semester, we gave you four slip days for homework and projects, which means that you can use these slip days to work on your projects beyond the deadline, without detriment to your project grade. However, these slip days are cumulative: this means that for all the assignments in this semester, you can only use a total of three slip days. Also, these are slip days and not slip hours: if you use the first few hours of a specific slip day, we will assume that you have used the whole slip day. Finally, since you are working in groups (you are, right?), the slip days don't accumulate: being a day late will count against everyone in the group's slip day supply. We recommend that you use at most one slip day for this project, since you have a paper and a final project to work on.
  2. As you work through your projects, we ask that you comment your code to make it easier for us to grade, and also to make it easier for any person who wants to know how your code works.
  3. Please save copies of your projects frequently. In particular, if you think that your project is at a stable state, save a backup copy elsewhere, before you make any substantial changes to it. Emailing it to yourself or project partners is a good method of backing up your work. This will allow you to "roll back" to a stable copy of your project if you make a substantial buggy change.

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 Navin, Luke, and Glenn will be 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.

Group Evaluation

This form is enitrely option and is only if you would like to give information to the GSIs regarding whether there was anything particularly important about how work was distributed among members of your group. Do not feel obligated to turn one in and we assume most groups will not.