Let’s say you don’t tie game mechanics to frame rate. How often should you update the state of the game? 50 times / second? 100 times / second? You need to pick a fixed rate if you want to keep the physics engine consistent. If you make the rate too high the game will not run on low-end machines, so you need to find the right balance.
But let’s say you make it 100 times / second. Now between those updates, nothing changes. You can render at 500 FPS, but you’ll be rendering the same thing five times before anything changes, so the extra frames are useless. There are ways around this. You could perform interpolation of object positions between the previous state and the new state (but this introduces input lag). You can keep things that don’t affect gameplay (e.g. eye-candy animations) running at the full FPS. But none of these things are trivially obvious. So it becomes a question of ambition, competence, and the will to put time (i.e. investor’s money) into it. Hence many projects simply prioritize other things.
Damned if I know. It's possibly the stupidest decision I've ever seen in a big name game. But yeah sometimes you'll be walking around and just all of a sudden get obliterated out of nowhere and it was because you got mapped by an NPC rocket with damage tied to frame rate. There's YouTube videos of people proving it works this way iirc; I know people used to post testing videos on R.
I don’t know this specific case, but my guess is that damage is a set amount per frame that a collision overlap is happening. This is perfectly valid if it is biased by the delta between frames. It means things get a little wonky at low framerates, but largely work well. But if you are assuming a frame is an exact length, you save a multiplication action, but gain the problem of unlocked frame rates breaking things (and frame dipping possibly causing problems).
In the past, games were developed with specific hardware in mind. They didn't really think of how their game would run on modern PCs 25+ years later. Some games even used that as a feature, famously, Space Invaders devs noticed that the game started speeding up as players destroyed more of the enemies because it didn't have to render them and so it made the game harder as you progressed which was more fun!
By the way, there are ways to run retro games with speed limiters, you've just got to look into it more.
A big problem with an unlocked framerate is the physics system, which you can generally solve in two ways:
You tie the physics to the framerate. Problem is that this introduces all sorts of weird behavior, caused by rounding errors and frequency of collision checks. For example, objects could start glitching through thin walls if their framerate is low because collisions are checked less often.
You run the physics at a fixed internal interval. This solves a lot of problem with the first approach, but also means that you have to put in effort to mask the fixed framerate through interpolation/extrapolation if you still want to keep the actual framerate unlocked.
So Wolfenstein New Order probably went with the first approach, made sure their physics system stays stable within a certain FPS range (30-60), and then locked the FPS beyond that.
You have one “frame” where you just do everything: read the player input, do whatever actions, calculate collisions and physics and whatever, and draw everything when all those calculations are done.
Then you move on to the next frame and do everything again. Everything lines up all the time and always happen in the same order. Simple, quick, and consistent.
To decouple calculations and framerate, you don’t know when the game will try to draw something. It might be in the middle of when you’re calculating collisions, or moving the units, or calculating physics. Or you might end up doing multiple calculations while the GPU is slow and can’t draw anything.
So you have to add an extra layer in between, probably saved to some memory somewhere. Now every time the GPU draws something, it has to access that memory. Every time you calculate something, you also access that memory. Let’s hope they DON’T try to read and write on the same spot at the same time, that could cause bugs. And so much memory access, you’ve basically doubled your memory bandwidth requirements.
It’s complicated, more resource intensive, and introduces potential bugs.
And not just easier, but cheaper. On lower end platforms it’s expensive to do floating point calculations all over the place because you don’t know how long it’s been since the last frame. If you can assume the frame rate, you can get a lot of performance back too.
Because it’s easier to programm a single thread that executes a sequence of commands like [ update-gamelogic, update-graphics, etc. ] instead of at least 2 threads (for gamelogic and graphics) that you have to synchronize somehow. Synchronization can be pretty difficult!
Tying game logic to the framerate doesn’t really have anything to do with single- vs multi-threading. You can properly calculate the time since the last update in a single-threaded engine.
If the game loop doesn’t run at the same speed as the render loop you’ll get ‘tearing’ - some game objects are at the latest state, some are not. That can cause some funky bugs.
From my understanding, tearing can occur even if the game logic and render command submission happen on a single thread, since it’s a consequence of the OS compositor sending buffers to the monitor in the middle of rendering.
correct, but now you’ve just identified two separate types of tearing, both happening at different times. put them together and the perceived frequency will be significantly worse than it was prior.
being able to zero one of those out and only worry about the other means you can hopefully optimize a better solution - as much as one can when you can’t realistically atomically update the entire display from top to bottom.
Not a game dev but I’ve done some programming and I love games so I’ll take a stab. There’s a few reasons I can think of:
That’s how the engine they’re using works. Game engines take a long time to develop, and so if you’re using one off the shelf or from a previous project, it may be from a time when tying behavior to the frame rate was a low overhead tool for timing that would cause few if any issues. Given that Wolfenstein is a Bethesda title and they’ve made many games with similar engine level limitations, this seems most likely to me for this particular case.
They never intended to release it that way, and just set it up that way early in development to start getting to the real gameplay work. Then the deadline came around and it wasn’t a high priority in terms of getting the game out the door.
Probably doesn’t apply to Wolfenstein, but for indie games that have one or only a few developers, none of those people may have done much programming before, instead being more focused on other aspects of game design. So if you’re learning as you go, there’s a good chance some hacky things will make it in to the final product.
Wolfenstein New Order was made by Machine games and used ID Tech 5, same as Doom 2016. Nothing to do with Bethesda or their Creation Engine. Bethesda only published it.
I suppose that’s what I get for just doing a quick google 🙃
That is really interesting though, my understanding is that Doom 2016 is known for running pretty well and achieving high framerates, or at least that was the sense I got from tech youtube when I watching that more. I wonder what the devs were doing in that case.
Add comment