5 ms·

> 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 on

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

bob1029 4y ago
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?
- dafelst 4y ago
  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.
- rollcat 4y ago
  > 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 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 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!
andrewmcwatters 4y ago
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.
- deleted 4y ago
  [deleted]
- dafelst 4y ago
  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.

bob1029 4y ago

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?

dafelst 4y ago
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.
rollcat 4y ago
> 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 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 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!

andrewmcwatters 4y ago

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.

deleted 4y ago
[deleted]
dafelst 4y ago
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.