All of this is true and has been true for decades in the game industry.

The other side of this seesaw is: Games are fundamentally in the novelty business. Players like some amount of familiarity, but they want new experiences. Every game engine has a sort of "grain" to it where it tends to produce games with a certain look and feel. The flat-ish shading and floaty physics of Unity is a particularly visible example of this. So using a widely used game engine can put you at a disadvantage if you're trying to make a game that doesn't go with that grain and offers players something different.

As more studios consolidate on the same engine, more players will get tired of that sameness and reward other studios more. As more studios do their own thing, players will become saturated with novelty and the benefits of not using an engine will go down. There is no stable equilibrium.

I firmly believe if software engineering unionization ever starts to take hold, it'll begin with game developers.

There's a lot of money in gaming but the workers are treated like shit, as you pointed out.

This kind of argument has been made since the days of renderware.

I have seen a number of projects go from

'We're building our own engine'

To

'we should have just gone with $engine_of_the_day'

To

'We were so lucky we chose to make our own engine'

If you want to make a game like fortnight, the Unreal is your pick. If you want to try something that hasn't been done before you could do worse than rolling your own engine.

Especially if you are looking for where the fun is, the idiosyncrasies of your own engine gives you a world with it's own flavour if you incorporate that flavour into your design process you could create a feedback loop that turns into something special.

For me this falls apart on the consumer side of things.

UE5 games are manifestly lower quality than games built on custom engines. Optimization is especially worse. UE5's performance baseline _requires_ the use of upscalers (DLSS/FSR, fake/AI frames) in order to hit basic targets like 1080p@30fps.

I won't buy games built on Unreal Engine. Homogeneity of this type is horrible for customers of the gaming sector.

> It lets you treat your employees as a replaceable commodity

This has been the objective of the tech industry for years

>It lets you treat your employees as a replaceable commodity that can be scaled up and down as it makes monetary sense rather than a cohesive team of skilled artisans.

Can we extend this elsewhere? Are tech companies' decision to use popular programming languages (eg. python) or software (eg. postgres) part of some dastardly ploy to make programmers "a replaceable commodity ... rather than a cohesive team of skilled artisans"? Should all programmers push for having bespoke tech stacks at their companies so they can be "skilled artisans"?

There's truth in the fact that it's easier to hire and ramp up on standardized tools.

It's a fallacy to extrapolate that into calling a team structure completely fungible. Throwing away an effective team that was able to ship a game is an incredible waste.

Sounds great until Epic realises they can charge whatever they like in licensing fees.

This is ARC Raiders/Embark Studios. Games made by hoards of anonymous contractors and maintained by a skeleton crew incapable of iterating meaningfully on their product.

giant corporations arent interested in hiring skilled artisans or artists. it doesnt matter how skilled your team is with idTech, the chances of success for any video game are just vanishingly small and inconsistent.

it feels to me like the AAA game industry is like hollywood except the budgets are higher and there are even lower chances of success. i mean theres literally multi hundred million dollar games that essentially made zero dollars. Even shitty blockbusters make some money.

It looks exactly like what Microsoft already did to its browser engine Trident, which was replaced by Google’s Blink on Edge.

You're framing this as a thing done by a greedy corporation in an evil manner, which maybe it is, but it's also just a sign of the times.

For most of the 90s and 00s, your game engine, specifically idTech in this case, was a competitive advantage. Doom and Quake/2/3 all represented massive technological jumps over their predecessors and were way ahead of their competition in terms of looks. Games like Unreal (Tournament) and Tribes competed using their engines' strengths; those engines didn't look as good but were capable of rendering much larger spaces than idTech, and those games emphasized that, e.g. Tribes' massive multiplayer maps with vehicles, or classic UT maps like Facing Worlds and Lava Giant.

Then in the late 00s to 10s, things started to hit a wall. Probably peaking with Crysis in 2007, which is likely more remembered for its engine, graphics, and system requirements (all of which were truly mind-blowing at the time) than its actual gameplay. After that, games' graphics improved at a much slower rate; it started to be less about the engine's capabilities, which were increasingly homogenized, and more about art direction.

Now in the 2020s, we have UE5 for AAA games with high-fidelity graphics and Unity for everything else... what is the competitive advantage in maintaining your own engine? As you mention, you have to have internal expertise, which is less well-documented than UE5/Unity because you don't have dedicated documentation staff; you have to maintain your own tooling, which is likely worse because you haven't invested as much in it. From a ROI perspective, unless you're planning on investing so you can license out the engine and become a UE5/Unity competitor, it doesn't make sense to maintain your own engine.

And looking ahead, frankly, consumer GPUs are now so expensive that game graphics have likely peaked for at least a decade. There will simply not be better hardware available to gamers for the foreseeable future. Games "looking good" will be more about art style and direction, and you sadly do not need a team of game engine programmers for that.

You could just mandate that they make an API compatibility shim. Then they can't revolt and there is reference code for interfacing with the proprietary library.

it also makes your games worse. those general purpose engines all have a smell to them.

>It lets you treat your employees as a replaceable commodity that can be scaled up and down as it makes monetary sense rather than a cohesive team of skilled artisans.

Jane Street hires devs at high salaries and makes them use OCaml rather than a more mainstream language. The company makes more money trading than traditional giants like JP Morgan do.

So just depends on if your strategy is right. I blame Microsoft incompetence.

the endless optimization of everything sure does strip out most enjoyable things, though. often it is these irreplaceable people who contribute the magic that makes their creations popular.

George Fan created "Plants vs. Zombies". After the success of PvZ (the first one) PopCap fired him and replaced him with someone much cheaper. PvZ2 was horrible. All subsequent games (the ones I've played) have been awful. So, money was saved. Money was probably made by microtransactions. But no one talks about PvZ anymore. The magic was torn out for profit.

[dead]

And of course, there is really no down-side to low-wage contractors wielding UE5. /s

You're presenting this with ironic swipes like "bad things like ask for more money", but it's hard to read this description as anything but straightforwardly more efficient.

If there are few downsides to centralizing game engines, and the need for engine work is inherently cyclical, why should we want engine work to be internal and non-cyclical?

I really don't know much about game engines so maybe there are real downsides to that approach, but the way you've laid it out makes it seem as if Microsoft made the right decision here.