The Challenge of Balancing an RTS

Balancing an RTS is difficult. It’s a long, iterative process and, inevitably, there will be mistakes along the way. Today, I’ll be exploring what makes balancing an RTS such a challenge and will provide some examples of my hurdles and intentions from my time as a designer on Ashes of the Singularity: Escalation (Ashes).

Many Variables & Context

The main reason why RTS games are so difficult to balance is the abundance of variables that need to be taken into account. Let’s assume two equivalent units that cost the same fight each other and Unit A beats Unit B with 20% health left. Does this mean Unit A is overpowered and should be nerfed by 20% to compensate? Unit A might overperform in this one specific case, but does the same thing happen if you get 5 against 5 or 50 against 50? Factors such as reload, burst, and projectile speed can make a massive difference when looking at the scalability of an interaction. Let’s assume even in the 50v50 scenario, Unit A win with a 20% advantage. Is it now safe to say Unit A are overpowered? Unfortunately, it’s never that simple, you can’t just test things in a vacuum and compare them by their direct interactions, you need to look at matchups in their totality, and the only way to include the known and unknown factors is in regular matches. Other factors to take into consideration include the type of production and economic management for each faction, the synergy with other unit types and abilities, and additional mechanics such as regeneration or energy.

Let’s take a real example: One of the balance mistakes I made in Ashes was a gunship buff back in an old update. Previously, gunships were never used because their production was very inaccessible and the gunships themselves were weak. I both buffed the gunships and made them more accessible, which made rushing them out overpowered. I tested the performance of gunships against anti-air in the unit spawner and thought “Well anti-air is very cost efficient against these so it should be fine.” However, having air units attack anti-air and seeing how it performs is a very inaccurate simulation of a real game. The strength of gunships came from the ability to rush them out and surprise your opponent who may lack anti-air, or even if enemy anti-air was present you could just avoid them and fly around sniping extractors to weaken their economy.


Managing Bias

Testing regular games is time-consuming, and it’s difficult to replicate every situation. You need to test the late game, multiple game types such as 1v1 and 4v4, different maps, play styles, and skill levels. To adequately test this full range of scenarios, you need to outsource the playtesting, but doing so can water down the quality of the feedback if the people offering it lack the context, skill level, or are unable to eliminate their bias. Bias can take many forms; it could be the preference for a particular faction and playstyle, or it could be a designer’s own bias that an idea is great and it’s the community’s fault for not understanding it yet. I mitigate my personal bias through the three following ways:

#1 Lots of varied playtesting

Not much of a surprise, but the importance can’t be overstated. Lots of playtesting is essential in order to develop the game knowledge and mastery required to see through the bias and false claims of other people. As a designer you need to have the confidence and expertise to say, “No, you’re wrong, and here’s why.” Feedback from community members can be fickle, and you’ll only hear from a vocal minority, especially when they’re not happy. An RTS needs the stability of an expert designer who has a clear direction in mind.

To avoid my own bias, I continuously alternate between both factions. I play a variety of maps and try to play team games, despite my preference for 1v1. Playing against a variety of players is also crucial, as different players have varying play styles and there may be something unbalanced that some players don’t utilise.

#2 Watching replays and observing

This is similar to the idea of playing lots but is even better. When you’re observing a match, the emotional investment of winning or losing is thrown out. Better still than just passively watching is Shoutcasting, because when broadcasting and communicating the raw game to live viewers, it’s unavoidably clear when things are unfair or not fun.

#3 Variety of feedback

Taking feedback from a variety of people is incredibly helpful, whether it’s from players or other team members who may observe an “out of the box” factor. For example, an engineer saying “You probably shouldn’t make this building cost this resource because it may trip out the skirmish AI.” It helps to identify some people you can trust with the quality of feedback and assemble them into beta testing groups. People will suggest things that may have occurred to you but never articulated or may call you out on an oversight that you never considered.

Many players offering feedback may not have good suggestions, but if enough people are pointing towards the same issue, then it’s worth investigating. Feedback is a safeguard against making bad decisions, but you have to be critical about the feedback you are getting because their vision for the game may differ from yours.

Find The Root Problem

Often, the perceived balance problem isn’t the actual problem; players will typically only report issues at a surface level, but fixing the underlying cause is necessary to allow for maximum strategic diversity. Let’s take a recent case from which has now been fixed in the latest update. There were several claims of one of the factions, PHC, being stronger than the other faction, Substrate, in the late game. A wide blanket claim like that is not helpful so pressing for more information led to reports that one of the endgame units, the Leonidas juggernaut, is overpowered because Substrate lacks an answer since it duels the Substrate juggernaut equivalents.

I initially dismissed this as players not respecting the counter system; the Leonidas is intended to duel other Juggernauts since it lacks the area of effect damage of the Substrate equivalent, making it vulnerable to masses of air units or low tier ground units. I mostly play 1v1 games, which rarely go for long enough to field Juggernauts, so I hadn’t much experience trying to counter the Leonidas in a real scenario. In theory, Substrate had counters to the Leonidas, but I then played several team games and free for alls as Substrate where juggernauts became prevalent and noticed my assumptions didn’t hold up.

I tried building heavy gunships to counter Leonidas Juggernauts, but even with my own buffer of mobile anti-air to protect them, I was helpless as the gunships reliably got picked off by enemy air fighters. Likewise, trying to rely on mass ground units to counter the Leonidas was flimsy as one small mistake, and an Orbital Strike would decimate my entire army. I worked out what the underlying cause was; it wasn’t just that the Leonidas was overpowered, or that the units designed to counter it were underpowered, it was that the counters to the counters of the Leonidas were too strong.

Accurately diagnosing balance problems is only half the challenge; working out the best solution can be more difficult. When investigating how I will fix a balance issue, I’ll generally pursue the path of what will best foster strategic diversity. Had I not followed the rabbit hole to its origin and instead just weakened the Leonidas or buffed the Substrate equivalent, then the factions may be balanced in the late game, but it would result in just throwing Juggernauts at each other – the late game wouldn’t be as strategically diverse with functional counters. Asking if the game is “balanced” is the wrong question; it should instead be asking if the game is fun, challenging and strategically rich. If faction A has an overpowered thing, the solution isn’t to give faction B their own overpowered thing to compensate.

The Leonidas was overdue for a nerf, but it didn’t get one for so long because late game stuff is really hard to test. Let’s say Juggernauts only get used 1 in 30 matches I play; how many of those matches can be used to draw conclusions? Most of the times Juggernauts get fielded in my games is when somebody gets a big lead, so they sit back and rush out a Juggernaut, which then is promptly used to crush their opponent and end the game. I deliberately had to pick huge maps with similarly skilled players in 4+ player games to try and naturally create situations that would showcase the relative performance of Juggernauts. Anything situational or only available in the late game will be difficult to test, but the Leonidas’ over performance was prolonged by my initial dismissal of the players just not using the right units to counter it.

Map Design

The more asymmetric factions and units become, the more their performance varies on different types of maps. StarCraft 2 is praised for its meticulous balance while maintaining vast asymmetry between the factions, but this is only possible because of how formulaic its maps are. There are many strict rules that every StarCraft 2 map needs to follow else certain matchups would be broken; if there were no ramps into the main base Terran would be helpless against Zerglings.

Air units are always stronger on large maps because their mobility is more significant, and relative range of anti-air is smaller. Similarly, base defences are stronger on choke point centric maps because there’s less room to maneuver around them. A designer needs to decide on a loose format for the maps to adhere to, else it will be impossible to balance asymmetric content. It’s okay if unconventional and quirky maps are a part of the game, but they should not be used in standard play such as automatch.

Reconciling Single Player & Multiplayer

Unlike most RTS, Ashes uses the same stats for its single-player campaigns and multiplayer. Sharing stats has the advantage of ensuring consistency so that learning the game via single player better prepares you for multiplayer and prevents you from making false assumptions about units. The downside of this is that sometimes decisions for skirmish and multiplayer get held back by the needs of the single-player campaign. The missions can be changed, as much work as it’d be, but the voice over for them can’t be.

Technical Limitations

Most balance changes in Ashes are easy for me to implement, involving just a simple tweak of files. However, many things instead require a programmer to implement and even if it’s not time-consuming for them, but it still takes away from their crucial time of what would otherwise be fixing bugs or adding new features. Code limitations also mean as a designer I can’t just freely tinker and experiment. Some balance changes would also require an artist, large abilities such as an Orbital Strike can’t have their radius reduced because doing so would require the video effect to be redone to sync up with the adjustment.

An artist would also be required if I wanted to put juggernauts(Tier 4) in a separate production structure from dreadnoughts(Tier 3). That would require a whole new 3D model and texturing from an artist and a programmer to set up in the game. Performance can also be a factor; if I wanted to triple the number of drones spawned by Drone Hives, then players may get frame rate drops if they have too many of them on screen. Even for just balance changes, a designer always has to operate within a limited framework and sometimes has to settle for compromises.

Game Knowledge

I pride myself on being one of the top Ashes players in the community and having an incredibly deep understanding of the game. Despite this, I have made embarrassing mistakes due to lacking game knowledge about a particular thing. The antidote to missing game knowledge is obviously just more and more playtesting and getting feedback from other people who may notice things before me, but it’s important to be modest and avoid thinking “I know everything about the game” even after having spent an enormous amount of time on it. I try to assume that maybe other people might know something that I don’t.

Foresight of Changes

 Balance changes need to be done carefully to prevent them going overboard and flip something from underpowered to overpowered. It’s essential that a balance designer has the game knowledge and foresight required to predict the consequences of changes and preemptively make adjustments to compensate. Little changes can lead to wide consequences such as timings and performance of counters. The knock on effects of balance changes is the context that community members tend to lack, so if a designer doesn’t understand their game well enough and is basing their changes mostly off community feedback, there will be a perpetual state of playing catch up for new balance issues that arise each update.

Intuitive Design

Aside from balancing, there are other ideals to aim for such as making the game more intuitive. Certain changes may make the game more balanced, but if it’s a contrived and visually unintuitive change, then that’s something you want to avoid. Before I began working on ashes, the Strategic Bomber could only target buildings which was jarring as it was a very artificial limitation. It took a lot of tweaking to balance a Strategic Bomber capable of engaging units, but giving it more freedom and depth to players should be one of the highest design goals.

Cool Factor

The visual presentation of the game is a factor that needs to be considered, balance isn’t everything. Lowering the projectile speed of a weapon might make it more balanced, but it could have the consequence of looking contrived and less cool. In Ashes, light air units spawn as squadrons of 3 while heavy air units spawn as a single model. This has the consequence of splash damage and single target anti-air performing drastically different depending on which type of aircraft they are engaging. I’ve thought about removing the squads of 3 that light air units spawn and replacing them a single entity with triple the stats, but the light air squadrons look cool and help to make the game feel large scale. Gameplay should generally come first, but there are other factors to take into consideration, and there’s usually a balance solution to find that doesn’t involve removing the cool factor.

Asymmetric Factions

Another factor that has to be kept in mind is the asymmetric design; it’s generally more interesting if the factions are unique and the units aren’t the exact same as their alternative. Balance changes should try to avoid making the factions less asymmetric, but this isn’t always an option depending on how the counter system and matchup are fleshed out. Managing asymmetric design is often a battle of competing qualities, asymmetry is good but strategic diversity, and intuitive gameplay is better, if the asymmetric design is sacrificing those other qualities then it’s bad design.

Asymmetric design can also be a balancing challenge if factions vary in their difficulty level; if one faction is easier to play than it will practically be overpowered in low-level games, while the more difficult factions will presumably be overpowered in high-level games. Ultimately, asymmetric design can be great if it’s done correctly, but if done poorly just done for the sake of it, it can and has ruined RTS games. I like to think of asymmetric design as a tool that can be used to create fun varied gameplay, not an objectively good feature that should be aimed for to tick a box. If you’d like to check out some expanded thoughts on asymmetric design in RTS click here.

Final Thoughts

RTS games are immensely challenging to balance as they have a vast range of factors that need to be taken into consideration, requiring lots of playtesting. It’s crucial for a balance designer to have a deep mastery and understanding of the game because while invaluable, player feedback is fickle. A designer requires foresight to predict consequences of changes and needs to diagnose issues at a deep level to cater maximum strategic diversity. The challenge of balancing is increased by designers having to work within a limited framework and having to make compromises between other design principles.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s