From my experience of shipping a few AAA games: a universal game engine will always be suffering from trying to balance efficiency vs universality. It's not a

From my experience of shipping a few AAA games: a universal game engine will always be suffering from trying to balance efficiency vs universality. It's not a big deal to write an OOP engine where you just insert objects into a scene graph and each has a callback to draw itself, write a whole library of different classes for all kinds of purposes and ship it. The problem is that it's going to be much slower than a game written from scratch by a semi-competent programmer. It's also not a very big deal to write an extremely efficient engine that will render, for example, streaming landscapes very fast and in great detail but won't render anything else nearly as well. It's believed that neither of these would sell well even though id software has allegedly made much more money selling their specialized maze shooter engines than selling their maze shooter games. Though probably nowhere close to the money Unity/Epic makes. Unity/Epic try to make an engine with OOP APIs in the front and optimized pipelines in the back. This is very hard and this is why they: a) don't have much competition an b) are not very good. In my opinion, the only threat they both face is some yet unknown universal rendering technique appearing and making both obsolete. Till then, they will always have a customer base of studios who do not know/want to write their own game and not satisfied with naive OOP engines (and there used to be hundreds of those, even DirectX had one built in, called "D3D Retained Mode").