Dev Update: Stability System
We decided to remove the Stability System from RR this week, a decision which came after much discussion and deliberation, collecting and listening to player feedback, and exploration of potential replacements and alternatives.
The Stability System - or the system where Heroes would become Unstable after dying once and Banished after dying while Unstable - was introduced to RR very early on in the closed alpha. Since then it has gathered mostly negative feedback from the player base since its introduction, being frequently cited as one of the biggest pain points that players have had with the game. If you’re interested in learning why the system was initially added to the game, what its goals were, and why we’re deciding to remove it now, I’ll be discussing these topics in detail right here. No worries if you’d rather just skip to the patch notes though!
Why Stability?
The primary goal of the Stability System was to act as a replacement for the persistent Health/HP which can be found in so many Rogulike games. The vast majority of games we’ve drawn inspiration from, including Slay the Spire, Across the Obelisk, The Last Flame, and Hades have a Health bar in them that measures how healthy your character or team is and persists throughout the entire run. Health in these games acts as so much more than a number to dictate when you die - they are often the primary axis of risk/reward decision making. Events in all of these games frequently ask the player if to trade their Health for some kind of power.
In card-based or action Rogulike games where players make dozens of skill-testing decisions in every combat, persistent Health makes perfect sense as a system for both measuring when a player's runs will end and as a tool for serving the player deep and interesting risk/reward choices. The “am I strong enough to sacrifice health for power here, or do I need to heal?” question is core to so many of the coolest choices in each run of these card-based and action Rogulike games, but in playing other Autobattler Rogulikes such as The Last Flame and Tales and Tactics I often found these systems to be clunky, confusing, and frustrating.
In an Autobattler the player doesn’t get to make in-fight decisions, they have to live or die or by the choices they made before the fight starts. This is part of the charm of Autobattlers, but it presents some awkward moments when it comes to run-wide Health. If you decide to tax the player’s run-wide Health whenever a Hero dies (such as the Flame mechanic does in The Last Flame), you can often run into situations where a single Hero death can end your run mid fight. I was personally incredibly frustrated when my entire run ended because one of Heroes made a strange mid-fight decision which I had no control over.
I also found that taxing the player’s run-wide Health whenever you lose a fight (such as they do in Tales and Tactics) led to a very different set of problems. Allowing the player to progress forwards in a run after losing a fight feels awkward, but having the player repeat the fight until they win often leads to situations where it is optimal to use your lives as a tool to be as greedy as possible and incentivized intentional losses.
For these reasons, I decided fairly early on in designing RR that it needs to feel very clear and fair to the player when they lose a run, which meant Flame-like mechanics where a single Hero loss mid-fight can end your run were out. I’m very happy with how run-ends work in RR right now - I think the Shard Stabilizer does a great job of giving the player an extra life while still incentivizing you to win every fight. But the Shard Stabilizer isn’t a run-wide resource in the way the Health in so many Rogulikes is, and my expectation was that without some kind of run-wide resource which can be lost during or used to drive interesting decisions during events, that fights would feel low stakes and events would feel boring.
Enter, Stability System. I thought that tying in-fight Hero death to a persistent resource would make fights feel higher stakes, and that allowing players to restore Stability by benching a Hero for one fight would result in the Reserves feeling much more impactful. As RR’s “Health”, I also expected that it would be the primary resource we use for risk/reward choices in Events. It all sounded great in principle, but it all fell flat for one simple reason: it feels really bad to get your Hero Banished. We discussed reducing the penalty for losing a Stability while Unstable - such as forcing the Hero to sit out for a fight - but ultimately decided the end result would feel the same. Each Hero feels so important to a team in RR, and players kept telling us that being forced to fight without one too often feels like the run has already ended. The feedback was clear: it was time to say goodbye to Stability.
Why remove Stability now?
At the end of the day it doesn’t matter how well-intentioned a system is, or how many goals it accomplishes for you. If the feedback is consistent patch after patch, then it’s time to make a change.
A lot has changed in RR since the system was first introduced. The Backup mechanic joined the game a few patches ago and has been successful at making the Hero Reserves feel important - a job which previously rested solely on the shoulders of the Stability System. I’ve also introduced a few new abilities, items, and keywords (such as Tilly’s new Signature passive and the Generate keyword) which have made fights feel higher stakes than before. Before the introduction of these new mechanics, I worried that removing the Stability System would result in fights feeling boring and players having no reason to care about purchasing new Heroes once their team took shape. Now that we’ve had the chance to see the impact that these new mechanics have had, I feel much more confident that removing Stability will solve many more problems than it might potentially cause.
Thanks for reading! If you’re interested in seeing more articles like this one which talk about the game design of RR, let us know in the Discord.
Aleco Pors, Lead Game Designer