For the development team behind DragonSword: Awakening, building a new open-world action RPG meant heavily modifying Unreal Engine 5. The game pairs a bright, anime-inspired aesthetic with a 19-character tag-team combat system, all set across a massive map. In this recently released game, we follow a boy named Lute across the Continent of Orbis. It’s a game that we love a lot. So much so that we gave it a 10 out of 10!
The team behind the game was kind enough to break down the technical and design realities of the project. We discuss custom shading, the necessity of overhauling UE5 for portable hardware, and the strict physics rules required to make rapidly swapping characters feel heavy and responsive.
Taming Unreal Engine 5
The leap to Unreal Engine 5 usually means a focus on photorealism. DragonSword uses the engine’s advanced lighting instead to power an anime-inspired art style. This clash between physically based rendering (PBR) and toon shading required a custom solution to ensure characters fit naturally into shifting weather and times of day.
Since Unreal Engine 5’s rendering system is fundamentally built around physically based rendering, the biggest technical challenge was maintaining a realistic lighting environment while still consistently expressing the sharp contrast and warm color tones distinctive to an animation-style look.
To solve this, we built our own stylized shading approach that layers toon-style shading and realistic material rendering on top of PBR-based rendering. For shadows and highlights, we leaned more heavily into toon shading, which makes the boundaries and shapes of light and shadow read more clearly, while for areas where material properties matter — like metal or specular reflections — we actively leaned on PBR’s realistic representation. Rather than flattening every element into a simple toon style, we adjusted the balance between the two approaches depending on what we were trying to depict.
Another difficulty was making sure this style stayed consistent not just under one specific lighting condition, but across real-time shifts in time of day, weather, and regions with entirely different moods — rather than only looking good in a narrow, curated setup. While making use of Unreal Engine’s various lighting and environment systems, we continuously fine-tuned things so that character shading wouldn’t swing too far into realism, or lose its animation-style form, as the environment changed.
Since this is a game with a lot of fast-paced action in particular, character silhouettes, motion, and attack effects needed to read clearly even in the middle of combat. So rather than shading that just looks beautiful in a static screenshot, we put a lot of effort into keeping contrast and highlights stable through character movement and shifting lighting.
Ultimately, the core of our stylized rendering wasn’t using UE5’s advanced lighting and environmental rendering exactly as-is in a realistic way, but selectively reinterpreting its strengths to fit our animation-style art direction.
Beyond the art style, the team had to ensure the game performed smoothly during combat, particularly on portable hardware.
The biggest technical challenge was getting the sheer scale of an open world to run smoothly even on portable devices. By nature, open-world action games don’t have a consistent load — there’s a huge gap between the load while exploring the field and the load during combat moments when skills are chaining rapidly. And in an action game, frame drops directly translate into damaged input feel, so our goal wasn’t the average framerate, but making sure the rhythm of the action never broke down even in the worst moments.
To achieve this, we made sweeping modifications to the foundation of UE5’s open-world systems. Rather than using the engine’s default functionality as-is, we reworked the engine itself to match the characteristics of each device. As one example, we applied HLOD differently per device — maximizing draw distance and detail on desktop, while ensuring sustained performance on portable devices within their power and thermal constraints. A portable device isn’t simply a “lower-spec PC” — it’s a separate platform where sustained performance matters more than peak performance, so there were quite a lot of engine modifications specialized for PC and portable respectively.
Another area we paid a lot of attention to was PSO cache optimization. Most stuttering originates here, and these momentary hitches barely show up in benchmark averages, but players notice them instantly. In particular, if a stutter happens right when a new effect or enemy first appears, it kills the feel of combat outright — so we put a lot of effort into improving the PSO cache, making sure the experience stays smooth from the very first fight, no matter the device.
In the end, this whole process came down to deciding “how far we’d adjust, and what we’d never compromise on” — and our answer was always the responsiveness of the action.
The Reality of Open-World Scope
Creating a seamless map brought its own set of problems. Moving players from open fields into tight underground spaces without obvious loading screens meant compromising on certain traversal ideas.
We actually tried designing a sequence where, after solving an ancient mechanism at a ruin overgrown with massive trees, players would drain a lake and descend vertically from the surface into an underground arena via a mysterious elevator that had been submerged at the bottom. In the end, we had to scrap it because it felt too disconnected from the rest of the existing world.
Instead, our more general approach was to shape entrances in an S-curve, placing fog and narrow rock gaps along the path. This naturally obscures the player’s view with fog and terrain while buying enough time for the next area’s data to stream in — all without the player ever noticing the transition happening behind the scenes.
Managing a project of this scale also changed how the developers approach early production and world layout.
The hardest lesson was that the precision of your initial design determines everything that follows. This applies just as much to the initial terrain layout as it does to the compatibility, combinations, and roles among the 19 characters — including ones we knew we’d add later. Structures like these need to be laid out as tightly as possible at the very start of the project. Once you start revising, it’s never just that one piece — whether it’s terrain or character relationships — you end up having to tear apart and redo everything connected to it.
The bigger the scope of a project — and open worlds are about as big as it gets — the riskier a “build now, polish later” approach becomes, because the amount you’ll eventually have to revisit grows exponentially. Our advice to other developers preparing something similar would be: don’t rush to build flashy content first. Invest the time upfront in solidly designing your initial terrain layout and the relationships between characters. Once that foundation is solid, expanding content afterward actually becomes much easier.
Momentum and Tag-Team Mechanics
The game’s foundational design extends to its 19-character combat system. Players constantly swap heroes to stack status ailments, but maintaining a sense of weight during rapid character transitions required specific rules for hit-stop and physics.
When you switch through Signal Switching, the character you swap out doesn’t just disappear — they stay on the field and finish whatever action they were already performing. We designed combat around a structure where more than one character can hit the same target at the same time.
Hit detection on monsters is processed individually per character, so a hit that lands later doesn’t get swallowed up by an earlier stagger/hitstun.
On top of that, hit-stop only applies to the character you’re currently controlling. If hit-stop froze the screen for the leftover character’s hits too, the freezes would stack up every time you swap, and combat would end up feeling choppy. We treat hit-stop not as an effect applied to the world, but as a response tied specifically to the player’s own input.
As a result, hits keep landing continuously out in the field, while weight and impact are concentrated only on the character you’re actively controlling. The hit response stays consistent no matter how fast you swap.
Alongside the main roster, players also collect Familiars. The developers decided to split companions into these two distinct categories to serve different roles.
We deliberately split Heroes and Familiars to serve different roles. Heroes are combat companions you build the fight with together — swapping in and out through tag action to chain combos, and linking status effects to trigger each other’s signal skills. They’re meant to feel like partners you’re actually syncing up with in battle. Familiars, on the other hand, exist to make mounts feel like companions who roam the world alongside you, not just a means of transport. We prepared many familiars with different appearances and traits, rather than limiting it to one type, both to make travel itself enjoyable and to add the fun of collecting.
With 19 playable characters, several combat synergies were eventually scrapped or reworked.
Honestly, most of the ideas that didn’t work out ended up being scrapped so thoroughly that we barely remember the specifics anymore (laughs). What actually stuck with us more was a different kind of regret. Some combinations were clearly well-designed at the concept stage, but under the original service structure, players who hadn’t acquired a particular character simply never got to see that interaction play out.
For example, Othello’s ice spear can be detonated by Cerese, and Dana reacts to it as well. And when Dana’s summon Chako grows larger, Othello’s skill reacts to that in turn. These layered signal-trigger interactions, designed around specific character combinations, just weren’t visible to a lot of players because of how hard certain characters were to acquire — and that was the part that genuinely disappointed us. Fortunately, that’s all been resolved in the current Steam version, so players can now fully experience the combination fun we originally intended.
The Burden of Living Legends
DragonSword‘s timeline is set exactly 60 years after the original six heroes defeated the dragon. It’s an unusual gap—long enough for the world to move on, but short enough that the heroes are still alive. Meeting these aging legends directly affects how the young protagonist, Lute, views the world.
Sixty years felt, to me, like the most delicate and realistic length of time.
The idea that living legends exist, and that you could still go meet one, is a genuinely exciting premise. Some people look at them and dream of becoming that themselves someday; others might already see them as faded glory and shrug them off. What matters is that because they haven’t fully calcified into pure myth, all of these different perspectives and judgments can coexist.
Zoom out, and you’ll find people who are indifferent even though these figures are still alive, people who dismiss the events of 60 years ago as a made-up story, and even people who don’t know it happened at all. I felt that wasn’t so different from how we actually live in the real world.
On top of that, the heroes themselves have grown old now, each tangled up in their own lives, convictions they still hold onto, stubbornness, and competing interests. I wanted to create a world where characters like that could exist alongside a mix of complicated opinions and judgments about them.
And in this world, Lute is a boy who dreams of becoming a hero.
As Lute meets them, he sometimes sees the hero he imagined confirmed right in front of him, and sometimes he’s disappointed. He might betray them, or be betrayed by them. Because of this ambiguous distance, Lute can never look at them purely as “heroes.”
That’s why his dialogue always carries two things at once: admiration and respect toward them, and the kind of boyish honesty that still won’t look up to them unconditionally. And yet, precisely because of that distance, the boy who wanted to become a hero ends up building his own values and growing into a new kind of hero for this era. In that process, Lute reflects something back at these old heroes — something only a boy can show them. Almost like reminding them of a youth they’d long since forgotten.
Thank you for reading, we hope you enjoyed our interview. If you’d like to know our thoughs on the game please stop by and read our review as well:
Leave a comment