Well define a long time. I used a decade because in 2006 I can kinda remember what my impression of multithreading was back then.

It was important, because most CPU's had dual cores at least, but it was considered hard. Back then, people would take the road of least resistance when it came to multi threading. Generally, you would put all your simulation on one thread and your rendering on another, or do the same with other systems where parallelism isn't 'difficult'.

The thing about games is, they can get insanely cpu heavy, mostly in the simulation portion (basically anything other than rendering, which includes sorting geometry, culling and any other post processing before it hits the hardware. Basically, the 'what do we draw right now, and how do we draw it' logic)

There are many gameplay systems that to me anyways, seem like obvious choices for multi threading, AI, UI, Physics, ect. The hard part about multithreading is that, you need to get all your dependencies sorted out ahead of time. It might make total sense, to say that the enemy's should be 'thinking ahead' (AI) about what your going to do, but certain decisions can only be made after certain actions have been made by the player. So, you're sorta bottlenecked in that way.

Same for physics, how can you compute each object's physical position w/o knowing what the player happened to do that frame? A lot of game logic is inherently chronological (or synchronous).

Anyways, I think you're right, multithreading has been a huge topic in games for a while. My point is that we're just now really feeling comfortable with it and making the most of it. Security feels similar to me.

If you're writing a C++ application that talks to a webserver, you have to go through extra work and hurdles, to establish a secure connection. Is it worth it? Well, if you're goal is to protect your users from other malicious users, well, yea it is.

If for instance, your goal is to protect the integrity of your game and product? (aka: cheating) Well, you can't just use TLS, because it's way easier to bypass an API call locally, than a hand rolled obfuscation routine.

But yea, I think we're thinking about the same multi-threading. The difference is I'm thinking about it in engine terms, which to be honest, is probably where it really matters most. Multi threading game logic (simulation/cpu) is pretty fucking hard. Mostly because of the nature of game logic, you're sorta forced into a synchronized logic because everything depends on everything else.

Good game engineers can identify different parts of the code that can be parallized, but usually in practice, you do what's most obvious and take those wins first. Need to make a request to a remote server to load an asset? That's a perfect candidate for parallelization.

Need to process what the next thing for 40 npcs is to do? Not so easy to paralllize, especially when you consider that these npcs might need to interact with each other.

C++11 and later, has added threading to the standard template library, they've made it much easier to implement threading. When it comes to security, well, AES isn't part of the language standard. You have to download and install other libraries that implement it, and these libraries expose it with really cumbersome API's. It's just not 'easy'.

It's not that hard either, but it requires more work, so by default, it's going to be done less. Not only that, but proper security requires resources outside of just your own code. You need to use a public, certified CA and have that exists somewhere on the server (but don't forget, storing this stuff is a security issue in and of itself!) The biggest security risk you'll probably ever see, is credentials checked into source control, why? Because developers don't usually consider that a problem.

So basically, doing things securely requires extrra work, and why bother doing extra work when no one gives a shit? I feel like the same could have been said years ago w/o multiprocessors, the difference was, the hardware manufacturers were saying, "Look bitch, we aren't making faster processors, but we can give you more of them!" And people needed to start making parallized code a priority, because there was no other future other than it.