Unit3 Lesson 15

These two projects both have similar problem: frog doesn’t jump every time that the up arrow is pressed. The first one it happens every 3rd time. Code looks good to me. Help?

Hmm… did your students make changes to the code after you posted this? Both of them work every time for me (as long as the frog is on the ground).

Let us know!

Mike

These both look good to me too. Problem solved?

–Michael K.

I’m sorry I didn’t respond to your answer on the frog jumping problem. Yes, I guess he figured it out.
Could I ask you to look at this one:
https://studio.code.org/projects/gamelab/GNZLWqH0pCP8m1hlTkQzZBZN-ZNhQsKl71Nn1jfPra8
The problem is that the bullets only affect the alien if they are very close to each other.
Thanks for any help!

I initially wrote a reply and then retracted it after looking further, so if you saw my first reply, I’m not sure it was accurate. Instead, what I think is happening here is something else.

One potential issue is that immediately after firing, it checks to see if that bullet has made contact, but it is apparently not checking a 2nd time, so my guess is that “keyWentDown” only triggers for a limited time and the conditions of collision aren’t checked again when the bullet is further away from the pink alien.

Another issue, though is that the bullet sprite is being created three times on lines 1, 52 & 59. Normally, sprites are created outside of the draw loop once (like in line 1) and then are updated inside the draw loop. When you create more than one sprite with the same name, the later ones are replacing sprites that already exist. GameLab lets you do that, but it can only track collisions on one at a time, so when multiples are created, not all of them will trigger a collision.

Some potential things to look at to solve the problem.

  1. See if they can create the bullet once outside the draw loop and then only update it inside the draw loop.
  2. maybe create a variable such as “fired” that initially is set to 0. When the space is pressed, signaling the first time it is fired, the variable could change to 1. Then as long as the variable is 1, it could continuously check for the collision. This may eliminate the problem with the “keyWentDown” not allowing it to check for very long.

I played with it for a little while, but didn’t implement the last suggestion yet, so give that a try and see where you end up. There still may be a problem with multiple instances of the same sprite, but I’m sure if they work on it a little longer, they will make progress and if they are still stuck, let us know and we can explore it a little further.

Mike

I agree with @mwood. Creating sprites in the draw loop can be problematic because all of the sprite’s settings are being reset 30 times per second. I think the “shoot” function (and related items) can be simplified. I would have the student think through these questions:

  1. Think about destroy and lifetime. These remove the sprites from existence:) Since the sprite positions are resetting, do you need to destroy or set a lifetime (a lifetime will remove the sprite when the count down is complete)? I would consider visible=true or visible=false when you want the sprite to exist but not seen (like when the bullet is on the pink sprite but not being shot OR when bullet.isTouching(yellow) but then you reset yellow).

  2. Avoid creating sprites in the drawloop since all settings are reset 30 times per second.

  3. Think through what a bullet does as it shoots. First, it starts at pink.x AND pink.y (I would think about setting those separately). Then, the velocity sends it in a direction. It will then either keep on going (where an if statement should reset it back to pink.x and pink.y ± the positioning) OR it will hit the yellow sprite (but then doesn’t it still need to reset to pink.x and pink.y)?

  4. I LOVE the variable aim to set the velocity and positioning of the sprites!

The foundation is there!
I hope these tips help but let us know if you need further assistance!
Michelle