Engine selection is one of the earliest and least reversible decisions in a project.
Commercial engines
Licensed platforms with large toolsets and communities.
Which reduce time to a working prototype substantially.
Licensing models
Revenue share, subscription or seat-based fees.
Which have changed repeatedly and caused genuine disruption.
In-house engines
Control and specialisation at high maintenance cost.
Which only larger studios can sustain.
What the engine determines
Rendering approach, tooling, platform support and hiring pool.
What the decision actually commits you to
Tools, workflow, hiring pool, platform support, licensing terms and the community you can ask for help.
Which persists for the life of the project and frequently beyond it.
Changing engine mid-project is possible and is usually close to starting again.
Licensing controversies
Terms changed retroactively by an engine provider.
Which caused substantial disruption and a reassessment across the industry.
Open source options
Engines with permissive licences and growing capability.
Which gained significant attention after those events.
Genre suitability
Engines with strengths in particular kinds of game.
Which matters more than raw capability.
Learning resources
Documentation and community size as a practical factor.
What actually decides the choice
What the team already knows, what the game needs technically, and what the licensing costs at expected revenue.
Which in practice usually means the team's existing expertise dominates.
Retraining a studio on a new engine costs a year of reduced productivity, which is rarely worth a marginal technical advantage.
Rendering capability
Lighting, materials and scale differing substantially.
Which matters most for visually ambitious projects.
Tooling and iteration speed
How quickly a designer can test a change.
Which affects quality more than raw capability does.
Console support
Certified platform ports and the work required.
Middleware
Physics, audio and animation systems layered on top.
Which are separate licensing decisions.
What has changed recently
Licensing terms altered by a major provider prompted studios across the industry to reassess dependencies they had treated as stable.
Which drove genuine interest in open source alternatives that had previously been niche.
The episode was a reminder that an engine is a business relationship as much as a technical choice, and that the terms can move.
Evaluating an engine
Prototype in it before committing.
Which reveals workflow problems that documentation does not.
Team familiarity
Existing expertise as the dominant factor.
Which is rational rather than conservative.
Long-term maintenance
Version upgrades and their disruption.
Which studios plan around release schedules.
For people learning
Free tiers and extensive tutorials on the major engines.
A note on how this industry reports itself
Games is an unusually opaque business for one with such a visible product. Budgets are rarely disclosed, sales figures are announced selectively, player numbers are quoted in whichever metric flatters, and profitability is almost never stated at all.
Most of what is publicly known comes from court filings, leaked documents, regulatory submissions and former employees speaking after the fact. That material is reliable when it exists and covers a small fraction of the industry, which means any general claim about how games perform commercially rests on a limited and non-random sample.
Where the better information is
Developer conference talks are the single best public source on how games are actually made, and a large number are freely available. Regulatory filings during acquisitions have disclosed more real financial detail than a decade of press releases. Trade publications with industry sources are considerably more informative than consumer coverage on business questions.
Treat anything presented as an industry-wide figure with some caution, including in this article, and prefer sources that say where their numbers came from.
Why the business side is worth understanding
A great deal of frustration with games comes from decisions that look inexplicable from outside and are entirely predictable once the commercial structure is visible. Why a game shipped unfinished, why a beloved studio was closed after a successful release, why a sequel dropped features the previous game had, why a service shut down two years in.
None of these are mysteries. They are the outcomes of funding structures, platform economics, publisher portfolio decisions and the fact that games are made by people working to schedules set before anyone knew what the game would be.
Knowing that does not make the outcomes better. It does make them legible, and it makes it easier to tell the difference between a studio that made a mistake and one that was never given the conditions to succeed.
One thing worth remembering
Games are made by people, mostly people who care a great deal about them, working inside commercial structures they did not design and frequently cannot change.
Criticism of a game is fair. Criticism of the decisions behind it is usually aimed at the wrong floor of the building.
Further reading
Developer conference archives, postmortems written by the people who shipped the projects, and trade reporting with named industry sources are the three places where this material is covered properly and in public.
All three are freely available, and none of them require any technical background to follow.