Ember and Blade is made by Nine Lives, an in-house development studio at LINE Games, and the studio has been unusually open about how the game is built. Its central technical problem is stated plainly: put a thousand enemies on screen in 3D and keep the build light enough to run on a handheld. This page collects what the studio has published about the team and the engineering behind that goal.
The Studio
Nine Lives describes itself as an in-house game development studio at LINE Games, based in Seoul, South Korea, formed in April 2024 and currently making Ember and Blade. LINE Games remains the publisher, and both storefront listings credit LINE Games Corporation as developer and publisher, so Nine Lives is the team inside that company rather than a separate legal entity.
The studio publishes a credited team page of fifteen people covering direction, design, art, programming, animation, modelling and technical art, listing each member by working handle rather than by name. Its stated way of working is to build small and connect deep, and to make, show and fix quickly rather than follow a fixed plan. Two of the game's cats, Shay and Lumi, double as the studio's mascots and front its blog, with Shay posting community news and Lumi keeping the development log.
Engine and the One Versus One Thousand Goal
The game runs on Unity, and the studio has since named the exact version: Unity 6.3 LTS. The founding question during prototyping was whether a one-versus-one-thousand loop was viable in a 3D environment at all. The technical director has explained that this is cheap in 2D, where an extra monster costs roughly one more sprite, but expensive in 3D, where every additional entity adds draw calls, skinning, shadows, animation and culling. Simply spawning a thousand enemies produces severe frame drops, so solving that was treated as the starting point for the premium survivors-like the team wanted to make. An early prototype rendering nine hundred enemies was published as proof the approach worked.
How the Hordes Are Rendered
The studio has described a deliberate split in how enemies are built, driven by the fact that trash mobs and bosses need opposite things. Bosses had to stay as mechanically rich as a soulslike encounter, while ordinary demons only need to be swept away convincingly.
Tier | Technique | Why |
|---|---|---|
Elites and bosses | Skeletal meshes with traditional bone animation | Expensive per character, but their low numbers keep the cost manageable, so quality is not compromised |
Trash mobs | Vertex Animation Textures, with identical meshes drawn together by instancing | Reads pre-baked animation from textures instead of skinning, which limits animation variety but is not a problem for enemies whose job is to be hit |
Alongside that split, the studio uses an entity component system to process the logic of thousands of entities at once, and GPU instancing to draw repeated meshes in a single pass. Backgrounds were treated the same way: meshes merged where possible, assets reused aggressively, and distant objects simplified, on the reasoning that players look at the area immediately around their character. The bosses that justify the expensive pipeline are covered on Bosses and Judicators of Fate.
Effects and Memory
The studio has said effects were the part it underestimated. Once a thousand enemies were on screen, every strike produced a hit effect, every kill a death effect, and Blessings rained down on top of both, pushing the active effect count well past the enemy count. Unity's built-in particle system simulates on the CPU and handles hundreds of particles comfortably but struggles in the thousands, so the team moved its main effects to a GPU-based system, rebuilding every existing effect in the process. A later optimisation draws many copies of an effect from a single instance rather than cloning it per hit.
Memory is handled by pooling. Damage numbers, newly spawned enemies and effects are pre-allocated and recycled, because creating and discarding hundreds of objects a second would make cleanup alone a heavier cost than the game logic. One consequence is worth knowing as a player: enemies never truly disappear when they die. They return to a queue and come back in a later wave wearing a different look, which is described on Enemies and Demon Hordes.
Public Technical Talks
The team presented this work publicly at Unity's Seoul developer conference in July 2026, in a session titled Hundreds of Enemies, One Lightweight Build, delivered by a technical director and a technical artist from LINE Games and covering rendering, effects and memory optimisation. A playable build also appeared in the conference's Made with Unity showcase. The studio has published the session recording and its slides, and returned to the same material in an August 2026 developer note. Shader warmup using pipeline state objects was named as an area still being worked on, adopted only in part because the results were not yet where the team wanted them.
Direction and the Combat Rebuild
The most consequential development decision so far was announced in June 2026, when the game's director, credited as J. Kim, said the next demo would rebuild combat rather than polish it. The reasoning given was that every update since late 2024 had pulled the game in the same direction, toward faster movement and more active play, and that the team had not gone far enough. That decision is what produced the combo system and active blessings described on Combat, and the build history behind it is traced on Demo History.
The studio's framing of the optimisation work is that it should be invisible. In its own words, the better it is done, the less noticeable it becomes, and the intended outcome is that a player notices nothing and simply cuts through enemies smoothly.