015 : Slowing down

Now that you have the player constrained to move on the main platform, you can start working on the rest of the game. What do you want to work on first?

Well, I need platforms, monsters, ...

Oh wait, I just remembered, we should fix the player movement so that player can build up speed and come sliding to a stop.

Why do we need that?

Well, we don't absolutely *need* it, but it does make the game far more satisfying to play than simply moving one or two pixels at a time.

It sounds like it's going to be hard.

Actually, it's not. You already have variables to store the player's current velocity in velocity_x and velocity_y. Now you'll need add a place to store the "delta", which is the amount to add to the velocity then the arrow keys are pressed.

But if we keep adding to the velocity, won't the player keep going faster and faster until they fly off the edge of the screen?

Yes, that's why you also need a *maximum* velocity -- you'll allow the velocity to increase up to the maximum, then you won't let it get any higher.

script.js: Define how fast the player's velocity should increase.

function init_player() { ... _player.velocity_x = 0; _player.velocity_x_delta = 0.8; _player.velocity_x_max = 3.5; _player.velocity_y = 0; }

Run your code in a browser and verify that there are no errors.

Why are they set to 0.8 and 3.5? What do those numbers mean? And why don't I need them for the y velocity?

Whoa! One question at a time! The 0.8 value means that if you press the arrow key, then player will start moving 0.8 pixels every time the screen is updated. And if the player holds the key down, it will increase until it reaches 3.5 pixels per update.

But how can you move 0.8 pixels? Don't you have to move 1 pixel or 2 pixels? What does it mean to move 3.5 pixels?

Ahh. Good observation. When the player is drawn, the x,y position will be rounded to the nearest integer value. So we can track the player position and velocity using real numbers (like 0.8) and they'll be automagically converted to integers when needed.

OK. So why don't we need any of this for the y velocity?

The y-direction is the jumping direction, so we'll handle that when we add support for jumping.

Oh, OK. So how do I use these values?

Every update, you can simply add the player's velocity_x_delta to the current velocity if they're holding a movement key, but you'll need to clamp the velocity so that it doesn't get larger than velocity_x_max.

Previously, I had -1 when the player was moving left. Do I need to subtract from the velocity when moving left and add when moving right?

Correct. And you need to make sure you don't go less than -velocity_x_max when going left, or greater than +velocity_x_max when going right.

script.js: Update the player's velocity using the new variables.

function check_input() { _player.velocity_x = 0; _player.velocity_y = 0; // Left arrow or 'a' to move left. if (_game.keymap[37] || _game.keymap[65]) { _player.velocity_x = -1; _player.velocity_x -= _player.velocity_x_delta; if (_player.velocity_x < -_player.velocity_x_max) { _player.velocity_x = -_player.velocity_x_max; } } // Right arrow or 'd' to move right. if (_game.keymap[39] || _game.keymap[68]) { _player.velocity_x = 1; _player.velocity_x += _player.velocity_x_delta; if (_player.velocity_x > _player.velocity_x_max) { _player.velocity_x = _player.velocity_x_max; } } }

Run your code in a browser and verify that there are no errors.

Try your code now and see what happens.

Yargh! The player keeps moving and it's hard to make it stop.

Hmm.. we should probably fix that.

GOTO 017