This page is being redesigned for the 2022 school year and is being constantly updated.

Be sure to REFRESH this page daily so that you are seeing the latest updates.

Follow the directions on this page. However, if you get stuck and/or something doesn't make sense, contact your teacher immediately.

Also, don’t forget to use the WHHS CS Game Starter Tutorials website if you need help incorporating some game elements into your projects.

Follow the directions on this page if you are attempting to create a Classic 2D arcade-style GAME EXTENSION game in Code.org's GameLab.

Remember, that the directions on this page are general directions. They should work for any kind of classic 2D arcade-style GAME EXTENSION that can be built in GameLab. However, since each game is unique, some of the instructions may need to be modified and some may not apply to you at all.

If you have any questions about your build, be sure check with your teacher immediately for clarification.

Remember that each THREE-WEEK PROJECT is usually completed in three school-weeks (or 15 normal school days). However, due to external factors (holidays, assemblies, etc.), the exact time allocated for this TWP could be more or fewer than 15 school days. Check the Daily Class Announcements for full details on the time frame for this project.

The general criteria for grading will be based on the following:

1. How well a student properly PREPARES and PLANS OUT the entire project before attempting the first build.

2. How well the student honestly REFLECTS, ASSESSES, and makes appropriate ADJUSTMENTS (as necessary) to the project build.

3. The quality of final ARTIFACT. This will be assessed in the following ways:

   1. The UX (User Experience) of the finished product (does the program actually work, etc.)

   2. How well the student follows good programming conventions when writing the code (whitespace, indentation, comments, naming conventions, user-created functions, organization/structure, etc.).

   3. How well the student incorporates NEW coding structures that demonstrate learning and growth as a programmer. (i.e., don't show me what you already know how to do. Show me that you can learn and incorporate new ideas).

The THREE-WEEK project can be broken up into FIVE main chunks:

• Project Proposal

• Project Planning

• Iterative Project Development (building, testing, and continually making small improvements/adjustments)

• Final Project Submission

• Evaluation, Feedback, and Reflection

While we generally do these in order, there is overlap between the last four chunks. For example, we are constantly reflecting on the project from the very first day (via our programming journal) and there are Reflection elements built in to the Iterative Project Development . . . that, in turn, can cause us to go back and refine our original plan.

Your project should be a very interactive and flexible process.

The Project Proposal can be chunked into TWO main steps:

1. Determine the Scope of your Project

   • What do you plan to build (a new project or are you extending another project)?

   • How much time do you have to build it?

2. Create your Project Proposal (ONE-PAGER)

You will need to decide what you think you can accomplish in the time we have allocated for this project. Coming up with a REALISTIC idea of what you can successfully build over the 15 days is an important skill to develop. We are not looking for the best project you can make. We are looking for the best project you can make in 15 school days. Make sure you understand the difference and keep that in mind as you craft your ONE-PAGER.

Additionally, for a project EXTENSION, you must clearly indicate how your final extension is a 15-day improvement over the original. It's not enough just to add "more" to a project. There should be a distinct difference between the ORIGINAL and the EXTENSION.

Note: it is always better to over-plan (and not get to everything) than it is to under-plan and finish early. Wherever you ultimately end up on Day 15 with your project, you should be working to make improvements during all 15 days of the project cycle.

Typically, your ONE-PAGER is printed in hard-copy form. However, we will be creating and submitted a DIGITAL document. Since we will be submitting a digital document, you can use up to TWO pages of the digital document (but no more).

When your ONE-PAGER gets approved, you will be able to earn points for the rest of your project.

ONE-PAGER Components

A typical ONE-PAGER for a classic 2D arcade-style GAME EXTENSION should contain all the important facts about the project you intend to build. You will need TWO sets of sketches.

The first set of sketches should be about the CURRENT state of your game (before you add in your extensions). Make sure you detail the following:

• What is the current objective of game (how do you win? // how do you level up?)

• How do you play?

• What is the current role of the user? Do you control a character/avatar?

• How do you currently interact with the game? Do you use the mouse/keyboard?

• How do you level up? Is there any leveling up?

• Be sure to include various modes of the CURRENT game play (splash screen, game play, levels, boss, game over, etc.).

• Be sure identify all the sprites/variables that are currently used along with their current behaviors.

• Be sure to identify the naming convention(s) that are currently used for sprites/variables/functions, etc.

• Identify whether or not there is a scoreboard (or some kind of user feedback) on the screen and how it is CURRENTLY used in the game.

Once you've detailed your CURRENT state of the game, you need to create NEW, DETAILED sketches to identify how you plan to extend the game.

ONE-PAGER Document

Make a copy of the Classic 2D Arcade-Style Game EXTENSION: ONE-PAGER and complete the digital document. Refer to the ONE PAGER Components section (above) for what needs to be included in your ONE PAGER.

Make the document PRIVATE but give your teacher COMMENTING rights. You can't earn any points for your work if your teacher can't see your work.

The formatting of the ONE-PAGER document is entirely up to you. Arrange your page in a way that best communicates your information. Use use solid visual communication and design strategies. Most students find that it's easier to complete the sketches on notebook paper and then include images of those sketches in the digital document.

Finally, seek help if you have any questions or you are having any trouble completing this assignment.

ONE-PAGER Document Submission

When you are sure you have completed all the requirements for the ONE-PAGER, go to the ONE PAGER section of the Three Week Project Submission Forms page to submit your work.

Once your ONE-PAGER IS approved, you can start earning points on the rest of your project.

Your first big assessment will be on the quality of the PLANNING you do before you start your build.

To get your project started off on the right footing, you need a solid plan for the next three weeks.

If you plan well, the rest of your project usually runs smoothly. If you plan poorly, you will likely encounter a lot of frustration while trying to build and complete your project.

The Project Planning can be chunked into FOUR main steps:

1. Establish and set up your Programming Journal

2. Complete the Daily Entry section of Your Programming Journal (one entry completed for each day of the project).

3. Complete the Version Schedule in your Programming Journal (this should be completed prior to starting your first build).

4. Complete the "Prep" section of your Programming Journal (this should be done prior to starting your first build).

Note: be aware that you cannot make up any of your planning work after you begin your build. Once you've started your build, you have moved beyond the PLANNING phase (and beyond the ability to earn any more points for this portion of your project). Therefore, be sure you have completed all your planning steps before you begin working on any portion of your digital build.

Your programming journal is where you will document your project scope, your project planning and prep work, AND where you will keep a record of your daily reflections about your work/progress throughout the project cycle.

As soon as you get access to your PJ, your should complete your COVER PAGE.

Programming Journal - Document

Make a copy of the Classic 2D Arcade-Style Game EXTENSION: Programming Journal.

The directions for completing each section of the PJ are listed throughout the rest of this PROJECT PLANNING section on this website. Keep reading for all the details.

Head to the Programming Journal section of the TWP Submission Forms page on our class website to submit the URL for your PJ.

DO THIS RIGHT NOW! The link for the URL of your PJ should be submitted BEFORE you start completing any of the pages in your journal.

As soon as you submit the URL for the PJ, you should complete the COVER PAGE of your PJ.

The first day you get access to your programming journal, you will need to begin completing the daily entries. There should be an entry recorded for each day of the project.

The video below will explain how to fill out the DAY OF PROJECT and WORK DAY portions of your programming journal.

Overview of the Version Schedule

The VERSION SCHEDULE (VS) is the final step of your PREP work. The VS serves several purposes:

1. It helps you plan your project by identifying all the iterative steps you plan to build throughout the project

2. It helps you manage your time by either:

   • helping to keep you on schedule, or

   • knowing when you might need to adjust your plan because you are too far behind (or too far ahead) of schedule.

3. It keeps links to archives of your completed builds for quick access.

Layout of the Version Schedule

The TASK column will help you organize your build. This column should list a description of each iteration/build of your project. You should organize the tasks in the order that you plan to complete each of these builds. This part of the table should be completed first. Once you've laid out all your builds, and you have them organized in a logical, sequential order, you can begin to complete the rest of the table.

The SCHEDULE TO FINISH column will help you plan out and schedule your time. Look at each task. How long will it take you to complete that task? What day to you expect to complete that task? Remember, you only have three weeks. Many students start with a specific plan for their project. Then, once they plan out how much time it will take to complete each task, they realize that they may need to modify (add or remove tasks) in order to either finish the build in three weeks OR in order to continue iterating their project over the course of three weeks.

In the VERSION column you will list VERSION NUMBER that you assign for that task. Your numbering system should match the modified semantic versioning we use for our class projects (see the section below for more information). Be sure to identify your major updates vs. your minor updates vs. your "baby-steps."

The DATE COMPLETED column will only be filled out when you successfully complete a working version of that task/build AND you have linked to the REMIXED version of that project. Your task is not considered complete until it is bug free, archived, and linked to your VS. Only then should you fill out the Date Completed section of your VS.

As you are working, you may find that some tasks take longer than your had anticipated and you might complete other tasks sooner than anticipated. This is normal. It's hard to predict, in the very beginning of your project, exactly how everything will play out in the future. Even if you find that you are getting wildly behind schedule, don't adjust your VS. Just keep an accurate record of when you complete your work.

However, if you find that you are way ahead of schedule, you will need to modify your VS by adding more tasks to complete. Remember, your goal is to continue to iterate throughout the entire three weeks of the project. Do NOT, under any circumstances, stop working if you complete all your tasks. Your job is to keep iterating for all three weeks. At the end of three weeks, you will submit what you have.

Version Numbering

If you are starting a NEW project, your version numbering should start at 0.0.1 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.

Remember, your goal is to continue to iterate for the entire three weeks. Your grade is based more in the journey (constant iterative development) rather the end (whatever project you end up with).

Our class versioning system follows 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.823553.38 - it all depends on how you identify the tasks in your build. For our class we are usually trying to build our project up to VERSION 1. Version 1 is usually considered your first major release of your completely finished, working, and stable project. Therefore, unless you are extending an already working project, all your version numbers will likely be somewhere in the range from 0.0.0 to 1.0.0.

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. In our class, if we take a game as an example, we would consider version 1.0.0 to be a fully working game with a splash screen, end screen, a scoreboard to keep track of stats, and multiple levels of increasing difficulty.

The Y place holds the major improvement to your program as you iterate though the 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):

• 0.4.0

• 0.4.1

• 0.4.2

• 0.4.3

• 0.4.4

• 0.4.5

• 0.4.6

• 0.5.0

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 your 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 before you get started. Additionally, you should watch the two videos below to give you more background.

NOTE: There are several versions of the programming journal - each one tailored to a specific type of project. Therefore, what you complete for prep work will vary slightly from project to project.

The first several pages of your PROGRAMMING JOURNAL are dedicated to your planning documents. All programming journals (PJ) have a cover sheet as the first page. Somewhere, several pages in, you will find the Version Schedule (VS) Table. Everything from the COVER SHEET up through the VS is considered part of your PREP work for your project. Fill out each page/table as required for your project. Be as thorough and as detailed as possible. The more you pay attentional to all the detailS in the PREP section, the easier your BUILD will be.

Full directions for this step are usually included in the Daily Announcements.

Since the Version Schedule (VS) has a bit more detail to it, there are special instructions for that section below.

Building a programming project is a series of small, incremental steps. Because most programming languages are so exact, it is important that you constantly test your work to catch, and fix, all bugs as they happen.

Using your Version Schedule (VS) as your guide, you should attempt to tackle your first build (or whatever the next build is in your list).

Once you have completed your task (from your Version Schedule (VS)), you need to test and make sure that your build is bug free and stable/working. If you find bugs, you must fix them before you move on.

If your build/task is stable and bug free, you need to make an archive of that build so that you will have it for future reference. It should be a snapshot of that moment in your project.

Do NOT continue to iterate an archived build.

Once you have archived your build, create a link to that archived build in your Version Schedule so that you can have quick access to it when needed.

At this point, you should review your Version Schedule (VS). Are you on track? Do you need to modify anything regarding your project? If you do, make those changes to your VS. If not, select the next task in your VS and repeat the steps above.

Continue this process every day until the project is over.

Since Peer Evaluations are a whole-class project, and not all students are completing the same project for their THREE WEEK PROJECT, you will need to navigate to the Peer Evaluations section of the TWP Submission Forms Page to complete the Peer Evaluations for this project.

Final Reflection: Document

Make a copy of the TWP: Classic 2D Game EXTENSION: Final Reflection and Self Evaluation document and follow the embedded instructions.

Final Reflection: Submission

Navigate to the Final Reflection section of the TWP Submission Forms Page to submit your work.

[Hidden]