koobas.hobune.stream
Physics acting different in build than in editor
Player movement script:
void Update()
{
if (player.GetButton("start") && fire.gameState == 0)
{
fire.startButton();
restart = true;
fire.gameState = 1;
}
if (player.GetButton("Right"))
right = true;
else
right = false;
if (player.GetButton("Left"))
left = true;
else
left = false;
if (player.GetButton("Down"))
down = true;
else
down = false;
if (player.GetButton("Up"))
up = true;
else
up = false;
}
void FixedUpdate()
{
if(fire.gameState == 1)
if (right)
{
direction = 1;
transform.position = new Vector2(transform.position.x + speed * Time.deltaTime, transform.position.y);
}
else if (left)
{
direction = 3;
transform.position = new Vector2(transform.position.x - speed * Time.deltaTime, transform.position.y);
}
else if (up)
{
direction = 0;
transform.position = new Vector2(transform.position.x, transform.position.y + speed * Time.deltaTime);
}
else if (down)
{
direction = 2;
transform.position = new Vector2(transform.position.x, transform.position.y - speed * Time.deltaTime);
}
}
The boulders just have a rigidbody 2D and polygon collider.
Editor mode: https://youtu.be/WR0aCkjmI-M Build mode: https://youtu.be/_cZXtBaO04I
As you can see, physics is acting different, you can easily go past the boulders in build mode but not in edit mode. Where does that come from?
In your fixed update it seems you are missing a pair of curly brackets for the very first if statement. Also please make sure your code is properly tabbed for easy debugging for anyone giving answers. Is this line important: if(fire.gameState == 1) in your fixed update? If it is then it needs to be properly bracketed.
Thanks for pointing that out, it is a mistake, although not related to this problem.
The problem that you have here is that you multiply all your movement values by Time.deltaTime. Time.deltaTime is not needed here since you are in fixed update. Fixed update always takes place in the same timely distance. So while there always is a FixedUpdate in a interval of 0.02seconds (that is the default i think - look that up in your project physics settings) Time.deltaTime is framerate dependent. So when you build your game an Update takes less time so there are more Update calls between each FixedUpdate than in the Editor.
To keep the correct timescale i'd recommend to use Time.fixedDeltaTime here.
I replaced it with Time.fixedDeltaTime but there's no change in the physics behaviour.
When Time.deltaTime is read during FixedUpdate(), it's automatically converted to/treated as Time.fixedDeltaTime. Additionally, when modifying positions directly (transform.position) to simulate movement over time, you *DO* want to make use of that scaling to make it framerate-independent.
When you want proper physics interactivity, though, transform.position will just teleport past colliders. The exact equivalent with proper physics interactions would be Rigidbody.MovePosition(), but I think there are more fundamental underlying problems here in general.
I don't want proper physics interactivity, though, as i am happy with how it works in the editor, and i know there are plenty of games successfully using 'transform.position' in various mechanics. The problem is the lack of consistency for these interactions between the editor and the build.
