Debugging Rock-Paper-Scissors

Overview

Students design and test an algorithm for a digital rock-paper-scissors game without initially using computers. They decompose the game into steps, represent decisions with conditional pseudocode, identify bugs, and explain how repeated testing improves a solution. The lesson assumes mixed prior experience and serves 25 students working in pairs.

Learning intentions

Students will be able to:

• Define an algorithm as a precise sequence of steps for solving a problem.
• Decompose rock-paper-scissors into inputs, decisions, and outputs.
• Write conditional logic using “if,” “else if,” and “else.”
• Test pseudocode, locate bugs, and revise a solution.
• Explain how patterns and repeated testing help improve an algorithm.

Success criteria

• I can describe what an algorithm does and break a problem into manageable steps.
• I can write pseudocode that handles all three game choices and ties.
• I can test my algorithm with different inputs and identify at least one bug.
• I can explain what I changed and why the revised solution makes sense.

Curriculum links

• Common Core Mathematical Practice: making sense of problems, planning a solution, persevering, and checking whether an answer makes sense.
• Common Core Mathematical Practice: looking for patterns and structure in conditional rules and repeated game outcomes.
• Grade 7 Geometry: drawing and representing conditions with technology, applied here through pseudocode, flow diagrams, and an optional digital implementation.
• Grade 6–8 Writing in Technical Subjects: using technology to produce and present relationships between information and ideas clearly.
• Common Core does not contain dedicated computer science standards; the lesson therefore uses these Mathematical Practice and technical-writing connections to support algorithmic thinking.

Lesson structure (60 minutes)

1. 0–5 min · Hook. Open with the introduction and hook slides and silently display: “Can a computer play fairly if we do not tell it every rule?” Teacher plays one quick round against a student, intentionally declares an incorrect winner, and asks what information is missing. Students identify the choices, rules, and possible outcomes.

2. 5–15 min · Explicit instruction. Use the algorithm and conditional-logic slides to model an algorithm for making a sandwich, then connect it to rock-paper-scissors: identify inputs (player and computer choices), processing (compare choices), and outputs (winner or tie). Teacher models: “Get player choice. Get computer choice. If choices are equal, report tie. Else if player has rock and computer has scissors, report player wins … otherwise report computer wins.” Students annotate the algorithm planning and pseudocode worksheet and answer: “What would happen if we forgot the tie rule?”

3. 15–28 min · Pair algorithm design. Distribute the algorithm planning and pseudocode worksheet to pairs. Partner A writes pseudocode using clear steps and conditional language; Partner B checks that every possible pair of choices is addressed, then partners switch roles. Students may use the structure “If…, else if…, otherwise…” but must explain each decision in their own words.

4. 28–40 min · Unplugged testing. Pairs test their pseudocode by acting as the player and computer, using paper choice cards or hand signals. They run at least six test cases: three wins, two losses, and one tie, recording the expected and actual result on the test-case table. Teacher circulates and asks, “Which input did you test?” “What pattern do you notice?” and “Does the result make sense?” Students revise any unclear or incomplete step.

5. 40–52 min · Debugging challenge. Display the intentionally flawed pseudocode on the debugging challenge slides: “If player = computer, report tie. Else if player = rock AND computer = paper, report player wins. Else report computer wins.” Pairs use the debugging and revision section to find at least two bugs, create test cases that expose them, and rewrite the algorithm. Invite pairs to explain whether each bug is a logic error, missing condition, or incorrect output. If devices are available, students may implement and test the corrected version in Scratch or Python.

6. 52–60 min · Share and assess. Use the discussion and exit-ticket slides for a brief pair share: “How did testing change your solution?” Students complete the exit ticket on the worksheet: define algorithm, write one correct condition, identify a bug in the challenge, and name one test case that checks a tie. Collect responses as students leave.

Resources

• Computer and projector
• the complete 10-slide teaching deck
• the algorithm planning and pseudocode worksheet
• Paper choice cards or hand signals
• Whiteboard and markers
• Optional Scratch or Python-capable devices
• Timer
• Vocabulary displayed on the board: algorithm, input, output, condition, pseudocode, bug, test case, debug

Assessment

• During modeling, ask students to identify the inputs, processing, and output in the example.
• During pair testing, check whether students test ties, wins, and losses rather than only one example; listen for explanations based on rules and patterns.
• Use the exit ticket to assess algorithm definition, conditional logic, debugging, and understanding of testing. A strong response identifies that the flawed algorithm incorrectly says a player with rock beats paper and fails to distinguish all winning combinations.

Differentiation

• For multilingual learners, provide sentence frames: “The input is ___,” “If ___, then ___,” “The bug occurs when ___,” and “Testing helps because ___.” Pair students strategically and allow oral rehearsal before writing.
• For students needing support, provide a partially completed decision table showing rock, paper, scissors, and tie outcomes. Permit flowchart symbols, numbered steps, or a word bank before requiring full pseudocode.
• For students with attention, language, or processing needs, chunk the worksheet into one section at a time, read directions aloud, and assign clear partner roles: Writer, Tester, and Checker, rotating halfway through.
• For advanced students, require a compact solution with fewer repeated conditions, add score tracking or three-round play, or translate the algorithm into Scratch or Python and explain how their code handles invalid input.

Classroom management and digital citizenship

Keep pairs seated with one worksheet and establish a “driver/navigator” routine if devices are used. During testing, students must challenge the algorithm, not criticize the person; use specific evidence such as “This test exposes a missing condition.” Remind students not to copy code without understanding it, not to enter personal information into online tools, and to credit shared ideas. Devices remain closed until the teacher gives permission.

Answer key/model responses

• Algorithm: A precise, ordered set of steps used to solve a problem or complete a task.
• Inputs: The player’s choice and the computer’s choice.
• Outputs: Player wins, computer wins, or tie.
• Correct rule pattern: Rock beats scissors; scissors beats paper; paper beats rock; matching choices create a tie.
• Debugging challenge bugs: The rock-versus-paper condition reports the wrong winner, and the single “otherwise” rule does not explicitly represent all winning combinations. A valid fix is: “If player = computer, report tie. Else if player = rock AND computer = scissors, report player wins. Else if player = paper AND computer = rock, report player wins. Else if player = scissors AND computer = paper, report player wins. Else report computer wins.”
• Testing explanation: Testing uses varied inputs to reveal errors and confirm that the algorithm works for expected cases, including edge cases such as a tie.