University of Wisconsin-Madison

Fri 10/22 (5 pm): Draft submitted to Scratch website for Student Comments

Wed 10/27 (before class): Complete project due

Wed 10/27 (in class): Demo

The goal of this project is to create a points-based game using both integer and boolean variables. The game can be either educational or action oriented. Your game is expected to be interactive; that is, the actions of the user (e.g., clicking the mouse or typing characters) will change how the game behaves. How the user interacts with the game is completely up to you!

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.

Within our specification, you are welcome to create any game you like. You are encouraged to use inspiration from projects on the Scratch website or other games you like to play. Please avoid any offensive material.

We anticipate that you will want to carefully review the material we covered about Variables in the Lecture from 9/24. You'll probably find it useful to study the code for the fish game, adventure framework, and the two-player game.

We also recommend looking at the following for both inspiration and implementation hints. Note that not all of these examples use Boolean Variables; you will need to make sure that your project does!

1. 

   Maze-Based Adventure Games

   You may want the user to navigate through a maze, gathering objects for points. The code to ensure that a Sprite cannot move through walls can be a little tricky; we recommend outlining the object with a unique color on each edge of its costume and ensuring that the corresponding color is not touching a wall in the corresponding direction. See the sample for details.

   You may want the user to be able to shoot bad objects. The code to shoot is not too difficult. For example, the user could click the mouse to pick a target; you'll want to make a Sprite associated with the bullets, point the bullet in the direction of the mouse click and keep moving in that direction for some number of steps. For an example of how to move through a maze and even shoot, look at the code for Level 2 of this Maze Adventure-Style game.

2. 

   Math Drills.

   You may want to create a game in which the user answers different math facts. Rather than simply type in the answer, the user might have to select different moving answers (e.g., by clicking objects with the mouse. We suggest examining the code for these two examples: Identify and Counting.

3. 

   Pen Based Games

   I love the game "Bug on a Plate". The user moves the bug using the arrow keys. The user gets a point everytime they pick up a piece of fruit, but they lose if they run into their previous trail (marked with the pen). A complete version of this is included as part of the Sample Projects in the Scratch distribution; a simplified version of the code is available here

4. 

   Object Avoidance Games.

   An example of straight-forward game is one in which the user controls the main character (e.g., a monkey) with the arrow keys. The user is expected to catch some good objects (e.g., bananas) while avoiding bad objects (e.g., red bananas and the monkey theif). The monkey gets points for every banana it grabs and loses points if the thief runs into them. To determine when a Sprite has reached the edge of the Stage (e.g., the falling bananas), you will find the question blocks under the Sensing Menu useful. Sample code is available.

5. Anything else that sounds interesting. You are not required to follow any of our suggestions given above. You can implement any game that has points and follows the specifications given below.

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. Points: The game must track the number of points the user has achieved in this run of the game. The number of points should be tracked with a Variable and displayed to the user.
2. Boolean Variable: Your game must use a boolean variable (i.e., a variable that can hold only two values: true (1) or false (0)). This variable must cause something useful to be done in your program! The boolean variable will probably track whether or not the user has done something yet and the game will probably not let the user perform certain other actions until that boolean variable is true (e.g., the user cannot start the next task until they've achieved some specific goal) .
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. The instructions should be complete enough that someone can understand how to play your game without you telling them how or without them having to examine the code!
4. Assessment: At the end of the game, you must give a different message to the user depending upon how many points they obtained. For example, you could classify the user as (Beginner, Intermediate, or Advanced) depending on if the acquired 0-5, 6-10, or 11 or more points. Of course, your categories will be different (and hopefully more interesting!)
5. Multiple Levels: Your game must have at least three levels of difficulty. Higher levels might involve more difficult questions, make objects move more quickly, have less time, or have more objects to avoid. The difficulty level should increase as the user makes progress.

   Implementation Hints: You will want to use a variable to track the level the user is currently at. You should strive to make the code (i.e., the instruction blocks in the scripts) as identical as possible for each of the levels. You should try to use variables to capture what is different about each level and to use the variables to make the code act differently. For example, a variable could designate the amount of time it takes for a Sprite to move across the Stage; you could set this variable to a smaller amount for higher levels; you'll then use this variable within the appropriate move blocks.

Implementation Hints

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!

We anticipate that the code for implementing multiple levels will be the most challenging for you. We recommend leaving that functionality for last: get the other aspects of your game implemented and working correctly before adding in multiple levels! 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 (30 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? This is a subjective measure!
• Documentation (15 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) 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

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

Part 1: Share and Comment through Website

The image that you upload will be used to later create a mosaic from all student projects; so, please pick a flattering image of your project! Run your game to a point where you like the image on the Stage, then stop it, save it to a file, and then upload it. You can upload it 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. You should then go to the Gallery Fall10-Project 1 on the Scratch web site. Once you are at the Gallery, you will see a button labelled "add my project" which will allow you to add you project. This step must be completed by Friday 10/22 at 5 pm.

NEW: You also must comment on five other student projects that have been added to the Gallery. After Friday, please browse through a range of projects and comment on five projects. Please choose projects that have not yet received five comments, since we would like everyone to get some feedback. Your comments should be added to the projects themselves and not added to the gallery.

To give feedback to other students, you should download their code (and not just play it through the web site). You may give feedback exclusively on the game play and appearance of their project or you may look at their code and comment on their code structure. Let your peer know what you like and don't like about their project, what you find confusing, and any bugs or problems you discover. You should write an amount near the 500 character limit. Please be polite and constructive, while giving feedback that is specific to this particular project. (You will show your comments to the TA when you have an individual demo with them.) This step must be completed by Monday 10/25 at 5pm.

Part 2: Submit through Learn@UW and Demo

Second, 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 Wed 10/27, before class.

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

NO LATE PROJECTS ACCEPTED