An engine is discussed as though it determined how a game looks. It is a collection of systems solving problems every game faces, and the visual result depends far more on the art direction than on the engine.
What is inside
A rendering system converting scene descriptions into images.
A physics system simulating collision and movement.
An audio system handling playback, mixing and spatialisation.
An input system abstracting across devices.
An asset pipeline importing and processing content.
A scripting layer allowing designers to build behaviour without writing engine code.
And increasingly, networking, animation systems, and tooling for level construction.
Why studios use existing engines
Building any one of those systems well takes years.
Which means a studio building its own engine spends a large portion of a project on technology rather than on the game.
That was worthwhile when engines were less capable and when a proprietary engine conferred a technical advantage.
It has become harder to justify as commercial engines have improved, which is why several studios with long-established internal engines have switched.
Why some still build their own
Specific requirements that general-purpose engines handle poorly.
Very large worlds, unusual simulation requirements, particular performance profiles, or a genre with distinct technical demands.
Control over the technology stack, which matters for long-running franchises and for platforms with unusual constraints.
And avoiding licensing costs at scale, which become substantial for very successful titles.
The licensing models
Generally either a royalty on revenue above a threshold, or a per-seat subscription, or a negotiated arrangement for large customers.
Which means the cost structure differs enormously between a small independent project and a major studio, and the decision calculus differs accordingly.
Changes to licensing terms have caused significant disruption when announced retroactively, which prompted substantial migration and a subsequent reversal in one prominent case.
The tooling question
Underrated and frequently decisive.
How quickly a designer can build, test and change something determines iteration speed, which determines quality.
An engine with excellent rendering and poor tooling produces a worse game than the reverse, because iteration count matters more than any single technical capability.
Studios building their own engines frequently underinvest in tooling, since it produces nothing visible.
Middleware
Specialist components licensed separately and integrated.
Audio middleware, animation systems, crowd simulation, dialogue tools, analytics, anti-cheat.
Which means a shipped game frequently contains technology from a dozen vendors, and integration between them is real work.
Engine and visual style
Worth stating because the assumption is so common.
Games on the same engine look entirely different, and games on different engines can look nearly identical.
Default settings and commonly used features produce recognisable tendencies, which is what people are noticing when they identify an engine from a screenshot.
Those are conventions rather than constraints, and studios investing in art direction override them completely.
What it means for a player
Very little directly, and it explains some things — why a game supports particular features, why modding is possible or not, and why performance characteristics resemble other titles built the same way.
Determinism
A requirement in some genres that constrains engine choice heavily.
Games using lockstep networking — where each client simulates identically and only inputs are transmitted — require the simulation to produce bit-identical results across machines.
Which is difficult, since floating-point arithmetic can differ between processors and compilers, and it is why such games frequently use fixed-point mathematics instead.
Strategy games with many units use this model because transmitting full state for thousands of units is impractical.
Modding support
Whether players can modify a game depends on choices made during development.
Exposing the scripting layer, shipping editing tools and using open data formats all enable it, and each has a cost in development time and in security exposure.
Games with strong modding communities have demonstrably longer commercial lives, which is a reasonable argument for the investment.
Build times
An unglamorous factor with large productivity effects.
If compiling and packaging a build takes hours, iteration slows for everybody, and large projects have exactly this problem.
Hot reloading, where changes take effect without a full rebuild, is among the most valuable tooling investments and among the hardest to retrofit.
Version upgrades
Moving a project to a newer engine version mid-development is disruptive and sometimes unavoidable.
Which means studios generally lock a version and backport specific fixes rather than upgrading, accepting that they forgo later improvements.
Long projects can therefore ship on technology several years old, which is a routine and rarely mentioned reality.
Source access
Whether a studio can read and modify engine code determines what problems it can solve.
Engines providing source access allow deep customisation and debugging into the engine itself, which matters when a problem originates below the game code.
Engines that do not require working through the vendor, which is slower and sometimes the only option.