Introduction to Computer Applications 2010

FizzBuzz

In this project you will create a game. In programming circles, this game is called FizzBuzz, but in other contexts it is known as Bizz Buzz. There's not a lot of action or plot, but it does illustrate several more widely applicable programming practices and it serves as a good introduction to Scratch. A computer and human player take turns counting. When either one's count is a multiple of three, that player says "Fizz." If the count is a multiple of five, the player says "Buzz." If it is a multiple of both, say both, so "FizzBuzz". For all other counts, just say the number. The player who holds out the longest without making a mistake wins. Since you will have programmed the computer's side, you can take credit for its flawless performance when it beats any other human player. This particular implementation is written in an object-oriented style as it might be done in Java. It makes frequent use of messages and information exchange via variables.

Instructions

A graphical programming language begs for graphical instructions, so the many screen shots below show you what you are after and the text hints at how to get there. Click on the pictures for larger versions if that's handy, but better yet, download a zipped collection of the full scale graphics in case the internet goes down unexpectedly. Since all the code is provided, however, you'll have to prove that you understand what is going on by answering questions. It would be a good strategy to read the questions first and keep them in mind while building the code.

Preparation

Go ahead and play the online version of this game so that you understand the rules and have a good feel for the user interface. Also read the aforementioned questions.

1. After you start Scratch, but before you write or draw any code, save your Scratch project as FizzBuzz.

Sprites

The graphics you choose for the sprites pictured below is not critical. Be creative. However, do give your sprites the recommended names (see the list below) so that these instructions continue to make sense and other people, like your classmates, can use the same vocabulary when trying to help. The picture below shows the suggested placement of the sprites.

1. Name your sprites computer, human, mathematician, fizzButton, buzzButton, fizzBuzzButton, and numberButton. You rename them in the middle pane next to their picture. You get the Stage for free.
2. Add some sort of instructions to the stage. Double click the sprite, choose the Costumes tab in the middle pane, press the Edit button, and with the Text Tool write some instructions. If you want text on your buttons, you will have to edit them in a similar way.

Variables

The "state" of the game is to a large extent stored in variables. They are also used to communicate information between different sprites. They work much the same way as variables in algebra except that they always have a single, known value at any point in time. That value will change throughout the life of a program.

1. First double click on the human sprite because one variable, buttonPressed, is "local" to it. When you add this variable, make sure you choose "For this sprite only".
2. The other variables, answer, count, delay, and guess are all "global" variables. Choose "For all sprites" when adding these variables.

Buttons

The buttons, four of them in total, are not especially smart in this program. They know how to enable and disable themselves (as do buttons of almost all operating systems and widget sets). When clicked, they simply broadcast that fact to anyone interested in listening.

1. Add the pictured code to the fizzButton. You will need to define new... messages.
2. After you have drawn the code for fizzButton, grab each of the code snippets and drag them to each of the buttons showing in the sprite pane. Each of them needs very similar code. If you afterwards double click them, you should see that they have received copies of the code.
3. The buzzButton, fizzBuzzButton, and numberButton should broadcast buzzPressed, fizzBuzzPressed, and numberPressed messages, respectively, when pressed. You will have to change these for each button so that they don't all act like the original fizzButton.

Mathematician

The mathematician, rather than the computer player, provides the brains of the program, although behind the scenes. The first thing that it does is hide, but even hidden, it decides whether it is time to fizz or buzz.

1. Once you have the code for the reset message complete, double click on it and have the mathematician hide once and for all.

Computer

Although the computer player isn't especially smart, it does know enough to consult the mathematician for the correct answer. As you can tell, it also takes great pride in having won the game. At this point you should be able to double click on any of the code snippets and manually force various responses from the computer. You can even make it lose.

Human

The human player has more code that any other sprite and that is typical of objects that deal with real human interaction by providing a user interface. This sprite has to deal with all the buttons that the real human might press and, for example, try to keep the human from playing out of turn. Humans are notorious for not following directions and this sprite assumes some responsibility for enforcing the rules.

1. The code for the reaction to each of the buttons being pressed is very similar. Draw the code once for fizzPressed and then right click on the snippet and choose duplicate. Place the copy at a convenient location and then edit the messages and values.

Stage

The stage directs all the sprites that act on it. It implements the main "entry point" to the program by responding to the flag being clicked. It is where some global variables are initialized to control aspects of game play. The general scaffolding of the game is programmed here so that the different sprites can mind their own business fairly independently of other ones.

1. Just add the pictured code to the Stage. Read it carefully, because the Stage is related to several of the questions below.

Questions

While you create the program, keep an eye out for clues to the answers to the following questions. Include the answers, preferably in an attached Word document, when you submit the project. You may wish to try out some of the suggested code modifications. If you do so, make modifications in a separate copy of the project or make the project configurable so that it supports both the original functionality and the modifications. Write in complete sentences and provide detailed answers.

1. How is clicking a button during the computer's turn prevented? Does double clicking a button mess up game play?
2. The Stage includes code that loops forever. How can the game end then? What code ends the game and under what conditions is it the code executed?
3. If you wanted to play Bizz Buzz instead of Fizz Buzz, what code and graphics would need to be changed? What changes are necessary so that the user observes only Bizz Buzz in the running program? What changes are necessary to remove all traces of Fizz from the programmer who can open the project in Scratch and look at the code?
4. How could the human player be allowed to go first?
5. Where are the three and five, the numbers corresponding to Fizz and Buzz, recorded? What would need to be done to change to three and seven?
6. What code could you change the make the computer lose for once? Suggest how you might change it so that some of the answers it produces are correct and some incorrect.
7. Rather than playing forever, how about playing up to 51? If the human holds out that long without making a mistake, the computer forfeits because its battery runs out. Briefly describe the changes you anticipate to be necessary.
8. How can you make the computer play against itself? How can one human play the game solo, without the computer opponent?
9. In an even more difficult game, the count would not increment by just one every time, but by some other number. It would be very convenient to be able to configure that number in the program. How can you do that?
10. Describe a change to the game that you think would make it more interesting. What capability would you like to see in version two?

Delivery

Submit both FizzBuzz.sb (the Scratch project) and the answers to questions (possibly FizzBuzzQuestions.docx) in a single email. The Scratch project should be attached. Answers can be recorded in the email message, but it would be much safer to record them in a file of some kind first and then attach them along with the first file. You may also transfer two files via USB drive.

Grading

The two major parts of the project, the programming of the various components and the answering of the questions, will be handled separately.

Components

There are seven separate components (sprites, variables, buttons, mathematician, computer, human, and stage) plus preparation and delivery. Each component will be evaluated on a zero to four scale. For preparation and delivery there is a point each for correct file name and specified delivery with both files arriving together. This amounts to 30 points total. The scale

- 4 - The component has been completed as (or as if) specified. It is both functionally complete and technically correct. It may include personalization, alternative design elements, or special features.
- 3 - The component has only cosmetic defects which don't substantially affect functionality. It may not be obvious what is wrong, but careful reading of instructions, proofreading of code, and testing of functionality could turn it up.
- 2 - The component does not work in all cases, including some obvious ones. It should have been possible to notice problems with a minimal investigation of functionality.
- 1 - The component works in only exceptional cases. There is something obviously wrong with the program and it doesn't work more than it does work. It is too incomplete or filled with errors to use as intended.
- 0 - Little to no work is apparent. The program doesn't work and is a long ways from doing so despite the student having had ample opportunity to complete the assignment.
- Sprites: 4
- Variables: 4
- Buttons: 4
- Mathematician: 4
- Computer: 4
- Human: 4
- Stage: 4
- Preparation & delivery: 2

Questions

Three points are offered for each question. They will be judged on correctness, completeness, and adherence to convention (e.g., mechanics, grammar, instructions). The scale follows. Since there are ten questions, this part is also worth 30 points.

- 3 - Exemplary. Thoughtful and insightful.
- 2 - Sufficient. Reasonable, clear, and correct.
- 1 - Insufficient. Unreasonable, unclear, or incorrect.
- 0 - Absent. Unaddressed, incomplete, or not done.

Page updated

Google Sites

Report abuse