Hi,
After weeks of trying to resolve this issue, I still have instances of my game character falling through the floor. I understand this happens when the collision happens in between frames, if the player experiences a frame drop due to limited cpu resources, is this problem unavoidable? Is a low frame rate the only thing that could cause this?
I’ve tried:
my game:
If you’re using fixed-step Arcade Physics (the default) I don’t think frame dropping could cause the problem.
It can happen if velocities are very large or the bodies/tiles are very small. But that doesn’t look like the case in your game, unless the ground is very thin.
It can also happen if you place bodies directly overlapping each other, especially with zero velocity.
When do you see the problem?
I have arcade physics and fixedStep set to false. When it was set as true, all the movement was super choppy. The ground at its thinnest is 32 pixels.
Sorry I should have clarified, it happens randomly when the player is airborne, either jumps or gets hit and is falling, then when they should land on the ground, they fall through it. They don’t fall through after standing or running.
I haven’t been able to re-create the issue in a long time, but a user in my comments said it happened and I believe them because I used to see it a lot. Setting the tileBias seemed to make it stop for me, but I guess it’s still happening.
Hello!
I’m actually experiencing a similar problem. When my game falls to 30fps or lower, my platform character occasionally falls through my 16px tile floor. This happens when the character falls onto the floor, or jumps onto it. So, my guess is that its velocity is too high, and overshoots the 16px bounding box.
So I have a few questions for any experienced users about this:
Is it possible fix the physics timestep at 60, even if the fps falls to 30. (Or, are they linked? I have fixedTimestep set to true, which seems to lock the physics update to the fps)
Is it possible to increase the collision bias? I noticed there’s a collisionBias option in the arcade physics config, but setting this ether higher or lower than 4 seems to make no difference. Does anyone have an idea of exactly that this does? (Have read the docs, but I’m still not sure: Phaser 3 API Documentation - Class: World) What kind of numbers would I need to test to see an effect?
Thanks!
The physics step size is fixed by default. It’s variable only if you set fixedStep: false in the physics config or this.physics.world.fixedStep = false.
So if you have fixed step on (the default) I don’t think a low frame rate by itself should cause a separation failure. There may be something else going on, maybe in your scene update() or collision callbacks.
You can increase tileBias (for sprite vs. tile) or overlapBias (for sprite vs. sprite) in the physics config. I would start by doubling the value.
Yes, the (default) fixed time step is exactly what prevents these problems. If fixedStep is false, the physics engine will use the render FPS, which can make it behave unpredictably.
Keep in mind that physics engines tend to break if run at a low enough FPS (I don’t think there’s an exact way to quantify it). Arcade runs well at 60 FPS, but that’s not always enough in certain cases. With a variable time step, you have no control over the FPS of the engine, so you also can’t control whether it works correctly.
That’s a good idea, and it reminded me to ask something. Is your collision handled by colliders (physics.add.collider) or do you check for collision manually in update() (with physics.collide)? Colliders will use the physics FPS, preventing these problems if the engine uses a sufficiently fast fixed time step. Manual updates use the render FPS, which can cause problems if it doesn’t quite sync up with the physics FPS.
If your physics run with a fixed time step, you’re using colliders, and the bias options samme suggested doesn’t help, you can also try to increase the physics FPS.
@samme and @Telinc1 Thanks both so much for your helpful and detailed replies! I’m busy doing some more testing based on your feedback and will report back soon! 
Just one question for you @Telinc1, how can I increase the “physics FPS”? (is this different to the fps property in the config?)
@samme @Telinc1 I’ve run some more tests and have an update on this:
My physics config looks like this:
physics: {
default: "arcade",
arcade: {
gravity: { y: 2000 },
debug: false,
overlapBias: 8,
tileBias: 32,
fps: 60,
fixedStep: true
}
},
If the game’s rendering fps is between 40-60fps, all is well, no fall though. If on a slow machine the rendering fps drops to around 30, floor collisions can be missed, and the game character falls through the floor.
But, my understanding of fixedStep: true is that the physics timestep should remain locked at 60fps, even though the render fps falls below that. If that’s correct, it doesn’t seem to be working in my case for some reason.
@Telinc1 Just confirming that my collisions are handled by colliders (physics.add.collider), which, if I understand correctly, should sync with the physics fps. However, my colliders do reference sprite properties (x and y) that are mutated in the scene update - I wonder if that could be throwing it off? If that’s the possibly a problem (?), is there some way to force the scene update to sync with the physics update?
I also can confirm that setting collisionBias to any number seems to have no effect on collisions in any way that I’ve noticed.
Make sure you’re not modifying physics sprite positions (sprite.x, sprite.y) in scene update() or collision callbacks. You should modify only body.x and body.y, if needed.
I never found a resolution to this issue, players still say the character falls through. I’ve read the thread multiple times, and it sounds like the solution is to make sure not to have fixedStep=false. However, when I remove that, the game becomes very choppy and stuttery, the player is constantly shifting all around when he should be standing still.
I can’t set it to true due to falling through the floor, and can’t set it to false due to stuttery movement. Can there even be a solution to a problem like this?
It seems abnormal even for low FPS, unless the velocities are huge.
I tried the game with { fixedStep: true, fps: 60 } and I didn’t see any of that. It seemed to run normally. I also tried it with { fps: 5 } and the character fell through the floor.
So you might try something like { fixedStep: true, fps: 300 } to see if it removes the stuttering on your machine.
I just want to verify having had this same issue for more than a year, and having read and tried every suggested solution on the net, my sprites still fell through the floor maybe one out of 100 times on lower frame rates.
Our team ended up writing a custom platforming engine which solves this - but it was a lot of work.
If have fixedStep turned off, there’s one more thing you can try — increase the fps.min value in the game config.
I’ve been having similar issues and what worked for me, oddly enough was decreasing the fps from 60 to 30. Can anyone explain that?