Hey folks,

Today I’ll be discussing some principles for the effective design of competitive real time strategy games. These principles help ensure a flexible foundation that enables a balanced, fun, and highly competitive game. I’ll then argue that the Protoss race in StarCraft II uniquely violates these principles, creating an unsatisfactory gameplay experience.

Finally, I’ll conclude by arguing that the correct approach to these problems in the long-term is a major redesign in the mold of Patch 3.8. I’ll state upfront that this post is not a criticism of the game’s designers. In fact, many of these problems stem from smart design responses to issues that were more fundamental in nature.

Special thanks to Artosis for giving this a read ahead of time and providing some feedback.

Motivation

The core motivation for this post is the underrepresentation of the Protoss race across StarCraft II’s biggest leagues – Gold, Platinum, and Diamond, covering about 70% of the player base.

First and foremost, this negatively affects players who prefer to play Protoss – they’ve either switched to a race they don’t like as much or have left the game entirely. The remaining players experience a smaller player pool to share builds with, discuss strategies, or simply vent about frustrating issues. This is a vicious cycle – the smaller player base incentivizes players to switch races or leave the game, worsening the existing problem for remaining players and increasing their incentive to do the same.

Everyone else is negatively affected, too. Race asymmetricality is a core building block of competitive real time strategy games. It’s a key driver of a fun and diverse competitive ladder. Players don’t get to experience a large part of the game’s design because they’re not able to find the appropriate opponents on the ladder. When they do, they face an experience disadvantage because they’ve played their opponent’s race far less often than their opponent has faced theirs. This can be frustrating, especially in a game with so many sharp timings like StarCraft II.

Why has this happened?

Why does this underrepresentation occur?

One could argue that the tutorial features Terran, creating an extra incentive to play Terran. But that doesn’t explain why Zerg is so popular.

One could argue that Protoss has a less interesting aesthetic or that its lore is unappealing. But that doesn’t explain why Protoss representation was at parity with the other two races a few years ago before substantially dropping off.

One could argue that Protoss is either easier or harder to play than the other two races, pushing Protoss players to the two extremes of the ladder. But then we would expect to see Protoss overrepresentation in Silver and Bronze or Master’s and Grandmaster, which we do not. (For what it’s worth, I disagree with this idea for many other reasons, too).

One could argue that Protoss has been consistently underpowered for the past several years. But that doesn’t explain the consistent success of Protoss players in numerous international tournaments.

The right way to answer this question would be to look at the results of scientific surveys of the player population going back to the launch of the game. Unfortunately, that data does not exist. Instead, we’ve got to do our best by analyzing the core gameplay and seeing if there is something different about Protoss that leads to this issue.

Design Principles

To me, the explanation comes down to design principles – Protoss uniquely violates a number of principles of strong competitive real time strategy design which leads it to be less satisfying and less enjoyable to play than the other two races.

What are these design principles? There’s no academic field of real time strategy with volumes of data and proven frameworks for building good games. As a result, I’ll be taking my time to carefully justify why the principles I outline in this post really should be called “principles” – why the designers of a competitive real time strategy game violate them at their own peril.

Execution Must Respect The Vision

Before we get started, I must emphasize this point – a game’s design must respect its own vision. Games are creative works built by people trying to accomplish something. How a game is executed, first and foremost, must respect that vision.

This is important because it helps us define whether something is a problem and, if so, the right way to tackle it. Warp Gate is a good example. Blizzard has made it clear that this is not a design feature they will ever substantially change – it’s part of their vision for the Protoss race. As a result, there’s no use spending time thinking about solutions which require a modification to Warp Gate. We should instead design solutions with it in mind.

Design Principle I: RTS players like RTS mechanics

This one is pretty straightforward. FPS players like shooting guns. RPG players like role playing and fiddling with their stats. MMO players like grinding. Players enjoy a given genre largely because they enjoy the mechanics of that genre.

The necessity of constantly comparing weapon statistics in a game like Borderlands is a feature, not a bug. It’s a looter shooter that appeals to people who like that kind of mechanic. Players like myself find this boring, so the designers provide a colored ranking system so we can shuffle our inventories quickly and get on with exploring and fighting. That doesn’t mean the focus on inventory management is a mistake – some players may find it annoying, but for most it’s one of the fundamental selling points of the game.

The core mechanics of real time strategy games can be found right within the genre’s name. Strategy emphasizes the player’s plan, like figuring out what they want to do, why they want to do it, and adjusting the plan through good decision making. Real time emphasizes the fast-paced execution of this plan – building things, producing units, growing an economy, expanding across the map, and so on. I put together an entire piece on why an emphasis on mechanical execution is critical to the genre – you can find it here.

Relative to the other two races, Protoss at the Gold to Diamond level exercises fewer core RTS mechanics, which makes it relatively less enjoyable.

Let’s start with the big ones – “power mechanics”. As I originally discussed here, power mechanics are basic tasks that need to be exercised constantly and deliver a measurable, substantial boost to the player each time they’re employed. For Zerg, this means things like spreading creep or injecting. For Terran, this means things like dropping mules. Even something like constant worker production could be considered a power mechanic.

Protoss doesn’t have a unique power mechanic. Chronoboost was changed to an automated toggle, which often translates to “set-and-forget” for players at this level. This is a problem because power mechanics provide a host of benefits to the gameplay experience:

• They’re viscerally enjoyable – the player gets to see the result of their action immediately, and that feels good.
• They’re cognitively easy to think about, meaning they don’t feel frustrating to use.
• They’re mechanically challenging, providing a highly visible avenue for improvement. Players can focus on improving their execution of power mechanics and see tangible, immediate results, even after years of playing the game – this feels good.

A lack of power mechanics means a less satisfying game experience relative to the other two races. But it’s not just here where Protoss is lacking:

• Protoss production occurs in “bursts” through warpgate rather than continuously like Terran and Zerg. This is less satisfying – it’s fewer opportunities to feel the joy of building stuff.
• Protoss tech structures, like the Robotics Facility, produce fewer high tech units than the other races, but idle time on them is far more costly. This feels more punishing.

Real time strategy players like real time strategy mechanics. Take some of those mechanics away from a race and it will be less fun to play than the other choices.

Design Principle II: Competitive players prefer incremental improvement

Players who play a game competitively like to improve incrementally, ideally every time they play. It feels good to get closer to a goal and make progress. It’s relatively more frustrating to need to play dozens or hundreds of hours to accomplish this when compared with learning something new and getting a little bit better every few games.

Competitive play in StarCraft II, in my view, begins somewhere around Gold League. This is when players play the game regularly enough that they’re usually genuinely interested in doing better and climbing the ladder. Their absolute skill level isn’t particularly important – a desire to compete and play better is all that matters. By analogy, folks work hard to win after-work basketball leagues, regardless of the skill gap between them and players in the NBA.

Protoss at the Gold to Diamond level features fewer avenues for incremental improvement than the other two races. Many of its core mechanics are binary – the player either executes them correctly or they don’t. Here are a few examples:

• Protoss base defense relies heavily on the Mothership Core, added in Heart of the Swarm. This relies on correct Pylon placement and the Mothership Core being in position. Base defense efficacy ends up feeling very binary: either the player built their Pylons in the right place or they didn’t, either their Mothership Core was in position or it wasn’t. Terran and Zerg depend heavily on actual units to defend themselves, allowing them to focus on much more incremental tasks like good macro and splitting up their forces effectively.
• Protoss is especially vulnerable to certain kind of units, like Mutalisks without having Phoenixes, a situation exacerbated by Heart of the Swarm’s addition of Tissue Regeneration. Building the appropriate response in-time requires good scouting and game sense, higher-order skills that improve in a discrete way. Terran and Zerg players can focus on the incremental task of simply building more stuff (as compared to “the right stuff”) more often than Protoss players can.

The fewer avenues for incremental improvement and the more punishing nature of binary tasks means that it’s harder for a Protoss player to focus on improving simple things relative to a Terran or Zerg player, leading them to be more likely to feel helpless when they’ve made a mistake and more frustrated about a loss.

Design Principle III: Avoid dead or late converging tech tree branches

Players’ decisions in a real time strategy game build upon one another – ideally, the opener flows neatly into the mid-game which flows neatly into the late game. An optimally designed tech tree complements this by allowing earlier decisions to build upon or unlock later decisions.

Dead or late converging tech tree branches run counter to this by offering decisions that don’t neatly flow into the rest of the game. This puts the player at an inherent disadvantage, because their early decisions don’t strengthen or complement their later decisions. The designer responds to this by making these branches especially strong, ensuring that they punish the opposing player enough to enable the late-converging player to catch up.

The problem with this is that it’s frustrating for both parties. Particularly at the Gold to Diamond level, it creates binary situations in which a tech either works or it doesn’t, making games feel coin-flippy.

The Protoss tech tree is significantly less complementary and forward-flowing than either Terran or Zerg – many strategies call for players to invest in tech that loses utility for a significant portion of the mid-game.

Let’s compare the Dark Templar with the Cloaked Banshee. Both are capable of doing enormous damage if left uncountered – but the Banshee calls for the Terran player to build a Starport and a Tech Lab, useful items in the mid-game. In contrast, the Dark Shrine and Dark Templars don’t contribute significantly to the Protoss mid-game composition.

The design compensates for the weakness of the late-converging Dark Templar tech path by making it comparatively stronger than the more complementary Banshee tech. Cloaked Banshees are much easier to incrementally scout (see lots of gas being mined, see a Starport, see a Tech Lab, see it flying across the map) and have a lower ceiling on their damage output (limited energy) than Dark Templars (Dark Shrine can be proxied anywhere rather than close to the opponent, DTs can be warped directly in the opponent’s base, are permanently cloaked and one shot workers).

For middle-league players, early game Dark Templars can either instantly win the game, or they can do very little – it’s not often to see the same experience as Cloaked Banshees, where there’s a micro battle to prevent the opponents’ scout and a tussle to get enough workers to trade efficiently before being killed. The Banshee tech has a far wider range of outcomes than the Dark Templar tech, which is more binary in its results.

Oracles, introduced in Heart of the Swarm, have the same problem. Many Protoss mid-game compositions don’t rely on the Stargate, meaning the Oracle was designed to do enormous damage when built early in the game. The design here is a bit better and closer to the Banshee experience thanks to the unit’s micro potential, but it’s still too binary. There are still too many situations where the Oracle is either game-winning or accomplishes very little.

The Phoenix also suffers from this problem, though in the opposite way. Many Protoss mid-game compositions against Zerg don’t feature Stargate tech, yet Phoenixes are essential to countering mutalisks. The Phoenix tech tree in this case doesn’t properly complement the Protoss army because, relative to the tech choices that Terran and Zerg make in these situations, its utility is vastly more binary.

This is frustrating for everyone involved. It limits the number of viable macro opening and mid-game tech tree paths for Protoss players; meanwhile, when they choose to invest in late-converging tech early in the game, they produce games that are far more coin-flippy than similar strategies by Terran or Zerg. The key point here is that the tech choice forces a kind of all-in rather than the player choosing to do an all-in and then picking the tech they like; it forces a limited number of mid-game compositions rather than the player choosing that route. This takes away player agency.

This design also has the insidious side-effect of turning minor balance problems into severely imbalanced and frustrating situations. Each late-converging tech tree branch can be game-ending – any situation which gives Protoss players space to freely switch from one to another snowballs into a major gameplay issue. The TvP tech tree problems described in this post* were caused by a relatively minor problem with early game Adepts. The design is more fragile and thus more vulnerable to creating balance issues, hurting the gameplay experience.

* I disagree with the author’s later characterization of Protoss’s mechanical difficulty.

The StarCraft II Game Engine

This isn’t so much a principle as a fact of life – a game’s underlying engine is what every design decision is built upon.

The StarCraft II game engine provides smart AI, strong pathing, and unlimited unit selection. This means that larger armies aren’t necessarily proportionally more difficult to control than smaller armies – having twice as many units doesn’t mean a twice as large overhead in unit control, giving the player opportunities to do things like attack in multiple places or get better surrounds.

The fundamental design of Protoss is that it features fewer, stronger units than the other two races. This means that it benefits relatively less from the design of the game’s engine. The designers need to solve this problem – either by tweaking the numbers perfectly to balance Protoss against this disadvantage or leveraging a high skill ceiling to allow Protoss players to improve their way out of losing situations. (See my post on mechanics for an in-depth discussion of balance through a high skill ceiling).

The designers have generally chosen the latter – it’s a more flexible approach to building a balanced game. The StarCraft II team’s approach to upping the micromanagement skill ceiling has historically been to emphasize ability mechanics.

This approach comes into conflict with the addition of content in expansion packs and game updates. The addition of more units scales better when the player is focused on the more basic aspects of unit control, like moving and attacking – there’s less cognitive load associated with adding more units onto the field. It scales poorly when new units add cognitive load – which, presumably, the player was already fully utilizing prior to the new content.

Protoss’s original design featuring smaller armies with sturdier units forces the designers to give them more abilities than the other two races when adding new content in order to retain a balanced gameplay experience. The result is that virtually every core Protoss unit save for the Zealot has a cognitively challenging ability that is essential to using the unit effectively. This places relatively more emphasis on the higher-order skill of ability usage, making Protoss armies more frustrating to control and less viscerally fun to use, particularly for Gold to Diamond players – abilities are, by their nature, more binary and less incremental than the more basic aspects of unit control.

A Call For A New Design Patch

These problems come together to create a relatively less satisfying and less enjoyable gameplay experience. The mechanics are less fun, incremental improvement less viable, the tech tree more narrow and coin-flippy. In addition, Protoss’s fundamental design comes into conflict with the design decisions baked into the game’s engine.

I argue that these problems, often introduced one by one through design patches and expansions to keep the game balanced or resulting from the original design not scaling as the game evolved, have alienated Protoss players. They’ve either switched to different races or left the game entirely, resulting in the underrepresentation that we see today.

These are not issues that can be fixed by changing some numbers. The interdependency of gameplay systems means that changing the design of something like the Mothership Core necessitates changes to numerous other systems as well. As a result, fixing these problems requires a fundamental overhaul of how Protoss functions as a race, similar to but more expansive than the 3.8 design patch which changed numerous aspects of the Terran race to make mech more viable. A simple balance patch won’t be enough.

Pointing out these problems is much easier than offering solutions, which I won’t do here. I’m working on a project to propose a suite of design changes, but it’s not ready yet. It requires a lot more thinking and discussion with other players. I’d love to hear your thoughts on the state of the Protoss race and what kind of design changes you envision to make it more satisfying to play.

That’s everything I had for today. Coming up, I’m working on a long-form video going in-depth on gameplay balance in real time strategy games. Thanks for reading and I’ll see you next time.

(P.S. If you are interested in learning more about the StarCraft II engine, I highly recommend this video. One of the most interesting things it shows is that the decisions around unit AI and pathing were made very early in the game’s development process.)