So, I've been working on a 2D side-scrolling platform game and I'm a little unsatisfied with the way I handle jumping characters. Currently, jumping is essentially just adding a given amount to the Y-component of velocity. The problem is that this method only affects the jumping character, without applying a force in the opposite direction. I'd like jumping to behave a little more realistically, such that, a character standing on a see-saw (assume he/she is on the end lifted off of the ground), for example, would jump less far because the force applied would push the see-saw toward the ground in addition to propelling the character upward.

I'm not sure if that made any sense. I hope it did.

So, I was watching David Rosen's talk on animation and got an idea: using two circles to represent the character, stacked vertically but overlapping (similar to what is seen at about 4 minutes in that video I linked to), and applying a downward force on the bottom circle (assuming the circles are attached by a sort of spring) should, hypothetically create the scenario that I'm looking for.

So, I'm planning on prototyping this method in the next few days, but I was wondering if I'm over-thinking this. Is there a simpler way of handling this situation? Is there a better way of handling this problem? Have you done anything like this?

Well in reality when you jump there's a normal force along with the force exerted by the jump. In a physics engine you can simulate this kind of thing by applying equal and opposite forces on the player and whatever they are standing on. You can just see if the player is standing on something, if they are then take your jump force and apply it to both the player and the object it's standing on.

You need to take a weighted distribution:

Vec3 jumpForce = GetPlayerJumpForce( );
float massSum = massPlayer + massStandingObject;
player.velocity += IntegrateForce( jumpForce / massSum * massPlayer, dt );
standingObject.velocity -= IntegrateForce( jumpForce / massSum * massStandingObject, dt );

This pseudo code is just dealing with linear motion, but you can easily add in rotational dynamics by applying the force at a specific point on the rigid body.

To get more realistic you'd need to simulate the joints of legs and have the various bones of the body apply forces, this way you can apply a force over time that is correct for a jump animation. I'm sure you can see how much more work this sort of thing is.

You can solve only the position instead of position and velocity in the collision resolution phase.

Another way is to set a X coefficient of restitution, so the object that moves won't be able to fly around the world.

If you're using a physics library, the physics object should already have collision flags such: CF_NO_CONTACT_RESPONSE, CF_STATIC_OBJECT, etc. that act as a helper in the physics simulation.

Vec3 jumpForce = GetPlayerJumpForce( );
float massSum = massPlayer + massStandingObject;
player.velocity += IntegrateForce( jumpForce / massSum * massPlayer, dt );
standingObject.velocity -= IntegrateForce( jumpForce / massSum * massStandingObject, dt );

Yes, but try to not change directly the velocity of the object to avoid a unstable physics simulation. Some physics libraries uses momentum as the last state of the object, so applying a force instead of chaning directly may be a good idea. Use a fixed-time-step, compute a force (torque if it's a rotational force) — maybe the point of application of the force too — and apply to the object, so in the next frame the state of the object will be integrated by the time step. BTW if you're using a physics library I believe it has already some kind of function like X::ApplyForce(...) or something, so you may use that.

Thanks for the responses folks. I guess I just figured that handling it that way would utilize the physics that I've already implemented instead of tacking on specific-case code.

Just to be clear, modifying the velocity yourself is usually the preferred way to implement character controllers! So there's no harm in modifying velocity instead of applying a force, since a applying a force will be integrated into a velocity anyway.

Just to be clear, modifying the velocity yourself is usually the preferred way to implement character controllers! So there's no harm in modifying velocity instead of applying a force, since a applying a force will be integrated into a velocity anyway.

Applying force\torque instead of changing directly the state of the object is the preferred way because is the only place that interfacing with the rigid body makes sense.

All rigid bodies are integrated in each fixed-time step logical tick of the game. So, why calculate the integrated velocity when you can set the accumulated force in one tick, integrate, clear forces, and start over and over again?

It is true that if you're not accumulating the force in the rigid body, the only way to change that is the way you said, but almost every physics libraries have this kind of properties available to facilitate the interfacing, contact resolution, debuging, etc. Looks like you're using an physics object to represent the intermediate movement generator, so maybe this apply to that.

For an high-level object such a game entity, you can do whatever you want with its spatial data, but the best way of keep the simulation stable all time in a low-level physics library is to not do that, and instead search for collision flags, modify the total force of the object, etc. I believe David Baraff said that in one of his papers of not changing the velocity, etc. but I've forgot all my links.

You're right if you want a force correct velocity, but usually with character controllers and whatnot you just want, as a game designer, specific velocities. This is where you'd just manually set your velocity. But for this topic specifically you're also probably right, since the original poster sounded like he wanted a force correct jump.

Thanks again. I'm using my own physics-code, and it works pretty well and runs relatively quickly. It sounds like the trade-off between continuing along my original plan and executing a change-of-velocity is really just the amount of control I have over this from a design standpoint. I'm currently using a limited version of the velocity-method that you suggested, Randy, so at least I know I can fall back on that if the other method doesn't work out like I hope.