Intriguing. Makes even more sense that Frost Giant Studios (who are using UE5 for their upcoming RTS) have written their own networking code (with rollback!), and thrown away other big parts of the engine.
I'm dying to be proven wrong, but the intersection of people who know multiplayer networking well, Unreal Engine 4 or 5, and have successfully implemented client-side prediction with reconciliation and rollback in said software and out of it as well, are vanishingly small.
I failed to understand how one could use the existing engine's loop which is variable framerate, the existing replication system, which favors an implementation opaque RPC system over explicit payload structures, and rewrite Actor movement and engine timing subsystems without having a parallel network loop that uses none of the above.
My guess is that it is possible to use Unreal's variable framerate and replication system, but only rewrite Actor movement implementation details by creating a class that inherits from it and overrides the behavior entirely, but you're still stuck with the fact that because the Unreal Engine uses a variable framerate, you have an inconsistent rollback timeline across every client.
You want consistent frame times, in my experience, to have rollback. Does it mean that it's impossible otherwise? No, but you can get caught rolling back in-between game states that don't actually exist on the granularity of the timestep you're running at.
The code is horribly ugly, but works well. The ugliness I think is less to do with integrating with Unreal and more to do with the author though. That said, it works.
The Unreal Engine has a long history, and its origins did not start from a fixed or semi-fixed timestep. The Unreal Engine doesn't benefit from a variable timestep, it's hampered by it, and the engineers have deemed it too difficult to fix, because the decision permeates the entire engine.
There is a "fixed timestep" mode, but it's for cinematics, and specifically for synchronizing the engine with external hardware, IIRC. But it's not a true fixed timestep, it's actually a fixed framerate, instead.
The idea of incrementally defenestrating UE5 in favor of in-house components is compelling to me. This path definitely works a LOT better in a team setting where you have actual artists looking for things to work on.
I don't know how the licensing actually works out around this though... Assume you went full ship of Theseus on UE5 and replaced 100% of it with in-house. Will Epic Games be happy walking away from this, or is there some fundamental legal component that we know we'd never screw with?
They have two subreddits: r/frostgiant, and r/stormgate (for their game). They regularly ask the community for feedback/discussion/brainstorming on some topics relevant to the gameplay (like pacing, asymmetry, monetisation, e-sports, etc), openly share their conclusions from the discussion, but unfortunately in-depth technical stuff doesn't really pop up often.
They specifically bragged about their pathfinding (apparently at least on par with StarCraft II), and the rollback netcode (which is "directly inspired" by fighting games, and apparently not a common thing for RTSs), but again, everything is scarce on technical details.
The unofficial Discord community (https://discord.gg/stormgate) has a "Yeti Tracker" channel that automatically cross-posts any comments made by FGS staff; there's also https://stormgatenexus.com (fan website) where many of the interviews are transcribed and distilled into articles.
I'm watching all of these closely, I can ping you if I see more engine-tech-heavy stuff popping up!
At least that is how it is in practice - the language in the license agreement is actually a little fuzzy, when our game was sold from one company to our current one, the lawyers had a bit of a frowning session over some of the language there, but ultimately decided it was okay. Maybe in the future it will be challenged, but for now, self-owned engine changes are the norm.