framerate dependant programming on slow pc's?

Physics
1

I’m creating a game as a hobby project, and was thinking about the performance on slower, or very slow, machines.

So, bear with me a moment:
On very slow pcs it could be a possible that the physics framerate (default 50 times per second) isn’t able to keep up. The physics engine is what keeps collisions happening and thus keep things (like the player) in place.

Now, what if the physics framerate drops to such a low point that players can actually walk through objects or walls?
Because most games will be programme fps-independant, a player movement of 10 units will still be 10 units even in these very low physics framerates, thus it’s likely some or all collisions won’t be detected anymore, simeply because they ain’t happening in those few physics steps…

If one wants to publish a webplayer game, with these low performance pc’s and laptops in mind (which there will be plenty of), wouldn’t it be better to program movement in the game framerate dependant when the fps drop too low?
Things would seem to move very slow in case of a sudden slowdown or pc incapable of running the game, but at least it would’t be making faults like going through walls (or worse, the ground). This way even these machines would give a slight impression of what the game could be on a faster machines, in stead of breaking.

Or should I check every movement with raycasts to avoid these problems?

Anyone have any thoughts on this?

2

I’m pretty sure the physics engine already takes that into consideration using raycasts.

And if you want your character to move equally fast on fast/slow pcs’, you’ll just have to use Time.deltaTime.

Example from the reference:

function Update () {
// Move the object 10 meters per second!
var translation = Time.deltaTime * 10;
transform.Translate (0, 0, translation);
}

That’d make the object move at a set speed dependant on how long it took to do the last frame.

3

You should implement a different behaviour of your game for slower CPU/GPUs.15-25 frames per second is the minimum framerate.
Use raycasts instead of triggers/colliders for moving objects.
Disable realtime shadows, pixel shaders (including water), rendertextures etc. if the frame rate drops below the framerate limit.
Changing the quality settings at runtime can effect the performance too.
The user can reduce the screen resolution to improve the performance.
Check the amount of drawcalls per scene and keep them as low as possible.
If you implement all of the above your game will run even on cpus/gpus that aren’t state of the art.

4

The charactercontroller seems to do raycasting in between collision steps to detect missed collision (try moving a charcontroller insanely fast into a collider, it always hits it). Other colliders (triggers, rigidbodies and kinematic rigidbodies) don’t seem to do this and can easily miss a collision.

Indeed, the character should move equally fast on every pc, but as my first post suggests, on pcs which are to slow to keep up with the physics framerate, it’s exactly this framerare independant behaviour (this is what deltatime does) that causes troubles (or so I think)…

5

No, it doesn’t do raycasts unless you specifically call Physics.Raycast.

That doesn’t have anything to do with physics and the fixed timestep.

–Eric

6

What do you mean by “implement a different behaviour of your game for slower CPU/GPUs”?

So it is better to always use raycasts in stead of colliders/triggers?
Because they are harder to implement than colliders. And some situations (lets say a 3rd person character moving in a 3d world) are much harder to implement (if you should check every direction of the character with raycasts, this would get very expensive). It seems impossible to completely rule out colliders.

Disabling certain graphical effects etc is an all round good idea for slower machines, but even this doesn’t guarantee the physics steps will all be executed.
Maybe this only happens one in a million chances and I am worrying about nothing? But I’m not sure. I’d rather have my have run in slowmotion on pc’s which can’t handle the game in stead of having the player walk trough walls, falling through the ground, and breaking the whole game…
Am I

7

Disabling certain cpu or gpu intensive features will automatically increase the frame rate.

The character controller works perfect except you increase it’s speed dramatically.
The general problem with colliders and fast moving objects is that it’s not granted that a collision occurs between 2 frames (frame 1 player is infront of an object, frame 2 player is behind an object because of the players speed). The raycast will always show you the intersection/collision.
As far as I know the FixedUpdate has a higher priority than Update but the desired frame rate for FixedUpdate isn’t granted!

It’s much better to realize that problem instead of ignoring it.
Even if raycasts are harder to handle they are less time consuming than colliders and absolutely accurate.

8

I’m not sure what you mean by “less time consuming”, since you need colliders for raycasts to work. Adding raycasting will therefore always be slower. Also if you’re just raycasting from the object’s transform position, you’re not taking the width of the object into account, which is fine for some things (like small projectiles), but in other cases you’d need multiple raycasts to take the size of the object into account.

In any case, FixedUpdate can run a number of times in a row in an attempt to reach the desired fixed timestep. If the CPU is so overloaded that it can’t run physics 50 times per second (or whatever the rate is set to), then physics will run slower than normal. However, if things are that bad, the game is going to be unplayable anyway.

Unity 3 has the option for continuous collision detection, which avoids the problem completely, but it uses more CPU time compared to the usual method, so should only be used for objects where it’s important to not go through things.

–Eric

9

Correct, if the fixedupdates can’t keep up, the game will probably be impossible to play anyways. But even in this case I think giving the player a slowed down version in better than giving a version in which the player can fall through the ground etc (tunneling effect).

Would it make sense to keep track of the fixedupdates, and once it only gets executed 20 times or so (meaning the cpu can’t handle the game), scale down the timescale so everything with deltatime just moves slower and hence the physics and collisions can keep up?
Or just keep deltatime out of fixedupdates anyhow? (because if the cpu can’t keep up, time should get scaled down, and if it can keep up than the deltatime is a fixed number anyway)

What are the best practices here?
I seem to find a lot about all round optimizations, but none specifically about assuring all collisions etc happen as intented, even on slow machines…

I haven’t heard about this, but will surely look into it. Thanks for mentioning it :wink: