Hi! I’m Dmitry Ulitin, Senior Game Designer on War Robots project.
When we decided to add the SWORD Unit 190 robot to our game, we knew we were taking on a serious challenge. For the first time in the game’s history, a robot would wield a sword — a melee weapon in a world where everyone was used to guns and long-range combat. We had already experimented with close-quarters combat using certain robot weapons, but it was never truly “melee”: harpoons and AoE weapons came close, but there had never been a true “sword.” So this time, we wanted the robot to get right up in the enemy’s face — and to do that, we had to build a new system.
But the new weapon wasn’t a “sword-gun” — it was a sword inside an ability. In other words, it activated after a leap and had to match the gameplay of the robot’s concept.
The concept was created in collaboration with the legendary Kunio Okawara, a designer known for creating robots for many other franchises. This time, Okawara-san designed a robot specifically for our game.
It seemed simple: a robot with a sword — a familiar idea, done many times before. But when we started implementing it, we realized there were tons of technical and creative problems we hadn’t even considered at the concept stage.
How Do You Make Melee Combat in a Shooting Game?
The first and most obvious problem: how do you implement melee attacks in a game where the entire combat system is built for ranged fighting?
We took the simplest approach: we used a regular gun, but made it fire within a predefined area rather than in a straight line. Technically speaking — it “shot” inside a collider. This collider shape is built from primitives, like blocks in a construction set, but invisible to the player. That let us use the game’s existing gun logic. The only difference: there’s no projectile flight — the damage is dealt instantly to everyone inside the collider at the moment of attack.
This is similar to systems used in fighting games and slashers — we just adapted it for our needs.
A key detail: the collider has to be slightly bigger than the sword’s actual visual model. Otherwise, players would miss even when their hits look accurate. We enhanced this effect with a visual trail — when the sword strikes, it looks like it leaves behind an energy arc.
When the Robot Is Too Fast
So we figured out how the robot would strike, but our concept also called for a raider — a robot that could fly and use its aerial position in combat. In other words, it needed to reach enemies mid-air. On paper, the concept was awesome: the robot dashes at an enemy from the sky using the game’s physics engine. It was meant to look cool and dynamic. And we thought it would.
In reality, targeting caused a big issue. The robot would accurately fly to the enemy’s position — but often overshot, “flying through” them, and the hitbox was too small to land the strike once it landed. Even with the slightly larger invisible collider, it wasn’t enough. Worse still — the robot would fly through the ground because it was moving too fast. The physics engine wasn’t designed for that, especially when syncing between multiple players.
Passing through walls was rarer, so it seemed like a low-priority issue at first. We assumed there were settings that could fix the behavior — but there weren’t. We had to try other solutions.
First Iteration: Speed Boost
We gave the robot extra ground acceleration — basically, it started running faster with the sword. This helped it reach enemies and land hits even if it overshot in the air. It helped, but playing tag with enemies was still clunky.
Second Iteration: Larger Hit Zone
This almost fixed the original problem. But the more we tested, the more often the robot clipped through walls and terrain. We started to think the default physics engine just wasn’t up to the task.
Third Iteration (Most Risky): Rewrite the Physics
We created a custom layer on top of the game’s physics. The robot would now move from point A to point B using a controlled algorithm. The base physics were still there, but collision detection and pathing were handled by code. That solved everything — now the ability worked smoothly and reliably.
But How Do Robots Swing Swords?
Our animators are pros at animating machines and robots — we do it all the time. A game designer gives instructions, and animators bring the robot to life. But a robot with a sword was a different beast. After meeting with the art team, we realized the risk was higher this time and asked animators to sketch out ideas in advance.
We explored different attack styles: cross-slash, overhead, spinning slash…
The animations looked great — but not all of them worked for gameplay. We started importing them into the engine and testing how each swing looked from behind (since War Robots uses a third-person rear camera). No point in making an epic swing that players can’t even see.
Game designers, animators, and VFX artists all met several times. This complex animation required tight collaboration between departments. We also studied other games with similar melee mechanics to see how they handled sword attacks.
Eventually, we settled on a balanced animation that looked mechanical, fit the gameplay perfectly (a side sweep), and let us fine-tune the timing.
Even our producer got involved — he filmed himself demonstrating different sword swings to give feedback.
When the Animation Lives Its Own Life
So we had a new animation and a new hit system — but one problem remained: the animation wasn’t synced with the sword hit. The swing would play visually, but the damage came a moment later. It looked terrible.
In War Robots, we usually build mechanics first and visuals later. Here, the ability triggered two parallel processes: the animation and the “shot.” Just three seconds total, but any lag between clients caused desync between the two. This had to be fixed.
It was especially noticeable when players saw a SWORD Unit flying toward them — the swing played, but the damage came later.
We urgently reworked the animation so the swing would restart only when the “shot” triggered. And we reworked the shooting logic too: our sword was no longer just a gun firing a burst — now each attack was a single hit, with the interval controlled by the server.
This allowed us to sync the animation and hit more precisely.
To smooth the effect, we made each swing deliver three hits — just like in anime: the robot slashes once, but lands three strikes at 0.1-second intervals. That way, it looks like the sword is slicing through the target multiple times.
The Final Result
After all this work, we ended up with a robot that truly fights with a sword. Each challenge forced us to invent new solutions — from adapting fighting-game-style colliders to building our own impulse-dash system.
Creating the sword robot required collaboration between programmers, animators, game designers, and VFX artists. But when everything came together, it created a unique experience never before seen in War Robots.
The SWORD Unit 190 didn’t just become a new robot — it opened the door to melee combat in the game. And now that we know how to tackle these challenges, you might be seeing more sword-wielding robots in the future!
