Install Steam
sign in
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Bahasa Indonesia (Indonesian)
Bahasa Melayu (Malay) BETA
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem


Hi, my name is Krzysiek. On SacriFire, I work on design and level art, and I also handle most of the combat design. Lately, my main hobbies have been trying not to go insane and not gain too much weight during development.
This is my first real project in game development, and looking back at how our combat system evolved, I’ve come to realize it's less of a straight path and more of a constant process of questioning, breaking things, and trying again. So, I wanted to take a moment to walk you through that journey - what we tried, what didn’t work, and how the system slowly grew into what it is today.
At the same time, we made a conscious decision to separate combat encounters from exploration. Instead of fighting enemies directly in the world, encountering them would transition the player into a dedicated battle arena - a solution deeply rooted in classic JRPG design. Admittedly, it was a departure from our original inspiration, but one that felt right for the pacing we were aiming for.
After coming back from the holidays with fresh heads (and extra insulation), we shifted our focus heavily toward the feel. Enemy behavior, responsiveness, clarity - all the small things that are easy to overlook when you’re zoomed out and focused on systems, but absolutely crucial for making combat enjoyable all the same.
“When the player stands still, the world stands still with them”. A simple enough concept, but one that required rethinking a lot of the underlying systems we had in the oven - especially AI behavior and the principles of how enemies initiate and execute attacks. Still, it brought a kind of cohesion to combat that we were previously missing. Something finally budged, and this time, it was in the right direction.
When you think about it, the whole point of such a weapon would be adaptability - the ability to respond to different enemies and situations dynamically, as the situation requires. Locking the player into a single form felt like wasted potential, a potential we were determined to unearth and give the concept justice.
More questions began bubbling to the surface: What if each weapon form had its own unique advantage? What if one of those could excel at breaking through armor, the other could slow and hinder enemies, and yet another one apply battlefield pressure in even more different ways? Ultimately, the most pertinent question surfaced: What if these forms could fluidly interact with each other? That’s when the idea of combos started to take shape - sequences of attacks mixing different weapon styles together, in a specific order, triggering unique combat effects on execution. Suddenly, the weapon wasn’t just versatile - it became expressive.
The resulting system struck us as one where mastery isn’t just about knowing what to use, but when. The DIVOS became a tool for every task, and it fell on the player to best tap into those possibilities by properly composing their attacks. To that end, the combos were one of the first changes we introduced, but not the only one. In our search for fun and focus, we also decided to revamp a concept from the earliest stages of development, namely, the Affinity system.
That changes how we think about balance. Ezekiel needs enough tools to handle pressure, adapt to different enemies, and stay in control, but not so many that every encounter loses its teeth. Companions add extra options and moments of cooperation, but they don’t replace the need for the player to understand the flow of combat.
Hey everyone!
Hello everyone!
Apart from the very respectable works of the Western world, over the years I have grown an insatiable liking for all Japanese media and became a great fan of many JRPGs and animes. Some of my favorites are the Persona series and JoJo’s Bizarre Adventure, which both have become a primary inspiration for SacriFire’s tonal palette.
The subconscious realization of the present living and breathing world lets the player’s suspension of disbelief take over and enjoy any and every setting, no matter how far from reality it might be. Here are some of my favorites so far.
One of the goals of our combat system is to Stagger the enemy by filling their gauge and breaking them, dealing critical damage and stopping them in their tracks. When I first heard of this mechanic and saw it in gameplay, I immediately thought of Star Platinum’s iconic “The World” attack and it clearly inspired me in making the sound. At the same time, I also wanted to create some kind of a jingle to be played as soon as the game registers a Stagger hit, something akin to the Persona 5’s All-Out Attack.
And for that you definitely need good foley, meaning sound effects synchronized to the movement of a character, such as footsteps, cloth and armor, grabs, and so on. Right now, for Ezekiel there are sounds for his armor, cape, footsteps (6 different surfaces), jump, double jump, falling, land, dash, roll, slide, grab and ledge grab. You could also add teleporting sounds but they are not exactly foley.
To properly implement and time the sounds to specific animations, in cooperation with our programmers, we came up with an Animation Event system in Unity that lets me attach FMOD events to any animation in the game. It’s incredibly convenient and enables me to do all the foley work myself, without any additional help from different team members.
There’s also a separate system for footsteps alone, as it requires a more profound approach linked to the surface detection system, so that the parameter responsible for switching between different footstep types can function properly. Unfortunately, in some rare cases, the Animation Event system played back some sounds later than expected. This has been the case with the ledge grab sound, which resulted in a delayed feedback in movement, making climbing feel a bit sluggish. To circumvent that, special code had to be written that plays the particular FMOD event right as the game recognizes a ledge climb action.
The difference between a game cutscene (especially real-time ones, like in SacriFire) and linear media like anime is that while the camera does take away player control for a moment, we are still set in the very same scene in which we were just running about freely. The problem is, some sounds that are needed in dungeon exploration, are at the same time potentially annoying in a cutscene, like Checkpoints present in dungeons. Or if the camera flies away from the player character, how do we make it so that we hear what it sees? And what about changing shots and idling audio emitters suddenly cutting out due to the sudden jump of distance?
Lastly, what if the camera changes in the middle of a cutscene and travels a substantial distance over the level but at the same time, suddenly cutting short all idle background world looping sounds? For that, I created another VCA and event that works the same way as the previous one, which is played on every camera change in Unity’s cutscene timeline. It’s purpose is to gently fade-out and fade-in all the looping sounds in the scene.
Loading
