1

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 cardboard markers

scissors hole puncher ruler

2

tape or glue dots

DESCRIPTION

LESSON OUTLINE INTRO: Review classroom code, littleBits basics and code concepts. Introduce the lesson prompt. 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

3

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). 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

loops variables logic engineering design remix power, input, output pixel game

4

RESOURCES

ATTACHMENTS Invention Log Lesson slides Pixel art template Invention art template Debugging checklist Feedback 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 + setup Intro (10 mins) Create (25 mins) Play (10 mins) Close (5 mins) DAY 2: REMIX (50 mins) Prep + setup Intro (5 mins) Remix (30 mins) Play (10 mins) Close (5 mins) DAY 3: SHARE (50 mins) Prep + setup Intro (5 mins) Share (40 mins) Close (5 mins)

INSTRUCTIONAL STEPS

STEP 1: SETUP - Prior to Class Duration: 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

5

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 Platform (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: INTRODUCE Duration: 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).

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.

6

STEP 3: CREATE Duration: 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:

7

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: PLAY Duration: 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. 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?

8

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 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.

9

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: REMIX Duration: 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 SCOREBOARD Level: 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 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

10

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 screen Level: 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.

11

REMIX #3: MAKE IT A 2-PLAYER GAME Level: 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.

12

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

13

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: Play 1: Feedback from groups and what they were going to do to fix it Remix 1: Students address the areas that need work from their test run Play 2: The results of their testing AFTER remixing and making changes Remix 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: SHARE Duration: 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.

14

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, 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: CLOSE Duration: 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

1

LITTLEBITS LESSON

HOT POTATO...OF DOOM!

LESSON OVERVIEW/ESSENTIAL QUESTION:

Students will use their knowledge of loops, conditional logic, and variables to create a game of Hot Potato using the littleBits Code Kit. Essential Question: How can code concepts work together to create a new spin on a traditional game?

LESSON TAGS

GRADE LEVEL SUBJECTS DIFFICULTY DURATION

elementary, middle arts, math, music science, engineering

intermediate 3x 50 minute periods

PREREQUISITE KNOWLEDGE

- Hello World: knows how to use littleBits, code blocks in sequence and upload code to the codeBit - code concepts: loops, variables, conditional logic (Tutorials 1.0, 1.1, 2.0, 2.1, 3.1, 4.0) - recommended: Ultimate Shootout

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 pipe cleaners cardboard markers

hole puncher scissors

2

+ optional craft materials so students can customize their game even more.

DESCRIPTION

LESSON OUTLINE INTRO: Review of loops, variables, Community Code, and goals for the lesson. CREATE: Students will build the ‘Hot Potato...of Doom!” invention from instructions in the Cope Kit app. The game includes music and a timer. PLAY: Each group tests out their coded invention. Groups can also combine to make the game more fun! REMIX: Students will customize their Hot Potato game through circuit, code and concept changes. SHARE: Gather students into a circle and play the Hot Potato game using their remixed versions. Allow classmates to provide feedback on the inventions.

LESSON OBJECTIVES - Demonstrate knowledge of how the color-coded Bits work together in a circuit. - Define and apply loops in the Hot Potato program. - Use variables to store data to be referenced for the Hot Potato program. - Define and apply conditional logic in the Hot Potato program. - Apply the steps in the littleBits Invention Cycle to create a new version of the Hot Potato Game.

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

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). 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

conditional logic variable loops Invention remix

RESOURCES

ATTACHMENTS Invention Log Lesson slides

4

Invention art template Debugging checklist Feedback chart

TIPS & TRICKS Volume control: If using the speaker Bit in an invention, the volume in your classroom can get loud! Connecting your audio jack on the 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 + setup Intro (10 mins) Create (25 mins) Play (10 mins) Close (5 mins) DAY 2: REMIX (50 mins) Prep + setup Intro (5 mins) Remix (30 mins) Play (10 mins) Close (5 mins) DAY 3: SHARE (50 mins) Prep + setup Intro (5 mins) Share (40 mins) Close (5 mins)

INSTRUCTIONAL STEPS

STEP 1: SETUP Duration: 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 work well) ahead of time for creating the spider. If you’d like to provide your students with the templates for the spider, be sure to print copies beforehand. You may want to construct your own example to play with the class during your lesson introduction. Seeing a working model of what they are building can help the students understand the goal of their Create phase and increase student engagement. You can also explore the Invention Platform (filter by “Code Kit”) on the littleBits website for remixes that students have created for this lesson.

5

STEP 2: INTRODUCE Duration: 10-15 minutes

Open up your Hot Potato...of Doom! lesson slides and review the goals for the day. Review: Optional for new or younger groups: What is our classroom Community Code of Conduct?

● Review the list you created in the last lesson. Ask for a thumbs up high as a sign that they agree to follow the community code.

Code concept review: Ask students where they see loops, logic and variables in real life. Record answers on the board. 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 that apply to this lesson, refer to Tutorials 1.0, 1.1, 2.0, 2.1, 3.1, 4.0. Lesson Prompt: Share with students that they will be challenged with putting a new spin on an old game: Hot Potato. Over the course of the lesson they will build the Hot Potato...of Doom! invention, play with it, and then change it to make it their own using their knowledge of loops, logic, and variables. Students will then share what they have created. Warm up: Using your model invention, bring students into the center of the room and play a few games of Hot Potato so they see the invention in action. Warning: fun will ensue! Break students into 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 on the internet. We recommend the “Good Play ToolKit” and “Institute of Play’s Design Pack” as a place to get started.

STEP 3: CREATE Duration: 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 Hot Potato code. Based on the level of your students, you may chose to complete the Create phase in the following way: OPTION 1 (Beginner): At each group workstation, ask students to open up the littleBits Code Kit app and click on the Hot Potato...of Doom! invention. Students will watch the instructional video and follow the instructions to

6

create and code their invention. For support, hand out the Debugging Checklist and the spider art template, if needed. Students will follow the instructional steps in the app to build the circuit, download the code to their circuits and decorate their game. 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. Encourage students to reference their Bit Index booklet if they get stuck or want to learn more about a particular Bit or accessory. Hot Potato Circuit:

OPTION 2 (Intermediate): Either as a class, or in groups, ask students to think through the different elements of the Hot Potato game that they just played: What were the things you experienced with your eyes and ears? What were the core elements of the game (time, repetition, animations)? What code blocks do they suspect are included in the code? After a 5-minute discussion, ask students to open a blank canvas in their Code Kit app. Share the link to Disassembled Hot Potato Code with your students (email or file share). To import the code to the canvas, click Import and drag and drop the file into the window. You may want to model these actions first and then walk students through the steps together. When imported, the blocks should appear scattered in the canvas, as below:

7

Challenge your students to use the deconstructed blocks to create the code they experienced in the Hot Potato game. All the code blocks for the game are presented in the canvas; no additional blocks will be needed. You could start students together for the first few steps (see reference in Play phase below), or have them break off on their own right away (customize instruction to meet the needs of your group). Allow 10-15 minutes to experiment, then move into the Play phase to test out their circuit and code.

NOTES

● Every Code Bit has its own unique name (i.e. Speedy Monkey). When using the codeBit dongle, 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 more smoothly. See the Implementation Checklist for more info.

STEP 4: PLAY Duration: 10-15 minutes

As you move through the Play 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?: Once the inventions have been constructed, students should test their prototype to make sure it works and to explore the circuit functionality. A. TEST THE CIRCUIT (STUDENT PROMPTS): Have students pass their circuit between their partner(s) or pair up with groups. If the circuit doesn’t work:

8

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

● Check your volume control on your speaker: Is it too loud or too soft? ● 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. 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.

The gray [DO FOREVER] block runs the code inside of it forever, so we can play the game over and over without resending the code.The purple [SEND IMAGE (worried face) TO OUT 1] block sends the face

9

image to the LED matrix until [SIGNAL FROM IN 1 IS ON].

When the button on IN 1 is pressed, the orange [START TIMER] block tells the timer to begin counting how many seconds have passed. The orange variable [HEARTBEAT TIME] determines the speed of the heartbeat animation by setting the time between the big and small heart images. We [SET HEARTBEAT TIME TO 250] at the start of the game.

The gray [REPEAT UNTIL] block will run the code inside of it until the game time exceeds 10 seconds. We [SEND IMAGE (big heart) TO OUT 1] and then [SEND TONE D OCTAVE -1 TO OUT 2 FOR HEARTBEAT MS]. The big heart will stay on the LED matrix while the tone is playing. When the first tone is done playing, we [SEND IMAGE (small heart) TO OUT 1], and [SEND TONE D OCTAVE -1 TO OUT 2 FOR HEARTBEAT MS]. The sequence of these 4 blocks creates the heartbeat animation. After the second note plays, the green [SUBTRACT 7 FROM HEARTBEAT TIME] reduces the heartbeat time by 7 milliseconds, making the animation faster with each round.

When time exceeds 10 seconds, a skull image is sent to the LED matrix, and three tones play. Then, the game timer stops counting and resets to 0 seconds. The code goes back to the beginning, and the game can be played again.

10

Check out the Bit Index and Code Comments for more information about the Bits and blocks used. CONTINUED FOR OPTION #2: After playtesting, call on students to talk through their choices in the code and what they experienced in play (how was it different from the model?) To check the code, open up Hot Potato...of Doom! in the Code Kit app on your main computer screen and have students compare it to the code that they’ve constructed in the canvas. For Remix, students can either open up the default invention code in the Code Kit app (remind students to save their code first if it’s something they want to keep!) or continue to use the code that they’ve been working on.

NOTES

● The Debugging Checklist can provide additional support during the playtesting phase. ● It’s easy for students to get distracted and forget to document their process in the Invention Log.

Be sure to set aside a few minutes between each phase to make time for documentation. ● 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: REMIX Duration: 20-30 minutes

Here are three sample remix prompts for Hot Potato...of Doom! that will allow students to put a new spin on the game. You can assign them all or just one, or create your own. There are different skills and difficulty levels listed below for each remix. REMIX #1: CHANGE THE CONTROLS Level: Beginner

● Swap out the input Bits to change the game play. How can changing the inputs change how the game is played?

○ Hint: Switch out the button for other input Bits and see how the circuit is affected. To take it up a notch, you can also try tweaking the input code

● Sample Solution: When using the slide dimmer, you can make it turn on when the signal is at 80%.

11

REMIX #2: ADD AN ELEMENT OF SURPRISE Level: Intermediate

● If someone has played Hot Potato many times, it may become repetitive and they may hold the game long enough to eliminate the person next to them. Add Bits and code to control the length of each game.

12

○ Hint: Use the different inputs you explored in Remix 1 to add variety to the game. Try experimenting with variables to add even more surprises.

● Sample Solution: The signal from a dimmer on IN 2 changes the game time. If the time goes above 10 seconds, the heartbeat time gets longer.

13

REMIX #3: CHANGE THE CONTEXT Level: Advanced

● Put a Happy Birthday twist (or song of your choice!) on Hot Potato by changing the song and adding a festive image or birthday message at the end. You can also change the design of the invention so it resembles a present, party hat, or something celebratory.

○ Hint: Tutorial 4.1 shows you how to compose a birthday song. ● Sample Solution: Incorporate part of the birthday song plus a party image to make the game

festive.

14

15

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 variable 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. Students should be playing deliberately and with discipline, and should abide by the community code of conduct in gathering and delivering feedback about the games of their peers. 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

● Assigning the entire class the same remix may allow the students to see how each group had a different spin on Hot Potato. It would also be easier for you to have all the same materials ready for them to use.

● 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 saving their code. Refer to your Implementation Checklist for guidance on creating your file management system.

STEP 6: SHARE Duration: 30-40 minutes

Have students spend a few minutes documenting (video/images) their invention and saving 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 phase to allow students to view each other’s code in a gallery-walk or play each other’s remixes in round robin 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, question, idea.

16

● 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.

STEP 7: CLOSE Duration: 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 27).