[andrewmcwatters]

In my experience, you’re better off having a single codebase with client/server/shared code and using either the equivalent of ifdefs or conditional blocks gating execution for these states.

Unreal uses a different architecture where the codebase allows you to define who owns what, but it’s ultimately the exact same thing, and more confusingly done. Further, they have some actor states which are never actually used.

Unsurprisingly, Unreal’s networking model is unpopular. They also struggle with an architecture that has been unreliable by design since the late 90s, but now I’m digressing.

One codebase, split execution. If you use this traditional model, you can also avoid shipping server binaries to users if you so desire.

For reference, I am the author of Planimeter Game Engine 2D.

[lbotos]

Thanks! I think it makes sense, as a non-game programmer it felt "weird" so appreciate the confirmation from your angle.

[sedatesteak]

I also was doing the same but ultimately put it down to wait for Godot 4 (and its niceties such as occlusion culling - I had performance issues with quake 1 maps loaded up through godot). Do you have a repo?

I had networking etc running fine with client/server architecture but I would like to see how others have achieved this.

[lbotos]

Mine was a bashed together repo from some example tutorial. I was trying to build a paintball game so most of this was actually interest in exploring solid body projectiles vs. hitscan. I was able to get 10 players with 10 balls per second running reasonably smooth without any crazy optimization so that was cool. When I hit the wall of shared lib thats when I gave up further exploration.

[intelVISA]

Yeah you can easily compartmentalize client/server with ifdefs but it's pretty hideous. Do serious shops on MP titles stick with UnrealNet? I find it performs poorly even with some of the bandaids like Replication Graph.

[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.