[andrewmcwatters]

Unreal's default multiplayer architecture is unreliable by design and Tim Sweeney's whitepaper on its design from 1999, IIRC, talks about it in plain language. It's dramatically different than the Quake family of engines which reliably replicates entity states. The fact that he does not think of clients as being capable of having accurate replicable state is jaw dropping and appalling to read. It's, well, like reading a dissertation of provably wrong statements.

Serious shops hack around the fact that Unreal uses a variable timestep. Because it uses a variable timestep and uses an RPC design that does not align state changes with frametimes, you, by definition, cannot make say, a reliable first-person shooter. Every game that uses Unreal must use cone projection and proximity hacks on top of the RPC system to attempt to make a reliable first person shooter, because you cannot guarantee the state of actor positions and inputs coming from the same frame of execution.

Beautiful game engine though. Absolutely unreliable, though.

If you ever wondered why FPS games on modern versions of the Unreal Engine had multiplayer that felt so bad, it's because the engine isn't designed from the ground up to be accurately replicated to clients.

The design issue is systemic, so it may never be fixed, and Unreal engineers have decided it's too difficult or laborious to tackle.

[intelVISA]

UE, especially on the networking side, always feels like the poor man's id Tech. Even stuff like QuakeC was miles ahead of Kismet.

[andrewmcwatters]

Yeah, everything about early id Tech is just, without exaggeration, decades ahead of Unreal. Of course, sex sells, so since Unreal renders fairly well, for this reason alone I think it attracts amateurs.

I think Godot wants to do the same thing, and I'm sure it'll work, but the authors are just like the rest of the open source community in that they don't actually work on features meaningful to most games.

Back to Unreal networking: what really sucks is that you can't easily just avoid using it by using your own networking subsystem. Because features like default actor movement are tightly bound to the RPC system, and concepts like network visibility are directly integrated with actors, you may unintentionally end up screwing up what needs to be networked to clients unless you very closely match what the existing networking code does.

It's sophisticated enough that I suspect there isn't a single company or individual who has done this, because that too would be far more effort than it might be worth.

It's so gross to me that you immediately cannot use things like the replication graph if you decide you want your game to support split screen. IIRC, that was a technical limitation for some reason. I could be misremembering. It's just disgusting.

[TulliusCicero]

Interesting. I know that Frost Giant (heir apparent to the Starcraft/Warcraft part of Blizzard) has said that they're building their own gameplay logic engine and networking stack on top on UE5 for their RTS, I wonder if what you're saying is part of why.

[intelVISA]

UE is the last engine I'd use for RTS, though people have done wonders in spite of it -- check out the tech behind HŌRU game for some impressive examples.