Skip to content
Kiplinlen

Elden Ring Engine: What It Actually Runs On

5 min read

A rider with a lance charging a large dragon in a moonlit marsh

Image: Bandai Namco Entertainment / FromSoftware

A proprietary, in-house engine rather than a licensed one — the same lineage that powered Dark Souls and Bloodborne before it.

The Elden Ring engine is not Unreal, not Unity, and not licensed from anyone else — it is FromSoftware's own proprietary tech, built in-house and carried forward through more than a decade of the studio's previous games.

That is the short answer. The reason people keep searching for it is the follow-up questions: why a studio this size still maintains its own engine, what the thing is actually called, and why a 2022 open world caps at 60fps on hardware that could push three times that.

Where it comes from

It is an evolution of the engine FromSoftware used for Demon's Souls, Dark Souls and Bloodborne, written in C++. The lineage runs unbroken:

Demon's Souls (2009) → Dark Souls (2011) → Bloodborne (2015) → Dark Souls III (2016) → Sekiro (2019) → Elden Ring (2022) → Armored Core VI (2023) → Elden Ring Nightreign (2025).

Each of those rebuilt parts of the engine rather than starting over, which is why a 2009 game and a 2025 one still share file formats.

FromSoftware has never given it an official public name. Two nicknames circulate:

  • "Dantelion" — taken from strings modders found inside the games' own files. It appears in internal code references, not in anything the studio has published.
  • "Souls engine" — a fan label rather than a technical one.

Neither is confirmed studio terminology, which is why you will not find the name on a job listing or in a conference talk.

How you can tell it is the same engine

You do not need the source code to see the lineage. The file formats are shared across every game on that list:

What it holds Format
Models FLVER
Animation HKX (Havok)
Archives BND, BHD/BDT
Compression DCX
Balance and tuning values PARAM

Modding tools written for Dark Souls III largely work on Elden Ring with adjustments. That is the clearest practical proof that the two are the same technology at different stages of its life.

Havok handles physics and ragdoll, as it has since Demon's Souls — the one major licensed component in an otherwise in-house stack.

What changed for Elden Ring specifically

Open-world scale is the real departure. Everything before it was built around discrete, hand-placed levels joined by loading screens; the engine had never had to stream a landmass.

Three things had to change:

  • Streaming. The Lands Between loads continuously as you ride. There is no loading screen between the overworld and most of what sits on it — they are reserved for legacy dungeons, teleports and death.
  • Rendering at distance. Long sightlines, a day-night cycle and weather all arrived at once, and none of them is a problem a corridor-shaped game has to solve.
  • AI outside a script. Earlier games could afford tightly scripted encounters because the player always arrived from a known direction. Open-world enemies have to behave when approached from anywhere, on horseback, at night.

What did not change is the part the games are actually about. The animation and hitbox systems — frame-accurate attack windows, invincibility frames on a roll, poise — carried over more or less intact. That is why Elden Ring's combat feels like Dark Souls III's even though nothing around it does.

Why it is not a licensed engine

Building in-house gives FromSoftware direct control over exactly the systems its combat depends on. A general-purpose engine hands you a competent animation system; it does not hand you one where a roll's invincibility window is a tuning value someone on the team can move by a single frame and ship that afternoon.

There is a practical argument too. The studio has been paying down this codebase since 2009. Porting fifteen years of tuning data, tools and institutional knowledge onto Unreal is not obviously cheaper than maintaining what already works.

What it costs players

The trade-offs are visible, and worth naming honestly.

  • The 60fps cap on PC. There is no official uncap. Parts of the simulation are tied to frame rate, which is why third-party uncappers historically broke physics rather than simply running the game faster.
  • Traversal stutter. Elden Ring shipped with hitches as you crossed the world, tied to shader compilation and streaming. Patches improved it; it has never entirely gone.
  • Menus and UI that have barely moved since Dark Souls II, because the engine team's attention is elsewhere.
  • Anti-cheat coupling. Easy Anti-Cheat sits close enough to the game that disabling it is the standard first step for mods and for reliable offline play.

None of that is incompetence. It is a small engine team supporting a studio that ships a game every couple of years, and the decision about what not to rebuild is deliberate.

Does it matter to you

Not directly — nobody interacts with an engine. But it explains a set of things that otherwise look unrelated: why the PC port has the specific limits it has, why the modding scene is unusually deep for a game that never shipped official tools, and why the games keep feeling mechanically continuous across thirteen years.

Does Nightreign use the same engine

Yes. Nightreign is built on the same technology, which is why its movement, combat timing and animation all read as Elden Ring's rather than as something new. The changes there are structural — run length, three-player co-op, a map that shrinks — not technical.

Will the next FromSoftware game use it

Nothing has been announced either way, and the studio has never publicly discussed switching. The pattern so far has been continuous evolution rather than replacement, and every game since 2009 has followed it.