1 vs. 1,000: Achieving Technical Excellence
Hi everyone, this is my first time writing to you. I’m Danny, the Technical Director of Ember & Blade.
In this developer’s note, I’d like to share the technical challenges our small team tackled, and the engineering behind Ember & Blade’s massive 1 vs. 1,000 Musou-style combat.
──────────────────────
1. Prototyping
Before we officially started development, we had just one question we wanted to answer during our initial prototyping stage:
"Is a 1 vs. 1,000 gameplay loop actually viable in a 3D environment?"
Ever since I was a kid playing games like Dynasty Warriors, I’ve always had a deep passion for action games where you carve your way through endless waves of enemies.
That’s why we started Ember & Blade with a single, clear mission: to build a 3D Survivors-like that lets you mow down enemies in 1 vs. 1,000 combat, while capturing that classic Musou-style flow.
This isn't much of a challenge in 2D, because the cost of rendering one more monster is as cheap as drawing a single sprite. In 3D, however, it turned out to be a highly daunting challenge.
Each additional entity brings along various costs like draw calls, skinning, shadows, animation, and culling. If you simply tell the engine to 'Spawn 1,000 mobs!'—severe frame drops are an inevitable consequence.
Finding a technical solution to this was the starting point of the Premium Survivors-like we envisioned.
Consequently, our first step was to determine the best approach for 'high-volume rendering.'
We used ECS (Entity Component System) to process the logic of thousands of entities, GPU Instancing to draw the same meshes all at once, and VAT (Vertex Animation Texture) to bake animations into textures ahead of time. VAT, in particular, was one of the critical keys to building our 3D Survivors-like.
The following video shows an early prototype rendering 900 mobs using ECS, GPU Instancing, and VAT.
──────────────────────
2. High-Performance Monster Rendering
The VAT technology we adopted is rarely used in action games because animation blending is notoriously difficult and the number of animations is strictly limited.
In practice, if we optimized every single monster this way, bosses and elite monsters would lose their sense of weight and impact.
That wasn’t what we wanted.
We wanted our bosses to be as formidable and mechanically rich as those in a Soulslike, while the trashmobs would be satisfyingly swept away.
Because the requirements were so different, we split our monster creation into two separate pipelines based on their tier.
For elites and above, we use skeletal meshes and traditional bone-based animations. While this approach is expensive, their low numbers make the performance cost highly manageable, meaning we didn't have to compromise on quality.
For our trashmobs, we utilize VAT. Rather than processing skeletal meshes, it reads pre-baked animation textures. This virtually eliminates skinning costs, and identical meshes are grouped together via instancing to be rendered all at once.
VAT limits animation variety and blending, but neither is a critical requirement for trashmobs, whose primary role on screen is simply getting hit anyway.
The following video shows how much we gained in terms of frame rate and draw calls before and after implementing VAT.
The same principle applies to the background. With 1,000 mobs running around on screen, we simply didn't have the performance budget to go all-out on background details.
We merged meshes as much as possible, reused assets aggressively, and ruthlessly simplified distant objects. Since players mostly focus on the immediate area surrounding their character, think of it as a conscious choice to focus our visual polish on the center of the screen.
──────────────────────
3. Maximizing Efficiency via VFX
One thing we completely underestimated during development was the visual effects (VFX).
We figured that if we could manage the 1,000 monsters on screen, we would be in the clear. However, once we actually started building, we realized that combat and hit effects didn't just stop at 1,000. Every single strike triggered a hit effect, every kill spawned a death effect, and blessings constantly rained down on top of it all—instantly ballooning the active VFX count far past 1,000. No matter how efficiently we rendered the monsters themselves, the sheer volume of effects dragged our frame rate right back down.
Unity’s standard built-in Particle System is the default choice for handling visual effects in many Unity games. However, because these simulations run on the CPU, they work beautifully for hundreds of particles but struggle to handle them in the thousands.
To solve this, we transitioned our primary effects to VFX Graph—a GPU-based effects system—effectively offloading the simulation workload to the GPU. Since GPUs excel at massive parallel processing, the number of active particles we can now support is on a completely different order of magnitude.
It was a massive undertaking that required completely changing our VFX workflow and rebuilding every existing effect from scratch, but you can see the results for yourself in the video below.
This clip features 'Crush on You,' one of Selaphiel’s blessings. It floods the screen with particles, yet runs smoother than ever. Because it’s an early skill, we luckily preserved both the CPU-driven Unity Particle System and VFX Graph versions, making it the ultimate comparison piece.
In addition, we're taking things a step further by using VFX Graph's newest features for optimization. Recently, we introduced VFX instancing via Graphics Buffers. Previously, every hit required cloning the effects individually, creating cloning overhead and preventing instancing from working properly. Now, with Graphics Buffers, we only keep a single VFX instance active, and that single instance draws multiple effects simultaneously.
Remiel's 'Zap Flick' was the very first blessing to benefit from this optimization. As you can see in the video, there is a stark difference between cloning and rendering each card individually versus drawing them all at once via Graphics Buffers.
──────────────────────
4. Reuse, Recycle, Repeat
While the story so far has been about 'how we render,' this final chapter is all about 'how we conserve’.
In fact, a huge chunk of what you see on screen is actually pre-allocated behind the scenes using Object Pooling. Damage indicators, freshly spawned monsters, exploding VFX—nearly everything is constantly being used, reclaimed, and recycled.
The reason is simple: on a 1 vs. 1,000 battlefield, hundreds of objects spawn and vanish every single second. Creating these objects fresh and discarding them every time would make game logic the least of our worries; the constant memory cleanup alone would make the game incredibly heavy.
That’s why monsters in our game never truly disappear when they die. Instead, they return to the queue and reappear as "new" monsters in the next wave. In other words, that monster you just slashed down might be running right back at you a moment later, just with a different look.
This same principle applies to background assets and other resources. Reusing background assets and textures across multiple areas keeps the build size light, reduces the memory footprint, and shortens loading times.
──────────────────────
Final Takeaways
To ensure you can fully enjoy seamless 1 vs. 1,000 Musou-style combat, we are constantly researching and prototyping various new technologies every day.
For instance, modern graphics APIs offer shader warmup techniques that pre-compile shaders using PSOs (Pipeline State Objects)—a technology that is still actively evolving.
Currently, the warmup results aren’t quite where we want them to be, so we are only adopting certain parts of this method. However, we fully intend to actively implement this technology as Unity provides more advanced warmup methods in the future.
Bringing what once seemed like a reckless challenge to life has involved a tremendous amount of trial and error—and we expect there is still plenty more ahead.
You’ll be able to experience the fruits of these efforts firsthand in our upcoming demo, releasing on September 3. Optimization is, by nature, an invisible art; the better it is done, the less noticeable it becomes. If you don't notice a thing and can simply slash through enemies with satisfying fluidity, that is the best outcome we could have hoped for.
We unpacked these optimization concepts in detail during our talk, 'Hundreds of Enemies, One Lightweight Build,' at Unite Seoul 2026. If you'd like to see the full story behind our engineering process, please watch the video below.
[Unite Seoul 2026] 수백 마리의 적, 가벼운 빌드:〈엠버 앤 블레이드〉로 만든 3D 뱀서의 비주얼과 최적화
The presentation slides are also available through this link: https://nine-lives.dev/insights/unite-2026.
If you have any questions regarding performance or our technical approach, or run into any issues while playing, feel free to leave a comment or join our Discord to let us know. We remain dedicated to continuously refining our performance to deliver an even smoother experience.
To wrap things up, here is a behind-the-scenes look at how the shader warmup runs in the background on the Ember & Blade loading screen.
— Danny, Technical Director