University of Wisconsin-Madison

Homework Assignment #8 : Due Friday 11/11 before 5pm

The goal of this homework 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 homework has a number of strict requirements that you must fulfill. Be sure to read this entire page before proceeding.

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. After seeing the question, 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 10 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. 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.

11. Please avoid any offensive material.

Extra Credit: Up to 3 points

If you would like your homework to be considered for extra credit, you must implement at least one of the following OPTIONAL features. In your project notes, you should state which optional features you've included. You will obtain a total of 1 extra credit point for implementing any combination of optional features and submitting your project to the Extra Credit Gallery (to be posted later).

You may obtain a 2nd extra credit point if your project wins the voting rounds.

Everyone who votes in all of the rounds can obtain one extra credit point.

These are the optional features:

1. Timer 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 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 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 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. Click don't Type : Instead of having the user type using the keyboard, have them click with the mouse. 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.

Implementation Requirements and Hints

As you implement your homework, 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 10 (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 10 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).

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 homework. Do not wait until the last minute to start! 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.