Week 3 Debug It

DebuggingTime for Week 3’s Debug it activities.  I love how the facilitators use broken code to teach new coding concepts in this workshop.

Here are this week’s challenges.

  • Debug each of the five Scratch programs in the Week 3 Debug It! studio.
    • Debug It! 1
      In this project, the “Inventory” list should be updated every time Scratch Cat picks up a new item. But Scratch Cat can only pick up the laptop. How do we fix the program?
    • Debug It! 2
      In this project, Scratch Cat gets 10 points for collecting Yellow Gobos and loses 10 points for colliding with Pink Gobos. But something isn’t working. How do we fix the program?
    • Debug It! 3
      In this project, Scratch Cat is thinking of a number between 1 and 10. But something is wrong with the guess checking — it doesn’t work consistently. How do we fix the program?
    • Debug It! 4
      In this project, the “# of hits” display should increase by 1 every time the Scratch Cat is hit by a tennis ball. But the “# of hits” increases by more than 1 when Scratch Cat is hit. How do we fix the program?
    • Debug It! 5
      In this project, Scratch Cat is navigating a maze to get to the yellow rectangle. But Scratch Cat can walk through walls. How do we fix the program?

None of the challenges stumped me this week.  In fact I usually found the bug on my first pass through the code.   I think I have internalized many great problem solving strategies over the years.  But for debugging and when looking at code I tend to ask myself 3 questions?

  • What is this code supposed to do?
  • What is it actually doing?
  • How can I fix it?

This can then lead to:

  • How else can I fix it? 
  • Or: What is the simplest fix?
  • And: How can I change or extend the code from here?

I think it is important to teach children that in programming, as in life, there are many different ways to get to the desired outcome, and some are easier than others.

Here are my solutions and reflections on the challenges.

Debug-It 3.1 remix In the code for sprite4 (the laptop), it looked for when it was touching (sprite1– the cat) then disappeared and added the laptop to the inventory.
The code for sprite 2 (cheesy puffs) was looking for when it touched sprite 3 (the lamp) were and the code sprite 3 (the lamp) or was waiting to touch sprite 4- the laptop. Because only scratch moved, he only ever picked up the laptop. Solution– change the code blocks for sprite 2 and sprite 3 to look for when they touched sprite 1.

Tip– change your sprite names to descriptive names like cat, laptop, etc… so it is easier to see where there may be an error.

Debug-It 3.2 remix In the code for the yellow sprites, if it was touching the cat, there was a block that said to add 10 points to the score then hide. In the code of the pink sprites it said to wait for touching the cat then gave no further directions. I added the blocks to add -10 points to the score and hide the sprite to each pink sprite. Problem solved.

*Note to self. In the example they set up separate code for 6 pink and 6 yellow sprites. I think you could add more variety to the game, and less chance of bugs by using the clone sprite function and some random generators for to vary the number of each kind of sprite, their location, and even how often they appear on screen.

Debug-It 3.3 remix: Simple error. In the code checking if the secret number was greater than the guess it checked if it was < the guess. I just had to change the code block to if secret number > guess.

*note to self: I suppose I could have just reversed the conditions to ‘if guess is < secret#’ and that would have had the same effect.

Debug-It 3.4 remix: What was happening is that the hits kept incrementing while the ball was crossing Scratch for multiple hitcounts for each contact. I added a block of right after the hit count incremented and before the repeat. This made the counter increment only once for each contact.

Note to self: It would be neat if the ball bounced off of scratch when it hit him. One method I saw online was to add “point to sprite1” then “turn 180%” to have it bounce off the other sprite in a roughly realistic bounce. I think the accuracy of the bounce would depend on how large the sprites are and how scratch determines the location of a sprite. How does it do that? Does it use one of the outmost corners for the x,y value or a mean of the x and y values? I need to do some research and experimenting on this one.

Debug-It 3.5 remix:: I added this code to detect when Scratch is touching green walls. Forever {{If touching green then move -10 steps]}
*An alternate would be to only let him move if he is touching the white path. This would enable him to navigate a multicolored maze, as long as the path was white.

Leave a Reply