Final Project


Overview

This project is an opportunity to demonstrate your ability to apply your 15-112 knowledge in a creative and open-ended way. Within the constraints explained in this document, you may create anything you wish. If you are unsure of what you want to create, you may get some great ideas from the 112 Project Gallery. You should also go to Faculty OH and TA OH where we will gladly help you ideate. In any case, be creative and have fun!

You can either do a standard project or a custom project. We expect most of you to choose the standard option. If you wish to complete a custom project, you must fill out the Custom Project Request Form by Wed 15-Apr, and you must receive explicit approval via email from the course faculty by Thu 16-Apr. If you do not receive that email by that date, then you must do a standard project.

Here are the rules for all projects (standard and custom):
  1. User Experience (UX)
    Much of your project's grade depends on the quality of the user experience. This means your project must be richly interactive. That being said, you should resist the urge to add a bunch of superficial, shallow features. Instead, focus on a small set of well-chosen, well-designed features that produce a cogent, engaging app. Many people choose to make a game, though you may also choose to make something else, like a productivity app. Regardless of your app's basic functionality, your app's visual design should feel deliberate and cohesive, rather than being a collection of mismatched misaligned images and shapes. (Note that AI tends to struggle with this.)
  2. Code Design
    In addition to a rich UX, your project must have well-designed and well-written code using good style, as explained in the course notes and in lecture. Your code should be well-organized and easy for us to read and understand. Projects with egregious style will lose points. Note that AI often produces code with egregious style and poor organization, the kind that would lose points.
  3. Solo
    You may not work in groups. You must create your own project.
  4. Unique to You
    Your project does not have to be unique, but it must be new to you. Thus, for example, a lightly-modified version of Snake or Tetris would not qualify. That said, you are free to recreate projects from the 112 Project Gallery, but only if you have not previously written a similar project. That said, we welcome and encourage you to add some interesting and novel aspects to your project, even if it is similar to an existing project or app.
  5. AI
    While you are free to use AI...
    1. You must cite all such uses (see Citation below).
    2. You must understand ALL the code you submit (except for Exempt Code as noted below). This will be assessed in an oral assessment (similar to the oral writing sessions you have had this semester).
      • Note: if you do not fully understand all your code, you should expect a very low grade on your project.
  6. Required Effort
    You must invest at least 12 hours of time in your project, and this must be clearly evident in the scope and sophistication of your User Experience and of your code. If you are unsure if your project idea will fit within this scope, be sure to talk to faculty and TAs before starting.
    • Note: we expect most of those 12 hours to be spent writing and debugging original code. While (once again) you are free to use AI, do not spend most of your time trying to get AI to write your project for you.
  7. Interim Reports
    You must complete Interim Reports, one for every 2 hours you work on your project, or for every day you work on your project, whichever is more frequent. Also, if you started before the Interim Reports Form is available, then on the first Interim Report that you fill out you should include more details on everything you have done up to that point.
  8. Attendance
    You must be well-prepared and on time for all required project-related meetings. If you are even a minute late, your score will be reduced significantly, and if you miss a meeting we will not reschedule it and you will receive a zero for that portion of the project. (Obviously, if you are in the hospital or facing some similarly extreme situation, contact the faculty and we will accommodate your situation.)
  9. No Extensions
    There are no Extensions (or Grace Days) for any part of the project. The deadlines are all firm. We will not grade anything submitted after a deadline.
  10. Academic Integrity
    All syllabus policies apply, including but not limited to those in the 112 Homework Collaboration Policy (No-copying rule, 5-minute rule) and the Academic Integrity section, except where superseded in this document.
  11. Citation
    You must cite any code that you did not fully write yourself, including code from AI but also from any other source. Citations should be placed in a comment right above the relevant piece of code, and should make it clear which section of code it refers to (the function below, the next 5 functions, etc) and the extent to which you were involved in writing the code (entirely, partly, not at all), along with a link to the source (or at least the name of the AI tool you used).
  12. Exempt Code
    You must understand any code that you wish to count towards your grade, whether fully original or based on AI or other sources. However, you may also wish to use code without it counting towards your grade. We will call that "exempt code". For example, say you use AI along with some online demos to get a multi-user server working, so your game can run with several players each on their own computers. Cool! But what if that code is just too complex for you to understand? No problem. You just declare it to be Exempt Code (in a very clear comment around the part you do not understand). In this way, you still get to use that super-cool feature, but the code itself will neither help nor hurt your grade (and so we will not refer to that code in your oral assessment). Note that all exempt code declarations must occur prior to your oral assessment.
Here are the additional rules for standard projects:
  1. You must use CPCS cmu_graphics using MVC properly.
  2. You may not use any non-builtin modules.
  3. Your project must exist and run in a single CS Academy Creative Task file.
And here are the additional rules for custom projects:
  1. You may use non-builtin modules. That said, be careful here. Your grade will not increase just because you are using such modules, and many modules are rather complex and challenging to master.
  2. You are still required to use CPCS cmu_graphics (desktop version is ok here) and MVC, unless you have explicit faculty permission via email allowing you to use a different graphics package (such as pygame or opencv).
  3. If your project is not in CS Academy, then you must use github to store your code (in addition to still submitting your Interim Reports on the form we provide), in a repository that you share with your TA grader, and you must push regular updates to your code (at least once for every 2 hours of work you do, or at least once for each day you work on your code, whichever is more frequent).
    • This rule applies as of Tue 14-Apr. If you have started before then, you should add all the code you have to your github repository by Tue 14-Apr, and from then on you must follow the rules as noted above.
    • Also, if you are working outside of CS Academy, you must include the file main.py, and this must be the file we run to run your whole project. Also, place the triple-quoted string (see below) at the top of this file.
Finally, here some suggestions (not requirements) and additional notes for all projects:
  1. Choose something you care about. The best project experiences always are from students who have a passion for their project.
  2. Bigger is not better. We grade on quality not quantity. Resist the urge to add lots of features, or lots of levels, or lots of complex graphics. This will not increase your grade. Instead, include enough complexity to showcase your design and coding talents, but no more.
  3. Start early. Do most of the work during the first half of the project period, leaving the latter part to mostly polish your project and prepare your project submission (video, etc).
  4. Since we will be grading a wide variety of projects, this requires some subjectivity in our grading. While this is true, be assured that we will take measures to ensure that we are grading fairly and consistently.
  5. A "working" app does not have to be 100% free of bugs, but these bugs should not be large enough to detract substantially from the user experience. So debug your code well, but don't worry if a small bug here or there crops up now and then.
  6. Assuming most of you will invest thoughtful effort in the project, we expect the median grade for the project to be around 85.

Due Dates

Project Mentor Sign-Up Form Due by Sun 12-Apr by 8pm
Mentor Meeting #1 Due by Fri 17-Apr by 8pm (though earlier is preferred)
Mentor Meeting #2 Due by Tue 21-Apr by 8pm
Project Due Due by Fri 24-Apr by 4pm
Project Showcase Required, on Fri 24-Apr at 7pm
Project Oral Assessment Required, due by Sat 25-Apr by 8pm

Project Forms

Here are all the forms you will need to fill out at various times (as described in this writeup) to complete your project:

Project Submission

Once again, your project submission is due by Fri 24-Apr by 4pm. We will grade whatever you have submitted (if anything) by then.

Project Submission Form:
Before the deadline, you must submit the Project Submission form, which will ask you for a link to your uploaded video (see Project Grading Video below) and a few short questions about your project. If your video link is ready, you should be able to complete the form in about 30 minutes, but don't put it off too late, since the form will lock at the deadline.

We will download a copy of your code from CS Academy (for standard projects) or your github repository (for custom projects) at exactly 4pm on the due date. To avoid the risk of your submission being buggy at 4pm, you should make sure that your project runs and is in a gradable state well before then, and you should definitely avoid trying to add new features in the last few hours. Additionally, do not modify your code after the deadline has passed.
Feature List:
Include a triple-quoted string at the top of your code that briefly describes the key features that you want us to grade. If it is not obvious, you also need to include brief instructions for graders explaining how to make those features visible.

Grading Shortcuts:
Also, to help us grade your project, we ask that you provide "grading shortcuts", or specific keys graders can press to put the app immediately into a state that showcases some of the best features you implemented. For example, in a platformer, maybe press B to skip right to the Boss Scene, something like that. List those grading shortcuts in your triple-quoted string, and perhaps in the project UI itself (e.g. in a grading shortcuts screen).

Project Grading Video:
Everyone must also create a short video (no more than 2 minutes, preferably 1 minute) where you screenshare your running project with your voice-over where you showcase the most important features that you want graders to be aware of. Graders will watch the video (closely, but only up to the first 2 minutes in all cases) just before grading your project. Note: You do not need to make a very polished video, so long as we can see your running project and clearly hear and understand your comments. One very easy way to do this is to use zoom, share your screen, and record the meeting.

Grading

Your project will be graded as follows:

Project Component Weight Notes
Mentor Meetings 15% The mentor meetings are not assessments, but rather just to help make sure you are making good choices and progressing smoothly. You will receive full points if you show up on time and participate earnestly. Again, we expect and hope that most of you would receive all of these points.
Interim Reports 15% So long as you follow the rules outlined above, with sufficiently frequent reports with brief but thoughtful commentary, you should receive all of these points.
Oral Assessment 40% This is where you will demonstrate your mastery of your code, with both your mentor and a grader present, in a style similar to oral writing sessions. Note (once again) that if you do not fully understand all the code that you submit, you should expect a very low grade on this portion. Also note that if your project quality or perceived effort is particularly low, we may deduct points (perhaps many points) from this category as well.
Project Quality 30% This will be equally weighted between your User Experience (UX) and the quality of your code. Note that we will use the project video you submitted to help us grade this portion. If you do not submit a project video, you will recieve no points here.

That's it. Once again, be creative and have fun!