Setting the MovingPlatform's Speed about citrus-engine HOT 11 CLOSED

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.

from citrus-engine.

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.

from citrus-engine.

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?

from citrus-engine.

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 (

from citrus-engine.

@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?

from citrus-engine.

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.

from citrus-engine.

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)

from citrus-engine.

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

from citrus-engine.

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?

from citrus-engine.

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 ;)

from citrus-engine.

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

from citrus-engine.