2D Platformers, Physics and Timing

Unity Engine
1

I am building a small 2D platformer using rigid-bodies for character movement and I have several related questions about how best to approach things.

First off is what is considered correct in terms of what should go in Update() and what should go in FixedUpdate() when scripting rigid-bodies?

Here’s a simplified version of what I’m currently doing - which I understand should give me consistent behavior regardless of frame rate. I collect the inputs and store them in a variable in Update() (so I don’t miss them), then apply that input on FixedUpdate() - is this “correct”.

public class Character : MonoBehaviour 
{
	
	Vector3 totalForces = Vector3.zero;

        float walkSpeed = 10f;
	float gravity = -10f;


	void Update () 
	{
		float walkDelta = (Input.GetAxisRaw("Horizontal") * walkSpeed) - rigidbody.velocity.x;
		totalForces.x += walkDelta * Time.deltaTime;

		totalForces.y += gravity * Time.deltaTime;
	}
	
	
	void FixedUpdate()
	{
		rigidbody.AddForce(totalForces, ForceMode.Acceleration);
		totalForces = Vector3.zero;
	}
}

Secondly is the setting of the fixedDeltaTime variable. I understand for performance reasons you want to tweak this value so it as high as you can get away with so FixedUpdate is called less often.

Doing this however alters the rate at which my characters move. This would be a pain if I decide change the value of fixedDeltaTime during development. This also leads me to believe my approach to adding forces is not right.

Thirdly - the thing that is bugging me the most is that when collisions are being resolved the colliders will often pop into the level geometry and pop out again. I know PhysX uses a penalty force mechanism and this is a result of the renderer updating whilst the collision is being resolved. Using continuous detection doesn’t resolve this, the only thing does is increasing the physics frame rate to be larger than the update frame rate. I’m sure its a bad idea to do this especially when everything else physics related works fine running at 50fps.

Thanks for any help.

2

  1. In this instance having the variable collection in the FixedUpdate would not be a problem. Only 1 person can actually press the keys. This would become an issue if you have, say 1000 AI units and all of them trying to make adjustments in the fixed update. For that matter, I would make all the player’s commands FixedUpdate and all AI commands either Update or on a separate plan (Coroutines)

  2. I would not use the fixedDeltaTime variable. It is not necessary in most events.

  3. This is not generally an issue until you get into large object counts or extremely detailed collision models.

Since all of these are performance related, I would suggest tailoring your performance levels to where they are not so heavy. If you want 100 objects in the scene, perhaps object management or other means of helping your processor out would help. Not everything has to be physics controlled. :wink:

3

Thanks for the input.

1 - Yep makes sense.

2 - I would normally agree but…

3 - This happens with just 2 primitive colliders on sceen and the only way to fix it is to reduce the fixed update interval. For example if my 2D character jumps onto a platform it will noticeably pop into the platform and back out again. By increasing the number of physics updates im guessing the collision gets fully resolved before the next draw update and you dont see the pop in. On npc’s I wouldn’t mind but on the player character this is very obvious once you’ve notice it.

I know physics engines aren’t meant to delivery realistic character physics but apart from this issue everything else works really well.
I can’t use the character controller due as it limitations on things like gravity flipping, floor alignment etc.

I guess my real question is should I just set my physics update to 60fps and stop worrying about it - or will it come and bite me in the ass later?

I’ve tried the box2D/farseer physics port and it doesn’t have the pop in issue even when the physics is set to 30fps. However it would be a lot of work to tie in raycasts, triggers etc that you get with built in PhysX physics so I’d prefer avoid that - or even worse roll my own tile based physics.