Whenever I start the unity editor and play it in the Game windows, sometimes the object can jump higher sometimes it is just small jump. I didn't change any value in my script nor changed it in inspector window.

It usually happens when I restart the unity editor or having my computer shutdown / restart and reopening the project.

Here are the jump code

void jump() {
     if (isInGround) {
         float currentJumpForce = jumpForce * Mathf.Abs(rigidBody.velocity.x) / 3.53f;
         rigidBody.AddForce(Vector2.up * currentJumpForce);

I place the code inside the FixedUpdate method, for what I have read the physics calculation should be inside FixedUpdate right?

private void FixedUpdate() {
    if (Input.GetKeyDown(KeyCode.UpArrow)) {

I have read many are having similar problem, but it really doesn't answer this question.


I forget to explain it in the question. The jumpForce is calculated based on the velocity of the gameObject has. I capped the velocity to certain speed based on this code

void accelerate() {
     if (rigidBody.velocity.x <= maxSpeed) {
         rigidBody.AddForce(Vector2.right * acceletateForce);

where maxSpeed is a constant. I know this is probably not the accurate way to cap the velocity, or is it? Maybe this is where it gets messed up?

I just kinda assume the velocity is the capped from the camera movement and the 'display' or the movement of the screen. It seems the same to me.

  • \$\begingroup\$ Seems like currentJumpForce calculation depends on rigidBody.velocity.x, which means the faster the object is moving to the +x or -x axis, the higher the object will jump. Is there a reason for this? Is it a game feature? \$\endgroup\$
    – TomTsagk
    Aug 22, 2018 at 13:10
  • \$\begingroup\$ @TomTsagk yes it is indeed a feature. I'm sorry for not explaining that before. But I'm sure I had capped the velocity to certain speed, and when I tested it when it reached it's limit. I'll try to update the question then \$\endgroup\$
    – otong
    Aug 22, 2018 at 15:11

1 Answer 1


Physics calculations should indeed be in the FixedUpdate. However, Input should be captured in the Update. This is because the FixedUpdate is called whenever the physics engine updates, while Update is called whenever the screen updates. You can thus have more than one call to FixedUpdate in the frame where the user pressed the key.

There are two options to solve this. First, call the jump function in the Update function, which works, though not entirely correct. Or set a flag in the Update and call the Jump function in FixedUpdate.

See also this

  • \$\begingroup\$ Setting a flag in update then acting on it in FixedUpdate can introduce an unnecessary frame of latency, since Update happens after FixedUpdate, we'll have to wait till next frame at the earliest before the flag is read & acted upon. Myself, I prefer to do the opposite: check for input in both FixedUpdate & Update, and set a flag once one or the other has acted on the input, so that we don't double-dip and handle the same input twice. \$\endgroup\$
    – DMGregory
    Aug 22, 2018 at 11:10
  • \$\begingroup\$ That works too. I was going off the linked answer. I tend to do all my logic in Update, but at the same time, I tend not to be using Unity's Physics in the first place. \$\endgroup\$ Aug 22, 2018 at 11:57
  • \$\begingroup\$ @ImperialJustinian can you explain or have a link why you tend to not use the Unity Physics? is it that bad? \$\endgroup\$
    – otong
    Aug 22, 2018 at 15:30
  • \$\begingroup\$ The main games I make as a hobby are roguelikes, and movement is all based on tilemaps. In addition, movement and the like is more turn based than real time. When I said do logic in Update, I meant "When it happens in an update function". And no, its not bad. Unity is a tool. In my opinion there is no real "right" way to use Unity. There are ways where it is not recommended or advised though. \$\endgroup\$ Aug 22, 2018 at 15:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .