Inspiration
Hi, I’m Neo, and I’m the lead developer for Ninja Clash. Two years ago, I set out to answer one question: what would it feel like to be a ninja in VR?
What is Ninja Clash?
Ninja Clash is a 4 player multiplayer PvP game made for shonen anime fans. The rules are simple: be the last person standing for three rounds.
(Since launching the game in October 2024, the game has reached more than half a million lifetime active players, and has consistently stayed in the top 20th percentile for weekly retention (both @7d and @28d) in comparison to other apps on the store. As somebody who has clocked more than a thousand hours on anime PvP games and even met my partner through one, when I started the game, I knew that anime fans were underserved on the quest store, but I had no idea how high the demand would be!)
I designed this game specifically to take full advantage of the medium of VR. Take the kunai for example: you can precisely manipulate them with your hands, and wherever you place them becomes a marker you can use for teleportation. And yup, you can walk on any surface, including walls and ceilings. It’s a uniquely crazy thing to experience in VR.
Unlike some other VR games, you use the joysticks to move. This frees up your hands to perform hand signs, where you precisely match the position, rotation, and finger openings of your hands in specific sequences to cast ninjutsu. If you were a kid that memorized ninja hand signs in real life, you can finally use that same knowledge to perform real ninjutsu in game!
Each technique in the game tries to utilize full body movements as much as possible for maximum immersion. For example, if you want to sprint, you need to put your hands behind your back. If you want to super jump, you need to swing both your arms up. If you want to summon an earth spike, you need to crouch in real life and touch both your hands to the floor.
What did I work on for this competition?
From October to November, I worked on Ninja Clash’s latest jutsu: Paper Bombs! Anyone familiar with ninjas knows about this iconic ninja tool. These explosive devices can stick to any surface, and can be made even more versatile by attaching them to kunai. In October, I worked on prototyping the paper bomb’s basic interactions. In November, the time period of this competition, I worked on getting the paper bombs game ready, adding additional features and multiplayer support.
October: An Unforeseen Pivot
When I started what would become the Paper Bomb update in October, I actually didn't start working on paper bombs at all. I started the month prototyping two other jutsu: "water style: piercing stream" and "wind style: air slash". I hadn't been able to release a new gameplay mechanic for a long time, due to critical work on other parts of the game's infrastructure, so I wanted to add two new jutsus in two months for my players. However, once I had the chance to prototype them, I thought the concepts didn't feel different enough from the other jutsu in the game or take advantage of VR in a truly unique way, so I knew I had to pivot.
Paper bombs have been highly requested by the community, with the earliest mention of it being one month after I launched the game in November 2024. I was reluctant to do them at first since I knew they would be incredibly complex, and would slow down the amount of new content I could add to the game. However, after prototyping them, they felt incredibly promising and took advantage of VR in a way I hadn't seen before, so I decided to pivot, going from doing two simple jutsus in two months, to doing one very complex jutsu in two months.
October: Prototyping Core Singleplayer Paper Bomb Interactions
With that said, here's what I worked on for Paper Bombs in October.
Spawning System
Every jutsu I craft is made with intense care, starting from the spawning system. I prototyped a variety of different solutions, including an item wheel, but ultimately ended up with the simplest solution possible. To give some context, to spawn a kunai, you put your hand behind your back and press the grip button. So to spawn a paper bomb, you put your hand behind your back and press the trigger button. I came to this solution after realizing that the best hand pose for a paper bomb pinched it in between the index finger and thumb, which perfectly corresponds with the trigger button.
Sticking System
Only one side of the bomb can stick to a surface, but to make it as seamless as possible when you throw it, no matter how it collides with the wall it will automatically rotate to stick on the correct side.
Attachment System
It’s as intuitive as possible: all you have to do is touch the paper bomb to the ring of the kunai. If you want to detach the paper bomb, you just have to pull it far enough, and the thread will snap like a rubber band. To make paper bomb kunais even faster, you can hold a kunai behind your back and press the trigger button to spawn and attach a paper bomb directly onto the kunai.
Detonation System
I tried a couple different approaches, but ultimately I settled on an incredibly intuitive and ninja-like technique that would be consistent with kunai teleportation. To teleport to a kunai, you look at the one you want to teleport to, and then press the right stick button. So to trigger a paper bomb, the only difference is that you have to make a one handed sign where you point your index finger up, then look at the paper bomb you want to explode and press the right stick button.
November: Multiplayer Paper Bombs Support and Additional Technical Systems
In November, I still had a lot to go before I could release the jutsu for the game.
Damage Calculation System
To start, I wanted the paper bombs to deal self damage, which would be a first for the game. The hp system was only coded for multiplayer, so I implemented hp handling in single player and while I was at it, rewrote the damage detection system on the player rig since I knew I could do it better, making it so that each body part goes through a central damage processor on the body to make damage detection more intelligent.
Secondly, I wanted the paper bombs to have damage falloff, so the explosion would do more damage the closer the target was. At first, I was measuring the explosion to the nearest body part, but it didn’t make sense to do max damage if a non-critical body part like the hand was close to the bomb, so I measured the distance from the explosion to the upper chest area, where the vitals would be. For the damage falloff algorithm, I used an inverse square falloff to realistically model the energy dissipation of the explosion.
To best determine the max damage, I playtested a variety of damage values with my community. Ultimately, the most satisfying max damage was the player’s full health. Everyone knows how lethal explosions are in real life and in ninja lore, so it felt most immersive and satisfying.
One final important thing to mention about the damage system is that I use an overlap sphere for detecting if an object is within the explosion radius. In order to make sure that players can’t be hit by explosions on another side of a wall, I do a line cast check to see if there’s any environmental colliders between the paper bomb and the player.
Multiplayer Paper Bombs Support
With the paper bomb mechanics and damage system settled, I could work on the network implementation. For my netcode system, I'm using Photon Fusion 2 shared mode.
The fundamental idea you need to understand to wrap your head around shared mode is object ownership: When a player's objects are simulated on their own device, they can be controlled freely because that player is the "state authority" of those objects. When a player's objects are shown on another player's device, those objects are "proxy" objects, and they can't be controlled freely because another player is controlling them. (This is a bit of a simplification, because one player can give away their state authority over an object to another player, but it's good enough for the purposes of this article.)
This idea of ownership guarantees that all players can be in consensus about the game state, since each object can only be controlled by a single person at a time.
With that said, I’ll walk you through the netcode implementation.
Networked Spawning
I have a paper bomb manager which handles the spawning and despawning of paper bombs. I use object pooling for performance, spawning a fixed amount of paper bombs when the player is loaded in, that are used for the entire game. Spawning a paper bomb involves unhiding it, teleporting it to the correct position, and then putting it in the player’s hand. The network implementation attaches onto the paper bomb manager when “network mode” is activated when a player joins a lobby. When the paper bomb manager spawns a paper bomb, the attached network implementation syncs the unhiding and teleportation of the paper bomb across the network at the next network tick.
One reason this method is so good is that it ensures that the paper bombs are spawned as fast as possible on the client, leading to the lowest delay possible from the client pressing the trigger button and the paper bomb spawning. An old solution I tried would handle spawning and teleportation solely on the network implementation, making it so that for the client, the paper bomb wouldn’t spawn in their hand until the next network tick, which only occurs every 32 ticks, rather than 72 ticks for local fixed updates. After I figured this out, I actually rewrote my old kunai manager implementation as well so that kunai spawns would be as lightning fast as paper bomb spawns.
I think I rewrote this spawning system at least twice in November to get to the elegant, responsive, and relatively bug-free solution I have now.
Networked Damage Detection
I already had a damage system in the game, so I just had to add the single player damage detection system I created for paper bombs to the pre-existing network player damage detection system, in addition to rewriting the network hp handler to work with the new centralized damage detection system on the player models.
For a brief primer on how the network damage detection system works, the player model is replicated and synced on other devices. When a player on another device hits the proxy for the player model, an RPC is sent from the proxy to the state authority of that player model, and the damage is dealt. Before the proxy sends the message, the damage is processed on that local device as a client prediction, so the hp bar will show the damage was done on the proxy before the state authority actually processes it to provide fast feedback for the attacker. In order to account for network lag, there’s a “substitution system”, where if the state authority is performing a fast position change via teleport or super jump, they have temporary invincibility, and when they get a damage RPC, they send a message back to the proxy saying that the damage was nullified because the state authority was moving so fast and didn’t actually get hit, and the client prediction on the proxy is rolled back.
Networked Hand Pose Syncing:
Before this update, I had a very rudimentary hand syncing system. Basically I would send whether or not the grip button and trigger button was pressed via two network booleans, and the player proxies would move the fingers associated with the buttons. The upside is that this was super bandwidth efficient, but there was no system for syncing custom grip poses, which would be essential for getting the paper bomb hand pose to look correct on proxies.
I created a solution where I associated specific numerical values with different stored poses. When the state authority player entered a custom grip, it would send an event that would change this numerical value across the network, and then the proxy would copy that pose as well. This way hand pose syncing would still stay bandwidth efficient, only needing to sync two extra bytes across the network (one for the left hand pose override and one for the right hand pose override).
Networked Transform and FX Syncing
Syncing up an object’s position and rotation across the network is a pretty solved problem with Photon Fusion. All you have to do is add a network transform to the object, and then it does most of the work of syncing the position/rotation.
Syncing the explosion vfx and chakra thread fx is also pretty trivial. I just send RPCs from state authority to proxies when the effects play on the state authority. One important thing to mention is that the explosion FX are object pooled, to avoid having to instantiate objects every time an explosion is called which would be very costly on the CPU, and they are object pooled separately from the paper bomb objects, so that way I can despawn the paper bombs immediately without despawning the explosions, which linger after the paper bombs are gone. So on the state authority, I have an object pool for the explosions, and the proxies also have object pools that are created when they are instantiated on other devices. When the object pool spawns an explosion on the state authority, it calls an rpc to the proxies.
Additional Explosion Interactions
One of the small things in the October single player test that players really liked was a special interaction where one of your paper bombs exploding could trigger your nearby paper bombs to explode. Encouraged by the feedback, I ended up adding three special interactions for explosions in November to make them feel more immersive and interactive.
Chain Paper Bomb Explosions
The first is that I got paper bomb explosions to explode other players’ paper bombs across the network. This one wasn’t too hard to implement, I just had to send an RPC from the other player’s proxy paper bomb to their state authority paper bomb. You do have to watch out for timing issues though. Because when you blow up a proxy paper bomb, you have to wait for the time required for the rpc to travel to the state authority, and then when that state authority paper bomb blows up, the explosion vfx rpc has to be sent back to the proxy that blew up. So there’s a bit of a delay between when you blow up an enemy’s paper bomb and when you get the corresponding explosion fx. Luckily chain explosions are more noticeable when there’s a delay between when one paper bomb explodes and another one explodes anyways. So the way it works is when you blow up your own paper bombs with an explosion, instead of exploding successive paper bombs immediately, I schedule their explosion with a coroutine that waits 0.25 seconds before exploding it. And for blowing up network paper bombs, you just trigger successive explosions without waiting, because there’s a natural delay from passing messages across the network.
Trigger Paper Bombs with Fire-Based Projectiles
The second is that I got paper bombs, both your own and other players', to explode when hit by a fire jutsu. This one wasn’t too bad to implement either, especially since I did this after coding the networked chain explosions. The principle is the same, the only difference is that I had to add some extra code to the fire jutsu to detect if they hit a paper bomb so I could trigger the existing detonation code.
Destroy Kunai with Explosions
The third is that I made it so that kunai are removed for the round when hit by an explosion. I had to extend the kunai manager, making it so that a kunai can be included/excluded from the spawning pool. This one initially had a subtle execution order bug, where if the kunai had a paper bomb attached to it, the explosion would despawn the kunai first and then the kunai would despawn the paper bomb, so that the attached paper bomb wouldn’t chain explode from the paper bomb explosion. I fixed the order of operations so that the paper bomb chain explosion would trigger before kunais are considered for despawning.
Force Grab UI
Before this update, force grabbing worked Half Life Alyx style, where you would point at an object, hold the grip button, and then make a pulling motion. With the addition of paper bombs, you could now force grab objects the same way except using the trigger button. Because force grabbing used to only be associated with the grip button, even I found it slightly confusing to force grab paper bombs sometimes, and it added some unnecessary cognitive load in game.
To address this issue, I explicitly added animated UI icons to show the correct button to press for force grabbing depending on the object you’re hovering on. I got the initial icon by getting a side view of a quest controller, and then telling ChatGPT to turn the image into an icon. Then I used a photo editor to change the color of specific parts of the icon to create an animation. I tested three different color based animations before settling on a mostly colored controller with the specific button in white, and the white button would disappear once pressed. The beauty of this approach is that the controller icon is color coded and the color is very clearly visible. It’s mostly blue if you need to press the grip button, and mostly red if you need to press the trigger button, so that way, once you read the icon once and understand what it’s asking you to do, each successive time, you can just look at the color of the icon to determine if you need to force grab with the grip or trigger button, leading to an unconsciously intuitive experience. To add to this color association, every time the grip button is mentioned in the tutorial, it’s in blue text, and every time the trigger button is mentioned, it’s in red text.
Future Work
A Better Networked Stick Algorithm and Grabbing of Other Player’s Ninja Tools
As mentioned before, the netcode is a state authority based distributed system. This means that each player solves the consensus problem by only having control over their own objects. And that means they can’t control other player’s objects: if they do manipulate another player’s object, it isn’t synced to other players because they don’t have true ownership over that object.
The biggest problem this led to with the paper bombs implementation is when you try to stick a paper bomb onto another player. When another player moves, your paper bomb that is stuck to them lags behind them, especially on other players’ screens. This is because of object ownership: for correct synchronization, when you stick a paper bomb onto another player, that player should own the position and rotation of the paper bomb, not you, since you see a slightly out of date view of where the player truly is. This means that you’re sending your own paper bomb’s position in relation to an out of date position which causes this lag issue.
So ultimately the solution is pretty simple, right? All you have to do is transfer the state authority of your stuck paper bomb to the other player temporarily, to remove the lag. But then the problem is you have to get state authority back when you grab it or despawn it via code so you can use it like normal. And every time you transfer state authority, you need to perform client predictions in order to make the transfer look smooth. So I took a week in November to start working on this state authority transfer code for the paper bomb stick, as well as code for doing state authority transfer on grabs, while also masking the transfer with client predictions, learning all of this theory on the fly. And then I ran out of time. I promised my community I would update the game by the end of November, and I wasn’t about to back down from my promise, so I scrapped the buggy implementation I had worked on and focused on polishing the rest of the game instead.
I learned a lot from that week. It gave me the theory and some practical experience on how I could make the game even more immersive by allowing you to grab other players’ ninja tools. The local ninja tool logic is a bit complex, making it nontrivial to synchronize, and the current network sync for the ninja tools wasn’t designed around this idea of transferring state authority, so I’m going to need to rewrite a lot of the network code for the ninja tools, but this will be awesome.
Upgrade the Netcode Architecture
I knew going in that shared mode wouldn't be ideal for a competitive multiplayer game, with its player authoritative model that is susceptible to cheating and gives an advantage to lagging players. However, when I started this project, I felt like I didn't have a choice, with no funds to pay for higher server costs, and no netcode experience under my belt. In year 2 of Ninja Clash, improving netcode is one of the biggest concerns for the community, and one I intend to address to ensure the game's longevity, even if I might have to take a couple of months off from content updates so I can switch frameworks and rewrite everything. I'll need to save up enough money to take the leap.
Marketing Overhaul
In the last two years, I’ve focused on creating a robust gameplay experience and establishing a revenue stream via in app purchases. I haven’t focused much on marketing, because my time was so limited and every completed gameplay and cosmetic update was a monumental struggle when I was doing everything for the first time. Things are changing now, and I’m getting more comfortable with gameplay and cosmetics updates.
With my PDP stats in the bottom 20% of the top 600 free apps on the store, I’ve started a major push to improve the quality of my promotional materials. I’m working with a 15 year game industry veteran artist, Julio Bencid, to create a professional cover art, and we’ve been working closely with my discord community via polls and written feedback to deliver the best possible promotional image for Ninja Clash. Our new cover art is set to be finished with a tentative deadline of December 12th to get ready for the holiday season.
For the store page, I’m going to be constantly iterating on the trailer, screenshots, and description with AB Testing.
I also have updates planned for the game specifically dedicated to making the experience look better in recordings, such as a UI Overhaul, a VFX overhaul, a sound system overhaul, adding more expressive facial animations to avatars, and more.
New Gameplay Mechanics
Paper bombs will not be the last innovative gameplay mechanic I add to Ninja Clash! There's so many more anime-inspired ideas I want to try to create a uniquely special gameplay experience. In the short term, I'm planning to add more iconic ninja tools, like shuriken and smoke bombs, while also adding more interesting VR-based movement options to the game, like punching in the air to propel yourself in any direction.
New Stylish Cosmetics
Taking inspiration from JPop and Asian Streetwear, it has always been important to me for the character customization options in game to feel cool and stylish. I'm looking forward to continuing to work with more artists to elevate Ninja Clash's unique sense of fashion, and enable players to express themselves with more categories, items, and specific niches!
Ranked System
As the game has grown, there has been a larger and larger gap between veteran and new players. Adding a ranked game mode will help to keep rounds more competitive and fun for everyone. Ninja Clash is at its best when it feels like anyone has a chance to win!
Clan System
One incredibly interesting thing you might notice from observing the Ninja Clash discord community is the formation of clans. I never intended for them to be a thing when I started Ninja Clash, but there's a vibrant culture of different subcommunities, each with their own community leaders, clan lore, rules, and even ranks that have formed organically around Ninja Clash. I've noticed that this game has become one of the central social hubs for people who both love anime and VR, and in the future, I would like to support this kind of natural community building directly in game.
Built With
- hurricanevr
- photonfusion2
- unity
- unitygamingservices
Log in or sign up for Devpost to join the conversation.