There is a popular economic theory that the market will sort it out, that competition weeds out the defective, and that if a solution has become an industry standard then it is objectively the best one. This logic arrived in game development in the late 2000s with the popularisation of Unity, and a bit later Unreal, and today any attempt to suggest writing your own renderer or memory manager runs into a wave of objectors and their chants: «don't reinvent the wheel», «focus on the gameplay», «make a game, not an engine».
Back in the seventies George Akerlof, in his work on «the market for lemons», explained that if a buyer cannot visually tell a good used car from a piece of junk (a lemon), then the market price averages out, the good cars leave, and the market fills up with those very lemons.
The arrival of good game engines on the market produced a large number of quality second-hand trinkets — that is, remakes. You would think we should be celebrating the extended life of good games, but instead we got a market flooded with garbage, and that affected not only remakes but the game market as a whole. How did that happen?
What gets sold to C-level management and producers is not UE5's good architecture, but a pretty demo scene built on bought assets, loud features and slides with the logos of other studios that «managed» to ship a remake. And when a presentation in such an engine says «our new system for managing virtualised geometry or automatic LODing solves all the problems with memory and the art pipeline», I can already see half the modellers being laid off, because management read it as an opportunity to save budget on them.
What is missing from the marketing presentations is that the architectural design of this system implies constantly rewriting GPU buffers, causing frame drops on any configuration except the vendor's ideal test rig with a hundred gigabytes of RAM and four 5090s in SLI.
That once you go beyond a nominal «100 objects per frame» the algorithm starts to degrade exponentially, and that debugging it inside a «black box» of closed source or half-documented C++ will cost the studio six months of work by the lead tomatoes — but the modeller layoffs have already been scheduled. The modellers were laid off and some of the programmers with them, and without them the perf got eaten by weevils, My Lord.
If anyone so much as mutters about cutting costs, marketing has already won... but the money has already been spent, the modellers have already been fired, the game is already in production, and the engineering opinion... well... on the B2B tooling market it is valued no higher than your morning coffee. We are catastrophically short of our own Kyle Kingsbury, someone who would say that this vaunted new feature makes development 10% harder while making it 2% cheaper.
buy vs build
In the «buy, don't build» paradigm, which has also been growing steadily since the big all-in-one engines hit the market, the assumption is that a third-party service module — be it a physics engine, a UI system or a network stack — is always more efficient than your own solution, because it is worked on by a «specialised team», even if that team is a lone student trying to earn his lunch money. Here is what it actually looks like in an average project:
[ Your own game ]
│
├─► [ Someone else's UI engine ] ──► (Allocates 1000 small objects on the global heap)
├─► [ Someone else's Physics SDK ] ──► (Ignores alignment for your CPU's SIMD instructions)
└─► [ Someone else's Analytics SDK ] ──► (Blocks the main thread for 15ms on an HTTP request)Each of these modules individually passed the vendor's internal tests — read: it started up and didn't crash the engine — but together they turn your memory into porridge. When you have an in-house engine, your architect can make an executive decision and rule that «all UI allocations come from a pre-allocated allocator», which of course takes a certain number of lines of code and possibly even a dedicated engineer, but it works fast and within your engine's paradigm. But if you bought a UI solution, you are signing up for a thousand small problems inside somebody else's closed code, for fragmentation and regular freezes, because a third-party module knows nothing about your game's memory architecture, nor about your game and its needs and rules.
Cultural blindness
The most dangerous argument against writing your own engine or subsystem has long since stopped being money. It is the cultural pressure of a generation of engineers and managers who, over these fifteen years, somehow quietly grew up inside the concept that «only lunatics write their own».
And if you go to management and say «we need to spend 4 months and write our own specialised tile renderer/ui/physics/insert your own» for our lovely isometric project, they will look at you like an unhinged «insane employee». Because the big studios sit on Unreal/Unity — are you really smarter than a thousand engineers at Epic? And if we are not on U/U, we won't be able to hire from the market, because nobody knows how to work with our homegrown code, and those who do want twice the money.
But those are the wrong questions, and Epic's thousand engineers are writing a universal tool that runs a mobile puzzle game, a 100-square-kilometre open world, a VR simulator and your specific game with its fixed constraints all equally «averagely».
My company makes a strategy game with tens of thousands of small 3D objects on a level, and every attempt to use the standard UE5 and Unity render graph runs into object transform processing and eats the entire 30ms CPU budget. Our own engine spends less than 5ms on the same task by laying out everything it can into flat arrays of floats and processing them through AVX instructions — but that engine was written (probably by gods) ten years ago, for completely different hardware, and they don't make them like that any more... neither gods nor engines.
The cultural norm now dictates taking something more universal and bigger, and then hiring 20 people to «optimise» what by design cannot be optimised; half of them will quit within six months because they «couldn't hack it», the other half will be moved onto bug fixing, because we have to limp to release and somehow ship a game with the system requirements and power draw of a small nuclear plant.
Core competency
«If it's a core business function, do it yourself. If it's not, buy it» — Joel Spolsky
And here the leadership of most studios decides that since we can't do technology, let our core competency be game design, story and art... Well, we make games, for players... and everything below that (rendering, network code, asset build pipelines, memory management) is «just engineering», which can be outsourced to engine developers.
But in many video games the technology already is the gameplay, and you cannot make Factorio without a specialised engine capable of updating hundreds of thousands of entities per frame. You cannot make No Man's Sky or Minecraft on the standard art pipeline of traditional commercial engines without deeply reworking the procedural generation. You cannot make a responsive fighting game if there are twenty layers of a bought framework's abstraction between the button press on the gamepad and the drawn frame.
By outsourcing its infrastructure, a studio voluntarily gives up its competitive advantage. If you use the same tools, the same pipeline and the same basic algorithms as the other 5000 studios on the market, your technical capabilities are bounded by the lowest common denominator of those tools — that is, by the engine. A generic, universal engine leads to the loss of technical core competency, and the studio is left with nothing to do but make a remake.
The economics of remakes
It is the natural product of the fear felt by a studio that has lost its technical competencies and moved to a universal engine — fear of risk and of the decay of its internal R&D. When producing a modern AAA blockbuster costs about as much as launching a space programme, management and investors no longer need innovation.
What they need is a predictable return on capital, and from the point of view of those corporate fence-sitters a remake or remaster looks like the perfect solution. Your marketing brand has already been built and proven over time, the design decisions were validated 20 years ago, and the «innovation» boils down to stretching modern physically based rendering and high-poly assets over an old owl. This is the ultimate expression of the B2B «lemon» market and of the loss of a core competency culture: instead of investing in new mechanics or building breakthrough engines, studios turn into high-tech conveyor belts for repackaging nostalgia, where the only real risk in selling a «lemon» is that the 16K textures will take three seconds longer to load.
Why you will keep buying «lemons»
Will the situation change? Hardly. The B2B market is currently beautifully insulated from natural selection, and when a game fails because of terrible performance, stutters or network code bugs, the responsibility gets shifted onto the designers, who blame the engineers, the engineers blame the engine, the engine vendor ships patch v5.4.2.2.1.4.5.6.7.83.beta with «improved stability» and sells it to you. Profit... everyone is happy, and it once again convinces management that building from scratch would have been more expensive.
We live in an industry where code that is broken by design has become the baseline norm, and an attempt to write a simple, efficient solution that works for a specific task is treated as a rebellion against the laws... the laws of the economics of remakes.
There is a thin layer of studios that preserve an engineering culture and are not afraid to write their own reinforced-concrete bad code, and it turns out that their game somehow runs at 60 FPS on outdated hardware, loads in seconds, and doesn't require 150 GB of disk space and an SLI of four graphics cards. Apparently they employ aliens there...
← All articles