In helping a student try to fix a bug, I’ve been having some issues with the “collide” block. I want to make something basic with the same functionality as the platform jumper game. I made movement and gravity, but this time just a stationary platform. If you move around a bit and jump a bit, you may notice that every once in a while a press of the “up” button to jump while standing on the platform does not actually trigger a jump. I also notice that the sprite seems to phase through the platform when it lands on it before moving back on top of it.
Any idea why this is happening? I really just want to know exactly how the collide block is working. Thanks!
Tim
Also FYI-- the goal is eventually help a student with Donkey Kong where the platforms are slightly rotated and Mario should be able to stand on them without gravity making Mario slip off in the direction of the rotation…but I think I need to figure out this problem first.
I’m not sure I have an answer for you, but maybe an observation or two. I’ve seen “glitches” in the past that are a little similar with collisions. For example, a ball can escape colliding with a wall when it is supposed to bounce if it is moving fast enough that the velocity allows it to “jump” over the thickness of the wall. I’m not sure that’s what’s happening when your sprite hits the platform and rebounds a little, but I also wasn’t able to see much of a problem with that myself when I played the game. It appeared to stick pretty well.
I did notice the lag in jumping. However, that improved when I changed the block to “keyDown” instead of “keyWentDown.”
Thanks for the response! Yeah, I’ve noticed some of those general glitches as well.
The keyDown instead of keyWentDown definitely makes sense to me from some glitches I’ve seen with collisions. My guess is that the collide block is somehow resetting the jump velocity back to 0 since the block the player is currently colliding with has a velocity of 0. I’ve noticed, especially when a sprite is rotated slightly instead of being just flat, that frame by frame the sprites might toggle between touching and not touching. Not sure if that’s what’s happening here, but in those cases the keyWentDown might be registering in the same frame where the sprites are touching again, and perhaps resetting the velocity as I mentioned above. So keyDown, since it often covers multiple iterations through the draw loop, would probably do a better job of avoiding this problem and indeed registering the jump.
I’ll try that. Thanks!
Anyone else thought through some of these apparent bugs in code.org, why they might be happening, and best practices to work around them?
Interesting to think about the issues. I do notice the sprite is “wiggling” when on the block when using the sprite.collide(block) function. When I use the watcher on your code, it does appear that the velocityY is constantly changing which means the boolean returned for the sprite.collide(block) is constantly changing from true to false.
I played around a little bit and put in an if statement using sprite.isTouching(block) and set velocityY to 0 if they were touching. I also removed the constant check for sprite.collide(block) since the if statement is essentially doing the same thing since it stops the sprite’s movement by setting the velocityY to 0 when the sprite touches the block. This did stop the wiggling. FYI - I am also using keyDown as @mwood suggested. Here is my remix. What is really interesting if you change line 19’s if statement to check for sprite.collide(block) instead of the sprite.isTouching(block), the wiggle comes back. It may have something to do with the returns. Documentation states that:
sprite.collide(target) returns: Boolean true or false. Changes output in the display after the sprites touch and drawSprites() is called.
sprite.isTouching(target) returns: Boolean true or false.
I am guessing (but just a guess) the subtleties in these returns is what is causing the constant change in velocityY? It does seem the keyDown and isTouching and velocityY to 0 (vs collide) fixed the wiggle and delay in jumping back up or at least that I can see. There are so many ways to problem solve these type of issues. There are probably many other fixes. But that is why we do what we do;)
Thanks so much to both of you! I was able to get the functionality to work. I even went ahead and tilted the block sprites. I had to add back a collide block into the if so that the sprite wouldn’t just phase through the block as it traversed it, but it seems to be working fine now (see link below). This should work for my student’s donkey kong game (although gotta get rid of the double jump).