Tried multiple laptops. Signing out and using different laptops.
Help!
Lori in Lincoln
Hi Lori,
Can you send more information? Do all the lessons lock? A shared link to a lesson would be helpful in helping us problem solve.
Thanks!
Michelle
I hope this helps. This not a consistent problem. This also happened on Unit 3 Lesson 9 bubble 15.
Hi!
Yes. That is a huge help. I love approaching these with students and going through the code line by line starting at the top and working my way down as the computer does. The questions I have in my head I ask out loud to see if the students can answer. I found myself doing that here as well.
So, my first observation was that I instantaneously saw the rock begin where it was coded to start at x=200, y=350. I would probably ask my students if they saw what I saw? Why does it so quickly move to the corner? I wonder if we lowered some of the velocityY values if we can better see why it shoots up to the top so quickly? So that was the first thing I tried was to reduce the velocityY speed from -10 to -1 like this rock.velocityY =-1. The next thing I noticed was that the counter pattern on line 8 was not correct. Also, because the student used velocity, he didn’t really need the counter pattern. This video does a good job of explaining why: https://www.youtube.com/watch?time_continue=3&v=zcP94yMYqrI&disable_polymer=true. So, I removed the counter pattern. Then we get to the conditional if statement. I guessed that the student used that so the rock could go the other way when it got near the top. I changed the if statement to <11 instead of ==11 because the draw loop runs 30 times per second so that statement has to be true for 1/30th of a second. I feel I am more likely to generate a true response if my boolean has a bigger test range to be true. So I changed the boolean to if (rock.y < 11) and slowed down the rock to rock.velocityY = 1.
Here is my final fixed solution for you to take a look at (https://studio.code.org/projects/gamelab/9ySb9Wcvps__lkg5GHcRvdQ6tLJ_694oP2UscwxzPRM). Remember, there are MANY solutions so this may not be exactly what your student was shooting for but perhaps some of the tips can help you find a solution to this puzzle and others as well.
Good luck!
Michelle
2 Likes
Thought I would chime in on the 2nd example. It had a few of the same minor mistakes as the first one, but didn’t require much changing to get it to work. It’s crazy how the tiniest mistakes change the functionality so much.
As @melynn mentioned above, line 25 is better done with an < sign rather than == so if the computer doesn’t check exactly when the frog’s y position is 65, it will check it when it is at 64 (or 63, etc.) Sometimes the frog might move faster than the loop can check the conditions.
The other issues were changing the overall velocity (frog.velocity) in lines 21 and 26. These blocks should refer to the vertical velocity (frog.velocityY) rather than the overall velocity. By changing the overall velocity, it changed both x and y velocities until they reached 0 and were pinned to the top left corner at 0, 0.
Then, I removed the else on lines 20-22 as they weren’t really necessary and I think this is what your student was after:
At any rate, I agree with Michelle that sometimes, you just have to slog away at the code one line at a time and sometimes even take a break from it. I will tell my kids if they get really stuck to tackle it again another day and I’m only a little surprised how often they figure it out when they stop thinking about it and then come back and try a new approach!
Best wishes!
Mike
1 Like
Thank you. That makes much more sense. It is funny that I can stare at it and not see the bugs!
1 Like