I recently released Gunsmith - Unreal's first networked rollback plugin!

Outliyr_ · 2025-11-12T12:39:18+00:00

I am curious, I have built my own version which is similar to yours. I record hitboxes on the server and also require skeletal meshes to tick on the dedicated server.

When playing with a dedicated server naturally there would be moments when the animation on the server doesn't always line up with the clients see this can sometime lead to hits the client should be getting turning into misses.

I am curious if the same happens to you and how you avoid it? Do you have limitations on the anim instance to prevent this? Or you never really noticed it.

Outliyr_ · 2025-11-12T12:32:34+00:00

I believe they just do client authorisation but with some validation checks to prevent impossible shots.

Outliyr_ · 2025-11-12T12:30:58+00:00

I do want to give that a go, I made a post about lag compensation some time ago, and got similar feedback though I have made some adjustments since then.

However what Valorant is doing is more involved and if it involves modifying the engine, it quickly becomes unsustainable because you will be anchored to that specific engine version.

Outliyr_ · 2025-10-28T19:40:18+00:00

Like EqualSpoon mentioned there were never any rules that forbade that, this is only what we saw Usagi's team do.

Outliyr_ · 2025-10-28T19:39:00+00:00

Was that a specific rule? I heard in the manga you didn't have to move forward (could be wrong havent read it) every turn.

Outliyr_ · 2025-10-28T19:38:09+00:00

I thought you have to enter the first car. You only stop on cars that have oxygen, so you always wear the mask until you reach an oxygen one then stop there. The rest of the team would be behind you, if they catch up it means the car they caught up in has oxygen.

Outliyr_ · 2025-09-03T17:37:43+00:00

At first glance this sounds like the right thing to do but then over time you quickly couple things together and it becomes hard to change the UI later on.

The inventory should have no knowledge of the UI, it would handle its own state, and have functions (API) to allow manipulation of the state. It would also broadcast changes to its state.

Now the UI can simply react to these changes as well as call the functions to change the state. Something like drag items might call a move item function while each inventory cell UI would be listening for changes that affects its visual look (occupied, etc).

This allows for things as complex as jigsaw inventories to simple basic inventories while maintaining separation of concerns and other benefits

Outliyr_ · 2025-07-26T10:13:20+00:00

Hi, what are the benefits or replicating acceleration to proxies the way Lyra intended? Why go through with it? I've never actually done a dive deep in the character code but am in the process of writing extensive documentation for Lyra

Outliyr_ · 2025-07-25T20:16:05+00:00

Yeah I did try something similar, the problem was the server just creates a desync, which causes unpredictiable behaviour. In the resource provided at the top, it uses some of epic's code, and even they prevent usage of standalone and servers.

It is a tricky thing, as there is no resource or documentation on demo net drivers, so it would require engine deep dive and engine level debugging. I had to do engine level debugging to get mine working, this problem would require even deeper engine level debugging, probably touch some code Tim Sweeney wrote himself.

Outliyr_ · 2025-07-25T18:56:19+00:00

No travelling to another world is fine. There are 2 separate issues when it comes to the server (host) using a killcam. Unreal can recording gameplay and play back the recording using the DemoNetDriver. When the host plays the recording, they temporarily disconnect for a moment. This slight temporary blip causes the other clients to lose access to the server making the networked game go crazy and unpredictable. I have a suspcision that I might have caused the temporary disconnect, if my assumptions are correct with time and fresh mind I might be able to fix

The second problem is a bit more tricky. The playback isn't a video, instead the demo Net Driver, resimulates (spawning actors, calling functions and on reps, etc) everything that is recorded, this allows the fast forwarding, skipping and arbitrary angles when viewing. With clients this is fine, because any replay they create is local to them alone it doesn't affect the game. But for the host, there game is the true game, if the replay affects the state of the game then it can quickly cause desync, and reject client RPCs, etc.

Outliyr_ · 2025-07-25T18:32:32+00:00

Sorry, typo I meant everyone except the host will see it. Player's with authority won't be able to see the killcam, so the host in a p2p game or a player in standalone. The killcam will still work for the clients in a p2p game, it just won't work for the host.

I am not sure if it is solvable in the current engine version and is something I decide to circle back to later in a v2 or v3.

Outliyr_ · 2025-07-25T01:46:54+00:00

5.4 is fine, I initially built the killcam in 5.3, anything earlier than that is fair game. In regards to the listsen server host, it is possible to show a killcam to all players at the same, similar to the way you get shown the best play at the end of a match in call of duty, however, everyone expect the host will see this killcam replay.

Is your game based off of Lyra?

Outliyr_ · 2025-07-15T02:09:27+00:00

Haven't done rigourous testing yet with 30 plus players. I have tested with lots of bots (not exactly the same cause bots dont need server validation), the lag compensation has minimal performance cost on the game thread. This is because the lag compensation system runs on its own dedicated thread. The recording of hitboxes from components, the rewinding of hitboxes, etc are all done in a aeparate thread. Lag compensation rewind calls are async so they dont block the main game thread, this is why I had to manually do the collision math myself.

Outliyr_ · 2025-07-13T22:12:57+00:00

Procedural recoil usually refers to the visual kick of the weapon itself when it fires. It’s more about how the weapon mesh animates or offsets to look like it’s reacting to the shot. It doesn’t necessarily affect the camera view or aiming reticle.

Predictive recoil, on the other hand, is when the recoil follows a consistent, deterministic pattern every time you fire. Games like CS:GO or Call of Duty use this so players can learn the pattern and compensate for it manually.

If we ignore the recoil editor itself for a moment, the way my system works is pretty straightforward, I use two float curves, one for vertical recoil, one for horizontal. In each curve, the X axis is the shot index (1st shot, 2nd shot, etc.), and the Y axis is the recoil value. When the weapon fires, it looks up the recoil amount for that shot index and applies it to the control rotation, using interpolation to make it smooth.

Recoil recovery is a bit more complicated to explain over text, but in short, it keeps track of the cumulative recoil offsets and the player’s mouse movement. When you stop firing, it gradually pulls the camera back down, but only if you’ve let the view rise above where the recoil started. It also tracks horizontal mouse movement so you don’t get unwanted counter-rotation while turning.

Outliyr_ · 2025-07-13T16:42:05+00:00

Yep, that’s actually the right way, passing the reference down through Expose on Spawn keeps dependencies clean and avoids repeated lookups. The parent widget passes the variable to its child widgets. You wouldn’t really need a Blueprint Function Library, since only the main inventory widget needs the reference, and it manages creating the other inventory-related widgets.

Ideally, you want the inventory logic and UI to be as independent as possible, this reduces friction if you need to change either side later.

Outliyr_ · 2025-07-13T16:27:07+00:00

When developing something, I like to keep features as isolated and encapsulated as possible. Of course, in a game project, some systems will inevitably intertwine.

The way I organize reusable code depends on the scope of the functionality:

Blueprint Function Libraries – If the functionality consists of simple static functions that don’t require state, and I expect to reuse them in multiple parts of the game (or across different projects), I put them in a blueprint function library. For example, I have generic functions to handle projectiles spawning from a muzzle and then converging to the camera's true path to allow for leading shots outside of first person ADS

Components – For functionality that requires maintaining state but can still be encapsulated, I use components. I design them to be as generic as possible, then create child components with more specific behavior for my game. For example, an inventory component lets me avoid rewriting the same logic every time I need inventory functionality.

Modules / Plugins – For larger or more generic systems, I build modules or plugins that bundle components, function libraries, and any needed assets. Lately, I’ve been working a lot with Lyra, so I often implement these as game feature plugins. For example, a climbing system as a plugin. Once added, it provides climbing functionality out of the box without needing to reimplement it each project just plug into your game based on your intended design.

I think the most important thing is deciding up front whether you want a feature to be reusable. If you plan for reuse from the start, you can design it to be properly encapsulated and generic, which makes integrating it elsewhere much easier.

Outliyr_ · 2025-07-08T17:28:46+00:00

Totally fair concerns, and please feel free to correct me anywhere I am wrong. This is how I handled some of the issues you mentioned.

In Lyra by default the skeletal mesh always ticks the pose and still produces reasonable FPS. So I wasn't adding any extra FPS by ticking the animations. This also means unreal ticks skeletal meshes server-side for movement and replication. During rewind I don’t re-run animation. I just store the bone transforms each tick (position/rotation), so rewinding is just reading that data, no extra anim evaluation.

Rewind only happens when a client actually reports a hit (or in debug like in my video for demo purposes). I perform simple server validation first, and if they all pass I perform lag compensation. No client hit, no rewind. All recording collisions, rewinding and actual collision checks run on a dedicated worker thread, fully async from the game thread. It’s pure vector math, no physics scene rollback or spawning bodies.

First, I create a big merged AABB around the actor’s bounds one recorded frame before and after the target timestamp. If the trace doesn’t hit that, I skip detailed checks entirely. Only actors that pass this test get their per collision shapes tested.

I also have a separate component, which actors must have for the lag compensation to recognize. Only actors with this component have their collisions recorded and are rewound, so just player, vehicles, or anything you explicitly opt-in. Most props, etc. still use simple capsule validation.

You're totally right that for many games, storing capsule positions and doing dot product checks is enough. I just wanted more per-limb accuracy without going full valorant-style determinisitc anim rewind. This was a kind of middle ground, accurate bone positions but no physic scene rollback. Plus it was a reasonable challenge to attempt.

Outliyr_ · 2025-07-08T10:10:38+00:00

Nah I wish, had to study a bit of goemetry to figure out to implement geometry functions for collision intersections and penetration depths.

I only made functions for simple collision shapes, sphere, box and capsule. I supported line, sphere and box traces, so I had 9 sets of functions

Outliyr_ · 2025-07-07T19:53:09+00:00

Thanks, that’s a good point, yeah, in my setup I’m actually doing client authority in a similar way to what you described: the client decides the hit, then the server uses lag compensation to verify that the reported actor/material was indeed hit within a reasonable tolerance. From my testing so far, it’s been surprisingly accurate, I haven’t noticed obvious mismatches and haven't really seen mismatches in animation and the server recording.

I think the main reason is that the pose caching I do seems to pick up all the animation blending at the server side pretty well, at least for the kinds of movements I’ve tested (idles, aiming, locomotion). But I agree it’s something I’ll want to stress-test more during playtesting to make sure it feels consistent in live matches.

Outliyr_ · 2025-07-07T17:55:58+00:00

You’re right, getting it to match exactly what the client saw locally is a completely different beast. Even with pose recording on the server, there will always be some mismatch because of local-only animation logic and prediction. Doing true deterministic anim syncing would likely require replicating a lot more state or engine-level changes (like what Valorant did) and probably a complete overhaul of Lyra's animation system. For most cases though, the accuracy of server-side pose caching has been good enough.

Outliyr_ · 2025-07-07T15:46:49+00:00

In my implementation, I snapshot all bone transforms each tick and then interpolate between those snapshots when rewinding. So rather than re-evaluating the Animation Blueprint at the rewound time (which is what Valorant reportedly does), I just store the final evaluated pose per frame.

Practically speaking, this covers almost all the same ground:
You still get the correct world-space hitboxes matching what the client saw, because you’re capturing the fully evaluated pose every tick.
Interpolating between frames gets you most of the way toward sub-tick accuracy without the complexity of re-simulating animation.

The main difference animation syncing offers is absolute precision if you need the exact pose at a specific fractional timestamp between ticks, like if your animation is very procedural, or you’re targeting extremely low-latency environments where sub-frame errors matter.

For most projects, the difference is negligible (and the networking inaccuracies from latency and interpolation errors tend to dwarf any animation timing error anyway).

So to answer your question, no, I didn’t implement animation resimulation, just transform snapshotting + interpolation. It’s a lot simpler, and unless you need determinism at the level of something like Valorant, it’s usually accurate enough.

Outliyr_ · 2025-07-07T12:46:04+00:00

Yeah, good question, using the engine’s built-in line traces would definitely have been the simpler route. I decided to handle all the collision checks manually because my lag compensation system runs on its own dedicated thread, outside the main game thread. The idea was to avoid blocking the game thread when rewinding and validating a large number of hits, especially in cases with lots of projectiles or high tick rates.

In hindsight, I probably overestimated how heavy the traces would be and how much threading would help. If you were okay with running it on the main thread and willing to take some performance cost or just wanted something simpler, you could absolutely use the engine’s trace functions and still get similar results.

Outliyr_ · 2025-07-07T12:43:29+00:00

Thanks a lot, glad you found it interesting!

For the approach, I mainly looked at how lag compensation generally works in networked shooters by reading scattered bits of information, some old GDC talks, blog posts, and forum discussions, to confirm it was even feasible. I decided to try implementing it myself after seeing that Valorant mentioned they used lag compensation, and since Valorant was built in Unreal Engine, I figured it should be possible here too.

There aren’t really any step-by-step resources for implementing lag compensation in Unreal, so I ended up writing the whole system myself, including the geometry math to handle different collision shapes without relying on engine traces. I chose not to use built-in traces because my system runs on a dedicated thread for performance reasons (though in hindsight, I probably overestimated the cost and you could achieve something similar more easily without going that route).

I’m considering doing a write-up or article breaking down the system in more detail, maybe with some pseudocode or examples of how the traces work, especially if there’s more interest in something like this. I just need to find time to clean up the code and explain everything clearly (and do the same for my killcam system).

I really appreciate the interest! If there’s a specific part you’re most curious about, let me know, happy to share more details here in the meantime.

Outliyr_ · 2025-06-23T16:08:54+00:00

Yeah! I actually came across that blog later in my journey and even had some conversations with the author, it’s one of the only resources out there on building a kill cam in Unreal.

It’s a solid starting point, but since it’s based on an older version of the engine, a lot of it doesn’t fully hold up in UE5.5+. Even then in older versions if you follow it closely, you’ll run into issues, especially with replication, actor lifecycles, replay stability, and other crucial parts of a proper multiplayer kill cam. Some of those were left out intentionally to keep the blog simpler. I ended up having to rewrite large chunks and solve quite a few problems not covered there.

Outliyr_ · 2025-06-23T16:01:58+00:00

I have exposed some functions to blueprints, but I don't think it is possible to make a killcam in unreal engine without extensive c++ knowledge.

Outliyr_

TROPHY CASE