Tilemap + arcade + moving platforms ?

[toto88x]

Hello,

 

I have a working 2D platformer with tilemap and arcade physics. Now I'm trying to add some moving platforms. The platform has a body and is immovable so that the player can collide with it. And I added a looping tween to make the platform move up and down.

 

It's working, except when the platform is moving downward. When that happens, we can see the player constantly "falling" on the platform instead of sticking to it.

 

So how can I make my moving platform works properly?

 

Thanks!

[toto88x]

Any idea how to do this? Thanks!

[j0hnskot]

Could we see a visual example?

[toto88x]

When the player is one the platform, and the platform is moving downward, we can see the player "constantly falling". And it make sense: the platform moves down, so the player starts falling, then he touch the platform, stop falling, and then it starts again.

 

So my question is: how to make the play "stick" to the moving platform? So even if the platform is moving really fast, the player just stays on top of it?

 

Thanks!

[lewster32]

You'll probably need a special condition for this, so that when the player is touching the platform the player's y position is locked to the platform until they jump or stop colliding with it. The implementation of this is up to you, but there's nothing I know of in Phaser to address this specific concern; though Phaser does already have some special code for 'riding' moving platforms in Arcade Physics's World.js:

                else if (!body1.immovable)                {                    body1.y = body1.y - this._overlap;                    body1.velocity.y = this._velocity2 - this._velocity1 * body1.bounce.y;                    //  This is special case code that handles things like horizontal moving platforms you can ride                    if (body2.moves)                    {                        body1.x += body2.x - body2.prev.x;                    }                }

If you think about it, the Physics system is doing what it should do, and what basically happens in real life. If a platform you were stood on suddenly started going down, instantly accelerating to full speed, or moved down faster than gravity was accelerating you, you'd find yourself falling rather than magically 'sticking' to the platform, but this is not expected in games, so the physics systems have to include a special case with platforms. 

[toto88x]

You'll probably need a special condition for this, so that when the player is touching the platform the player's y position is locked to the platform until they jump or stop colliding with it. The implementation of this is up to you, but there's nothing I know of in Phaser to address this specific concern; though Phaser does already have some special code for 'riding' moving platforms in Arcade Physics's World.js:

...

If you think about it, the Physics system is doing what it should do, and what basically happens in real life. If a platform you were stood on suddenly started going down, instantly accelerating to full speed, or moved down faster than gravity was accelerating you, you'd find yourself falling rather than magically 'sticking' to the platform, but this is not expected in games, so the physics systems have to include a special case with platforms. 

 

That make sense, thanks! However, do you have any idea how I could make the player stick to the platform? I don't really know where to start.

[lewster32]

Here's a fiddle I put together which works - but it does have the prerequisite that both the player and platforms have body.moves set to true, and that platforms are moved via velocity and not tweens/direct x/y manipulation: http://jsfiddle.net/lewster32/4yh8ee1f/

 

You'll need to alter your platforms to not use tweens - you'll probably need to remove the bounce settings and put something in place to zero the velocity of the platforms when they reach certain positions, but otherwise you'll have the bouncing and other problems trying to get velocity-moved objects to interact with non-velocity-moved objects.

[toto88x]

Here's a fiddle I put together which works - but it does have the prerequisite that both the player and platforms have body.moves set to true, and that platforms are moved via velocity and not tweens/direct x/y manipulation: http://jsfiddle.net/lewster32/4yh8ee1f/

 

You'll need to alter your platforms to not use tweens - you'll probably need to remove the bounce settings and put something in place to zero the velocity of the platforms when they reach certain positions, but otherwise you'll have the bouncing and other problems trying to get velocity-moved objects to interact with non-velocity-moved objects.

 

Wow, this looks great, thanks a lot!

 

I tried to add a new "bounce" object, where the moving platform should bounce against (instead of bouncing on the world bounds), and it doesn't work. Any idea why? Here the code I added: 

// In the create functionbounce = game.add.sprite(game.world.centerX + 100, game.world.centerY, bouncebmd);game.physics.arcade.enable(bounce);bounce.body.allowGravity = false;bounce.body.immovable = true;// In the update functiongame.physics.arcade.collide(bounce, group);

You can test the code here: http://jsfiddle.net/nhhmjvcc/

 

 

Edit: it works if I remove the platform2.body.immovable = true, but then it's the player collisions that doesn't work anymore http://jsfiddle.net/bewatp3d/

[lewster32]

It's because immovable objects don't generate collisions. If you want to control where the platform starts and stops you'll have to check every frame if they've moved past the bounce point you want to use, and if so, reverse their direction. You'll also need to account for overshoot to stop the platform getting stuck: http://jsfiddle.net/lewster32/nhhmjvcc/1/

[lewster32]

Made it work without timers: http://jsfiddle.net/lewster32/nhhmjvcc/2/

[lewster32]

Ideally you would do this all in an OO way, extending Sprite and making it so so each platform has an orientation ('horizontal' or 'vertical'), an initial velocity for that direction and a maximum and minimum range, then you'd just put this check in the extended object's update function.

[toto88x]

Made it work without timers: http://jsfiddle.net/lewster32/nhhmjvcc/2/

 

This version doesn't really work when the player is on top of the platform, he gets "ejected".

 

Anyway, thanks a lot for your help! I'll try to make that work for my game. Though this won't be easy, since I plan to have multiple platforms with 2 "bounce" object each.

[lewster32]

Yeah just tried it and he gets thrown off, just like you'd expect in reality - I'm afraid that's the tradeoffs you have to make when not using your own physics system! You could add this functionality in at the correct place (preUpdate) but it'll take a little bit of work and some understanding of how the physics works internally.

 

As for the 'two bounce objects' these just represent the x or y ranges the platforms move in, so you'd have a maximum x or y, and a minimum x or y, and when the platform overshoots either value its velocity is reversed. No need to create new sprites or anything, just store those values.

[toto88x]

In the version with timer ( http://jsfiddle.net/lewster32/nhhmjvcc/1/ ) the player doesn't get thrown off. Do you know why?

[lewster32]

Because in the non-timer version I set the position of the platform to the bounce.y position to ensure it doesn't overshoot, which causes a sudden velocity change outside of the standard physics calculations. I think your best bet would be to have a look at the code, it's pretty easy to understand, and it'll maybe give you some inspiration for ways you could make some changes to extended sprites etc.

[toto88x]

Yes, but in the timer version you basically do the same thing: changing the suddently the velocity. But there isn't the  thrown off issue. http://jsfiddle.net/lewster32/nhhmjvcc/1/

[lewster32]

The operative part of that sentence was 'outside of the standard physics calculations' - changing velocity is fine, but as soon as you start telling physics enabled objects exactly where they should be by setting their x and y values, rather than what velocity they have, it changes the calculations and things get funky.