LITTLEBITS LESSON

ULTIMATE SHOOTOUT

LESSON OVERVIEW

Students will use their knowledge of loops, logic, and variables to create a score tracker game that they build and code themselves.

Essential question: How do you create and customize a 2-player game that automatically keeps score when you hit the target?

LESSON TAGS

GRADE LEVEL SUBJECTS DIFFICULTY DURATION

elementary, middle STEAM, engineering, computer science

beginner 3x 50 min class periods

PREREQUISITE KNOWLEDGE

- Hello World: knows how to use littleBits, code blocks in sequence and upload code to the codeBit- inputs/outputs; loops, logic and variables (Tutorials 1.0, 2.0, 4.0, 4.1)

SUPPLIES

BITS ACCESSORIES OTHER MATERIALS TOOLS USED

Code Kit (1 kit per group of 2-3 students)

laptop with Code Kit app downloaded; USB port required if using the codeBit dongle

cardboardmarkerstape or glue dots

scissorshole puncherruler

DESCRIPTION

LESSON OUTLINE INTRO: Review classroom code, littleBits basics and code concepts. Introduce the lesson prompt.

1

CREATE: Students build the Ultimate Shootout invention - a score tracking soccer game - in teams of 2-3 students using the Code Kit app.

PLAY: Each group tests, then records learnings from their invention. Students explore how their invention works, plus the coding concepts behind it.

REMIX: Students will customize and enhance their inventions to create a 2-player game through opportunities to change the circuit, code, and the game play.

SHARE: Each group presents their remixed invention and code. Students provide peer-to-peer feedback and self-assess their work using their Invention Logs.

LESSON OBJECTIVES - Gain fluency with the Code Kit Bits and block-based coding conventions.- Utilize loops and logic in code to achieve efficient results.- Make use of code to trigger ‘benchmark’ events: Score reached, time

elapsed, etc.- Utilize computational reasoning to solve problems.- Construct viable arguments and critique the reasoning of others.

ASSESSMENT STRATEGIES

FORMATIVE ASSESSMENT: Use the Invention Log checklist (p. 16) to assess students’ understanding of the Invention Cycle, use of the Invention Log, and ability to attain lesson objectives. It can also be used as a self-assessment tool by students as they move from phase to phase in the Invention Cycle.SUMMATIVE ASSESSMENT: Use the Invention Log checklist to review students’ entries into their Invention Log and assess their understanding of the challenge and the invention process as a whole.

STANDARDS

NGSS

3-5-ETS1-2: Generate and compare multiple possible solutions to a problem based on how well each is likely to meet the criteria and constraints of the problem.

3-5-ETS1-3: Plan and carry out fair tests in which variables are controlled and failure points are considered to identify aspects of a model or prototype that can be improved.

MS-ETS1-2: Evaluate competing design solutions using a systematic process to determine how well they meet the criteria and constraints of the problem.

MS-ETS1-3: Analyze data from tests to determine similarities and differences among several design solutions to identify the best characteristics of each that can be combined into new solutions to better meet the criteria for success.

CSTA

1B-A-2-1: Apply collaboration strategies to support problem solving within the design cycle of a program.

1B-A-5-3: Create a plan as part of the iterative design process, both independently and with diverse collaborative teams (e.g., storyboard, flowchart, pseudo-code, story map).

2

1B-A-5-4: Construct programs, in order to solve a problem or for creative expression, that include sequencing, events, loops, conditionals, parallelism, and variables, using a block-based visual programming language or text-based language, both independently and collaboratively (e.g., pair programming)

1B-A-3-7: Construct and execute an algorithm (set of step-by-step instructions) which includes sequencing, loops, and conditionals to accomplish a task, both independently and collaboratively, with or without a computing device.

1B-A-6-8: Analyze and debug (fix) an algorithm that includes sequencing, events, loops, conditionals, parallelism, and variables.

2-A-2-1: Solicit and integrate peer feedback as appropriate to develop or refine a program.

2-A-6-10: Use an iterative design process (e.g., define the problem, generate ideas, build, test, and improve solutions) to solve problems, both independently and collaboratively.

VOCABULARY

loopsvariableslogicengineering designremixpower, input, outputpixelgame

RESOURCES

ATTACHMENTS Invention LogLesson slidesPixel art templateInvention art templateDebugging checklistFeedback chart

TIPS & TRICKS Volume control: If using the speaker Bit in an invention, the volume in your classroom can get loud! Connecting the audio jack of your speaker Bit to headphones can help, as well as establishing classroom management procedures that discourage students from turning the volume all the way up.

PACING DAY 1: CREATE AND PLAY (50 mins)Prep + setupIntro (10 mins)Create (25 mins)Play (10 mins)Close (5 mins)

DAY 2: REMIX (50 mins)Prep + setup

3

Intro (5 mins)Remix (30 mins)Play (10 mins)Close (5 mins)

DAY 3: SHARE (50 mins)Prep + setupIntro (5 mins)Share (40 mins)Close (5 mins)

INSTRUCTIONAL STEPS

STEP 1: SETUP - Prior to ClassDuration: 10 minutes

This lesson can be done individually or in small groups (2-3 students).

Each group will need at least one Code Kit, computer with the Code Kit app installed, plus one Invention Log and assessment checklist per student. Print out a copy of the Debugging Checklist for each group.

Set up a central location in the classroom for assorted materials and tools. For younger students, you may want to cut down some cardboard (8.5 x 11 sheets works well) ahead of time for creating the target and goal posts. If you’d like to provide your students with the templates for the soccer goal and target, be sure to print copies beforehand.

During the Create phase, students will construct their first prototypes according to instructions in the Code Kit app. You may want to construct your own example prototype before the lesson begins. Seeing a working model of what they are building can help students understand the goal of their Create phase and will allow you to quickly demonstrate it working in the Play phase. You can also explore the Invention P latform (filter by “Code Kit”) on the littleBits website for remixes that students have created for this lesson.

NOTES

● Refer to the Implementation Checklist to make sure you are set for your lesson.● All students will start by making the same game in the Create phase. They will take their games

in new directions during the Remix phase. This gives them all a solid footing upon which to explore the nature and function of the code in order to better discover how changes to the code affect the program.

STEP 2: INTRODUCEDuration: 10 minutes

Open up your ‘Ultimate Shootout’ lesson slides and review the goals for the day with your students.

Optional for new or younger groups: Discuss and agree upon your CCC (Community Code of Conduct.)● As a group, come up with 4-5 rules that you all agree on to have a fun and productive learning

experience (e.g. ask 3 before me, give constructive criticism, one voice, tools not toys etc).

4

Call on students to review the “rules” of littleBits basics that were covered in ‘Hello World’ lesson. See “Bit Basics” on pg. 2-3 in the Bit Index as a reference.

Code concept review: Ask students where they see loops, logic and variables in real life. You may also ask students to reflect on how the concepts they learned can be used in creating games. If students need a refresher on the inputs/outputs, loops, or variables content, refer to tutorials 1.0, 2.0, 4.0, 4.1.

Lesson Prompt: Share with students that they will be taking on the role of “Game Designer” for this project. Over the course of the lesson they will build the ‘Ultimate Shootout’ invention, play with it, and then change it to make it their own 2-player game using their knowledge of loops and variables.

Break students in teams of 2 or 3 and assign them to a computer workstation to begin the Create phase.

NOTES

● If you’d like to learn more about incorporating game design into your lessons, there are many wonderful resources available online. We recommend the “Good Play ToolKit” and “Institute of Play’s Design Pack” as a place to get started.

STEP 3: CREATEDuration: 20-30 minutes

If using the Invention Log, share criteria for success and constraints that are appropriate for your students (p. 3). For example, your criteria for success could be that the circuit must contain power, input and output. Or, your criteria could indicate the usage of a code block not in the original Ultimate Shootout code.

At each group workstation, ask students to open up the littleBits Code Kit app and click on the Ultimate Shootout invention. Students will watch the instructional video and follow the instructions to create and code their invention.

Encourage students to reference their Bit Index booklet if they get stuck or want to learn more about a particular Bit or accessory. For younger students, you may want to pause the class after each step to troubleshoot any common problems, as well as share successful build strategies amongst the groups.

For support, hand out or provide a link to the Debugging Checklist and the soccer art templates, if needed.

Ultimate Shootout Circuit:

5

NOTES

● Every codeBit has its own unique name (e.g. Speedy Monkey). When using the codeBit dongles, you’ll want to make sure the right codeBit is connected to each group’s computer. If you’ve labeled the Bits prior to the class, this process will go smoothly. See the Implementation Checklist for more info.

STEP 4: PLAYDuration: 10-20 minutes

As you move through the Play phase prompts, be sure to have students record their Play process and reflections in the Invention Log (starting with “How did your testing go?”, p. 8)

How did your testing go?: After the inventions have been constructed, students should test their prototypes to make sure it works and to explore the circuit functionality.

A. TEST THE CIRCUIT (STUDENT PROMPTS): Flick a piece of paper toward the target. The number on the scoreboard should go up. If the circuit doesn’t work:

● Check the cardboard trigger: does it move freely and make contact with the button when pressed?

● Make sure the button presses all the way down, and that the Bit is connected securely to the circuit.

● Check your power: Make sure your cable connections with the power Bit are secure● Check that your battery is charged● Check code (see Debugging Checklist for support)

B. HOW IT WORKS: Either as a class or in groups, ask students to discuss/explain how the circuit works.

6

How does the code work? A clear understanding of how it works will help them explore and experiment during the Remix phase. Make sure students understand how each component in the circuit functions. See the circuit and code explanations below for reference.

Opportunities for Inquiry: Guide students to observe the functionality of each block in the code:● What would happen to the program if the [WAIT FOR IN 2 TO BE OFF] code block were removed,

for instance?● Score is a variable in this game. Can a new variable be made called [Points] and substituted for

Score? What effect, if any, does this have on the game?● The score is displayed as scrolling text. Is there a way for the score to be a stationary number on

the screen?

The orange [SET SCORE TO 0] block sets our variable [SCORE] to 0, so we start each game with a blank slate. The gray [DO FOREVER] block will run the code inside of it forever. This means that the code will continually check if the button has been pressed.

The blue [IF/DO] block checks to see if the button snapped to IN 2 is ON. This happens when the button is pressed. If the button is pressed, the blocks inside of [IF/DO] execute. The green [ADD 1 TO score] adds 1 to the variable [SCORE], which holds the total points. The light blue [SEND SCROLLING TEXT score TO OUT

7

1] block sends the latest value of [SCORE] to the LED matrix. And the orange [WAIT FOR IN 2 TO BE OFF] block makes the code wait until the button is released before running the code again. We do this because code runs fast, so if we don’t wait for the button to be off before continuing with the code, the [DO FOREVER] loop can run multiple times before the button is released. This would add many points to the score at once. Using the [WAIT] block means we can only score one point from each button press.

Check out the Bit Index and Code Comments for more information about the Bits and blocks used.

NOTES

● The Play portion of the lesson can be an exciting time in the classroom, and students may lose sight of their learning targets in all the fun of playing the games. Remind students at the beginning of the experience that they should be wearing their “Game Designer” hats during this part of the lesson. Play should not just be a free-for-all, but should be disciplined and deliberate, with the intention of understanding the technical and physical elements of the game itself. Encourage them to carefully observe each other as they play the game, noting areas for improvement and redesign in their Invention Logs.

● For middle school teachers, add emphasis on documentation during these lessons. Ideas will come quickly, and could be forgotten just as quickly in the excitement of play, so we recommend using the Invention Log to document efforts to achieve the best results. Encourage organization and clarity in their work with the intention of creating documentation that stands alone, that is to say it could be read by any student or even an individual not in the class with a full understanding of the thinking behind it. Have students record their thinking as they play, or set aside 5 minutes at the end of the session to record their thoughts: What enhancements to the game are already occurring to you? What functionality could you improve upon?

● For middle school classes with prior experience with littleBits, if you have a collection of Bits available to you beyond those found in the Code Kit itself, encourage consideration of other Bits that might be integrated into the game design.

STEP 5: REMIXDuration: 20-30 minutes

If this is the first time students are remixing an invention, ask: “Have you ever remixed something that you’ve made? What do you think a good remix looks like?” You may help students with this exercise by referring to LEGO, for instance, and how once a model is built using the instructions, remixing is possible by rearranging the pieces to achieve a different construction. Remixing is a core phase in the Invention Cycle (reference the littleBits poster that comes in your Kit, as needed).

Now it’s time for students to make their inventions unique, based on the ideas and concepts they explored in the Play phase. You may provide students with your own remix prompt (examples below), or ask students to follow a particular prompt provided in the app. Try focusing the class on a singular prompt to start out (remix #1 or 2) and then move them towards the challenge of creating a 2-player game (remix #3).

REMIX #1: ADD ADDITIONAL VISUAL INTEREST TO THE SCOREBOARDLevel: Beginner

● Can you add a new graphic or message to the matrix screen when the game is over or a goal score has been reached?

○ Tips for Teachers 1: You may find that students are not yet comfortable with how the blocks of code connect to each other, and how to separate blocks from each other in

8

the canvas. Be available to remind them that blocks connect from below and only when the connection arrow lights up. Blocks only separate from below also, and therefore removing a block of code involves pulling all the code beneath that block with it, and then reattaching that code to the thread, minus the undesired block.

○ Tips for Teachers 2: Students may overemphasize the image in the matrix screen over the functionality of the program, and could compromise their productivity and learning by “over-designing” the win screen image. To avoid the Code Kit app being underutilized during this phase, provide the pixel art template for sketching out ideas, keeping the app itself open to experimenting and learning with the code blocks. The pull of working with the code will support bringing students back to the task.

○ Tips for Teachers 3: The combination of logic blocks and math blocks can be disorienting at first. The math blocks are for performing calculations, while the logic blocks compare events, including mathematical calculations. Therefore the equation or inequality used to determine the end of the game is found in the logic block menu, not the math block menu.

● Sample Solution : A trophy appears when the score reaches 10 points.

REMIX #2: INCREASE THE STAKES: Add a timer + stop screenLevel: Beginner

● Can you add a timer to the game, as well as a screen that pops up if time elapses before the goal score is reached? Optional: Can you add a sound to the timer, so that seconds are “heard” as they tick away?

● Tips for Teachers 1: Students may get stuck trying to use loop blocks for a task that requires a logic block. Having kids talk you through what they want the code to accomplish may reveal the logical language that can prompt them to look in the logic menu for their desired block.

● Tips for Teachers 2: Students who complete this remix early can try to incorporate multiple features here, perhaps a win screen and a time’s up screen. Additional screens can be added if desired: Halfway There!, Good Shot!, Lucky 7! or other such screens to support fluidity with the code.

● Sample Solution : Send a red screen when time exceeds 10 seconds.

9

REMIX #3: MAKE IT A 2-PLAYER GAMELevel: Intermediate

● Can you make a game that has 2 players interacting with the program simultaneously, competing to achieve a goal?

● Tips for Teachers 1: Be sure to remind students that as Game Designers, we want to allow ourselves to make mistakes as part our experimentation and play. Documenting those errors and discoveries will be as important a metric for success as the game itself.

● Tips for Teachers 2: A class or small group discussion prior to beginning the activity could be helpful to support children in imagining what a 2-player game can be. Brainstorming together might elicit more creativity, including new game concepts that are collaborative as well as competitive. Games could involve collaborating or competing to increase or decrease a score.

● Tips for Teachers 3: Versions of a 2-player game can be generated using variables, as shown below. Students may want to rewatch the variables tutorial video to help ignite their thinking.

● Sample Solution : Add a pixel to the LED matrix each time a point is scored by either player.

10

Documentation:To meet outlined NGSS standards, instruct students to fill out a new Remix section in their Invention Logs (p. 9-11) every time a design element is changed and tested. If you do not plan to adhere to the NGSS standards, allow students more flexibility and exploratory pathways during this phase of the design process.

Suggestions for the classroom: After students have worked on their remixes, pair up groups and have them playtest each other’s invention, 5 minutes per group. Record observations and notes in their Invention Logs (p. 12). This is another opportunity to remind students of their “Game Designer hats” and also a chance to refer back to the Community Code of Conduct from Day 1. Students should be playing deliberately and with discipline, and should abide by the code of conduct in gathering and delivering feedback about the games of their peers. You could structure your remix/play in the following format:

11

Play 1: Feedback from groups and what they were going to do to fix itRemix 1: Students address the areas that need work from their test runPlay 2: The results of their testing AFTER remixing and making changesRemix 2: Students spend the rest of the period modifying, remixing and finalizing invention

Opportunities for Inquiry: Students should document their experiences with each other’s games with detail in their Invention Logs.

● What features surprised you?● Was there any code that was new to you in your classmates’ work?● Is there any part of your peers’ work that might integrate into your own game?

NOTES

● If students get stuck changing the code to meet the remix prompts, refer them back to the tutorials listed in the prerequisite section.

● If your class breaks between Remix and Share, be sure to lead your students through the process of exporting their code, which will save as a code file. Refer to your Implementation Checklist for guidance on creating your file management system.

● Optional assessment challenge: Squish the bugs!○ You are going to create a game for another group using your remixes. Your challenge is

to break your code - you are going to make it stop working on purpose!○ You will create 3 levels (or however many students you have per group):

○ Level 1: Delete ONE block○ Level 2: Rearrange TWO blocks○ Level 3: Delete ONE block and rearrange TWO blocks

● Have groups switch with one game master who runs the challenge. First show the group what the LED matrix should do, then reveal the broken code. The other team has 5 minutes to fix it.

● Afterwards, have students independently write down 3 things they learned to add to their personal debug checklist. Share a few with the class on posterboard paper that stays up during lessons.

STEP 6: SHAREDuration: 30-40 minutes

Have students spend a few minutes documenting (video/images) their invention and save any files.

The Share phase is most successful when other students can view the code of the presenters. If possible, project each group's code onto the board (imported as code files into the Code Kit app) so that students can see and respond easily to the coding choices made by the presenting group. If that option is not available to you, students can demonstrate their inventions and time can be used at the end of the share to allow students to view each other’s code in a gallery-walk or play each other’s remixes in an arcade-style format.

Print out feedback charts for each student. Each group will spend 5 minutes demo-ing their invention and showing their code. Students should be prompted to explain their process and understanding of the code (Invention Log “Share” prompts can be used to guide their reflections).

Options for filling out the feedback chart:● Assign one notetaker in each group to fill out the feedback matrix per presentation. Rotate this

role so that each student gets a chance to record notes. Call on groups to share a glow, grow,

12

question, idea.● Each student fills out a single feedback chart, recording glow, grows, questions, and ideas from

all of the presenters into a single document.

NOTES

● If time allows, you may encourage your students to post their remixed inventions on the littleBits Invention Page. Often teachers will create a central account on the littleBits site to publicly showcase their class or school’s work.

● For an extra challenge/assessment: A group demos the invention and then the rest of the class (or paired group) has to attempt to write the code!

STEP 7: CLOSEDuration: 5-10 minutes

At the end of the presentations, collect the feedback forms and Invention Logs from each group. If you are assessing student work, the self-assessment checklist on p. 16 of the Invention Log may be filled out and handed in.

Printable/editable certificates can be used to celebrate your student’s achievements.

Students should take apart their inventions and put away the Bits according to the diagram on the back of the Bit Index. Students should clean up their workspace and close out their app.

For cleanup support, show your checklist on the board (slide 24).

NOTES

Optional Certificates:● Most Innovative Code● Most Challenging Game● Most Fun Game● Most Bits Used● Best Use of Loops● Best Use of Variables● Best Teamwork in Gameplay

13