When I was young there were a few luminaries in the software world who talked about how there is a steady if small flow of ideas from video game design into conventional software.
But I haven't heard anyone talk like that in quite sometime (unless it's me parroting them). Which is quite unfortunate.
I think for example if someone from the old guard of Blizzard were to write a book or at least a novella that described how the plugin system for World of Warcraft functioned, particularly during the first ten years, where it broke, how they hardened it over time, and how the process worked of backporting features from plugins into the core library...
I think that would be a substantial net benefit to the greater software community.
Far too many ecosystems make ham-fisted, half-assed, hair-brained plugin systems. And the vast majority can be consistently described by at least two of the three.
I’ve been of the opinion that every hard problem in CS shows up somewhere in gamedev. It’s a great space for inspo.
Game dev also rewards people for applying the 80/29 rule effectively and you see less of that in commercial software.
In each game generation there’s a game that would be easy to write on the next or subsequent generation of hardware and is damned difficult to implement on the current one. Cleverness and outright cheating make it work, after all fashion.
80/29 rule is the paretypo principle?
Typo but yeah.
It reaches a dead end eventually. That's where we are, edge of speed, where the only mods left are aesthetics veering at photorealism.
The game simulation will get more detailed/granular as aesthetics dial down in perceived value. You can always go bigger/wider/more procedural/more multiplayer.
This is also why every hard problem eventually shows up — games are just simulation + interaction, and eventually everything that can be simulated will have some attempted implementation out there, struggling along. (For some reason, this does not appear to stop at “interesting” things to simulate — see all the literal simulators on steam)
The simulations have yet to release photo-realism in lieu of event-perception, where simulation parallels reality, but that's not really playable as a game, only as a view.
My team's approach is game dev is probably for the hard problems in reality, behavior, ecology, language.
I came to learn that even though in process plugins are easier to implement, and less resource demanding, anyone serious about host stability and security can only allow for plugins based on OS IPC.
And in general, it will take less hardware resources that the usual Electron stuff.
Kernel design is (to me) another one where ideas have flowed into other software fields - there were monolithic kernels, micro kernels, and hybrid kernels, and they all need to work with third party modules (drivers)
The lessons from all fields seem to be relearnt again and again in new fields :-)
Because learning how to make a proper one requires building your own broken one first.
It might be slightly sped up by reading up on theory and past experiences of others.
I am around mid life and I see how I can tell people stuff, I can point people to resources but they still won’t learn until they hit the problem themselves and put their mind into figuring it out.
A lot of stuff we think is top shelf today was tried on mainframes in the late 80’s through the 90’s. Cloud computing is mostly recycled 90’s “fashion”.
See also people trying to bring Erlang back into fashion.