[jQueryIsAwesome]

The point being that it doesn't matter if you believe people will not play the game because game performance; if they really like it the will ignore it. And if they paid for your game you should at least try to give them an experience as good as possible.

[Garoof]

I'd say it's still fair to point out that you chose a game where framerate is particularly unimportant to begin with.

Like, you probably would believe the amount of people playing Quake Live at 7 fps.

[pfisch]

All games have minimum requirements.

[jQueryIsAwesome]

Yeah, in the perfect world all your buyers will have them. In real life sometimes don't.

Plus there is a lot of things you don't know; maybe he haves the minimum requirements but he is running a lot of background process because he installed a bunch of things he doesn't use.

[pfisch]

If the game is so bogged down that the fixed timestep cycle is slowing down the game is broken for so many other reasons. Objects will start tunneling through other objects.

[jQueryIsAwesome]

Changing the discussion from conceptual to technical making assumptions in the latter just to win an argument. I like that.

[pfisch]

No I am just being realistic as an actual game developer. This is not a conceptual discussion. It doesn't make any sense to implement this change because if your fixed timestep for the physics system is breaking down then gravity not calculating correctly is the least of your problems. The controls would be unresponsive if the dt became large anyway. You are talking about more than doubling the number of operations for all acceleration based movement which is just about every movement and applied force in the game. If you thought the framerate was hurting before because too many objects were on screen doubling the physics calculations is not going to help you out. It might not hurt that bad but it really depends, you would need to profile it. It doesn't matter though because the tunneling would be another bigger issue that you would also have to address for this to even matter, and that would definitely hurt bad to check for.

During the far majority of use cases the timestep is fine, and you are just creating deadweight by doing this. Plus I guess you are now doing tunneling checks as well to create further deadweight for the rare occasion when someone has framerate issues.

I am looking at this in the sense that I would actually implement this in a game I make, and I would not because the upside of doing this is basically "if the game is already fucked I want it to be maybe not as fucked but still having many other big issues with pretty much every other component of the game logic", vs a bunch of deadweight when the game is running correctly, which should be 99.5% of use cases.

Am I adding assumptions here? I guess so but they are real ones for real game developers. Unless you are doing something very unusual these would be your concerns.

This is not an academic exercise for me like it maybe is for you and most of the commenters it seems like.

[jQueryIsAwesome]

> the game is unplayably choppy anyway so it doesn't even matter.

My point originally was about this statement of yours, that is purely conceptual and you skew the discussion to address the other part of your comment (or you through that was the point but didn't explain so in your answers)

But anyway, one assumption is that every game should have a fixed gamestep, in many single player games (real single player games) you don't want to do that, because is preferable that the user can see the ball coming to the player than to magically appear behind the player even if that is "timely correct"; the ball/interface going slow is a lot less frustrating that losing without realizing why. Platformers for PC with (virtual) high speed movements come to mind as a common example of this.

Even multiplayer games suffer of this; in most online FPS if the server suddenly slows down all the players start experiencing lag and everyone looks like they are "teleporting"; with a not-fixed-timestep you could slow everyone down so the problem becomes a lot less frustrating because the player still have complete control and understanding of their in-game character; just a bit slow-mo until the server speeds up to normal. The teleporting should be used only to sync with the server when the client connection is the one with problems updating.