University of Wisconsin-Madison

Project : Due Monday 12/12 at Midnight

In-Class Demo Monday 12/12

The goal of this project is to create a card game that involves some element of chance (or luck or randomness).

Students may work on this project in teams of two. You may work on this project alone, but you still must implement the full project specification.

Picking a Suitable Card Game

We anticipate you will want to implement card games with relatively simple rules. To simplify a game, it is fine to implement an interesting subset of the rules; for exampel, you do not have to implement betting, if you so choose. You are likely to find Michigan Rummy and poker feasible to implement; the game of twenty-one will probably be pretty easy.

Children's card games like Go fish, Old maid, and War are also very appropriate. The game of Uno could be interesting to try. There are some other games you might not immediately think of. For example, you could implement the game Guess Who or Memory.

Different games definitely do have different amounts of difficulty in implementing them. Some of the points in this project will be awarded based on difficulty, but you do not need to be overly concerned about this.

If you have a question about whether or not your chosen game would be appropriate, just ask us. We would like to give you as much freedom as possible in choosing your games. As long as you ask ahead of time, we may be able to be more flexible with the specification. In fact, you could even create your own game...

The game may involve some amount of strategy in which the choices a player makes might make them more likely to win. However, strategy is not a requirement; you could implement a card game such as war in which winning or losing is pure luck.

The game should not have components that rely heavily on timing. The game shouldn't require quick reflexes or an action/adventure play style.

Specification

As always, be sure to read this entire page before proceeding. This project also has a number of strict requirements that you must fulfill!

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.

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. Cards: The game must have some number of cards, though it does not need to be a standard 52-card deck. 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.
2. 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 or the ordering of cards in the deck.
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. Enforce Rules and Announce Winner: The game must not allow a player to cheat or go against the rules. When the game is over, the game must announce the winner.

   If the user tries to do something wrong (e.g., bet more money than they have or not follow suit when they can), you have two options. First, the program could notify the user of their "mistake" and let them repeatedly try again until they make a valid move; second, the program could notify the user that they were caught cheating and terminate the game.

5. Modes: The game should be able to played in both multi-player and single-player mode; the user should be given this option when they start the game.

   In single-player mode, a single human player competes against the computer; the computer likely takes on the role of another player. For the computer's strategy, you do not need to implement anything very sophisticated; it is fine if the computer makes basically random choices.

   In multi-player mode, two or more human players compete against each other. The computer is there to either enforce rules, display the pieces, or tell each player it is their turn.

   Getting your game working in each mode is likely to be one of the most challenging parts of this project.

Implementation Hints

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.

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.

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!

The most straight-forward way to show the corresponding result is probably to have a different costume for each card. 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!

Your code for single-player and multi-player modes should be kept as similar as possible. You should not need to duplicate code across the two modes; you should be able to use a variable which designates which mode you are in to change the program behavior as needed.

In games with multiple Sprites all doing the same thing, 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. (See 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!

Grading your Code

Each individual in your team of two will receive the same grade for this project. It is expected that each student will put in roughly the same amount of work, though the types of contributions may be very different. Part of the challenge of this project is figuring out how to work productively with another individual. Collaborating is a skill that requires effort! When you turn in your Scratch code, you will also need to turn in a short document describing the role of each student.

Your joint 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?
• Documentation (10 points) Do you have good, descriptive names for sprites, costumes, variables, and broadcasts? Did you write project notes as asked in previous Scratch projects?
• Code Style (15 points) Do you use the correct programming structures? Do you use control structures, variables, and lists where appropriate? Do you avoid duplicating nearly-identical code throughout your scripts?
• Creativity (20 points) In the opinion of the graders, 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?
• Difficulty (10 points) In the opinion of the graders, is this a challenging game to implement?
• 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

The deadlines are meant to motivate you; they are not intended to force you to work at a rate that is unnatural to you. So, while the dates and times are firm, what you actually submit is very flexible. Here are the deadlines we've identified:

• Wed (11/30) 5pm: Find a project partner. Send email to cs202-tas@cs.wisc.edu to notify us of the two students in your project group. If you are working alone, let us know this as well. If you are looking for a partner, see the list of names in the Google Document sent over email (I don't want to post that link here).
• Fri (12/2) 5pm: Project proposal. Send a very brief description of your planned project to cs202-tas@cs.wisc.edu. It is fine to send just a single sentence; it is fine if your project completely changes from this proposal. We just want to encourage you to start thinking about what you are going to design and implement.
• Wed (12/7) 5pm: Project draft. Submit whatever Scratch code you have to the Learn@UW dropbox we will set up for you and your project partner. You will not be graded on this code. It does not matter how much progress you have made, as long as you do not submit an empty Scratch file (i.e., no scripts and just the Cat sprite). You should have something done by now, whether it is drawing backgrounds and costumes or implementing scripts.