I've worked in game development in various capacities since the 80s. While I agree with your sentiment, a lot of your points are incorrect and I feel deserve a

I've worked in game development in various capacities since the 80s. While I agree with your sentiment, a lot of your points are incorrect and I feel deserve a response. Sorry about the length. Firstly, the reason why people didn't/don't use the STL is for a long time it was garbage for games. The data structures and allocators were huge offenders. If you've done any real game development, especially in the more resource constrained days, used std::vector was terribly inefficient and made no sense. This is why studios all wrote a lot of the same lower-level code. As to why they didn't share this code, it's just the nature of the business, however a lot of the performance of certain libraries over the years was highly tuned to the individual game. Generally, games don't generate much reusability. Formats for assets change over the years, compression improves, resolution goes up, music chips improved, and so on. Even today things might have slowed-down, but programs used to produce assets make the level of effort of rehashing old assets not so worthwhile. Game studios that have tried to reuse things were often criticized for recycling when detected. The irony here is that this is actually justification for what you are saying - the assets aren't worth much long-term, so you might as well give them away along with the editors and level construction. An important thing you're forgetting though is a lot of editors and tools used in game development are very one-off and shoddy. As a studio, you simply don't have time to sit there and write a perfect UI or even unity-like UI for your tools. Sure, it happens sometimes, especially when a tool is upgraded game-by-game, but generally tools are fire and forget and often given to the lower-skilled team members. I've rarely worked with game dev tools that were not full of bugs and woefully incomplete, but this is just the nature of the beast when you have limited time and budget - you don't spend it all on making perfect tools. This alone I suspect prevents many studios from releasing things to the public because the tools are very fragile, buggy, imperfect, incomplete, and so-on that it's almost embarrassing for some to see the light of day and too much maintenance for the benefit for others. Regarding engines, I'm not sure what the gaming public's obsession with engines is. For well-tooled and documented engines, you have various degrees of offerings these days ranging from Unreal to CryEngine to Unity to other smaller, but still good engines. Those games with "custom" engines are probably no where near as useful. Sure, releasing the source would allow customizing and modding an individual game further, but again there's a lot of factors that go into this ranging from incomplete/broken pieces to game-specific hacks to lack of testing and so on. Unless a studio is in the business of releasing game engines and tools, it's hard to justify the risks. Often the copyrights and other things are not even owned anyway by the people who want to release them, so there's nothing you can do for example when your parent company or publisher views each and every line of code as some secret intellectual property. What really bugs me though is why people think that game engines are some magical thing. What is a game engine even? In my experience, in many game codebases it is hard to draw a line between "engine" and "game." Sure you can set out to do this from the start in your architecture, but most of the time it won't happen that way when you are under the gun. The best you can do maybe is circle back and architect/extract things better post-release, which no one generally gets paid to do (unless selling the engine). Even then, the engine is not some magical thing that makes the entire game work. An engine can be anything from a way of handling assets + some graphics libraries and input handling to only graphics libraries to a stack of glued together middleware and other libraries. You don't just plug-in assets, components, and a few lines of logic and hit "run." Although I've worked on things that resemble this and those tend to be the better designed systems, the truth is in especially older games, that doesn't happen. Even when using things like Unreal, a studio may plug-in their own pieces where possible and the line between what is and is not the engine gets blurred. You can definitely release a lot of it as a package that will work for the intended purposes of things like edit levels and characters, but often there's so much cruft and code-stink, it isn't easy. In general, some of the most elegant and some of the worst code I've ever seen is in games. The goal of most game studios is to release a fun game for profit, not to produce beautiful code and mod tools for the community. For whatever reason with games, fans forget how programs work and the fact there are real people trying to make a living behind all of these. Sure, many game programmers would love to see their work used even for free and would even donate their time to help out the community, but it's more of a fantasy than a reality. I'd work on 1000 things if I didn't have to worry about putting food on the table and I wager most other developers would. At the end of the day, even though it is games, it's still a job and people and companies have only so much time, money, and legal options.