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!


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


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!

Hi, this is Xavier, the creator of the alien shooter game. I have been giving you posts lots of consideration, but I can’t figure out a way for it to work. To @mwood, I tried the “fired” variable that you suggested, but it didn’t work. I don’t think it has to do with whether or not the code is checking whether or not the bullet hit because I also tried changing the shoot function from keyWentDown to keyDown and I held the key down. This also didn’t work, and since the key was down, it should have been checking.
To @melynn, I can’t just use sprite.visible because if I do that, the game will begin to lag due to the sheer number of bullets off screen, and the game is intended to be infinite. (I tested, it starts to lag at around 170). I also can’t just reset the bullet to the point at the gun because most people will want to shoot faster than that allows.
Finally, creating the sprite out of the draw loop. I can’t do this because, as I said earlier, I wanted the game to be infinite, and I don’t want to spend the rest of my life copy and pasting more bullet sprites and making new lines of code every time the person shoots.
These are my problems with the game, I hope you can help me out with trying to fix these problems. Could you send a link to an already working shooter game made on code.org that I could try to model the shooting part my game off of?

Thanks, Xavier

For Xavier,

I love that you are asking for an example game! Figuring out the solution to the puzzle is most of the fun! Here is a game I often use to model the shooting effect.

Let us know if it helps! Good luck!

I haven’t looked at @melynn’s example yet, but I found a student example as well, that I think would help as well, so maybe with these two, you could see how to rework yours a little. I am pretty sure you can get yours to work by changing a few things …

Good luck!