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
- If you haven't already, create your own Snap! account and sign up for access to BJC solutions and assessments. Instructions for creating a Snap! account are on this student page.
- Do this lab yourself before class.
- Plan for students' Snap! use:
- Students need an email account to create a snap account. School email accounts are fine if they accept incoming mail from outside of the school network. If it is possible for you to communicate with students before school starts, ask students to be sure they know their email address and password for the first day. Better yet, suggest that they create Snap! accounts before the first class. You can direct them to the first lab page, which explains how.
- Note that if a student under age 13 creates an account, the dialog box asks for a parent's email rather than the student's own email. This is a legal requirement for snap to be compliant with the Children's Online Privacy Protection Act.
- Some school districts will not allow your students to use Snap! accounts for coursework. If you are in one of your districts you can still use Snap!. Accounts aren't required to use Snap!, but they are extremely helpful. Without an account, students will need to "export" each of their projects every day, store the files themselves, and import them again when they want to continue their work. With an account, their projects are stored in the Snap! cloud and they can save and access them through the Snap! File menu.
Lab Pages
-
Page 1: Getting Started with Snap!
-
Learning Goal: Log in to Snap! via the Cloud menu, src="/bjc-r/img/1-introduction/cloud_button.png" alt="Cloud menu button" title="Cloud menu button">, using a personal username and password.
-
Tips:
- 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 one member of a pair doesn't have an account yet. You can work with the non-account students after class to get over that hurdle. (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 2: 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:
-
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 7, 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 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.
- Students should share their projects, but not publish them. 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 2 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.
-
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.