University of Wisconsin-Madison

Mon 12/13 (before class): Complete project due

The goal of this project is to create a Trivia Game, similar in format to Jeopardy or Who Wants to Be a Millionaire. We strongly suggest that your game pose questions related to a single topic that you care about; this may give you more ideas for creating a consistent theme with matching visual and audio elements. For example, your game might ask questions all related to Sports, or History, or Music, or Foreign Languages, or any field you have an interest in.

This project has a number of strict requirements that you must fulfill; you will then be able to select other bonus features you find interesting to implement (e.g., a timer, two-player mode, and lifelines). You will need to implement some combination of these bonus features for full credit. Be sure to read this entire page before proceeding.

Required Functionality (40 Points)

1. You must have a background and a main questioning Sprite that match the theme of your questions.

2. When the game starts, the user is given some amount of initial money (or chips or cheetos or whatever makes sense to you); the initial amount is also up to you. The player is then asked a question.

3. Before or after seeing the question (NEW: your choice!), the user determines how much money they would like to bet. The user may not bet more money than they have! If they get the answer wrong, this amount is subtracted from their total; if they get the answer right, this amount is added to their total. After the user gives their answer, they are told whether they were right or wrong. The player is then asked the next question until they run out of money (or decide to stop, or are asked the maximum number of questions).

4. Your game must ask questions in a different order each time it is run. In other words, you may not hard-code your program to first ask one particular question (e.g., "What is the capitol of Wisconsin?") followed by a second particular question (e.g., "What is the capitol of Michigan?"). Instead, your game must randomly select one of its possible questions to ask first and then second and so forth.

5. Your game must have at least 20 different questions.

6. You must ensure that the same question is never asked twice in the same game.

7. In the most basic version of the Trivia Game, the user can specify their answers by simply typing them in; your program will then check to see if the user's answer matches the known correct answer for that question (hints on how to do this are below).

8. Every time the player makes a guess, they should receive some type of feedback for whether they got the answer right or wrong. For example, the game could play different sounds, say different comments, or change the appearance of a sprite. In addition to that feedback, the game should also update their total amount of money and continuously display this amount to the player.

9. When the game is over, the user should be notified in some way and told why the game has ended.

10. Please avoid any offensive material.

Implementation Requirements and Hints

As you implement your project, you may have the following questions. If you do, we have some implementation hints for you!

1. How can the program ask a random question?

   Your program will select a random number between 1 and 20 (or the number of questions in your list) and then ask the question stored at that index in the list.

2. How can I check if the user gives the correct answer or not?

   Once you've place all of the questions in a List, you'll find it is natural as well to place the answers in a corresponding Answer List. If the user is asked the question at List index i, you'll check to see if they give the answer given at List index i in the Answer List.

3. How can I make sure the program doesn't ask the same question twice?

   There are two ways to do this. One way destroys the Question list as it runs; if you do this, be sure you keep the Answer list synchronized with it! The second way creates a new list that tracks all of the questions that have been asked so far...

4. How can I somewhat easily initialize the list to contain 20 different questions?

   To initialize your list with all of the questions, you have two good options. The first option is to display the list on the Stage and type in each question directly into each element. The second option is to right-click on the graybox surrounding the list on the Stage; this will give you a dialogue box in which you can specify a plaintext file to import that contains your questions. You should use a text editor or word processor to create that file with your questions; just be sure to Save As... your question file as plain ASCII text (i.e., the file extension should be .txt and not .doc or something specific to a particular word processor).

Bonus Features (20 points needed for full credit)

1. Timer (5 points) With this functionality, the user has only a fixed amount of time to answer the questions. You can give the user either a small amount of time to answer each individual question or a larger amount of time to answer all of the questions. If the user runs out of time, you could either count the question as wrong or end the game.

2. Two-player (6 points) Allow two people to compete! When the game begins, it should ask for the number of players. Each player's money will then be recorded separately (hmmm...I wonder what type of data structure is appropriate for this?) Each player is then assigned a different key which they use as a "buzzer". After a question has been asked, whichever player hits their buzzer first is given the opportunity to bet and answer. If that player is wrong, you can either give the other player a chance or just move on to the next question.

3. Visual Interest (4 points) Instead of making each question (or answer) plain text, show different images. For example, ask the player to identify different people, characters, or shapes. To do this, you can use the instruction block switch to costume (x). Notice that every costume has a corresponding integer value between 1 and the total number of costumes for this Sprite; you can store the desired costume number in a variable and then drag this variable into the switch to costume (x) block in place of (x).

4. Audio Interest (4 points) Instead of making each question or (or answer) visual, make it audio. For example, ask the player to identify different songs, tv or movie themes, or jingles. To do this, you can use the instruction block play sound (x) until done. Notice that every sound has a corresponding integer value between 1 and the total number of sounds for this Sprite; you can store the desired sound number in a variable and then drag this variable into the play sound (x) until done block in place of (x).

5. Prize Selection (10 points)After the user has played the game, allow the winner to purchase different prizes that cost different amounts of money. (Wheel of Fortune back in the 1980s used to work this way; it was incredibly boring to watch!) For example, you could show images of a car for $200, a diswasher for $10, and a set of playing cards for $1. The user can click on each image to purchase it and have that dollar amount subtracted. The game shouldn't let the player to continue purchasing prizes if they've run out of money! The player should have to keep purchasing prizes until they don't have sufficient money to buy any of the remaining prizes. The game should use a list to track the player's prizes and report all the prizes they purchased at the end.

6. High Score List (3 points): When the game is over, a list of the 10 High Scores is displayed (from highest to lowest). Don't let the size of the list extend beyond 10 scores! You should tell the user if they achieved a new high score and make sure their new score is inserted into the correct location so it remains sorted from highest to lowest. These high scores should be kept in a list. Note that you will not want to initialize the list when the game starts; if the user saves the Scratch file when done playing, the new contents of the list (and their high scores) will remain.

7. Multiple Choice (3 points): Instead of requiring that the user knows the answer off the top of their head, give them 3 or 4 choices to pick from. In the most straight-forward implementation, this isn't much harder to code than requiring the user to type in the right answer. For example, you could have the game host just "say" the 3 or 4 choices.

   One way of implementing this is as follows. In addition to the Question and Answer lists, you will also have 3 or 4 new Choice Lists. Choice List A holds the all the option As, Choice List B holds all the option Bs, and so forth; the order of the elements in these choice lists again matches the order of the question list. You'll probably modify the Answer List to indicate A, B, C, or D instead of the actual words of the answer.

   If you set up your game to have multiple choices, it will open up the following numerous new features you can implement...

   1. 50/50 Lifeline (5 points): If the user is stuck, they can use this lifeline. This lifeline will remove two of the wrong answers. The two wrong answers that are removed should be selected at random! The user should only be able to use this lifeline once.
   2. Phone a Friend (5 points): If the user is stuck, they can use this lifeline. This lifeline will tell them the correct answer with an 70% probability. That is, the program should generate a random number between 0 and 100; if that random number is less than 70, the user will be told the correct answer. If the random number is greater than 70, they should be told one of the wrong answers! Again, the wrong answer should be selected at random. The user should only be able to use this lifeline once.
   3. Click don't Type (10 points): Instead of having the user type using the keyboard, have them click with the mouse on both answers and lifelines. This feature works particularly well when the answers are visual (e.g., different costumes showing different people or places); if you don't have particularly visual answers, you can still have the user click on a Sprite for "A", "B", "C", or "D".

      To figure out if the user clicked on the correct answer, you are likely going to want to use logic very similar to that in the project Identify, in which kids were asked to count between 1 and 5 objects and click on the corresponding number.

Documenting your Code (20 points)

Part of your grade will be based on how well you document your code.

Code must be documented so that others can understand how it works. You will find documenting your own code useful: it is very easy to forget how code operates, even when you are the one who originally designed it! Because documentation is so important, your project grade will be partially based on the quality of your documentation.

Documenting the behavior of your code has three components:

1. Use good naming. All of your Sprites (and their Costumes) should have descriptive names. The name of a Sprite can be changed in the text box above the Tabs for Scripts, Costumes, and Sounds.

   All of your variables should have descriptive names. Variables which are accessed across multiple different scripts or Sprites should be named with the convention "First Letters Capitalized". Local variables which are not used outside of one script should be in all "lowercase".

   All of you messages (for broadcasts and receives) should have descriptive names as well. For a message X, to help show which Sprite sends it and which receives it, it can be useful to name the message "Sender : X : Receiver" (where Sender and Receiver are the names of those Sprites, respectively). As a short-cut, if a message is both sent and received within a single Sprite, you can omit "Sender" and "Receiver". If a message is sent by multiple Sprites (or received by multiple Sprites), you don't have to list all Sprites; instead you can just say "Many". For example, if Sprite1 sends the message "Game Over" to multiple Sprites, you should name that message "Sprite1: Game Over: Many".

2. Write Comments. Each Script that changes the value of Variables that are accessed in other scripts should describe its usage. The Comment should be connected to the Script. The Comment should describe every Input Variable and the assumptions that are made about those variables. The Comment should describe every Output Variable and how they will be set and what different values mean. (You don't need to make a comment for Scripts that don't access global variables, unless you want to!.)
3. Project Notes. Every Scratch project has Project Notes associated with it. These notes should describe how one can use this project (i.e., the basic rules for playing the game and how to interact with the program). The note should also describe any known bugs or problems. Project Notes can be written from the "File" pull-down menu.

Developing your Code

As always, programming assignments and projects in this class should be done on your own. You may ask other students in the class questions, but you may not share code with anyone in the class. You may not use existing code that you find elsewhere, including the Scratch website. You may look at the behavior of existing Scratch projects for inspiration, but you should develop all of your code as a completely new project and not modify, re-mix, or build from any one else's code.

The Instructor and the TA are very happy to give you suggestions on how to implement your ideas. We won't necessarily give the answer, but we will try to guide you to a reasonable implementation. If you have bugs in your code (i.e., it isn't behaving like you expect), we are happy to take a look and see if we can see the problem. But, again, don't wait until the last minute to do your project if you are hoping for any advice! We recommend writing small amounts of code and immediately testing that code to see that it works correctly before writing more code. Get each step working correctly before you move on to the next step! Always SAVE working versions of your project before adding significantly new functionality!

We expect that you will put many hours of thought and work into this project. Do not wait until the last minute to start implementing your project! Code written in a rush rarely works the way you hope it might! If you start your project promptly, it will be much easier to get help and advice from the Instructor and TA.

As always, you should strive to write code that is easy for others to understand and easy for you to modify. This usually corresponds to writing code in a compact manner and code that is identical across all Sprites that are doing the same actions (with perhaps only local variables and initialization code differing across similar Sprites).

Grading your Code

Your project grade will be based on the following components:

• Required Functionality (40 points) How closely did you follow the specification for the project? Does your game ask 20 randomly-ordered questions? Does it allow the user to specify how much money they are betting? Does it respond to correct versus incorrect answers as it should? Does the game stop when the user is broke or has answered 20 questions?
• Bonus Features (20 points) How many of the bonus features did you implement? You can obtain a maximum of 100 points for the total project, regardless of how many bells-and-whistles you add to your basic game.
• Documentation (20 points) Do you have good, descriptive names for sprites, costumes, variables, and broadcasts? Did you write comments where appropriate and use the project notes?
• Code Style (20 points) Do you use the correct programming structures? Do you variables, lists, scripts, if statements, and loops in a reasonable way?
• Demo (0 points) These points have been removed and given to homework 10. Did you upload your project to the Scratch website and comment on other students' projects? Were you able to explain how your code works to the TA in your demo? Did you show your project to the class?

Turning in your Project Code

Turn in your project through Learn@UW and sign up for a one-on-one demo with a TA. You should upload your project Scratch file (ending with the extension .sb) to your Learn@UW Project1 folder. If you have any problems uploading your code, send us email right away! Confirm that your project file actually shows up in your folder! We will use this version to grade your project. This step must be completed by Monday 12/13, before class.

We will have more details here about the sign-up sheet for a one-on-one demo with the TAs.

NO LATE PROJECTS ACCEPTED

While you are reading... We had many great games for Project 1. Please help publicize them on the Scratch website by viewing them all and clicking "Love it".