I worked on Just One Man as the design and product person on a team of 3.

I left after the demo to focus on VR research (and various sideprojects), while the rest of the team is still working on a full release.

Here’s what we were going for versus the eventual demo:

Here’s how people responded (it became the #1 trending combat game on SideQuest):

To explain why at least some people loved it, let’s go over two major problems that tend to occur in VR games with melee combat:

“Waggling”

In VR, because you aren’t actually swinging a real weapon with real weight, nothing prevents you from quickly flicking (“waggling”) your wrist back and forth to block every enemy attack and instantly killing them.
If given the option, almost all players will play like this, since it provides the most reward for the least effort.
This removes all challenge and satisfaction, causing many melee combat games to feel shallow.

Clunkyness

To prevent waggling, games tend to ask players to be precise (with precise collision physics), have better timing (with artificial limits on how fast players can move their weapon), or otherwise meet specific conditions (like requiring swings to pass some velocity threshold).
The more precision and conditions they add, the less viable waggling will be. But it will also create more ways to fail at blocking or attacking.
This can make games unapproachable and, in the absence of carefully designed feedback, will cause players to feel like their actions often fail for seemingly no reason: “but I blocked that!”.
The result is that melee combat games tend to feel clunky and unsatisfying.

Our first key solution:

A Beat Saber-style weakpoint system, where the player must swing in the direction of the weakpoint to pull off different martial arts combos.

This prevented waggling, encouraged a variety of cool-feeling motions, and made the correct motion visually obvious.

The general idea of using directional weakpoints came from Until You Fall. But we made some key improvements:

Combos

Instead of just having one type of weakpoint like in Until You Fall (see image below), we realized we could use different weakpoints to get the player to do all sorts of martial arts combos (although this wasn’t exactly a huge leap, since Beat Saber and plenty of fitness games had done something similar, plus the same idea popped up in Batman: Arkham Shadow before we released our demo).

So, for example, we could create a boxing combo by spawning two jab weakpoints and then a hook finisher. Or we could replicate knife combos, like a backhanded stab followed by two slices.

An unexpected bonus from these weakpoint combos was that they provided a way to differentiate weapons from each other, which was another problem that VR melee combat games have had forever.

Long story short, every melee weapon tends to feel the same in VR because weapons can’t actually be heavier or lighter and the developers can’t directly control how fast the player attacks (which is one of the main ways that non-VR games make weapons feel different).

By creating unique combos for each weapon, we could physically change what motions the player was doing and therefore make weapons actually feel different. Although, unfortunately, we didn’t really have enough time to add more than two weapons for the demo and so this didn’t shine through.

As an additional tidbit, we tried out all sorts of different weakpoint types but ultimately realized you could replicate almost every combo with just two weakpoint types: an attack foward (stab/jab) and an attack to the side (slice/hook). And that prevented a lot of extra effort that we would’ve otherwise had to spend on teaching different weakpoint types to the player.

We also tried all sorts of directional weakpoints, like only being able to attack from one direction, but we converged on the same solution that Until You Fall did (a bi-directional weakpoint).

Reason being that a uni-directional weakpoint just creates too many situations where the player’s hand ends up on the wrong side after an attack, causing an awkward hand reposition that breaks the flow of combat. This can’t really happen with a bi-directional weakpoint.

Lastly, it’s worth pointing out that around 5-10% of playtesters preferred not having any weakpoints at all, since they’d actually do combos themselves and found the weakpoints too restrictive. I was one of them.

However, not having weakpoints was catastrophic to the experience of >90% of players, since they would automatically default to waggling and ruin the game for themselves.

And that was a problem because we were aiming for a more casual target audience, that wasn’t necessarily used to hardcore VR swordfighting games and all their unique quirks.

Beyond that, we also felt like plenty of other games already provided a fully free combat experience for those who wanted it. We weren’t trying to make another Blade and Sorcery.

Hits-to-Kill

Another change we wanted to make to Until You Fall’s system was to make the player to feel more powerful.

In Until You Fall, it takes a lot of hits to kill an enemy. That makes the player feel less like an overpowered martial artist (our target fantasy) and more like a gladiator fighting for their life.

But then the question is: how many? More hits would allow us to do a greater variety of combos and further differentiate weapons from each other, since a weapon that takes 1 hit to kill enemies feels very different from a weapon that takes 3.

More hits would also create more room for progression and powerful abilities, since we’d have more space to reward the player with a lower number of hits to kill. In other words, you can’t make anything feel more powerful if everything already kills in 1 hit.

However, requiring more hits to kill also lowers the pace of the game, makes the player feel less powerful, and increases the physical strain on the player (since you can’t really rest while fighting an enemy).

After a lot of playtesting, it turned out that we had to settle with making every weapon take 2 hits to kill (except for fists, since they’re always dual-wielded and could therefore require 3 hits). Any more and players would get tired and feel like they were no longer overpowered martial artists efficiently flowing through the battlefield (like we wanted them to be).

This still gave us a bit of room to make powerful abilities, since we could lower the hits to kill to 1 or make abilities affect multiple enemies at once. But we definitely lost a lot of depth because of this decision that would have to be found from other sources.

Rules for flow

After striking a directional weakpoint in Until You Fall, the player’s hand often ends up in a position that’s quite far from where they need to start their next swing.

This causes momentum to be lost and forces an awkward hand reposition that breaks the flow of combat.

To fix this, we came up with a series of “flow rules” based on which types of motions felt the most natural from any given situation.

These turned out to be way more complicated than I expected, since we had to account for all the ways that players might be holding the weapon and all the places their hands might be after an action, like parrying or dashing.

Here are a few of these rules:

Weakpoints must spawn at the player’s torso/elbow level, since weakpoints that were too high or too low for our hand’s natural range of motion would quickly get tiring. This is one of the reasons why we also had to calibrate enemy heights based on the player’s height (alongside wanting to make players of all sizes feel big and powerful).
Weakpoints must spawn such that they’re easy to hit from wherever the player’s hand ended up after the previous action. For example, if you block with a sword, we assume you’ll slice directly from where you parried, since that’s the most efficient motion. If you blocking with your fists, we’ll assume you’ll use your other hand instead (at least most of the time), since attacking directly with that unused hand is more efficient than changing the angle of your blocking hand and then attacking with that.
The hit directions of consecutive weakpoints can’t be more than 40° apart from each other (in terms of z-axis rotation), since any angle greater than this would force a large hand reposition in between swings.
Weakpoints couldn’t spawn in certain locations, depending on how the weapon was held (forehand/backhand or left/right hand) and which motion we were asking the player to do (stab or slice). This is because some motions are simply too tedious, given our natural range of motion (see image below).

Telegraphing

Another reason why Until You Fall’s (and later some of Batman: Arkham Shadow’s) weakpoints can feel awkard is that the player doesn’t know where the next one will start from.

This creates situations where the player will move their hand in the wrong direction after a hit and then have to do that awkward hand reposition to hit the next one.

The fix was very simple. We just always showed the next two weakpoints, which instantly had a huge impact on our playtest feedback.

Immediate next move

Lastly, both Until You Fall and Batman: Arkham Shadow suffer from breaks in combat flow that happen when there’s too long of a delay between opponents or when an opponent suddenly interrupts you while you’re trying to do a cool combo.

This was antithetical to the feeling we were going for (an overpowered martial artist constantly flowing through the battlefield). So we had to fix it.

This simply meant having enemies (1) start their attacks right before the enemy in front of them died and (2) never attacking out of order, unless they were a visually distinct enemy type who’s behavior included that.

The interesting thing about this was that even small differences in attack timings had a huge difference in playtest outcomes. Enemies attacking just 0.2s too early or too late was the difference between an average playtest time of 30 minutes versus 10 minutes.

When things were perfect, we had players playing the same level for genuinely 3+ hours straight (despite the game having basically no content). When they weren’t, the game was forgettable.

It was the difference between “it’s pretty fun” and “this is the best VR game I’ve ever played”. And, interestingly, no player could point to this being the cause.

One of my biggest personal failures for the demo was my inability to guard this standard, as new stuff was added and more tech debt piled onto our AI system (which caused inconsistencies in attack timings).

The net result was that, while people did like our demo, it didn’t end up being as fun as some of our earlier builds.

Our second key solution:

A block system that checks for the right motion, as opposed to a collision between the player and enemy sword.

This prevents waggling without adding (overly) complicated conditions that are hard to understand.

Unlike the weakpoint system, I think our idea for blocking was genuinely new (which is why it took us like 12 iterations to finally get right).

To restate the problem, players can usually block attacks in most VR games by just waggling their controllers back and forth. In that situation, why have blocking at all?

The way that games usually prevent this is by making blocks require precision and adding a delay to the weapon’s position (relative to where your hand is in real life).

Precision takes a long time to learn, especially when it can be hard to judge distance in VR, so it tends to make the system unapproachable. This of course went against our desire to make players feel powerful.

Moreover, the combination of precise conditions and an artificial delay means that you will fail blocks despite your hand actually being in the right place. And that can feel very clunky to players that aren’t used to similar games: “But I blocked that!”.

Now Until You Fall does solve this in a smart way, by asking the player to copy a pose while blocking (see the image below).

But we felt using a UI element took away from the visceral feeling of actually blocking an attack yourself (although, in hindsight, we should’ve definitely just copied their solution because of how long it took to come up with an alternative).

So the idea we came up with was to ignore the weapon itself and just imagine what motion we want the player to do. In this case, we wanted players to move their hand far enough away from their side that they feel like they did a proper block.

We didn’t care about precision as much as the player just doing a big enough motion, since we wanted the focus to be on quickly responding and flowing onto the next enemy (as opposed to carefully dealing with each enemy one at a time).

We also tried a bunch of stuff like having to swing against the direction of the incoming enemy swing. But this wasn’t what most people did naturally and this motion was too similar to a normal attack motion.

That was a problem because we want motions in the game to feel meaningfully different and we noticed that straining the same muscle groups with multiple actions would cause players to tire very quickly.

The question, then, was how we’d actually get players to move their hand far enough to the side. After a lot of failed iterations, here’s the eventual solution we came up with:

Make a line to the nearest enemy, from roughly the middle of the player’s torso to the enemy’s torso.
Create a circle around that line.
If the player’s hands are outside of that circle and their sword is angled correctly to block the attack, the block is successful. If their hand is inside the circle, the enemy will hit you.
This way, we’re basically just checking that the player is moving their hand far enough away from their body in the right direction.

There’s some additional minutia as well, like:

Having to offset the circle position based on which hand is holding the weapon, since that changes our range of motion
Making block conditions more lenient when using weapons backhanded or blocking with their thumb pointed to the ground, since those block are much harder to pull off and we don’t need to be strict when the player is already doing a cool, non-standard motion
Changing the circle’s radius based on the player’s armspan, since it’d be unfairly hard for shorter players to move their hand as far as a taller player

This system worked very well. BUT only after we showed players the correct motion in-person.

Because it turned out to be bizarrely difficult to communicate 3D movements to players, even if that movement seems obvious to us and is exactly how you’d block an attack in real life anyways.

The reality was that very few players were able to translate a 2D video to their own movements or understand what we meant by “just move your hand far to the correct side”.

Somehow all common sense just disappears in VR, probably due to a combination of players being overwhelmed by a new experience and them not being able to see their real bodies (we didn’t even have hand models at the time).

So it took another ridiculous number of iterations to just figure out how to teach the right motion to the player, with the eventual solution being a combination of:

A glowing shield that spawned on the weapon whenever the block conditions were being met
And ghost hands showing exactly what motion to do (emphasis on exactly because players would copy the exact motion, even if we felt it was obviously just indicating the general idea).

After these changes, pretty much everyone we tested with finally learned how to parry in just one tutorial step. But boy did it take a lot of effort.

Here are some of the general things we learned from the project:

Design for a fantasy

It was insanely easy to make design decisions because we had a clear fantasy in mind from day 1.
All we had to do was ask: would this option make the player feel like a powerful martial artist, skilfully flowing through combat while swapping between weapons? Or, more specifically, we’d just pull up this gif:

Efficient motion, sufficient illusion

One of the main things that separates VR games from other platforms is motion. As dumb as it sounds, it’s good-feeling motions that make games like Beat Saber and Gorilla Tag the only few successful VR games on the market. We discovered this the hard way, through countless failed playtests.
And so it turns out that VR design is fundamentally about creating motions that (1) create a sufficient illusion of you doing the real thing, while (2) being efficient enough to repeat 8000 times.
If the game is just a bunch of button presses and not motions that feels good to do, it offers nothing that can’t be experienced much more conveniently via a PC or console game.
This means VR design involves spending a lot of time looking for cool motions in other media and acting out different types of slicing motions on public transport (as people call the police).
If the motion feels good, but can’t be repeated 8000 times, your game will quickly become unplayably tedious. Because VR games are just motions repeated 8000 times.
Tangibly, we realized we had to consider things like how much weight a motion will move, how well it aligns with our natural range of motion from any given position, how much energy the motion recycles as its repeated, and how well we’re spreading out motions across different muscle groups during the game.

Design for motion, rather than interaction

Since motion is so important in VR, we realized it’s best to start from motion you’re trying to encourage and then work backwards.
If you start your design from something other than the motion, you’ll end up wasting an ungodly amount of time trying to get rid of all the possible edge cases that result from the system checking for something other than that motion.
For example, start from a physics collision and you’ll end up spending a ridiculous amount of time tuning parameters and adding custom rules to prevent waggling without making the thing clunky as hell. Reason being that physics doesn’t actually care about whether the player felt like they did the right motion.
Or, put another way, it’s easier to fake what looks like a physics collision than get a physics collision to behave the way you want it to every time.

Motion controls don’t scale

Motions that are efficient are usually small. This makes it a nightmare to tell when a player actually wants to do the motion, especially when people do even simple motions quite differently and can be anywhere from 140 to 200 cm (and therefore have vastly different ranges of motion).
And this difficulty scales with the number of different motions we have in the game, since we’ll have to start trying to determine if the player was trying to do this motion or another one.
The net result is that it’s incredibly difficult to create a VR game where you aren’t constantly failing to do the right thing or accidentally doing the wrong thing. It’s why more complicated VR games seem almost invariably clunky and why the most successful VR games all have literally just one basic motion.
It doesn’t matter if you’re Valve or a small indie team like us, you’ll spend a ridiculous amount of time just trying to figure out a motion that works and then figure out how to tell if the player actually did that motion. For context, it took us 3 months just to make parrying work. Attacking took another 6 months.
And this is why I quit the team after the demo. Before this motion control problem is solved, nobody can make VR games that feel like “real” games, without making them far too clunky for most gamers. VR development simply isn’t scalable.

Communicating motion is unexpectedly difficult

As mentioned earlier, it was surprisingly difficult to teach basic motions to players in three dimensions, like just moving their hand far enough to either side.
The solution to this is to, perhaps unsurprisingly, communicate things in three dimensions.
For example, we found success with 3D mimic targets (like ghost hands showing the player what to do) and real-time feedback (like a moving bar to show how much harder they had to swing for it to count).
We also noticed that it was incredibly difficult to communicate anything other than binary states.
For example, we tried multiple types of attack, like weak and strong attacks. But players would just get confused and think they successfully attacked when doing weak attacks, even though these two attacks had a massive difference in visual and sound effects.
It’s just very hard for players, especially ones that are new to VR, to notice literally anything when something threatening is standing right in front of them.

100ms can be everything

Another interesting finding was how tiny changes had a massive impact on how our game felt.
Earlier, I mentioned how even a 0.2s difference in enemy attack timings meant the difference between a mediocre demo and “the best VR game they’ve ever played”.
We also experienced this when nobody even bothered to finish the 5 levels in our game after something caused the weakpoint hit visual effect to be delayed by, get this, 2 frames.
When it’s YOU doing the thing, and not some character you’re controlling on a faraway screen, little details start to matter way more.

Test after every change

There are so many more things that can go wrong when creating interactions for 3D than for 2D.
I already mentioned how hard it is to just get basic motions to work. Then you also have motion sickness, which can be triggered by seemingly random things even if you’re explicitly trying to avoid it (like an enemy sword bouncing up and down in the player’s peripheral vision).
And that’s a problem because, if you cause motion sickness, your game becomes genuinely unplayable to around 50% of the world population.
So we learned that, in VR, you must playtest after every single change. The longer you wait to discover what doesn’t work, the more difficult it’ll be to figure out that it was actually that random two frame animation delay that suddenly made your game crap.

Design isn’t the hard part

Perhaps the most important lesson was that design is actually pretty easy. There was never a challenge we couldn’t come up with a solution to. But we just didn’t have enough time.
Turns out that game development is fundamentally just a team management and prioritization problem (and I suspect every other game developer has figured this out too).
And I’m still not great at that, which was probably the biggest limiting factor for the project.

Here’s some additional info on our target audience, because I think having a clear target audience in mind was critical to making something that at least a few people enjoyed:

Casual VR “edgelords”

Aged 15-25, has lots of free time outside of school and university
Got a Quest 2, 3 or 3s for Christmas because it seemed cool, but can’t find a reason to use it, other than Beat Saber. They’ve already given up on it being anything more than a gimmick, so it mostly sits in storage.
Craves the anime swordsman power fantasy and always picks the samurai or ninja character in games
Constantly pretended to be a ninja or samurai as a kid, but doing that now would be cringe in most contexts. They’re looking for an excuse to be able to do that.
Responsible for the 30 million lifetime sales of the Devil May Cry franchise and the continued domination of combat-focused anime
Watches anime music videos and cool combat clips on Tiktok and Youtube
Doesn’t always get to feel powerful in real life, so wants to blow off steam and feel powerful by stylishly slicing hundreds of enemies. This desire builds up after tough days or when they see something cool on TikTok that they’d want to mimic.
They play a lot of PC/console games, but only play VR every now and then. That means they aren’t used to motion sickness or the general clunkiness of most VR games. They’re looking for something they can jump into without it being a pain in the ass (like Beat Saber).
We are NOT making a hardcore physics-based sword game for VR tryhards. We’re going for Devil May Cry, not Dark Souls or Blade and Sorcery. EVERYONE who plays gets to feel like a powerful samurai doing sick moves.
We are NOT making a game for players looking for a more chill or dancey experience. Beat Saber is already great. This game is for those who crave high-intensity slaughter.

Here are the design pillars that guided the project:

1. Audio-visuals straight out of an anime music video

Sounds and visual effects are visceral and absurdly over-the-top.
- E.g., the player’s sword does the anime glint thing, enemy heads fly off at mach 3 with a huge blood trail behind them, player super attacks disintegrate hordes of enemies
Gameplay and audio-visuals harmonize with music to make the player feel aggressive and insanely stylish

2. Make the player feel like a insanely skilled anime villain

Create the feeling of masterfully flowing through a combat scenario and stylishly dealing with everything enemies can throw at you. Parry this way, slice here, dodge that way, throw your weapon there, dash to the next enemy, slice a few times, catch this arrow, throw it back, etc.
The player is constantly pushing forward in combat and doesn’t have to wait around — they’re the ones in control of the battlefield.
There should be no doubt that the player is the most skilled master in the world. Slices are lethal and buttery smooth. Parries are intense explosions of sparks that send the enemy’s sword flying away. Abilities destroy hordes of enemies. Weak enemies cower in the player’s presence.
Get rid of everything that gets in the way of every player feeling like an overpowered anime samurai. No awkward VR movement, waiting for things to happen, weapons getting stuck on enemies, high time-to-kill, barely missing parries, accidentally missing weapon throws, etc.

3. The player can return to the fantasy day after day

The player doesn’t need to jump through hoops to experience the fantasy again. They should always be a few buttons away from slaughter.
There should be lots of space for mastery and replay, so that the player can always come back to slaughter enemies after a tough day of work or school

And some additional pillars that I used for combat design specifically:

“The Slice”: This game involves hitting enemies thousands of times, so it will live or die based on how satisfying that hit feels.
Simplicity: Nothing should take more than a few attempts to learn.
Combat flow: There should be no awkward moments that break flow, unless the player clearly messes up.
Combat variety: The player must constantly be encouraged to change up their approach as they go from enemy to enemy.
Skill expression: Everything the player does should have additional layers of skill expression that let them get additional value.
Progression: The player always has at least one short-term (seconds), mid-term (minutes), and long-term (hours) objective to keep them motivated.