Hacker News Reader

Comment by bob1029 | Hacker News Reader

> It makes the whole engine feel like a joke.

1000%. Multiplayer in UE5 (especially the documentation) feels like it's bad on purpose. Nevermind the actually crappy net code - Just try writing your own online services provider...

I've tried on many occasions to get excited about these engines and started a project with them. Unfortunately, when the entire realm of multiplayer feels half-assed my hopes are dashed catastrophically.

Right now, I am spending every moment of my free time developing my own game/engine from scratch. I honestly don't give a shit about Nanite, AAA graphics, et. al. Complex multiplayer experiences are far more compelling to me than raytraced graphics and sub-pixel triangles.

I think the exact nature of the net code is much more intimately linked to the game concept than anything in the rendering pipeline (for a multiplayer experience like Quake or Counterstrike). You will never get a perfect fit if you outsource this.

View on HN

> 1000%. Multiplayer in UE5 (especially the documentation) feels like it's bad on purpose. Nevermind the actually crappy net code - Just try writing your own online services provider...

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'd be very interested in reading more about FGS and what they've been up to around UE5.

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?

You can modify Unreal Engine as much as you like to ship a game and the engine changes remain your property, you just have to pay their royalties.

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.

> I'd be very interested in reading more about FGS and what they've been up to around UE5.

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!

It's not because they wanted to, I guarantee it. It's because it's impossible to not do it. Critically important details, down to the engine's frame timing, how replication is deeply integrated into the engine, and how the default Actor movement code works means you have to not gut just a single implementation detail, but you have to cut whole swaths of code out of use.

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.

It is certainly doable, there is a plug-in on the UE marketplace that meaningfully extends Unreal's movement replication to do nicer interpolation and extrapolation of movement, it is called SmoothSync. We used it in lieu of UE's character movement component on the vehicles in the game we shipped a couple years back. It is a bit heavier on bandwidth (to their credit, Unreal's movement component replication is VERY lean) but still well within budget.

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.

I'll have to check this out, thanks for mentioning it. I would be thoroughly surprised if it actually integrated with the rest of the engine though--my guess is they sacrificed this deep integration (foregoing the replication replay system, etc.) just to get something that works.

Pardon my ignorance (only interested in gamedev tangentially), but I would've assumed every game engine that progressed beyond a mere toy would always fix the timestep (or at least make it a single API call to do so). Or is there an entire class of games that somehow benefits from variable timesteps?...

You're not ignorant, it's an excellent question.

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.

Yes! I completely agree. You're not alone. There's a lot of us out here slogging through writing portions of game software we don't want to only because it's necessary to create the experiences we want that can't be delivered in a timely fashion with existing technology.

Reply on news.ycombinator.com