Yasuke - The Lost Samurai
Yasuke is my first large-scale solo project outside of game jams. It started as a narrative design project in college and slowly shifted into a primarily combat-focused project.
Yasuke tells the story of the first-ever black samurai and his journey throughout Japan, exploring the difficulties he faced along the way. While the project did start with the story and does have some narrative elements, what I primarily created in Unreal Engine 5 was focused on combat design.
Responsibilities
Role: Combat Designer
Team Size: Solo Project
Timeline: Concept started March 2023, production started May 2023.
Combat Design
Focused on developing enemy AI behaviors and systems, with an emphasis on modular infrastructure. Crafted player abilities that optimize counterplay and creativity.
​​
-
Created five complex enemies including one major boss each with their own attacks and behaviors.
-
Designed a complex weapon trace that analyzes different weapon impact locations, such as hilt or blade, to deal different kinds of damage.
-
Crafted modular behavior trees that allow non-programmers to quickly iterate on designs.
-
Made robust blood and camera shake systems that surpassed built-in editor logic and offered more bespoke visuals.
-
Rigged multiple models to use UE5's skeleton and ensured animations transferred cohesively and didn't hinder the combat experience.
(The project is still WIP so this page may be updated periodically to display more work)
Game Design
Worked on all areas of design such as level design, systems design, and narrative design to create a cohesive gameplay experience.
​
-
Used physical and in-game tools to create level blockouts that were historically accurate.
-
Created multiple easy to use narrative systems for future large-scale implementation.
-
Outlined the main questline and associated dialog, cutscenes, missions, and gameplay rewards.
Table of Contents, for those who skip around
Combat Design
Combat Design
Parry System
From the very beginning, I knew I wanted to create a combat similar to that of Sekiro's. I love how aggressive it is, for example, while many games would force you to dodge away from thrust/stab attacks, Sekiro takes a different approach and lets the player aggressively dodge toward the enemy, performing a Mikiri counter. This forces players to consider how they can offensively react to enemy actions, keeping the pace of combat fast, while also giving more opportunities for counterplay.
​
Given I was styling combat after that of Sekiro, I knew that the Parry system would be the most important part to get right. I started by implementing some basic sword trace logic to allow me to detect whether an enemy was hit. I opted to set up my sword trace using weapon sockets spread across individual skeleton meshes (for weapons) so that each could have its own unique set of traces - this would eventually allow me to detect whether an enemy was hit with the point, blade, or hilt of a weapon.
​
Now that I had the weapon trace setup I moved on to setting up the parry system.
Parry systems, truth be told, are easy to make and hard to get right. They don't require complex math calculations or anything fancy, but a simple check if the player was blocking within a certain point of the enemy's attack.
The hard part with parry systems is the refinement, getting the timing and visuals right so it doesn't just activate, it feels amazing to activate. The player should strive to parry, it should be the go-to action when they see an attack coming towards them -- though sometimes they should dodge.
​
I chose to keep the actual visuals and gameplay reaction minimal, like Sekiro but unlike God of War or the Souls games. I wanted the parry to be something you did frequently and loved doing, not necessarily a "major" moment during gameplay -- that job fell to the deathblow.
​
Arguably the most important part of a parry isn't the visuals, but the sound design. Sound design isn't the most obvious, but it's what brings the whole thing together. Cool visuals are nice and all, but without sound to back them up and give "meaning" they can fall flat. I looked for a long time to find a sound that I liked, and truth be told I'm still looking, but my current SFX works quite well.
​
I like to admit faults when I can, and I will freely say my parry system is not perfect, but I think I've managed to strike a good balance between gameplay, smoothness and stats, and visual design, sparks, and refraction. Pretty much every day that I work on Yasuke I find some way to improve the parry system, refine the timings, tweak the visuals, etc. Combat design really isn't a sprint, it is a long, LONG, marathon.
​
​
You can interact with this graph to see exactly what into my weapon trace!
Animations + SFX are from the marketplace, VFX are custom.
Combo System
Creating a good combo system, or rather the way the player attacks, is arguably the one thing you really can't get wrong. If the player doesn't like attacking, then why would they?
​
There are a couple of ways to structure a combo system. Most games take a simple approach and simply increment through a set of attack animations and loop through this process. Other games, like God of War, might change the combo to adapt to weapon changes, heavy or light attacks, etc. The latter creates more challenging combat, as the player might need to remember tons of different combo variations for different situations (though more often than not you can stick to the base combo if needed).
​
The problem with this kind of combat, in my view, is a lot of the intricacies go to waste, and not many players take full advantage of the system. In a project of my scale, I simply couldn't afford to spend the time developing a complex combo system that most players probably wouldn't touch. That's not to say the aforementioned system is bad, I would love to do something similar with more resources, but one of the challenges with game dev is working within constraints.
​
One of the keys with a combo system is the visual feedback that your attack went off, and more specifically the region it affected. To address this issue I opted to create a weapon trail, a common combat design trope. At first, I tried a complex weapon trail, something flashy and bold; there was no way the player would miss it. Eventually though, after some playtesting, I felt like it detracted too much from the core combat and became an eyesore.
​
In response to this, I pivoted and went minimalistic, trying nothing but simple refraction. This yielded this inverse and felt too lackluster, so I brought back some of the old flares. I wanted to make sure that players 1. knew where their sword would hit, 2. enjoyed the visual feedback from their weapon, 3. knew that my game is distinct -- which is mostly an art direction thing.
This yielded the results on the right.
​
​
Old weapon Trail before the changes. Color scheme was different for the player, this was the enemy version.
New Weapon trail after the rework.
Reactive Combat
Reactive combat, or rather the stuff that happens when you attack or get attacked, is often what ends up giving combat its weight. If you slice through an enemy and nothing happens, no blood, no camera shake, etc. it can give the player negative feedback. This can make the player feel like they are doing something wrong when they might not be.
​
For this project, I wanted to make the combat system fast-paced with minimal downtime. One of the options I had to add weight to player's hits was camera shake. However, while camera shake is a great way to control the player's view and add emphasis to actions, it also removes control from the player effectively "putting them in the backseat". This can become problematic if overused because it no longer adds emphasis but instead becomes a nuisance. A similar thing occurs with VFX: a frequently used VFX effect is less memorable than a sparingly used one. Not to mention, camera shake can cause players to get motion-sick, or feel like they can't see clearly. This led me, after a lot of playtesting, to remove the camera shake from my player's basic attacks.
It was still important to me, though, that players understood the weight behind their attack. I wanted to make sure when players landed a big hit, they knew they did something awesome. It's these moments in games -- using an ultimate ability, casting a massive spell, chopping off the enemy's head -- that often go on to define the player's memory of what we create. These are the rare moments that I do use camera shake, and other tools, to make sure the player knows they did something awesome!
​
(still writing this section, sorry!)
​
​
​
Deathblows
My favorite part of Sekiro: Shadows Die Twice, is probably the deathblows/executions. Unlike a lot of RPGs, Sekiro doesn't just have the enemy or boss flop over when they die, instead, the player must execute a brutal death blow on the enemy that drives home how intense the fight is. In other words: deathblows reflect intensity.
​
I started by focusing on deathblow speed; a lot of times when you deathblow you've parried 10+ times, and were potentially on the ropes about to die, so speed is key. Just as the deathblow reflects intensity, speed reflects pacing.
​
After that, I moved on to camera shake and visual representation of the deathblow. As discussed in hit reactions I use camera shake sparingly, but one place I use it a lot is in deathblows. It was important to me that the player knew this action was different than the rest of the combat I have. I wanted the player to know that this time they were slicing through flesh and bone, and the camera should tell them that.
​
Along with the camera shake, I focused a lot of blood VFX. Too much blood can detract from the execution, but too little can make it feel weightless and artificial. I opted to work on a case-by-case basis with a general rule of: "The harder the enemy the bloodier the kill." This meant that big bosses had big deathblows, while simple enemies were more minimalistic but still impactful.
​
This also visually lets the player feel a sense of progression as they move through the world, with harder enemies not just reflecting their strength via stats, but also via the feedback and underlying combat.
The video broke while I was gone on vacation, I'll fix it soonTM
Example of what a deathblow looks like. The snap to the player is temporary, eventually I'll blend it so the enemy turns or gets grabbed/something else
One of the boss deathblows.
Boss Design
Boss design is a vital part of any combat-heavy game. Bosses are the culmination of everything you've learned and fought up to that point, they should seriously challenge the player and be memorable.
​
For Yasuke I wanted to make sure that all of the bosses I designed had a unique identity. The first boss I designed, codenamed the "Brute", was a large warrior that yielded a Nodachi, a large katana-like weapon. My goal with this enemy was to counter the traditional thinking of "big sword, slow attacks" and instead create an extremely fast-paced fight.
I also wanted to emphasize the multi-phase boss system by having a fairly simple first phase, but a very difficult second phase. This wasn't intended to be jarring, but rather intended to illustrate the the player the gameplay can change in the blink of an eye.
​
One thing you'll notice is that a few of the Brute's attacks apply camera shake, this was completely intentional. I wanted the player to visibly feel the impact of some attacks, even if they dodged or parried it. The player should understand that this attack was deadly. I try to use it sparingly, but I do think it's another good example of how to effectively use camera shake.
The first boss fight I designed. There are some improvements that still need to be made, such as more telegraphed attacks and preventing the AI from getting "stuck" (when it pauses and stops doing anything for a moment).
​
I'd also like to add specific counterplay to some abilities, such as the "tornado" attack the boss does in phase two, perhaps the player has some ability they can use to stop this? I want to avoid the player feeling like they need to dodge or effectively "stop playing" while the enemy attacks.
Problems & Experiments
A Big Bloody Problem
Problem:
Because this is a primarily solo project and I'm primarily trained in game design, I knew that I wouldn't be able to spend the time making custom VFX, animations, etc. for everything. So instead I turned to the UE5 marketplace (or other places) for many of my assets. This meant, however, that many of them didn't work out of the box, or if they didn't they didn't work that well. Particularly with the blood VFX I had purchased, their decals didn't work at all... so how did I fix it?
​
Solution:
Somewhat anticlimactically, if you want to get really good decals you need to spawn it with blueprints, not in the Niagara emitter.
​
Originally when I was trying to get blood decals set up I tried to spawn the decals in the actual Niagara emitter itself. Emitters do have the ability to do this, and on some level, it works pretty well, but not when you want variety and customization for your blood. You can see clearly in the image on the right how repetitive the blood looks. To put it simply: it looks fake.
Circling back to how I actually solved this, I realized that the emitters and Niagara systems simply wouldn't be sufficient for what I needed. I made the most logical decision and turned to blueprints for my decal implementation. The challenge is, that communication between Blueprints and Niagara is, well, sketchy at best. That's primarily because I was spawning these particles via animation montages, not in some kind of blood component. That meant I needed a hard reference to the system itself to know where to actually get data from. This would mean if you had 100 different blood systems for VFX which each spawned a decal, you'd need 100 hard references to each system in your BP. Not ideal.
At this point the only option seemed to be a custom Niagara spawner, rather than the built-in one. This meant making a new BP notify with all the logic I'd need in it. I started by replicating the built-in functions such as spawn location, bone attachment, etc., and got it to work fairly quickly. From there that's where I encountered some difficulty. Apparently... you can't spawn actors (which was the basis of my decals) from a notify -- or at least it never worked for me. That meant that the entire basis for the decal spawner being in the notify just didn't work, at all.
Once again though, somewhat anticlimatically, the solution was rather simple. Take the data from the spawned system and send it to the owning player, and then have that BP do all the decal spawning. Lo and behold, it worked!
Pre-blood changes.
Post blood changes.
Note: Blood collision does not have a 100% chance of spawning a decal, but rather a pretty low chance. The obvious reason for this is performance, but also in some instances (like with the pool of blood), more decals isn't necessarily better.
Video broke