Fun fact: Instead of heavy fluid simulations, the Lux Engine used optimized rendering tricks: a flipped-camera perspective for real-time reflections, animated normal maps for depth, and local vertex displacements to create realistic wake ripples and splash particles when Po steps into the river.
What do you mean no pathtracing and approximated physical calculations of the water that manage to look worse than this? We can kinda get there with upscaling and frame gen!!
Not âEveryâ but yeah most, but since 2003s there was physical simulation, buoyancy calculation, fluid puzzle games like Plasma Pong and, in 2010 Hydrophobia was like the first action adventure game that uses real time water simulation as a game mechanic.
I mean yeah sure not everyone is using that exact combination of techniques if you want to take my statement literally, and there may be 1% of games that actually simulate fluids. The point is that water in games is 99% of the time just rendering tricks and techniques, none of it is actual simulation yet your original statement makes it seem like not doing fluid simulations is something special.
their dominance is bad for the gaming industry because they make it easy to pile on expensive features without understanding the performance costs underneath. Dedicated engines were built around a gameâs exact needs, carried less overhead, and forced teams to master memory, rendering, streaming, and hardware limitations. As the workforce becomes trained almost entirely on standardized Unreal and Unity workflows, building and optimizing specialized engines is becoming a lost art, making the entire industry more dependent on a few companies while games become increasingly bloated and poorly optimized.
This comment screams "I have never worked in the industry or with a proprietary game engine but tRuSt Me BrO." You have no idea what you're talking about, this is just incorrect assumptions and a misunderstanding of the industry fueled by anecdotes and nostalgia.
carried less overhead, and forced teams to master memory, rendering, streaming, and hardware limitations.
This bit alone is completely at odds with itself and shows how little you understand about how games are made and the amount of work involved in their creation. Pure nonsense.
How is that Unreal's fault? Devs are free to apply the same level of care and attention to their games in Unreal Engine. Dedicated engines haven't been used for ages now, even before Unreal became a thing, it wouldn't be feasible with the modern scale of gaming, creating a new engine per game would extend dev cycles out to be even longer, and not for any good reason.
Remember even in the time of "dedicated engines" there were still tons of games that ran very poorly. Throughout gaming history there have always been games that run pretty badly, and they were common back in the day as well as today.
It's honestly closer to the opposite. Engines like UE5 and Unity have lowered the barrier of entry to gaming so much to the point almost anyone can release a fully fledged game with some dedication + a decent/focused idea.
The biggest barrier now is component costs. But before that whole craze it was pretty cheap to just build a rig & download a free engine that will run.
im a junior game design student and they can teach artside students and backend programmers at 2 seperate programs across the premier school and the sister art school (im artside) largely because of unity and unreal making it easy to import substance, maya, blender, psds, etc so that people like us can get an easier grasp and go down alot of the pipeline ourselves while still having input on the larger engine and game feel/level design, not to mention aseprite support and unity's tilemap system making things really easy and play nice with programs like animate and toonboom
these people have no idea how much games they play have been ue and unreal in the past 15-20 yrs lol not to mention rpg maker gamemaker godot etc
Yep it's insane how much of it has been streamlined and end of the day, programming/game design/art is built on programming/game design/art of the past. We built ways to make all of the different workflows jive together in a way that makes sense to anyone who wants to delve into one part of it & expand from there.
Nobody knows it all. Or rather, anyone who only knows one thing can learn/be comfortable with the rest eventually because these are ultimately tools for creators that make creating easier.
Even with in-house engines it's a collection of institutional knowledge + new ideas coming in from people who have worked on other in-house engines or just your typical mass-market engines.
And it doesn't make it any less impressive. It's just how this shit works. It takes a village, or it takes 1 guy with a tight vision making something unique albeit with pre-made assets (and it still sells millions because it is novel & fun)
You can tell the helicopter is stuck. You canât tell just by looking at it the exact mechanical reasoning for its failure, unless youâre an engineer whoâs gotten a close look at it.
You can say âgame badâ but if youâre just a layperson then you donât have the background knowledge necessary to say âgame bad because of the specific game engineâ. There could be a million reasons for a game to be unoptimised. Unreal and Unity both fucking have the capacity for optimisation, same as any other game engine.
The game engine is pretty much irrelevant to a game being unoptimised. Itâs more of a time crunch thing; blame the executives. Itâs really more of a correlation than a causation.
I actually have enough background info to know the engine is an integral reason for the decline in game quality.
It boils down to "the engine does that out of the box, we don't need to care", so management never allocates the necessary resources for optimization, and/or overestimates the end result based on out-of-box engine capabilities.
With internal engines management calculates more carefully, or at least asks engineers their opinion before allocating resources.
So sit down, stop the opinion gatekeeping, and stop propagating bullshit.
The annoying thing is it's not even the engines fault. It's more a symptom of every major AAA game being so rushed out with so much jammed in that they just don't optimise shit and it rolls out a bloated mess.Â
While UE5 is harder to optimise since there's a lot more focus on heavier features, it's still easily possible if there's some time spent on it.
But instead of taking the time to make it optimized, we can just use our current engineâs built-in water simulations instead! Surely the players wonât mind that it makes the game run like molasses on any hardware older than a year or two, as long as the water looks cool.
175
u/SickboyJason Aug 23 '26
Fun fact: Instead of heavy fluid simulations, the Lux Engine used optimized rendering tricks: a flipped-camera perspective for real-time reflections, animated normal maps for depth, and local vertex displacements to create realistic wake ripples and splash particles when Po steps into the river.