CS10 Midterm Project Specification

The Goal of this Project

The goal of this assignment is to give you some experience with
developing reasonably complex applications. Your experience with
programming so far has been limited mainly to shorter labs and homework
assignments; this project will instead span over the course of three
weeks. Whether you realize it or not, you've already gained a huge amount 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).

Important Dates

Th/F, October 4/5

Project proposal lab

Fri, October 5

Project proposal due

Th/F, October 11/12

Project work in lab

Fri, October 12

Project progress report due

Th/F, October 18/19

Project work in lab

Fri, October 19

Project due

Project Proposal

This document will consist of filling out a google form and 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. If appropriate, talk about things that you've already done
in lab that you may use in your project.

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
form via the link on the main calendar. 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.

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:

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,

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.
Briefly discussing your algorithm for particularly complex problems is welcome as well. You will also be able to submit this on bSpace.

Project Submission

The official deadline for the project is Friday, October 19, 2011 at 11:59PM: a minute before midnight. You will submit your project on
bSpace.
Also, with your project, please turn in a file named README: this is a document (we recommend PDF or text 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 the purpose of the various lists, variables, and scripts. In sohrt, 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. Around one pages (ignoring pictures) will be fine. You can sprinkle your document
with
pictures if you think that these pictures will explain your ideas better.

Finally, submit a document called partners.txt that contains only the names of the people in your project group. Only one person needs to submit
the
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

There must be a clear way to start your program. Using the green flag is the recommended approach.

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's more efficient to use the QWERTY or DVORAK keyboard layout), or for some other purpose. It can't be just for entertainment
purposes.

"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, etc.

Create some of your own blocks.

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.

Grading

Project proposals

5 pts

Specification

10 pts

Meeting your specification

20 pts

Style

10 pts

Meets all requirements

15 pts

Total

60 pts

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).

Extra Credit: Video Presentation

There will also be a point or two of EC available for making a youtube walk-through of your project. Once uploaded, please upload it to Piazza.
Some information about capturing the video is here...

Other projects

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

Tips

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.

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.

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.