Three-week projects are just that - projects that are completed in (usually) three weeks. These are generally projects where students can pick the topic. The grade will be based on these big criteria:
The weight of each of these criteria varies depending on the time of year and the project.
The THREE-WEEK project can be broken up into the following chunks:
First, you will need to decide what you want to do for your THREE-WEEK project. You have the following options:
Once you've selected your project type (NEW or EXTENSION), you will create a ONE-PAGER for the idea you want to build for your project (see Step 2).
A typical ONE-PAGER is just like is sounds - a one page document that pitches your project. Typically this is printed in hard-copy form. Usually people use only the front-side of the document but occasionally, they will also use the back-side . . . but NEVER more than ONE sheet of paper.
Since we will be submitting a digital document, you can use up to TWO pages of the digital document (but no more).
Every time you start a new three-week project, you will need to submit a new ONE-PAGER to your teacher. You will need approval from your teacher before you continue with your project.
Your one pager can include all kinds of information BUT is should always contain the following:
The formatting of your ONE-PAGER is entirely up to you. It is your job to "sell" your project. Use use solid visual communication and design strategies.
Submit your document per the assignment instructions (usually in Google Classroom) and them move to STEP 3.
NOTE: Your ONE-PAGER / PROJECT PROPOSAL MUST BE APPROVED before you can get credit for any other part of your project.
Once you submit your ONE-PAGER you can begin the first page of your Programming Journal. Your programming journal is the documentation of all the work and all the iterations of your project.
Once you start your project (the first day you fill out the first part of your journal), there should be an entry for every day (including days you don't work on the project) until the project is complete.
This video below will explain how to fill out the DAY OF PROJECT and WORK DAY portions of your programming journal.
After you complete your first entry of your programming journal, you can begin work on the VERSION SCHEDULE for your project - which is PAGE 2 of your programming journal (see Step 4).
Starting on PAGE 2 of the programming journal is the VERSION SCHEDULE.
Your Version Schedule will help you accomplish these things:
If you are starting a NEW project, your version numbering should start at 0.0.0 and (ideally) the final version of your project should be version 1.0.0 (a fully functional and complete project - ready for people to use and enjoy). However, depending on the scope of the project, you may not be able to build a project from 0.0.0 to 1.0.0 in three weeks. Therefore, it is possible to submit a project that is still incomplete (has not reached version 1.0.0) and still receive a good grade. Likewise, it is also possible that you could complete a fully functional project (made it to 1.0.0) and receive a poor grade because the project you planned out for your three-week project could have been finished in one week. EVERY. PROJECT. IS. DIFFERENT.
Whatever you choose to do, your final grade is based more on the QUALITY of the work you produce (rather than the QUANTITY of work you produce).
Our class versioning system follow the basic principles of Semantic Versioning but is adapted for our class use. We still use three places with each number separated by a dot (i.e., X.Y.Z where each letter represents a number).
It is important to note that this is NOT a decimal system. Each number (X, Y, or Z) can be any size. For example, 1.6.2 is just as valid as 2.82.59938 - is all depends on how you identify the tasks in your build.
The X place holds the major version number. This is what we usually hear about with games. Is this version 1 of the game or version 3 of the game. It is reserved for major releases. For our class we are usually trying to build our game up to VERSION 1. Version 1 is usually considered your first major release of your completely finished, working, and stable game. Therefore, unless you are extending an already working game, all your version numbers will be from 0.0.0 through 1.0.0.
The Y place holds the major improvement to your program as you iterate though your builds towards version 1. For example, version 0.4.0 would be two major iterations BEFORE version 0.6.0 but neither of these iterations (versions) would be our final fully functional program (which would be 1.0.0).
The Z place holds all the iterations of your build as you work through your major improvements. In class, we usually call these the baby-steps of your iterations. These are the tiny changes you make in between major improvements of your build. For example, if between version 0.4.0 and 0.5.0 there were SIX baby-steps that I needed to accomplish the make this change, I would expect to see all of the following version numbers (listed in order from oldest (top) to newest (bottom):
If 0.4.6 is the last baby-step I need to do to finish my next major change, I don't need 0.4.7. Instead I jump straight to 0.5.0. Remember, this is NOT a decimal system. It is not uncommon to have version numbers that look like this: 0.17.32. It all depends on YOUR task list.
Finally, EVERY TIME you change your versioning (which is every time you complete a specific task) you should have a saved (REMIXED) file of the game at that version. EVERY saved version of your project should be bug free.
Never REMIX a "broken" project and never leave a task unfinished. ALWAYS make sure you new task is working BEFORE you move on to the next step.
If you are new to versioning, you should checkout the sample used on the DODGER game starter tutorial.
Still a little confused about how the versioning system works? Watch this video where I analyze the version numbering system used for the Dodger Game Starter Tutorial.
Still confused about how to fill out your versioning schedule on PAGE 2 of your PROGRAMMING JOURNAL? Watch this video where I evaluate and critique some previously submitted programming journals.
After you pencil in your VERSION SCHEDULE, you need to create your paper prototype.
All projects MUST complete a PAPER PROTOTYPE. You must sketch out, in detail, all parts of your project. This is different, and much more detailed, version of what you submitted with your ONE PAGER. This is an ANALOG version of the digital project you are trying to create.
If you are required to submit a digital document for this, most students find it easiest to create your actual paper prototype (on paper) and then take pictures of your completed work. Then, on your digital document, you can explain what is in your pictures.
Additionally, if you have an assignment posted in Google Classroom for the PAPER PROTOTYPE, please check for any specific directions there before you complete this step.
Use the following links to submit and/or view game projects UNLESS your teacher has specifically given you an alternate submission form (which is not uncommon, by the way). Check your Google Classroom posting for correct details BEFORE you submit: