Celius wrote:
I'm sorry, I don't quite get what you mean by this... Why would you be decreasing the velocity?
Because negative velocities move the player up, and we want the possibility to have the player go higher.
We have similar ideas, but while I'm thinking of extending the jump, you are thinking of cutting it short. I'll try to explain as I go along.
Quote:
Player.YCoord = Player.YCoord + Player.VelocityY
And also every frame, gravity does this:
#DEFINE Gravity 0.14
Player.VelocityY = Player.VelocityY + Gravity
That's perfect.
Quote:
However, when the player jumps, assuming the player is allowed to jump, here's what I do:
Player.VelocityY = -2.5
Great, we're on the same page. We just disagree on what comes next.
Quote:
I initialize the VelocityY with a value of -2.5, and the gravity adds .14 to that value every frame. Since VelocityY gets added to PlayerY every frame, that means -2.5 gets added one frame, -2.36 gets added the next, -2.22 the next, -2.08, etc.
OK, but then the instant you release the button the player stops rising. Sounds weird to me, because I can't remember of any games working like this (no matter the current speed, releasing the button just acts like hitting an invisible ceiling or something? Seems weird!). I'm more familiar with inertia, i.e. after applying the force, you have to wait for it to "wear off", you can't suddenly cut it.
My suggestion is basically this: once the jump officially starts, as well as setting Player.VelocityY to -2.5, you initialize a counter to, say, 16 (notice that I just got this number out of my ass, you'd have to test in order to find a good value). Then every frame, as well as adding the gravity to the velocity you will decrement this counter, and as long as it's > 0 and the jump button is still pressed, you add, say, -.10 (out of my ass, find a good value) to prevent gravity from working too quickly too soon.
Pseudo code:
Code:
//Counter was already initialized and the player is in "jumping" state
Player.VelocityY = Player.VelocityY + Gravity
Counter = Counter - 1
if JumpButtonPressed and (Counter > 0) and Player.Jumping then
Player.VelocityY = Player.VelocityY - 0.10
end if
Player.YCoord = Player.YCoord + Player.VelocityY
That way, after the initial velocity of -2.5 has been set, it will change into -2.36 the next frame, but if you do the above, it will move back to -2.46, and so on. The player will be able to "hold gravity back" for up to 16 (the value put into the counter) frames, thus making the jump higher. What he does with the button (keep it pressed or release it) after those 16 frames doesn't matter, the character will still rise until gravity has the velocity go over 0 and it starts falling. This should look and feel more natural than suddenly cutting off all vertical velocity.
Quote:
Sorry if this isn't making any sense, or if I just explained the obvious, or if the above is just a bunch of crap text for any reason at all =).
You were perfectly clear, I hope I have too this time.
Quote:
Just hope for the best, like you said. But it's important to still recognize these problems/glitches, as one day you could realize that they are the reason your program isn't working the way you expected.
Take a look at the
"Sonic 3 and Knuckles Glitches and Oversights" series on YouTube. The videos are very interesting from a programming point of view, as we programmers can in many cases tell what went wrong, and be prepared to avoid similar glitches in our own programs.
http://www.youtube.com/watch?v=XEOsmMOc_BA&fmt=18
http://www.youtube.com/watch?v=zJ5LsMeL0g8&fmt=18
http://www.youtube.com/watch?v=us93F4qvSVQ&fmt=18
http://www.youtube.com/watch?v=TxxmbcxNorA&fmt=18