Issue with jump not happening every time the up arrow is pressed

Link to the project or level: https://studio.code.org/projects/gamelab/TYiOHI5CZfcprHrWrrS96gYkC1G150sDJhMamcQU4WQ
What I expect to happen: When I press the up arrow I want the character to jump. I also want to be able to jump when moving side to side. Ultimately I only want the character to be able to jump one time, but i want to figure out why the character won’t jump consistently first.
What actually happens: Sometimes, when you press the up arrow the character won’t jump. This seems to be more obvious when the character is moving left or right. It seems to be a timing issue, but I can’t figure out what might be causing the jump action to not fire every time.
What I’ve tried: I have tried changing the way the jump is calculated (using counter instead of velocity). I have tried changing the order of the if statements that handle movement. I have tried setting the jump velocity in a few different ways (+=, -=, etc).

@yoxall.dustin,

You are clearly advanced in your programming skills and this looks like the fun start to a game. I haven’t had a chance to fully break down your game yet (and this goes beyond the scope of what a CS Discoveries student would be expected to learn and use), but a few questions.

Is there a reason you are passing the “sprite” parameter into your controlPlayer function, but sometimes using “frankie” and sometimes using “sprite” inside that function?

Does the gravity simulation have something to do with it? When I put a watcher on the gravity function, the velocityY goes back and forth from 0 to 1.5. Wondering what would happen if you temporarily disabled that.

Finally, and this is where I think the problem may be … how does the “frankie.collide” blocks affect the jumping? Is there a conflict between that and the jumps at any point?

I don’t have a perfect answer for you, but maybe if you look into these, you will find a way to make it work the way you want it to!

If I see or think of anything else, I will jump back in.

Mike

Hey Mike,

Thanks for the reply! Yeah I know this is a bit beyond what my students are expected to learn, but I wanted to build an example for them of something you could make and then I fell down the rabbit hole of what I could make work. It almost feels like I am hitting a processing limit of game lab, but I don’t feel like what I have so far is nearly complex enough to cause that kind of issue.

To answer your questions, the reason I passed the sprite parameter into my controlPlayer function was an effort to create a function that I could use again in other projects if needed. I had copy/pasted some code from other places into the function in my efforts to solve the issue and I forgot to update the variable name. They should all be sprite.

The gravity simulation may be part of the issue. Because the gravity effect is always on, the collide function is constantly firing when the character is on the ground or a block so the velocity is always changing. I didn’t think about if the collide function would prevent movement in the opposite direction. I wonder if it makes sense to only apply the gravity when the velocityY is less than 0. That way once the collide event fired the velocity would just stay at 0 instead of constantly changing.

On a side note, is there a place I can peek into the game lab functions to see how they do things? Might be helpful in the future to better understand what’s going on under the hood.

I’ll do some testing and see what I can find out. Thanks for the insight and help!

Dustin

Sounds good. Yes, I may try disabling the gravity first and see if that gets you somewhere.

If not, let us know and we can try to take another stab at it…

Mike

Hey Mike,

Link to new version: https://studio.code.org/projects/gamelab/TEBP79w6LKIcbdHT9fxdnvxzTQFpTBr2Wxt8kXbvry8

So I’ve had a bit of a breakthrough and I think I understand some of what was going on in the original version.

First, I think the order of the functions in my draw loop was a big part of the issue. I was trying to control the player before applying gravity and dealing with collisions. In the version I have working I am controlling the player as one of the last things in the draw loop and that made a big difference.

I do think there were conflicts with the checks I was making during my jump code that may have been giving me issues as well. I ended up going back and re-writing the jump stuff to be way less complex and that seems to have helped a lot.

I appreciate you taking some time to help me figure out what was going on!

Dustin

2 Likes

Nice. I know that the order in the draw Loop can make a difference for sure. This looks like it is coming along nicely. I coudn’t see how to start it though?

Mike

Yeah, once I got the jump issue solved I started working on a start screen, but I haven’t finished it yet. Once I get it finished I’ll post the link so you can take a look.

Dustin

1 Like