-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting the MovingPlatform's Speed #12
Comments
I'm afraid we do... 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. 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; //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. 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. |
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. What is your opinion? |
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 ( |
@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) . @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? |
The idea of Eric (CE's original author) was very simple : it's a kit to make a physics platformer game based on Mario. 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. You can quicky change the gravity of a world : var box2D:Box2D = new Box2D("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. |
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) |
No reason, I just didn't have time to work on it. Don't hesitate to make a push pull request ;) |
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? |
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 ;) |
Yes, from my Git's knowledge, you have to fork. |
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 :
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.
The text was updated successfully, but these errors were encountered: