Game Starter Project
GameLab
GameLab
This page is being redesigned for the 2023 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.
You will need to use the WHHS CS Game Starter Tutorials website to access the Game Starter Tutorials.
Follow the directions on this page if you are attempting to complete a Game Starter from the WHHS CS Game Starter Tutorials website for your Three Week Project.
The currently available Game Starters are listed below:
Dodger Game Starter (sample, tutorial) - since most people do this as a class project in the Fall Semester, this option is only available to students who entered the class late. This game makes use of object constructors
Breakout (sample, tutorial) - this game starter is in its initial stages. You may attempt this one if you would like but the current directions are not as detailed as the Dodger Game. This game makes heavy use of parameters, object constructors, and lists/groups.
Snake (sample, tutorial) - this game starter is in its initial stages. You may attempt this one if you would like but the current directions are not as detailed as the Dodger Game. This game makes heavy use of parameters, object constructors, and lists/groups.
Space Invaders (sample, tutorial) - this game starter is in its initial stages. You may attempt this one if you would like but the current directions are not as detailed as the Dodger Game. This game makes heavy use of parameters, object constructors, and lists/groups.
There are no other available Game Starter projects at this time.
The tutorials at the Game Starter website walk you through how to start building a particular type of game. It is up to you to finish the game by adding your own enhancements to the final version.
The instructions on this page show you what you need to do to incorporate the Game Starter Tutorial into a THREE WEEK PROJECT cycle.
Remember that each THREE-WEEK PROJECT is usually completed in three weeks (or 15 normal school days). However, due to external factors, 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:
How well a student properly PREPARES and PLANS OUT the entire project before attempting the first build.
How well the student honestly REFLECTS, ASSESSES, and makes appropriate ADJUSTMENTS (as necessary) to the project build.
The quality of final ARTIFACT in terms of both the UX (User Experience) of the finished product (does the game actually work) AND how well the student follows good programming conventions when writing the code (whitespace, indentation, comments, naming conventions, user-created functions, organization/structure, etc.).
Since much of the PREP work is already laid out for you with a Game Starter, there is no reason for your PREP work to be less than exemplary. Make sure you complete all your requirements.
Additionally, since much of the CODING work is already laid out for you with a Game Starter, there is no reason for your CODE work to be less than exemplary. Make sure you follow the directions and display exemplary work in your naming conventions, whitespace, indentations, and commenting.
{Hidden]
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 build should be a very interactive and flexible process.
The Project Proposal can be chunked into TWO main steps:
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?
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 days. Make sure you understand the difference and keep that in mind as you craft your ONE-PAGER.
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 every day 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 gain access to your PROGRAMMING JOURNAL.
A typical ONE-PAGER for a classic 2D arcade-style game should contain all the important facts about the project you intend to build. Typically, it should contain the following:
State the overall objective of game (how do you win? // how do you level up?)
An explanation of how the game functions:
How do you play?
What is the role of the user?
Do you control a character/avatar?
Do you use the mouse/keyboard?
How do you level up?
Sketches of various modes of game play (splash screen, game play, levels, boss, game over, etc.). All games are different so what you sketch will depend on YOUR game. Your sketch(es) should make it clear to a stranger what you expect your final game will look like AND what the experience will be like. On each sketch, you should:
identify all the sprites/variables you plan to use
identify the naming convention(s) you plan to use for sprites/variables/functions
detail the expected behavior(s) of your sprites (do they animate, move, fade-in, etc.). Be as detailed as possible.
identify whether or not there will be a scoreboard (or some kind of user feedback) on the screen? What information does it show?
Make a copy of the 2D Arcade-Style Game Starter: ONE-PAGER and follow the embedded DIRECTIONS in the document.
Keep the document PRIVATE but give your teacher COMMENTING rights. You can't earn any points for your work if I 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.
Finally, seek help if you have any questions or you are having any trouble completing this assignment.
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 digital document for approval.
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:
Establish and set up your Programming Journal (PJ)
Complete the Daily Entry section of Your Programming Journal (one entry completed for each day of the project).
Complete the Version Schedule (VS) in your Programming Journal (this should be completed prior to starting your first build).
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 PREP 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.
Make a copy of the 2D Arcade-Style Game STARTER: 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.
In order to make your document available for periodic checkups (as well as your final submission), you are going to SUBMIT your document NOW. Don't worry, you can keep on making edits to your document after you submit.
Before submitting, be sure to keep 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.
Go to the Programming Journal section of the Three Week Project: Submission Forms page to digitally submit your work.
Now that you have submitted the URL for your PJ, it's time to begin your DJE (Daily Journal Entries) and completing your PREP work (all the pages before the DJE begin: everything from the COVER SHEET to the FUNCTION TABLE).
Follow the instructions on the Daily Class Announcements and the TWP Project Schedule page as necessary.
{Hidden]
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.
Make a copy of the TWP: New Classic 2D Game: Final Reflection and Self Evaluation document and follow the embedded instructions.
Be sure to check the Daily Class Announcements for specific DUE DATES and DEADLINES for this assignment.
Follow the directions in the Final Reflection section of the CSD: Class Projects: Submission Forms page to submit your work.
[Hidden]