Programming Project 3 : Due Wednesday May 5(before class)

NO LATE PROJECTS ACCEPTED

The goal of this project is to create a one-person game of chance. The game must have some element of chance, or luck, or randomness to it. For example, many games using cards, or dice, or a roulette wheel, or even dominoes can have chance associated with it. For example, the player does not know and cannot control which cards they will be dealt or in what order the deck will be stacked.

The game may also have some amount of strategy in which the choices a player makes might make them more likely to win. For example, tic-tac-toe or any game in which the player may make choices, is a game of strategy. However, strategy is not a requirement; you could implement a card game such as war in which winning or losing is pure luck. The computer may have some strategy as well in how well it play.

If your game is extremely simple and involves no strategy (e.g., roulette), then your game should have a simulation mode. When the game is configured in simulation mode, the game should not require any input from the user (i.e., there are actually zero players). In simulation mode, the game plays multiple trials against itself and simply records the outcome (i.e., who won or lost).

The game should not have components that rely heavily on timing. The game shouldn't require quick reflexes or involve much action.

The game should be set up so that a single human player competes against the computer; the computer can either take on the role of another player or they can be simply the dealer or rule enforcer.

We highly recommend that you review the material presented in previous lectures. In particular, Lecture 33 ... win games against you? explored how to create strategy games. You will also want to look at Lecture 12 ... guess what will usually happen? to see how to perform multiple simulation or probability trials. The code for simulating the Monty Hall game show, flipping coins, calculating PI playing tennis matches is all similar in structure.

As always, be sure to read this entire page before proceeding. Even if you think you are not interested in a particular game, we still recommend that you look at all of the implementation hints because many of the techniques may still be useful. This project also has a number of strict requirements that you must fulfill!

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.

Within our specification, you are welcome to create any game of chance you like. You are encouraged to use inspiration from any games you like to play. Please avoid any offensive material. We recommend looking at the following for both inspiration and implementation hints:

1. Card Games.

   A variety of card-based games would be very appropriate. For inspiration, you can look at the list available through Wikipedia. We anticipate you will want to implement games with very simple rules. You are likely to find twenty-one and poker feasible to implement. You do not have to implement any betting options. It is fine to implement an interesting subset of the rules. Children's card games like Go fish, Old maid, and War are also very appropriate.

   For showing pictures of the cards, you can either draw your own costumes or use any of the images that are freely available on the web.

   When dealing cards, you will likely want to represent each player's hand with a list of cards; you may also want to represent the deck as a list. We strongly recommend designs that do not involve creating a separate Sprite for every card in the 52 card deck!

2. Dice Games

   A great source of chance or randomness is to use a die or set of dice. Any game with dice is (probably!) appropriate.

   One simple category of dice games to consider are race games in which players roll dice and then move a piece around a board (e.g., Chutes and Ladders) to reach a finish line. You can use an existing board game or create your own. For greater interest, we suggest having a board with different rules for each square (e.g., moving backwards or forwards additional squares or missing a turn).

3. Others.

   You are welcome to use any sort of randomness in your game. Examples include roulette wheels and dominoes.

Specification

There are a few requirements that your game must fulfill. Many other aspects as optional (like whether or not you have music playing in the background or other sound effects).

1. Chance: The game must have some element of chance. The element of chance, or luck, or randomness can occur in many different manners such as the particular cards the player is dealt, the ordering of cards in the deck, the roll of a die, the final value of a spinner or roulette wheel.
2. First or Second: One must be able to select if the human player or the computer goes first.
3. Instructions: The game must have instructions for the user. The instructions can be simple and always showing on the Stage or more complex and require the user click on a box or type a letter to see the instructions.
4. Play Again with Statistics: When the game is over, the player must be given the option of playing again. The game must track and display statistics showing how many times the player has won or lost in this sitting.
5. Strategy or Simulation: You have two choices to meet this requirement.

   Your first option is to implement a game that involves some strategy. With strategy, the player has a choice for moves that involves some amount of skill or decision making; a good strategy should enable the player to win more often than pure luck would predict. For example, in the game of Poker, the player can choose which cards they would like to hold and which they would like to discard. Depending upon the choice of the user, your game should then respond differently. You will probably not want to implement strategy using a game tree and the minimax algorithm: that will be much too complex. Instead, it is fine for the computer player to use a random strategy or a strategy that is easy to specify.

   Your second option is to implement a game with no strategy (or a fixed strategy), but to instead simulate the likelihood of winning. For example, one game with no strategy is a race game in which players roll a die and move the number of designated squares. A game with a fixed strategy is 21 if the player always draws another card when their current total is 16 or less. In both cases, the game can operate with no input or decisions made by the human player. In both cases, your game should have a mode that simulates the outcome. In simulation mode, the user should be asked to enter the number of trials to be simulated and the user should be informed of the outcomes at at the end; in simulation mode, no visual effects are needed.

Implementation Hints

Somewhere in your code, you will likely be calling the "random" block to generate different random numbers. You will then be mapping these different random numbers to different cards or rolls of the die.

The most straight-forward way to show the corresponding result is probably to have a different costume for each card or roll of the die. You can then use the instruction block switch to costume (x) to change to the desired costume. Notice that every costume has a corresponding integer value between 1 and the total number of costumes for this Sprite and that you can drag a variable into the block in place of (x). This should do what you need!

In games with multiple pieces (e.g., cards), you will want the code to be nearly identical across the Sprites. You will very likely want each Sprite to have their own private variable initialized to a unique identifier; for example, in a game with three cards showing, you might have three Sprites with the private variable my_id initialized to 0, 1, and 2, respectively. (Remember the Number Identify game for an example.)

In some of the card games, the human player may be selecting some cards to remove; you can program this in at least two ways. First, the player could click on each card they want to pick up; then, they must click on a different object (or press a key) to indicate they are done picking up pieces. Second, the player could indicate how many cards they want to discard (e.g., by typing 1, 2, or 3 or clicking on Sprites representing those numbers). You can experiment with either way.

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).

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! And, always SAVE working versions of your project before adding significantly new functionality!

Documenting your Code

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!

Grading your Code

Your project grade will be based on the following components:

• Specification (25 points) How closely did you follow the specification for the project? Did you implement all of the features we asked you to?
• Creativity/Effort (20 points) Does it look like you put effort into the project? Do the backgrounds, characters, and objects have a logical and/or interesting theme? Is the game fun to play or show interesting/educational statistics?
• 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 (15 points) Do you use the correct programming structures?
• Demo (20 points) 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

There are two steps to turning in your Project 3 code.

First, you should upload your project Scratch file (ending with the extension .sb) to your Learn@UW Project3 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.

Second, please upload your project to the Scratch website and add it to our Gallery named Project 3 - 202Sp10. You can do this by clicking on the "Share" button at the top of the Scratch environment and then selecting "Share this Project Online". In a pop-up menu, you will type in your username and password and then click OK. This version is so that others can see what you have created! You should then go to the Gallery Project 3 - 202Sp10 on the Scratch web site. Once you are at the Gallery, you will see a button labeled "add my project" which will allow you to add you project. Do this and feel free to browse through other students' projects!