Setting the MovingPlatform's Speed

[gsynuh]

Hi!

trying to port the box2D MovingPlatform to nape, I came across the fact that setting the speed parameter when creating a moving a platform in a state didn't change its speed. it still went at a max speed of 1.

If the parameter exists, I assumed that we would be able to change it.
My suggestion then would simply be that after normalizing the velocity vector, we'd multiply it by the speed like so :

//box2D version
                if (velocity.Length() > speed / _box2D.scale)
                {
                    //Still has further to go. Normalize the velocity to the max speed
                    velocity.Normalize();
                    velocity.Multiply(speed);
                    
                }

If that actually makes sense.

Unfortunately, this might re-open issue #8 , as with a speed of 2, the platform's friction is countered and the passenger can be thrown off of the platform when the platform suddenly change direction - and the fix in #8 will not work for horizontally moving platforms on box2D but also with nape.

This rises the question of whether or not this should be accepted as a default behavior or not by Citrus Engine, so it should be arbitrarily decided by you @alamboley , since its a "starter kit" .

Is a passenger supposed to stay on a platform, whatever the speed of the platform is (almost like in real life then) or should it drift off if its going too fast
(starting from a speed of 2 with box2D, and around 30 with nape apparently).

The very simple nape Port I have locally suffers from this "drifting off" effect even more than box2D.

I believe that in order to not have this effect going on, some movement calculations may need to be managed more by CitrusEngine other than just letting Nape or box2D do their thing and having CitrusEngine simply fixing things on every frame. for some extreme speed or cases, I know it shouldn't be the starter kit's problem, and devs should handle their extreme cases themselves.

but a speed of 2 is not an extreme case, so I thought asking this question was important, and help going forward.

[alamboley]

Indeed, the speed wasn't applied, I've updated the change.

Well, if our formula applied on #8 was right, we shouldn't have the problem there. Isn't it?

Like @makc said, I think that we don't expect to fall from a MovingPlatform. So we have to correct this problem.

[gsynuh]

I'm afraid we do...
using these settings for example

add(new MovingPlatform("moving", {x:200, y:600, width:140, height:95, startX:220, startY:600, endX:500, endY:600 , speed:2}))
add(new Hero("hero", { x:312, y:450, width:60, height:135 } ))

the hero will drift on every change of direction. and fall off if he is too far right in the first place.
only because the friction no longer negates the speed.

As I've said before, the velocity of the passenger should be relative to the platform, so when on the platform, if we did trace(RelativePassengerVelocity.x) we would get 0 (when he is not moving on it). Unfortunately there is no way to materialize this in code (yet)

And the only way we can truly fix this issue when being only able to change a body's "world" velocity would be to do this on every frame :

for each (passenger in _passengers)
     passenger.SetLinearVelocity(velocity);

AND (because this will mess with movement control) have CitrusEngine have a concept of relative velocity maybe, or the hero should know about what he is standing on, or simply rework the way movement is handled in the Hero's update;
because I can see this code for example

//inside Hero.update()
//Cap velocities
                if (velocity.x « (maxVelocity))
                    velocity.x = maxVelocity;
                else if (velocity.x » (-maxVelocity))
                    velocity.x = -maxVelocity;      

have troubling effects on this Moving Platform issue. Because the maxVelocity when on a moving platform is really maxVelocity + platformvelocity in fact. and that's only an example.

I'm trying to look into this.
I think revising the hero's update (and other entites) that handles movement might be something to go through.
If you can give your thoughts on the entire concept, I'd be glad to help suggest different possible solution, because in the long term, this can become even more hard to work with.

Edit : Hero knows what he is standing on, I forgot about the floor contact, this might be the solution for every possible moving object he could be standing on, whether it be a platform or any other class that has a body and velocity.

[alamboley]

You're absolutely right about the relative velocity.

At the moment, we can know the Hero relative velocity thanks to the getWalkingSpeed method. And we can note that on a moving platform it is eaqual to 0 unless the moving platform changes its direction.

The problem with setting a linear velocity from the moving platform code is that we aren't able to change bodies velocity after, and will lost acceleration speed, ect...

Does the CE should handle that? Finally I don't know, this is physics games. We shouldn't fight against physics behavior. If people want to be able to control everything they should create their own logic. The "simple" package show how to, it needs some works to be able to make a platformer game, but that would be a solution. Using physics you'll know that you're in a complex system and those things aren't easy to handle.
A game like Mario doesn't use physics, because in fact it doesn't really need. It just uses an AABB collision system which is simpler than a physics world.

What is your opinion?

[makc]

you know, if quick hacks do not do it for you, you could fix it "for real". i e have moving platform decelerate/accelerate at <1g in order to change direction. then, certain speeds + distance combinations will make this impossible, so there will be api change required, probably (

[gsynuh]

@makc . what would be the perfect acceleration or deceleration factor, what would be the duration of each phase (acceleration/normal/deceleration) to look ok - and will it look ok for every possible combination if its being pre-calculated? I don't know how this can be implemented other than having more properties added (which is not a problem) but an ease in / ease out effect, as evoked in the other issue, is much more complex than what was first expected from MovingPlatform apparently (at least that's what I understood) .
I understand how this would fix the problem for you, but it seems like a bit complicated for a newcomer that would simply want a simple platform and not have to fiddle with more parameters. This is really a deeper discussion on what CE is, what the starter kit strives to provide.

@alamboley I totally agree that if someone is going to purposefully chose the complex physics engine solution provided with CE, then they should understand that it's not going to be all "strict" like mario, and what appears as a bug, may just be a perfectly normal (and as close to perfect as possible) physical behavior. If it does not fit into their view of how the game should feel then they should change it themselves.

What is important is your point of view on the matter. How far should Citrus Engine intervene in the physics of the starter kit elements or not is your decision, and the Moving Platform problem did a good job at pointing this issue out but in the end it really depends on what you want to provide the user/developer for him to start off with.

What could definately help though, is to look closer at the default physics factor of the starter kit, for a game to feel real, we need gravity, elasticity, friction and velocities to be in some kind of equilibrium so it feels familiar / more like it happened on earth (unless the game happens in space or whatever) . The default values here seem fine at first....

But I think another equilibrium could be found, so it would look exactly the same, but perhaps gravity would be higher, default surface friction would be higher (therefore walking and jumping velocities need to be higher too) but then such a platform, moving at a normal speed -or a bit faster - would not make the hero jump and slide off of the platform.

you know what I mean, making things feel "heavier" may help.

Playing around with those physics factor might change a lot I hope, and Citrus Engine would not need to actually get involved into the physics process at all .

I want to try changing these default values, are they centralised anywhere?

I know that the first time I got my hands on a physics engine, I was not pleased with the movement at all, everything was floating around just a little bit too much, and this idea of finding the perfect "earth physics" equilibrium came up, and maybe that's the only problem.

@makc maybe try changing those values too.

In fact we are focusing on the Engine, but what if it was all because the physics factors were simply a bit off?

[alamboley]

The idea of Eric (CE's original author) was very simple : it's a kit to make a physics platformer game based on Mario.
We shouldn't remove natural physics behavior to clone Mario imho. This kit simply shows how to create CE's objects.
I shouldn't have the final answer, it should be based on what users want. So we could just wait and see if it is a topic which is redundant.

Concerning the gravity, indeed it's a possibility. However I've noticed something very worrying : if it is too strong, it prevents object to sleep and so it will consume lots of cpu. On mobile it can quiclky be a disaster.
That's why the Nape implementation is more "flying" than the Box2D one.

You can quicky change the gravity of a world :

var box2D:Box2D = new Box2D("box2D", {gravity:new b2Vec2(0, 50)});
box2D.gravity = new b2Vec2(0, 50);

On a Box2DPhysicsObject, you will see its color (using the debug view) will stay pink and not become grey.

[gsynuh]

May I ask if there was a specific reason why the port of MovingPlatform to nape was never done or included?

(I'm not requesting it, I currently have what seems to be a working port, locally, but I've got issues with it and maybe they can relate to why it wasn't done yet)

[alamboley]

No reason, I just didn't have time to work on it. Don't hesitate to make a push pull request ;)

[gsynuh]

Actually, if I want to work on CE and suggest things with push and pull, do I need to fork first or is there any other way?

[alamboley]

Also we may contact on skype if you want. It could be easier to chat in French. Just drop me a mail if you're interested ;)

[alamboley]

Yes, from my Git's knowledge, you have to fork.