New Quiz Game
AppLab
AppLab
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 NEW Quiz Game in Code.org's AppLab.
Remember, that the directions on this page are general directions. They should work for any kind of QUIZ GAME that can be built in AppLab. 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 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. This will be assessed in the following ways:
The UX (User Experience) of the finished product (does the program actually work, etc.)
How well the student follows good programming conventions when writing the code (whitespace, indentation, comments, naming conventions, user-created functions, organization/structure, etc.).
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.
This is 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 quiz game should contain all the important facts about the project you intend to build. Typically, it should contain the following:
State the type of quiz you are making (is this a trivia quiz, is this a knowledge quiz, is this a personality quiz, etc.).
State the overall objective of quiz (am I learning something, am I figuring something out, am I competing against others for a high score, etc.)
An explanation of how the game functions:
How do you start?
How will the questions be presented? One question per screen? Multiple questions?
Do I get immediate feedback after each question or only find out my results at the end?
Do I have to get a perfect score to finish the quiz?
Can I play again or do I only get one chance to play.
Sketches of various modes of game play (splash screen, question screen, scoreboard/results screen(s), end screen, try again screen, 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 UI elements that will appear on the screen
Any variables you plan to use (to keep track of things like the score)
identify the naming convention(s) you plan to use for the UI elements
identify whether or not there will be a running scoreboard (or some kind of user feedback) on the screen or just a final results page at the end of the quiz? What exact information will your scoreboard/results screen show?
Make a copy of the New Quiz Game: 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
Complete the Daily Entry section of Your Programming Journal (one entry completed for each day of the project).
Complete the Version Schedule 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 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.
Make a copy of the New Quiz Game: 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.
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.
The VERSION SCHEDULE (VS) is the final step of your PREP work. The VS serves several purposes:
It helps you plan your project by identifying all the iterative steps you plan to build throughout the project
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.
It keeps links to archives of your completed builds for quick access.
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.
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.
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 the versioning schedule in your PROGRAMMING JOURNAL? Watch this video where I evaluate and critique some previously submitted programming journals.
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.
NOTE: This section is not completed for all projects. Generally, this is only completed for non-game web apps.
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.
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: AppLab: New Quiz Game: Final Reflection and Self Evaluation document and follow the embedded instructions.
Navigate to the Final Reflection section of the TWP Submission Forms Page to submit your work.
[Hidden]