The video offers a sophisticated technical autopsy that correctly identifies structural engine bottlenecks over mere developer negligence. It is an essential watch for understanding why raw hardware power often fails to overcome fundamental architectural limitations.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
This is Why WuWa Feels UnoptimizedAdded:
So, a little while back I made a video about how genuinely stunning Wuthering Waves looks and how even industry professionals were impressed with what Kuro was doing within Unreal Engine. The lighting, the environments, the character effects, and from the looks of things, the response was great. You guys loved that video, too. But, as I was reading through the comments, alongside all the hype, every now and then I'd see something like, "Looks incredible. Can't say the same about the optimization."
Or, "It's all good and cool, but Star Chaser Camp is a nightmare in terms of optimization." And look, those comments are completely fair. But, what I also noticed in those threads was either Kuro is lazy and doesn't care about optimization, or just upgrade your PC.
So, I got curious and went digging into the technical side of this, and here's the thing. According to this breakdown I found on github.io, both of those are wrong. It was a very deep technical analysis, and so I'm going to try to translate the important parts into plain English so we can all actually understand what's going on. So, in this video, we're going to break down what's actually causing the stutter in Wuthering Waves, why it's not as simple as just optimize it, and what Kuro is actually doing about it. So, with that being said, my name is Lucas Sensei, and this is what's going on with Wuthering Waves optimization.
First, the most important thing. When people say WuWa runs badly, they're actually talking about at least two completely different problems that often get lumped together. The first problem is what we'll call the city stutter.
That constant annoying micro stutter you get where just by walking around Star Chaser Camp or Setmont, for example.
Your FPS won't stay stable, and the frame pacing feels off. And here's the weird part. Your GPU is barely even sweating. You can have an RTX 4090 and still get this problem. More on why that is in a second. And the second problem is what we'll call the exit freeze. That hard zero FPS drop you get when you leave a city. You cross that boundary and the game just stops for 1 or 2 seconds. Then it's totally fine. Longtime players from version 1.0 will remember when this was particularly brutal. It's gotten better with patches, but it hasn't gone away completely. These two problems look the same because they both happen near cities, but they have completely different causes, and they need to be addressed in completely different ways.
There's also a third problem, which is specific to mobile, which is a graphical lag when lots of visual effects are on screen, but the main PC problems are these two, and understanding them changes everything. So, why does your expensive GPU sit around doing nothing while the game stutters? This is the part that surprises most people. Unreal Engine 4, the engine that Wuthering Waves runs on, processes all game logic through a single thread called the game thread. Think about what that means.
Every NPC deciding where to walk, every building with an interactive door, every particle effect, every quest trigger, every collision check, all of it has to get processed in sequence on one single CPU core before the GPU is even allowed to start drawing the frame. The article gives a great analogy that really helped me visualize the problem. So, imagine this. A highway with eight lanes, but there's only one toll booth. All the traffic has to funnel through that one point before it can move forward. It doesn't matter how many lanes you have.
It doesn't matter if the highway itself is a Formula 1 track, for example.
Everything waits on that one booth. In Wuthering Waves, the game thread is that toll booth. Star Chaser Camp has dozens, maybe even hundreds of NPCs and tons of interactive buildings, ambient systems, and quest logic. All of it is queuing up through that one thread, and it starts to clog up, in a sense. And when it's full, your GPU is just sitting there, idle, waiting for instructions that are stuck in line. A technical benchmark found that on a high-end system, like we're talking about an i7 with an RTX 5017 there, the game was hitting nearly 100% load on one CPU core while the overall CPU was only around 40 or 45% busy. And the GPU was averaging somewhere around 55% utilization. The hardware has capacity. It can do a lot more, but the bottleneck is the design.
And here's the part that really blows people's minds. More CPU cores won't help. Having a 16-core processor doesn't move the needle on this specific problem in the slightest. The work that causes the stutter, all that NPC and scripting logic, is hardcoded to one thread. The other 15 cores can't touch it. What does help a little is a CPU with a large L3 cache, like AMD's X3D processors, and I'll explain why in a moment. So, underneath the single thread problem, there's actually a second issue making it worse, and it has to do with how data is stored in memory. Unreal Engine 4 uses what's called object-oriented programming. Every single object in the game, every NPC, every brush, every building facade, everything, is its own individual thing sitting in its own random spot in your RAM. When the game needs to update 10,000 of these objects every frame, the CPU has to go and hunt each one of those individually all over your memory. A good way to picture this is to imagine a librarian who needs to look up 10,000 books, but the books were shelved wherever they happened to fit when they arrived. So, they're not put away in any particular order. The librarian has to walk across the entire library, up and down, up and down for every single book. And that back and forth walking time adds up massively, even if reading the book itself is quite fast. That walking translates to CPU slowdowns called cache misses, when the CPU has to fetch data from slow main memory instead of fast nearby cache. And these checks happen thousands of times per frame in a dense city. This is why AMD's X3D CPUs, which have a massive amount of extra L3 cache, help a lot more with Wuthering Waves specifically.
More cache basically means like the librarian has a bigger desk to keep books nearby. She still has to make trips, but far fewer of them. It doesn't get rid of the problem entirely, but it can significantly reduce the worst of it. Some other games, like Arknights: Endfield, are built on an architecture called DOD, or ECS, where all the data for similar objects is stored together in a neat row. Basically like having all the books on one topic shelved right next to each other. The CPU obviously loves this. It makes their job a lot more easier, and that's part of why those games handle lots of characters and effects more easily. But, WuWa's engine simply wasn't built that way.
Now, for the second problem, the hard freeze when leaving a city, this one has a different villain, a different frenodian, if you will. Something called V8. Kind of like Aleph One, but different. Wuthering Waves has a scripting layer running underneath the gameplay built on a system called Peritus, which uses V8. The same JavaScript engine that powers Google Chrome. This has been confirmed by game log files and binary analysis. The reason it exists is developer convenience. The team can code and update the game quickly without recompiling the whole game engine every time, like they would need to do so in C++. The problem with V8 is what's called its garbage collector.
While you're inside the city, the game is constantly creating small chunks of data, NPC behaviors, interactions, quest triggers, stuff like that. And over time, these things pile up. And when you leave the city, V8 decides it's time to clean house. And here's the painful part. V8 does its big spring clean in what's called a stop-the-world pause. Everything freezes while it tidies up. So, for anywhere from half a second to two full seconds, your game is at zero FPS. Then it's completely fine. That's pattern two, and that's the exit freeze. The version 3.1 patch actually improved this by fixing the asset streaming side of the problem.
The game now unloads city data faster when you leave, but the V8 garbage collection part is still there. Fixing it completely would need a much bigger change. So, what's Kuro doing? Actually, something pretty significant. They're just not out there bragging about it because it's technical infrastructure stuff that's invisible to players, and it doesn't really sound as exciting as it actually is. What they're doing is is they're migrating their scripting layer from TypeScript, which uses V8, to C#, which doesn't. C# uses a completely different garbage collector that works incrementally, spreading its cleanup work across multiple frames piece by piece, instead of doing one big freeze.
What this means is that even the worst-case pauses go from potentially several hundred milliseconds down to single digits. Evidence of Kuro making this switch can be found in the game's own data files since back in version 2.8, when these new C# config entries started appearing. By version 3.1, more and more systems had been moved over, but it's an ongoing process that will take a few more patches to fully complete. They can't just flip a switch and move everything over at once on a live service game. And that's the key context. They're doing all of this while maintaining a 6-week content release schedule. It's kind of like they're rebuilding and replacing the engine of a car while it's driving. Every new character, area, and every event that they release on the new C# path has less performance risk than it would have on the old V8 path, and that value compounds over time. What this change does not fix, however, is the game thread single core ceiling. That lone toll booth is still out there on the CPU data highway because it's is a structural limitation of Unreal Engine 4 that, unfortunately, no patch can ever fully solve. Now, let's talk about the comparisons that everyone makes. Why Why Genshin feel smoother? Genshin runs on Unity, which has an architecture that's naturally closer to that cash-friendly DOD approach we talked about earlier.
And Hoyoverse had over a decade of experience building and customizing Unity before Genshin even launched with the experience from their other title, Honkai Impact 3rd. This means that they had an enormous head start knowing exactly how to push that engine to its limits. Plus, it's worth noting that Genshin has a significantly lower graphical ceiling than Wuthering Waves.
It's a different game with different constraints.
Now, what about Hogwarts Legacy? This is the comparison that should really settle the Kuro is lazy argument. Hogwarts Legacy was made by Avalanche Software with a Warner Brothers budget. It runs on Unreal Engine 4.27 and at launch, it had almost identical stutter complaints. It was CPU-bound in dense areas like Hogsmeade, GPUs underutilized, and throwing more CPU cores doesn't help.
Community members diagnosed the exact same single-thread problem independently. Hogwarts Legacy is an offline linear game without the additional complications of being a live service game with mobile support or a 6-week content schedule. And it still had the same problem because it's the same engine. The issue isn't Kuro's quality of work. It's that no open-world game on Unreal Engine 4 has solved this.
Not one. And here's what I think is the most honest takeaway from all of this.
Wuthering Waves is trying to do something genuinely ambitious. Open world, high-end visuals, densely populated cities, complex combat VFX, cross-platform all the way from budget phones to high-end PCs on a 6-week live service release schedule, and all on an engine not purpose-built for this combination. No other gacha game on the market right now is doing all of these things simultaneously on this engine at this level. Cyberpunk 2077 and Red Dead Redemption 2 run on custom engines that studios spent decades building specifically for open-world performance.
So, the comparison is a little unfair.
It's like asking why a production car doesn't keep up with a Formula One car.
They're built for different things with different resources over a completely different timescale. Kuro continues to work on this. Performance patches appear in nearly every major update. The migration from TypeScript to C# is real and ongoing. The version 3.1 improvements made a measurable real-world difference for the exit freeze. And these are incremental steps, not magic fixes, but they're real nonetheless. So, next time you see someone in the comments saying something like, "Just optimize the game. It's not that hard." You can point them to this video. And next time you see someone say, "It's a skill issue. Just upgrade your PC." Also, point them to this video, too, because upgrading your GPU won't help a CPU-bound bottleneck. And I'll be clear, I've been guilty of this as well just saying, "Why can't Kuro just optimize this?" So, reading this article was really enlightening for me because the honest answer is that this is an engine architecture problem compounded by the reality of live service game development and a lack of documentation compared to other engines out there. Kuro is making real progress.
It's just slow because the right fixes are hard, and they're doing it all without stopping the game. I'll leave a link to the GitHub article in the video description, and I'll be fully clear, I I'm not sure if everything is 100% correct. There was a lot of technical stuff that went way over my head, but I did my best to read through and understand it to make this video. If you have any experience in this field, and if there was anything off with the information in this video, please let me know down in the comment section below.
Not only for me to learn more, but for all of us to understand a bit more about the process. And if you found this video useful, don't forget to like and subscribe cuz it greatly supports the channel. Also, let me know down in the comments, do you have any lag or stutters when you play Wuthering Waves?
And if so, where? Where is it like the worst for you? And don't forget to be kind and respectful, guys. It's in short supply lately. But anyway, yeah. Uh so, until next time, I will see you in the next video.
Peace.
Related Videos
VALORANT's Latest 'Exclusive' Tier Bundle is Rough...
KangaValorant
17K views•2026-05-28
Flight Attendant Mocks Poor Looking Black Woman — Mid Air Announcement Exposes Her Real Power
SkyboundStories-b4r
184 views•2026-05-28
I FIXED My Friend’s Blown Turbo RX-8… Then Sold It
Cameron-RX8
134 views•2026-05-28
NewsWatch 12 at 5: Top Stories
NewsWatch12
1K views•2026-05-28
Simon Jordan & Danny Murphy deliver PREDICTIONS for Arsenal's Champions League FINAL with PSG
talkSPORTArsenal
6K views•2026-05-28
Botting is OUT OF CONTROL in Classic WoW (Again)...
SolheimGaming
108 views•2026-05-28
The "AI Job Apocalypse" is CANCELLED!
WesRoth
9K views•2026-05-28
STREET FIGHTER 6 - INGRID Story Walkthrough @ 4K 60ᶠᵖˢ ✔
RajmanGamingHD
12K views•2026-05-28











