because it’s easier.

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.

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:

1. 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.
2. 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.
3. 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.

At least it’s not Destiny 2 where incoming damage is tied to frame rate such that the higher yours is the more damage you take.

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 sychronize somehow. Synchronization can be pretty difficult!

This video might give you a good idea of what’s going on behind the scenes and why things are not trivial to get right: https://youtu.be/yGhfUcPjXuE

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.

Its mostly the game engine, usually.

A big problem with an unlocked framerate is the physics system, which you can generally solve in two ways:

1. 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.
2. 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.

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.

Reminds me of LEGO Island where turning is tied to frame rate.

It can simply engine design to not separate the concept of “game ticks” with framerate.

You can do everything in one swoop such as calculate physics, run NPC AI code, update game state, and render the frame.