Great Start to 2026
Hello and Happy 2026 to everyone!
First off, we want to apologize for the small gap between our 2025 updates and now. It’s been a busy stretch for us; life, learning, development, and everything in between. That said, we’re hoping to start posting more frequently about Repressed and the progress we’re making.
To kick things off, we’ll start with some of the bigger areas we’ve been working on: the Inventory system, the Train system, and a rework of both Damage and Bullets.
Inventory
The inventory is probably one of the most important parts of the game, since it’s where players will spend a large portion of their time. While it won’t be quite as time consuming as something like Escape from Tarkov, we still want the experience to feel smooth and enjoyable to use.
To support this, we needed to upgrade our inventory system to take advantage of new features introduced in Unreal Engine 5.6 and 5.7. This required a large amount of refactoring, which ended up being one of the biggest reasons development slowed down for new features over the past few months.
The good news is that once this work was completed, the inventory system ended up in the best state it’s ever been. It’s now more stable, easier to expand, and supports several new features that will help us continue building on it moving forward. We’re looking forward to showing this off our first dev log.
Train System
We’ve also been working on an extraction system that fits the world and setting of Repressed. In a post-apocalyptic era, transportation becomes scarce, and trains felt like a natural fit.
Players will use trains to infiltrate and exfiltrate target areas and specific zones around the map. There are still some details we’re refining, such as safety during transit, potential camping issues, and how frequently trains will stop. For now, without giving too much away, the early implementation is looking promising and feels like it will fit well with the overall gameplay loop.
Damage & Bullets
Another major area of work has been our bullet simulation and damage system. We created a custom plugin to handle this, and it has evolved quite a bit since the early versions.
Initially, the system was fairly simple and relied on basic replication. Since then, we’ve expanded it significantly. The system now includes features such as:
Trace matching across all clients to ensure penetrations and ricochets remain accurate
Improved performance for spawned effects
Better performance for automatic weapons
Client-side prediction with rewind logic, ensuring that shots both look correct for players and remain authoritative on the server
These improvements should make firefights feel far more responsive and consistent in multiplayer scenarios.
Backend Work
Behind the scenes, we’ve also made progress on our backend infrastructure. The systems supporting game data are fairly complex, and we reached a point where a collection of scripts was no longer enough.
We’ve started restructuring things into more of a framework, which allows us to test new data structures more easily and spin up fresh environments quickly. This flexibility will be especially useful as we move closer to a more gameplay-ready state.
Weapons
Weapons are a crucial part of any game. Without them, we wouldn’t have much of a game, at least not the one we want to make. Luckily for us, we have weapons, and plenty of them.
Alongside those weapons comes a wide variety of attachments, including foregrips, pistol grips, lasers, LPVOs, large scopes, red dots, holographic sights, barrels, suppressors, gas blocks, stocks, buffer tubes, handguards, magazines, and more.
At the moment, each weapon has a smaller set of core animations. These include draw, holster, fire, fire empty, reload empty, and reload retention/full. We feel these animations are sufficient to begin development with since they cover the important interactions players will use most. More importantly, it allows us to continue focusing development time on other critical areas of the game instead of getting stuck perfecting animations too early.
I know, enough talking, let’s see some in action. These are not in-game captures but rather basic renders from animation software. Still pretty neat nonetheless!
Levels
We’ve gone through what feels like a ton of different level iterations during development. Some had their basic layouts completed, others only had a single town built, and a few were abandoned entirely.
Many of these early versions were experiments, either testing new features Unreal Engine released or trying different optimization approaches to see what worked best for us.
After going through all of that experimentation, we eventually decided to take a different approach. Instead of immediately building inside Unreal, we started by laying out the level in Photoshop. It’s a very simple approach: nothing too detailed, just a general idea of where major areas and locations should be. From there, we bring that plan into Unreal and start building it out.
Of course, with only two of us working on the project, this is a massive undertaking and will take time, there’s no doubt about that.
You’ll also notice that we use a number of marketplace assets. We know there’s a lot of controversy surrounding asset usage in games, especially with the number of asset-flip projects that exist today. That said, we aren’t using these assets just to drop them into the world as-is.
Our goal is to use them as building blocks. We customize them, modify them, destroy them, change their art direction, and integrate them into the environment so they fit naturally into the world. They serve as stepping stones that save time while still allowing us to craft the experience we want.
For example, the mall currently in our main level uses a marketplace asset pack. However, when built properly and integrated with the surrounding environment, we believe most players won’t mind to see that we used the pack that we did. We’re not simply copying full asset-pack levels into the world—we’re using the pieces to build something new.
We also rely heavily on blockout tools while building levels. Many areas begin as simple placeholder geometry, but if you see a blockout area, you can bet that it will eventually be built out properly later in development.
Below are some examples of past and current levels we’ve worked on.
As you can see, some of these levels are fairly bland or incomplete, while others are more developed but still not quite where we want them to be for Repressed. Our goal is to build a single large world that feels immersive and worth exploring. It will take time, but we hope the result will make that wait worthwhile.
Optimization Passes
We’ve spent a lot of time working with assets, many of which weren’t originally built by us. Because of that, we’ve encountered a variety of development approaches used by different creators.
Some assets rely heavily on newer Unreal Engine technologies, like Nanite, which can render hundreds of thousand, or even millions, of triangles in a single mesh. Traditional meshes, by comparison, might render around 10k triangles at LOD0 (LOD meaning Level of Detail).
Over time, we’ve experimented with nearly every rendering and lighting approach Unreal offers, including:
Forward shading
Deferred shading
Nanite and non-Nanite meshes
Virtual Shadow Maps
Distance field shadows
Mega Lights
Lumen
Fully baked lighting
After extensive testing, we’ve decided to pursue a hybrid lighting approach.
The idea is relatively straightforward. Outdoor environments will use Lumen, since large outdoor scenes benefit greatly from dynamic global illumination and tends to produce a more natural-looking environment.
For indoor environments, we plan to use a combination of baked lighting and dynamic lighting. Our day/night system uses movable lighting, meaning outdoor light sources update over time. This allows sunlight and moonlight to still influence indoor spaces through windows and openings.
However, the interior lights themselves will primarily rely on baked lighting to reduce performance costs. In theory, this gives us the best of both worlds—dynamic outdoor lighting while maintaining strong performance inside buildings.
We’re still testing this approach. It’s not something we’ve seen widely used in other games, but we’re willing to experiment and see if it works well for our needs.
Right now, the mall in our main level already uses baked lighting indoors while still retaining the sun and moon lighting from outside. Once the mall reaches a more finished state, we’ll run more thorough performance tests.
Mega Lights
We’ve also spent time experimenting with Mega Lights. The performance gains can be significant, but they come with a tradeoff: noticeable lighting artifacts in certain situations.
At the moment, we’re still evaluating whether Mega Lights are worth using. When we begin testing more intense gameplay scenarios, such as firefights with both players and AI, we’ll have a clearer idea of whether Mega Lights are something we want to fully commit to.
If we do use them, there’s a good chance they’ll primarily be used outdoors where their performance advantages matter the most.
Mesh Optimization
When it comes to meshes, we’ve decided not to use Nanite. While the technology is impressive, it’s still relatively new and somewhat unpredictable, especially for large open-world environments like the one we’re building.
Instead, we trust traditional LOD systems and mesh optimization techniques. With Nanite, you often rely on the engine to dynamically optimize extremely high triangle counts at runtime. In theory that works well, but in practice it doesn’t always behave the way we want.
Another major reason is our use of World Position Offset (WPO) for foliage and environmental interaction. WPO allows trees and plants to sway in storms, bend from explosions, react to nearby movement, and more.
Unfortunately, Nanite does not handle WPO well.
In our tests, a simple landscape filled with Nanite trees (without WPO) ran at around 120 FPS on a system with a 12th gen i7, RTX 3080, and 64GB of RAM. However, once we enabled our foliage sway and interaction system using WPO, performance dropped drastically—sometimes down to 40 FPS, and as low as 15 FPS in dense areas.
While Nanite can work well for static environments, it becomes far less ideal when you want highly interactive foliage that reacts dynamically to weather, explosions, and combat.
Because of this, we’re avoiding Nanite for foliage and most meshes in the world. Our goal is also to ensure the game runs well on mid-range systems, not just high-end machines.
We regularly test on what we consider a fairly average gaming PC today, and the performance results so far have been promising.
The Unreal RHI thread, however, definitely has some opinions about our builds.
Particles
Particles are another area we’re currently exploring and learning more about. They can be surprisingly difficult to optimize while still making them look good.
Right now we’re using Niagara particles, mainly for bullet effects and smoke.
When a player is hit, they emit a small blood particle effect and sometimes a smoke effect. The smoke effect spawns randomly and runs for a randomized duration, which helps add a bit of visual variation. We think it adds a nice touch to the experience.
Weapons also emit several particle effects when fired. A muzzle flash and muzzle smoke always play, and we’re continuing to refine them so the smoke behaves more realistically.
Our goal is to make gunfire feel believable and impactful. When a bullet hits a player, several effects can trigger:
Muzzle flash
Muzzle smoke
Armor impact effects
Blood effects (if the bullet hits flesh)
Smoke effects from the hit player
The impact effect behind the player
That can mean five or six particle effects per shot. However, most of these are lightweight single-layer effects with small footprints, so performance during testing has remained very stable.
That said, particle optimization is still an area we plan to spend more time on as development continues.
Closing
As you can probably tell, a lot of our work lately hasn’t just been adding new features, it’s been laying the technical groundwork that will allow us to build the rest of the game properly. Systems like the inventory refactor, the bullet simulation plugin, lighting experiments, and optimization work aren’t always the most exciting things to show, but they are critical for making sure the game can scale as development continues.
Right now, much of our time is spent testing, breaking things, rebuilding systems, and figuring out what works best for the kind of game we want to make. Some ideas stick, others get scrapped entirely, and sometimes we discover better approaches along the way. That’s just part of the process when building something like Repressed.
With many of these core systems now in a much better state, we’re finally reaching a point where we can focus more heavily on gameplay, world building, and expanding the experience. There’s still a lot of work ahead of us, but we’re excited about the direction things are heading.
As always, we appreciate everyone who continues to follow the development of Repressed. We’ll be sharing more updates, experiments, and progress as things evolve.
More to come soon.