Forums » Help » Acceleration/Deceleration

I'm trying to learn how acceleration and deceleration work. I've read the documentation, but it's not behaving the way I expected it to.

In my code (below), I was surprised I had to use += with the acceleration to get the right effect. Without it, my player inches forward ridiculously slowly, and never gains speed. I thought I just had to declare 600 or -600 acceleration for things to incrementally pick up speed.

Adding the friction property for deceleration seemed to have no effect. I thought setting the friction would be similar to setting gravity. And would start acting upon the player's speed once he stopped accelerating. But I guess that's not quite how it works. Maybe someone can explain.

Thanks!

friction: { x: 600, y: 600 },
maxVel: { x: 500, y: 500 }, // [edit]

update: function() {
	this.parent();
	
	// Keyboard controls
	
	// Move up or down?
	if( ig.input.state('up') ) {
		this.accel.y += -600;
	}
	else if( ig.input.state('down') ) {
		this.accel.y += 600;
	}
	
	// Move left or right?
	if( ig.input.state('left') ) {
		this.accel.x += -600;
	}
	else if( ig.input.state('right') ) {
		this.accel.x += 600;
	}
	
}

Take out the friction, because it's reducing the velocity gained, then set a reasonable maximum velocity in pixels per second, e.g. maxVel { x: 600, y: 600 }

What happens is that over time, vel.x and vel.y will be increased up to the levels defined by the maxVel, at a rate defined by the accel parameters.

Hey Arantor. I tried again what you suggested. I should have mentioned I've had maxVel: { x: 500, y: 500 } set this whole time.

I remove the friction and that's fine (see no difference). I change the += to =, and I get the way-too-slow movement again. Is acceleration supposed to be used with +=? Thanks.

No, just set the acceleration to a discrete value, the internal loop in Impact will do the rest as far as updating the entity's vel parameters, which will update its pos parameters during the entity's update.

Also, put the call to this.parent() at the end of the update method. That way, any change in any given frame will be taken into account that frame, rather than setting it up for the next.

Aha -- issue with the slow movement resolved. The problem was some other code for mouse-click movement. Much better now; sorry for that.

I'm still a little hazy on some things. Currently when I tap a direction button, the player starts speeding up, and continues to even when I'm no longer holding the button down.

Further, at no point does he begin slowing down. Isn't accel supposed to take care of the automatic deceleration, or is there something else I should be setting?

No, friction is normally used for that, but it wasn't clear what you wanted.

If the idea is to get to a dead stop once the key is released, have an extra branch in your if's so that if neither up nor down is pressed, then slow the player down by setting vel.y to 0, and/or the same for left/right/vel.x, and also reset accel at the same time to 0 to make sure the player doesn't keep moving.

If the idea is to gradually speed up and slow down, use accel and set friction to a reasonable level (both the same isn't going to work so well), and I think you'll still need an extra branch to the ifs to reset accel.x/.y to 0 if a key isn't pressed.

Personally what I do now is void using accel entirely for the player and just set vel while the key is pressed and reset it to 0 when it's not, I find that works better for precise moving but it really depends what you're doing.

Alright! It's very nice after following what you said in the third paragraph. And yes, I needed to use the extra branch in my ifs, resetting accel to 0 if no key is pressed.
Much obliged, Arantor.

For anyone reading this looking for an idea, my accel is 300 and my friction is 150. My player is a rolling boulder, so he both gradually speeds up and slows down.

Glad you got it sorted.

Hope I can see that sometime, sounds like it could be a fun game. One word of caution: be careful with your level design - players that can't stop quickly can get quickly irritated.

Thanks for the tip; I've got it noted. I may up the friction yet in light of this.

I'd like to show my progress in the Games section in the near future. Though a big part of me wants to save the first impression for the completed version.

I can see the wisdom of that, because you're wanting to make a good impression. At the same time, depending on the feedback you get, you may decide to go back and overhaul the game (though with Impact, that's generally less of an issue than it might be in other development environments)

What I'd suggest is that when you're happy with it, but not quite 'done' with it, throw it over here and we'll take a look - that way, the cycle of feedback is stuff you can roll in before the 'final' version is done with, if that makes sense.

But in the end, it's when you feel ready for others to take it apart and poke it, however early or late in the cycle that may be.