Lab 1: Click Alonzo Game
Students dive right into programming, in the very first class, by building a game that they can play and share with others. The object of the game is to click on Alonzo (the character at right) as he moves increasingly quickly around the screen. Optionally, they can put the game on their smartphone, which is great for motivation.
This first lab is designed to hook students' interest in programming. Students will explore many of the ideas introduced here more formally later. Here, students explore the Snap! interface and learn to respond to user interaction (in this case, a click).
Spend the entire first day with the students programming, without an introductory lecture. Since the goal is for all students to experience the immediate excitement of building a functioning game, postpone introductory classroom management tasks (e.g., establishing classroom routines) until after Lab 1. Do, however, make sure students understand that if they need help with something, or they're not sure they understand something, it's always okay to talk with their neighbors. Only after they have a successful programming experience behind them, introduce any additional educational technology (Google classroom, Piazza, etc.) that you'd like students to use.
Students will formally learn about pair programming in Lab 2. For now, you might suggest that if they pair up, one partner can have the lab page on-screen while the other has Snap! open, or you might want students to work individually on the first day to ensure that they all know how to manipulate the Snap! environment.
Pacing
The 4 required lab pages could be split across 1–2 days (
40–80 minutes). Expected times to complete follow:
Prepare
Lab Pages
-
Page 1: Programming a Game.
-
Learning Goals:
- Create a response to a user interaction (in this case, a click) by using the
when I am clicked
hat block.
- Introduce repetition with the
forever
block.
-
Tips:
- Do not give an introductory lecture. But you may consider taking a few minutes to open Snap! from the front of the room and asking students to name a few things they notice about Snap!. Have a student "drive" the action on the main screen; if a student suggests dragging a block out to the scripting area, have your "driver" drag the block to test the suggestion. This should be a short activity; just long enough for students to get curious enough to test out their ideas themselves.
-
Don't worry if the block changes color from to
when you insert it in your script. Snap! alternates dark and light colors when you nest same-palette blocks inside each other. This "zebra coloring" is especially useful with arithmetic expressions.
- A script doesn't have to have a hat block; you can run any script by clicking on it. Scripts without hat blocks are convenient when tinkering with a project. For example, you can make utility scripts just for the programmer and not for the end user of the project (e.g., put the sprite in the middle of the stage and clear the pen traces, which can be a helpful script for debugging).
-
After Exercise 4, students should have built the following script. Even if you consider the first
go to
block redundant, don't tell students to remove it. Later in the project, additional code will make it important to keep the two separate.
-
In the starter file, the Alonzo sprite's "draggable" checkbox (just under its name, above the scripting area) is unchecked. This isn't the default, so if your students want to build a similar project on their own, tell them to uncheck it. This is important when a project uses "when I am clicked," because it's easy to move your hand on the mouse slightly while pushing the button, and the computer might treat that as a short dragging rather than a clicking. Unchecking "draggable" rules out dragging.
-
Page 2: Saving Snap! Projects.
-
Learning Goal: Save their Snap! project.
-
Tips:
- As mentioned in the "Prepare" section above, the best option for most schools will be Option B, which requires you to set up students account in bulk prior to the lab. See the Student Accounts and Privacy page.
- Some students may already have personal Snap! accounts or would prefer to make their own. Encourage personal use of Snap!, but also insist that students use a student account for their school work.
- If students set up Snap! accounts in class using Option C, consider asking students to enter in your (the teacher's) email address instead of their own. One advantage is that all password reset requests will then go to the teacher, instead of a student email that students may also have trouble accessing. Students' school email addresses may also be more short-lived than teacher addresses, so this potentially reduces instances where students lose access to their projects after they leave a school.
- A few students will have unpredictable problems creating Snap! accounts. To avoid letting these problems eat up the entire period, take advantage of pair programming; it's okay if only one member of a pair can save their work. You can work with students after class to troubleshoot issues. (Even better, if you can wrangle a teaching assistant or two from last year's students, this would be a great thing for them to handle during the first class.)
-
Page 3: Sharing Your Game.
- Learning Goal: Share Snap! programs.
-
Tips:
- Make sure both partners end up with a copy of the project in their accounts.
- This page is about sharing programs with others, but it is also a way for students to submit work in class. You can have students share their projects and submit their URL. As it says in the student pages, the URL will show the most recently saved version of the students' projects. This means you can ask students to make the link and submit it early in the assignment, and you can see the current version of the projects as students work. If it is important to you that students not be able to change the state of their projects after submitting them (e.g., with a strict due date) then you can have students submit their projects as an XML file.
- Students should share their projects, but not publish them. (They can't publish at all if you created student accounts in bulk.) Sharing lets them give the project URL to people directly, but publishing also displays the project on the Snap! web site. It's not a big problem if they do that, but if everyone does, then 1000 copies of the same assignment crowd out other projects.
-
Page 1 created the minimum playable game, and page 3 is saving and sharing it. When students improve the game on page 4, those improvements will automatically appear at the URL students have shared as soon as they save their project to the cloud.
Why is the shared link updated automatically when you save improvements to the project, but students' partner's copy isn't? Bear in mind that the link isn't a copy at all; it's a way to view the current version of someone else's project. Students' partners needs a copy so they can edit it on their own if one partner misses a class.
- There are other ways to save and share projects that are not listed on the student page. One important version to know is useful for the AP Create Task. Going to the File menu () and "Export summary..." will export an HTML file. This version of the project includes a picture of the stage and all of the scripts used in the program. Students can open this HTML file in a browser and then save the project as a PDF.
- The student pages show how to save and share within the Snap! interface, but you and your students may also choose to use some of the features on the Snap! community site. If students are logged in, they will see their username in the upper right hand corner of the screen. The dropdown menu from their username includes "My Projects," where students can access their projects. If they click into their projects, they can share their projects from here too.
- Another useful feature from the dropdown menu from their username is "My Collections." Snap! does not have a folder system for storing projects, but My Collections can help. Students can make different collections for their projects, just as they might use folders for files (e.g., a BJC Unit 1 Collection). Students can also share their collections. As teachers, you can also share a collection with the class; many teachers save project starter files for their class in a collection that students can then access and save a copy of when they start their own projects.
-
Page 4: Keeping Score.
-
Learning Goals:
- Understand the difference between sprites and costumes.
- Get acquainted with conditionals.
- Experience tweaking the timing of a game (playtuning it).
-
Tips:
- This lab uses the ghost effect to "keep score" in order to avoid introducing global variables. In Unit 2, after learning about local variables first, students will use a global variable to keep score formally. This way, they avoid learning the bad habit of using global variables where local variables suffice.
- Recall that the goal is for students to get to the end of this lab in one day (or two at most), with every student successful in creating a sharable game. Resist the temptation to teach things (e.g., visible stepping to aid debugging) on this first day. All of these ideas will be formalized in future labs and units.
- This page deliberately introduces an
if
statement, without explanation. If students are confused by this, encourage them to keep going, play the game, and see if it starts making sense to them. Assure them that everything in this lab will be taught "formally" a little later.
-
Page 5: Improving Your Game.
- Learning Goal: Explore running more than one script at a time (multi-threading).
-
Tips:
- When using the
say
block, some students may expect the sprite to make a sound; instead, this block makes the sprite display a speech cloud containing the message, as in a cartoon.
Solutions
Correlation with 2020 AP CS Principles Framework
Essential Knowledge:
- CRD-2.B.1: A program is a collection of program statements that performs a specific task when run by a computer. A program is often referred to as software.
- CRD-2.C.2: An event is associated with an action and supplies input data to a program.
- CRD-2.C.3: Events can be generated when a key is pressed, a mouse is clicked, a program is started, or by any other defined action that affects the flow of execution.
- CRD-2.C.5: In event-driven programming, program statements are executed when triggered rather than through the sequential flow of control.