StarCraft II and Brood War Belong to Different Genres

Hey folks,

Today I’ll be proposing a breakdown of competitive real time strategy games into two distinct sub-genres – “classic” and “modern”. To do this, I’ll argue that StarCraft II is not a successor to Brood War – it belongs to a different sub-genre.

To be clear – this piece does not take a position on which game is “better” or “worse”.

Special thanks to RAPiD for providing feedback on this piece prior to release. Special thanks to Lalush and AVEX, whose conversations have contributed a lot to my thinking around this topic.

The Two Types of Competitive Real Time Strategy Games

2016-12-24_teutonLateGameEconomy.png
Economic management in Age of Empires II.

Over the past two decades, a number of real time strategy games were released with either a partial or fully committed vision of a competitive multiplayer scene. Titles progressively coalesced around a common feature set and way of doings: professional playtesters to help balance the game, in-game ladders and automated matchmaking, periodic balance patches, financial and logistical support for competitive tournaments, and so on.

A hallmark of this period was progressive consensus around design paradigms that players did and did not want. One of the most significant was increasing focus on the strategy component of real time strategy and reducing focus on its real time or mechanical component, particularly around designing a convenient and easy to use user interface. Bruce Shelley, one of the lead designers of the Age of Empires series, noted this explicitly when discussing the re-design of the farming mechanic in moving from Age of Empires I to II.

This meant design decisions like streamlining macromanagement (multiple building select, rebindable hotkeys, etc), micromanagement (stronger AI, unit pathing, waypointing, etc), and simplifying economic management to encourage more focus on military strategy. Designers targeted both the casual and competitive scenes – mechanics were progressively simplified, but there was also lots of work done to ensure a good environment for competitive play. There are plenty of examples of this:

  • The inclusion of Age of Empires III, Dawn of War, and Command and Conquer in the World Cyber Games in the mid-2000s. The WCG required companies to sponsor their games in order to include them in its tournament. The inclusion of these titles indicates companies were willing to put concrete financial support into their competitive multiplayer scene.
  • The support for televised matches of Age of Empires II and the direct engagement and solicitation of feedback from professional players both indicate strong, tangible support for a competitive scene.

My point here is that the design shift toward emphasizing strategy was not an attempt to “casualize” the genre – companies viewed support for a competitive scene as vital to their interests. Here’s another quote from Mr. Shelley regarding the commercial success of Age of Empires:

How do you think Age of Empires ended up with such a large online following?

BCS: I think it sold well overall because it appealed to both online/hardcore gamers and casual gamers. There were a lot of different experiences in the box and players of all tastes could find a game that really suited them. For everyone the game was bright and inviting. For online particularly, I think it was well balanced and challenging, and always a little different thanks to randomly generated maps. We had playtested it for years in multiplayer mode (the artificial intelligence for skirmish mode was finished late) so it was fairly well polished for online play by the time it published.

The progression in design from mechanical to strategic focus was instead considered a modernization of the genre, increasing its accessibility to the mainstream market and making the gameplay experience more enjoyable. However, I’m going to argue that it achieved something completely different – it created a distinct, separate sub-genre of competitive real time strategy games that is fundamentally distinct from the “classic” competitive real time strategy games that preceded it.

To do this, I’ll argue that StarCraft II belongs to this “modern” genre, and is therefore not a true successor to Brood War, which belongs to the “classic” genre. I’ll also include numerous references to Age of Empires 2, which shares a number of design characteristics with Brood War and whose successors took a “modernization” approach similar to StarCraft II.

Design Fork-In-The-Road #1: Mechanical Execution vs. Strategic Execution

Classic real time strategy games emerged in an era where they were viewed as strategy games that were not turn-based. As a result, they placed emphasis on mechanical execution – building units, placing structures, researching technologies, etc – because that was the key value-add for players coming from a turn-based background.

Modern games’ progressive reduction in focus on mechanics in favor of strategy and decision making had a dramatic impact on how games played out. Classic real time strategy games rewarded the player who could build the most units. It was mechanically impossible to maximize production efficiency by the mid- and late-game while simultaneously doing everything else. Players that were more mechanically skilled could win by simply building a lot more stuff than their opponent.

The modern approach changed this paradigm by streamlining the mechanics of production and emphasizing the right units – choosing a composition that effectively countered your opponent and adjusting it as the game went by. The streamlined production mechanics made it more difficult to win by sheer mechanical force, so players placed more emphasis on building the right units.

This extends to economic management as well – the sheer size of mid- and late-game economies and their spread across the map in classic real time strategy games required enormous mechanical skill to effectively manage. The limitations in the user interface contributed to this, such as simplistic or out-right missing waypointing systems, which forced players to do lots of simple mechanical actions. Modern games streamlined user interfaces to make economic management easier, allowing players to focus more on what their economy was trying to achieve rather than whether or not their economy was actually doing anything.

Army control was affected, too. Controlling a maximum supply army in a classic real time strategy game was extraordinarily difficult due to things like poor unit AI, weak pathing, and limitations in the user interface around control groups. This created a comeback mechanic in which superior mechanical control of a smaller group of units by the losing player could defeat a winning player managing an uncontrollably large army. Modern real time strategy games change this. Armies are mechanically easier to control, meaning that a player with a larger army will usually defeat a player with a smaller army. Comeback mechanics instead center around strategic decisions like harassment or tech switches.

Positioning and tactical battle planning changed as well. It was difficult to perfectly control armies in classic real time strategy games – as a result, simply moving units to the battlefield and getting them to engage took precedence over taking the right position and planning out the overall movement pattern of an army. There was also more incentive to fight whenever possible – a higher percentage of engagements were viable because their results were more dependent on control than composition. Modern games reduced this mechanical burden, allowing players to spend more time planning their battles and winning by taking a superior position – in other words, focusing on more strategic tasks. This also means more emphasis on poking, prodding, and re-positioning over direct engagements.

The shift in focus from mechanical to strategic execution creates a shift in how games flow: more focus is placed on the trade-offs in a player’s strategic plan rather than trade-offs in the execution of their existing plan.

Design Fork-In-The-Road #2: Economy as a Playstyle vs. Economy as a Simple Input to Military

Classic real time strategy games generally featured three core playstyles that emphasized different skill sets. Age of Empires called these “boom”, “rush”, and “turtle” – economic focus, military focus, and unit composition focus. The general RTS terms I heard for these playstyles back in the day was “macro”, “micro”, and “turtle”, which represent the same basic concepts.

Modern real time strategy games progressively de-emphasized focus on economic play, viewing it as a burden on a player’s ability to focus on strategy. Economic playstyles of classic real time strategy games were particularly mechanically burdensome; managing numerous bases in Brood War or managing a near-one-hundred villager sized economy in Age of Empires 2 largely consisted of doing endless numbers of simple, mechanical actions in order to keep economies going.

(As an anecdote, competitive players complained about farm auto-queuing in the expansion to Age of Empires II, noting that it would dramatically reduce the game’s skill ceiling. For those who didn’t play the game, farms automatically ran out of food after a certain period of time, and players had to manually click each one and re-seed it as the game progressed. This was pretty challenging, with players having dozens of farms in the late-game and needing to re-seed constantly. The expansion pack allowed players to automatically re-seed farms by queuing future farms at their Mill.)

The modern approach was to instead target economy as a simple input to military units – in other words, simplify and reduce economic mechanics to flatten the economic differences between different playstyles. This encouraged players to focus on their unit composition and tech choices instead of their economy.

This shift in design had a substantial (and probably unintended) consequence: it fundamentally altered the dynamics around cost-efficiency when players chose to turtle.

Economic playstyles in classic real time strategy games centered around the idea that, by having a much larger economy, the economic player could trade units inefficiently against a turtling opponent and still come out ahead. This gave the economic player great incentive to expand across the map (or, in the case of Age of Empires, place lots of town centers), amass a huge number of workers, and constantly attack their opponent to prevent them from building a superior unit composition.

The turtling playstyle responded to this by emphasizing a highly cost efficient unit composition. If the turtling player could survive the constant attacks from their economic opponent, they could slowly move across the map with a significantly superior force.

This was an interesting, action-packed design. It limited the number of games where players played passively while maxing out their supply. The economic player was attacking constantly and building across the entire map, while the turtling player was scrambling to stay alive.

This wasn’t limited to the economic against turtle dynamic, either: the strength of expanding one’s economy, the ability to trade and engage the opponent’s army directly, and the need to spread across the map created action-packed games when one player rushed or when both players opted to play economically. Here’s a few examples.

Modern real time strategy games remove this dynamic by equalizing the differences in economy between different playstyles. Rather than players trading off between a focus on economy and military, every macro style has a similarly strong economy – the difference is the military strategy and unit compositions that are chosen. This places a huge emphasis on cost-efficient trades, which typically favor the defending player. It also means that turtling playstyles produce significantly more passive games because there is no longer an incentive to attack into a more cost-efficient force: players instead harass their opponent’s economy or, more likely, choose to turtle themselves into an equally good or superior late-game unit composition.

This is pretty easy to see if you compare Age of Empires II with its successors – large, “booming” economies are replaced by economies that serve only as an input to the ideal unit composition. Players tried as hard as they could in Age of Mythology and Age of Empires III to limit economic growth whenever possible and play the races with the most cost-efficient characteristics – Set due to his animals in Age of Mythology, Dutch due to their banks in The War Chiefs, and Japanese due to their Shrines and Musketeers in The Asian Dynasties. Here’s a quote from a guide written to help players adjust to the changes in Age of Mythology:

Compared to those in AoK, villagers in AoM work much more efficiently – you won’t need as many as you did in AoK. By the time you reach Heroic Age you shouldn’t need to build any more, unless you have lost a lot of them due to fighting.

It’s no coincidence that the same article also contains this advice:

Avoid fighting enemy soldiers if you can help it, and focus on attacking your opponent’s villagers and economy. Only face an enemy army if you are sure of a victory or if he is threatening your own economy.

I imagine most of the folks reading this blog post come from a StarCraft background, so I’ll go into more detail about the differences between the Brood War and StarCraft II economies.

(I’m not as familiar with Brood War as I am with Age of Empires 2, so I’ll take this opportunity to note that I am incredibly grateful to the numerous folks who gave me feedback on this section. Non-inlined-references are at the bottom of this post.)

Bases in Brood War began to mine more inefficiently when more than one worker was assigned to a single mineral patch. This meant that fifty or sixty workers spread across five or six bases would mine significantly more than fifty or sixty workers assigned to three bases. This is the basic foundation of an “economic” vs. “turtle” dynamic – the economic player can take more bases, have a much better economy as a result, and trade cost-inefficiently with a player sitting on fewer bases – hence the idea of a Protoss player being “one base ahead” in PvT when the Terran plays mech.

StarCraft II changed this dynamic by allowing perfect mining efficiency at two workers per mineral patch rather than one. Because there’s little upside in terms of supply efficiency of going beyond 70 workers, StarCraft II effectively has a “soft-cap” of a three-base economy. This means that a turtling player sitting on three bases will have a similar economy to an “economic” player sitting on more bases.

The design here stems from a desire to reduce the burden associated with economic management, and it’s very intentional – notice the goal of avoiding annoying players in this pre-release interview with Dustin Browder, the lead designer of Wings of Liberty:

Q: That leads us back to the balance between Micro and Macro. Since Blizzcon 2008, you have changed the economy system again. Back then there were already two vespene geysers in each base, but they would shut down for a short time after having collected a certain amount of gas. Therefore you would have to check the status of your source of income frequently, forcing a large amount of Micromanagement. Why this change?

A: Oh dear, we are thinking about how to modify the geysers since forever. We want you to have to manage your economy more. And the geysers would be a perfect start point, since they were quite unspectacular in the past: You sent three workers there, and that’s it. So we decided to change the mechanic, which hasn’t succeeded thus far. It was extremely hard to balance the new system. Had we decided to regulate the gas supply necessarily by hand, to collect the regular amount of resources, we would have severerly disadvantaged the newer players, since they couldn’t afford expensive units like Battle Cruisers and Templar. But just these units have the most appeal to casual players. Therefore, we would have to modify the mechanic in that way, that you still earn enough gas if you leave the geysers to themselves. But then, Micro experts would collect by far more resources and would produce only very mighty units like Carriers and Archons. That would also be unfair. In addition, the constant geyser-checking would become annoying very quickly. We want to reward the players, not annoy them.

(emphasis mine)

This line of thinking should sound familiar – it’s the same approach Age of Empires took to re-designing its farming mechanics. The removal of collection points followed a similar pattern in Age of Empires III.

The effects of the three-base soft-cap are compounded by the way bases are placed on the map. For a multitude of reasons, many stemming from Protoss’s relative inability to effectively defend three bases in the mid-game when their third base is too far away, bases in StarCraft II are much closer to one another than in Brood War. This is another advantage for the turtling playstyle – not only is their three base economy just as good as their opponent’s hypothetical N-base economy, it’s also fairly straightforward to achieve.

The result is that enormous emphasis is placed on cost-efficiency. Trading inefficiently is strongly discouraged because there is no effective way to counter-balance this with a substantially stronger economy. This lends a natural advantage to turtling playstyles that emphasize cost-efficient unit compositions. It also means the designer needs to put extra effort into balancing the game; if it’s reasonably straight-forward to turtle to the game’s “best” composition, then the “best” composition needs to be regularly examined and potentially nerfed. The ability for players to improve their way out of this situation by playing an economic playstyle is substantially hampered.

StarCraft II thus heavily incentivizes players to either rush or turtle. It manages to partly avoid this polarization by enabling a number of powerful timings in both the early and mid-game, allowing macro players to play something in-between the two styles. However, I want to emphasize here that what’s considered “macro” play in StarCraft II is not dissimilar from the “turtling” play we saw in classic real time strategy games – players are rarely, if ever, incentivized to trade inefficiently, meaning they adopt the same fundamental get-the-best-composition mindset of a turtling player. The inclusion of timings just acts to provide exit ramps that enable players to actually attack each other before maxing out their supply.

Before we go further, one point worth raising here is the concept of oversaturation. Brood War allowed players to oversaturate bases with workers to a far larger degree than StarCraft II, which severely punishes mining efficiency after the 17th worker. Furthermore, the large distance between bases meant that additional expansions were difficult to defend and hold. This incentivized players to stay on fewer bases than the economy fundamentals might otherwise suggest, encouraging players to expand ahead of their opponent only when facing a turtling style.

This is likely one of the key reasons that in Brood War we don’t see the same sprawling economic vs. economic styles that we saw in Age of Empires II – expanding in that game meant building town centers, which had built-in worker garrison and self-defense capabilities. Expanding was relatively safer and there was no concept of oversaturation on farms (oversaturation on wood was possible to a large extent while limited and eventually hard-capped on gold and stone), design features which heavily incentivized expanding outward. This also points to the fact that the economy is interdependent with other gameplay systems – the immobility of Terran mech disincentivized expanding too quickly, stronger static defense capabilities in Age of Empires II made expanding safer, and so on.

Design Fork-In-The-Road #3: Basic macro- and micromanagement vs. advanced macro- and micromanagement

I touched on this topic in the mechanics section, but I focused mostly on its impact on how games play out. I also want to examine its effect on user experience. Classic real time strategy games, partly by choice and partly by technical limitation, emphasized very basic macro- and micromanagement. The game engines’ capabilities were fairly limited, and players spent most of their time doing basic actions – selecting production facilities, queuing units, reorganizing their economies, moving units, targeting enemy units, etc.

Modern real time strategy games streamlined these mechanics and shifted focus to more advanced macro- and micromanagement with more strategic implications. Age of Mythology emphasized god powers, Age of Empires III emphasized positioning around cannons, and StarCraft II emphasizes ability mechanics (spellcasting, siege / unsiege, etc).

This approach synergizes with the economy changes mentioned previously. Dumb units in classic real time strategy games were remarkably ineffective without handholding, meaning that fights came down to control more than anything else. Losing units was also less painful because it was more acceptable to trade inefficiently. Smarter units in modern games are much more capable of winning fights on their own – a stronger army will generally defeat a weaker army, regardless of control. This places more emphasis on cost-efficiency and changes how players think about taking engagements. Players actively avoid fights they think they can’t win, because they’re less able to simply control their way to victory.

The difference in moment-to-moment actions also changes how difficult a game feels. Players in classic games spent their time doing things that were very easy and basic. Easy tasks feel easy. Players in modern games spend their time on more advanced and harder tasks like spellcasting. Hard tasks feel hard. I think this partly explains the feedback from Korean professionals that StarCraft II is “too difficult”, even though it is less mechanically challenging in-aggregate than Brood War. Advanced actions, particularly binary mechanics like spellcasting, come across as more challenging than basic tasks like queuing units.

The experience of controlling units on a moment-to-moment basis is also particularly different. Classic real time strategy games featured units that were ineffective without manual intervention. Controlling units meant a focus on achieving something. Units in modern games are not only more capable than their predecessors, they’re also easier to control thanks to user interface niceties like smart casting and stronger waypointing. Unit control has a chess-like feel to it – controlling an Oracle is less about achieving anything than it is about executing the right strategic decisions to get it in the right place at the right time to achieve a specific goal. Once that’s accomplished, the unit can do the rest on its own, at least relative to units in classic games.

How this ties together

These three forks-in-the-road share a common trait: classic games emphasize the real time component of real time strategy games while modern games emphasize the strategy component. Designers take different forks in the road because they synergize well with each other. An emphasis on building more units instead of the right units fits well with a sprawling, hard-to-manage economy that allows for inefficient trades, a streamlined user interface meshes well with smarter units that are easier to handle, and so on.

In the case of Age of Empires, this was very intentional – Bruce Shelley specifically cited simplified micromanagement as an achievement in the progression of the series.

This piece does not argue that one approach is objectively better, though it goes without saying that individual players will usually prefer one over the other. Rather, it emphasizes that they are different approaches which result in fundamentally different gameplay experiences.

This piece also does not argue that mechanics and strategy are mutually exclusive. Classic games featured plenty of tactical battle planning, positioning, and strategic development – observe the progression in the meta-game of Brood War over the past two decades. Similarly, modern games don’t benefit from de-emphasizing mechanics. I discussed both of these ideas in my mechanics piece.

StarCraft II’s design decisively treads the strategic fork in the road. It emphasizes the player’s plan and how they adjust that plan rather than their execution of that plan. It limits sprawling economic playstyles, producing more passive games with less action. Its user interface is strong and heavily featured. It requires more input from its designers to continually rebalance the game because of the strength of turtling into cost-efficient unit compositions (and remember – most “macro” play in StarCraft II is just turtling in disguise).

It’s not a successor to Brood War – instead, it’s arguably the best-to-date version of an entirely different type of game, the “strategic” or “modern” competitive real time strategy game. It’s more streamlined, more passive, feels harder, and is more focused on the right decisions – it emphasizes the strategy in real time strategy. Brood War and Age of Empires II are more mechanical, more active, feel easier, and are more focused on optimal execution – they emphasize the real time in real time strategy.

In the future, I’d like to examine the implications of these design approaches on a game’s viability as an electronic sport. We’ve already gone fairly long today, so I’ll save this for another time.

If you enjoyed this post, please consider following me on Twitter or Facebook to receive regular content updates, or checking out my game-design videos on YouTube and Twitch. Thank you for reading and see you next time.

Additional References

Time to First Action and Comparative Player Analysis

Hey folks,

Today I’ll be talking about time-to-first-action, why it’s important, and leveraging the concept to do some fun comparative analysis.

Time to First Action

Time to First Action (TTFA) is a way of organizing player actions in order to measure and evaluate player skill. It represents the time delta between a player moving their camera a significant amount – for instance, hitting a location key to return to their main base – and taking an action – say, injecting their hatchery. This idea was first introduced to me as Perception-Action Cycles (PACs) in a study on video games skill development. (thank you to Lalush for showing this to me)

Time to First Action was first conceived of, as far as I know, in Brood War. It was hypothesized as a more accurate predictor of player skill than actions-per-minute (APM). It measures how quickly a player responds to new information rather than simply measuring how many actions a player is executing.

APM is limited in its utility in measuring skill because it doesn’t differentiate between effective and ineffective actions – it’s hard to determine whether a change in APM correlates with a change in a player’s skill level. Time to first action tries to eliminate this by assuming that a player’s first action upon absorbing new information is likely to be useful – if this is true, executing it faster is better than executing it slower. It can therefore be used to approximate a player’s mechanical ability.

What Are We Measuring?

Each action measured by TTFA is composed of two distinct time segments:

  1. Cognitive segment – processing visual information, understanding what’s been seen, assembling a set of responses, deciding on the best response
  2. Mechanical segment – executing the best response

One of the consistent patterns I’ve observed across different types of games is that substantial increases in skill are associated with reducing or eliminating the cognitive segment associated with an action. Once this is achieved, the player only focuses on efficient mechanical execution.

It’s easy to see why this would be associated with a skill increase. The correct response is chosen almost immediately. Regardless of the mechanical difficulty associated with its execution, the player will quickly improve because they’re repeating the exact same thing over and over. What response to choose and how quickly it’s chosen has become a non-factor.

Time to First Action approximates, on average, how many of a game’s interactions a player has successfully transitioned from cognitive + mechanical challenges into pure mechanical challenges. The more a player practices and the more times they seem the same situation repeatedly, the faster they’ll react on average.

In theory, it also measures a player’s physical speed in how quickly they can react, but this has a fairly hard (and low) ceiling on it. The first action is usually very basic, like moving a group of units, so it’s easy to execute quickly. The rate that a game’s clock ticks – 16 times per second in StarCraft II’s case – also puts a ceiling on incremental mechanical improvement. Small, 10 to 20 millisecond improvements in reaction time won’t even register in the game engine.

Before we go on to our comparative analysis, I wanted to mention that this can be observed in traditional sports, too. Many professional athletes report that their games seem to occur in slow-motion; the better they get, the slower the game becomes. John McEnroe had this to say about professional tennis:

“Things slow down, the ball seems a lot bigger and you feel like you have more time. Everything computes – you have options, but you always take the right one.”

At Mr. McEnroe’s level of play, he had repeated the same kinds of tennis interactions – the ball is coming from this location to this location at this speed and this angle – so many times that in many cases he no longer even thought about them. He already knew the right response. When your mind isn’t thinking about what to do – when it’s purely focused on just doing it – time seems to move slower.

What Aren’t We Measuring?

Time to First Action measures how quickly a player reacts to new information. It cannot assess whether their reaction was correct. Its saving grace is the assumption that the first action players take upon absorbing new information will generally be a good one, if not the best one, particularly in competitive play.

Comparative Analysis

I conducted some replay analysis and compared three different players – ByuN (World Champion), MCanning (GM), and brownbear (high Diamond / low All-Time Legend).

Game events, player data, and other information were retrieved from replays using Blizzard’s s2protocol.

Each game event in a replay is associated with a type (like a camera update, a command, etc), a timestamp (measured in clock ticks), and a bunch of other data (such as coordinates for camera events).

I defined a “significant” camera movement as a camera update greater than 5000 units from the camera’s last location. For reference, a typical StarCraft II map is between 36,000 to 45,000 units across its X-axis and 36,000 to 45,000 units across its Y-axis.

Once a significant camera movement was observed, I calculated the latency until the next action. After processing a whole bunch of replays in this fashion, I generated some basic statistical data.

I used ByuN’s replays from Blizzcon, MCanning’s replays from his latest subscriber replay pack, and my own personal replays as the data sets for each player.

To start with, here’s a comparison of our time-to-first-action, The Y-Axis is time delta, in milliseconds, and the X-Axis is percentile. For instance, if you see that ByuN has a time-to-first-action of 1000 milliseconds at the 70 percentile mark, that means that about 30% of his time-to-first-actions are slower than 1000 milliseconds and about 70% are faster than 1000 milliseconds. The 50 percentile mark represents median, which typically represents a player’s “expected” time-to-first-action.

2016-12-21_ttfacomparisonbyunmcanningbrownbear

One of the first things we notice is the enormous difference between the Diamond player (me) and the two GM players. In the expected (median) case, I respond 250 milliseconds slower than they do. And this happens a lot – about 8 times a minute (half as often as the other two).

The other interesting piece is that the professional player (ByuN) and the GM player (MCanning) have similar time-to-first-action until the 60th percentile, where they begin to significantly diverge. This makes sense to me. By the time a player has reached GM, they’ve seen all of the most common interactions and have figured out the correct response. Only the professional player will bring down their reaction time on the long-tail situations that rarely occur. At the 90th percentile, ByuN’s reaction time is faster than MCanning’s to the same degree that MCanning’s reaction time is faster than mine at the 50th percentile. That may not seem like a lot, but because of how often these situations arise in a game, they add up really quickly.

While we’re on the subject of frequency, here’s a graph showing how often we each move our cameras per minute. The Y-Axis is camera movements per minute, and the X-Axis is percentile.

2016-12-21_cameramovementsbyunmcanningbrownbear

We once again see an enormous difference between between me and the two GM players – I move my camera almost half as often as they do. If we think about this in terms of Day9’s mental checklist, I’m doing almost half as many tasks as they are in my average game and typically responding a quarter of a second slower each time. That really adds up!

Finally, I ran the numbers for every player at Blizzcon. If you know the results, then you might be able to guess the fastest foreigner – Elazer! The guy is really fast.

2016-12-21_ttfaBlizzcon.png

Conclusion

Time to First Action is an interesting way of organizing player actions in order to approximate player skill. It’s an interesting starting point for thinking about skills development and how we get better at things. It’s by no means perfect – reacting to new information is only one of many components that compose mechanical skill, and even the way we measure it rests on an assumption of “smart execution” that is not always correct.

The comparative analysis provided here is just for fun. Even if we did want to draw serious conclusions from it, we would need a much larger sample size – the above is based off of ninety Blizzcon replays, thirty MCanning replays, and a couple hundred brownbear ladder games. Much like APM, no player should go out of their way to artificially increase their TTFA.

That’s everything I had for today. If you enjoyed this post, please consider following me on Twitter or Facebook to receive regular content updates, or checking out my game-design videos on YouTube and Twitch. Thanks for reading and see you next time.

Special thanks to Blizzard for releasing Blizzcon replays (and, more generally, for StarCraft) and MCanning (Twitter / Twitch) for releasing replays to subscribers. Also, thank you to Olimoley for allowing me to do this analysis on Olimoleague replays; I ended up not using the data for this post, but it helped me build the analysis tools.

Racial Balance in Real Time Strategy Games

Hey folks,

Today I’ll be discussing racial balance in real time strategy games. I’ll explain how I think about the subject and address some myths that frequently pop up in balance discussions.

What is racial balance?

2016-12-10_aligulacbalancereport
The Aligulac Balance Report

When players think about perfect racial balance, they typically define it as the better player winning the vast majority of games against an inferior player, regardless of the races that the two players selected. This definition is occasionally combined with an opposition to RNG mechanics, meaning that a player should win all games against players of lesser skill. Another common way of looking at it is to say that two players of equal skill should trade wins and losses at a 50:50 ratio, again regardless of the races that they select.

While these sound like good approaches, they suffer from a number of flaws that make them unworkable.

One is that they overgeneralize the concept of skill. Real time strategy games demand a host of distinct skill sets that grow and develop individually. Each individual game will emphasize particular skills over others, meaning that the overall skill level of any given player will have an uneven impact on their ability to win any single game.

In other words, I might have excellent macro fundamentals, but my unit control might be relatively weak. This means I might be able to beat a good player who plays a defensive macro style, but I might lose to an overall weaker player who does an all-in that demands very strong unit control from my end. It’s difficult to draw a balance conclusion from this.

Another flaw with these approaches is that they overgeneralize match-ups. Even if we were to find two players at precisely the same skill level, this doesn’t mean that they will trade wins and losses at a 50:50 ratio. Perhaps one player’s style fits better with the current meta; perhaps the match-up actually requires an uneven differential in skill, such as a Terran player needing better multi-tasking and a Protoss player needing better decision making; perhaps one player was just having a bad day and couldn’t focus.

Aside from these problems, there’s also a more practical issue. These approaches are very general, which means they really only serve to identify generally obvious balance problems. If I play against players of an “equal” skill level and find that Hydralisks are too strong, and you play against players of an “equal” skill level and don’t find this issue, how do we reconcile this difference? Aside from consensus, there isn’t a good way to provably determine whether a balance problem really exists.

A better way to think about balance is to emphasize individual games over generalities and optimal play over equal play. Here’s how I define a balance problem:

Assume two players A and B playing races X and Y. There exists a racial imbalance between X and Y if, in a game between A and B, the player that lost cannot be reasonably expected to improve their play significantly enough to have reliably won the game.

This definition focuses its attention on a measurable balance problem that can be replicated. Rather than trying to equalize the number of mistakes each player made, it concentrates instead on the more tractable question of whether a player can reasonably improve themselves out of a problem.

The advantage of this approach is that it does not require a general theory justifying why an imbalance exists – it can be identified with only a single game and consistently verified by replaying the actions in that game.

The designer can even apply it directly to find an issue:

  1. The designer suspects there’s a racial balance problem between races X and Y.
  2. The designer finds two players, A and B, of roughly equal skill level with the two races.
  3. The designer has the players play a game.
  4. The designer reviews the actions of the losing player and identifies the minimum necessary set of changes required to enable that player to have won the game.
  5. The process is repeated until the minimum necessary set of changes required to win the game becomes unreasonable.
  6. The win ratio at this point is examined. If it’s deviating significantly from 50:50, a balance patch is introduced.
  7. The process is repeated until a near 50:50 win ratio is achieved.

To reiterate: we focus on concrete instances – individual games – rather than generalities. We strive for a roughly 50:50 ratio at or close to the optimal level of play rather than just an “equal” level of play.

Considerations

The principle at the heart of this approach is the same principle at the foundation of well-balanced games – a high skill ceiling. Players are expected to take reasonable steps to improve their way out of losing situations instead of immediately pointing to a balance problem. This means that most balance issues are resolved on their own as the meta-game develops and the best strategies are found and perfected.

Astute readers will notice that this hinges on the meaning of reasonable. How much can we reasonably expect a player to improve in order to turn a losing situation around? That depends on how high we set our skill ceiling. As long as players are noticeably below it, we should be able to identify a reasonable set of mistakes that they can work on in order to win games.

Games like StarCraft II take this to its theoretical limit by explicitly designing for an unreachable skill ceiling. This means that even the very best professionals’ balance complaints can be rebuffed if the designer can convince themselves that these players can still substantially improve.

I think this is one of the reasons that widely perceived balance problems in the early game tend to be patched out faster than similar problems in the late game. The Adept nerf at the beginning of Legacy of the Void is a good example. Its window of imbalance in the PvT match-up occurred very early in the game. The number of potential mistakes in the early game is inherently less than in the late-game, meaning that it’s much easier to theorize or physically demonstrate that a balance problem exists – eventually, the Terran player’s minimum set of required changes would become so vast and focus on such minute details that it would become unreasonable to expect them to improve their way out of this situation.

This points to a flaw in this approach – and, for that matter, the general approach of balancing through a high skill ceiling. It’s very time-consuming to balance the late game with this process because of the sheer number of mistakes that will be made by this point in the game. There’s a trade-off here for the designer. The upside is that the large number of mistakes means there will almost always be enough opportunities for a player to improve their way out of a losing situation. The downside is that the time required to optimize the match-up in order to demonstrably prove an imbalance will be very long – this period of “wait-and-see” can leave a bad taste in players’ mouths.

The Ultralisk in Legacy of the Void is a good example. Blizzard waited for months as players optimized the TvZ match-up in order to see if Ultralisks were a genuine balance problem. But because of how visually jarring this interaction was – seeing marines do virtually no damage to a single unit – it generated resentment within the Terran player base.

As a result, the designer needs to strike a balance between this optimization process – often referred to as “letting the meta settle” – and theorycrafting what the meta will look like once near-optimal play has been achieved. This enables them to proactively identify and test small changes in order to smooth off the rough edges in the gameplay experience.

(For what it’s worth, I think this is why Blizzard focuses so heavily on the feedback from Korean professionals. It’s not so much that they’re better at the game – it’s that their professionalized approach to practicing means that it’s much easier to systematically identify balance issues).

Myths of racial balance

Balance is always a hot-button issue in any real time strategy game, and over the years I’ve come across common lines of thinking that address the problem in a fundamentally flawed way. I call these myths – let’s go through them.

Myth: Balancing for the best means an imbalanced experience for everyone else

I’ve seen this argument made since the early days of Age of Empires 2. At the time, it was claimed that professional playtesters didn’t accurately reflect the skill level of the average player, and therefore produced racial balance that only worked for the very best. This argument has lived on to this day, focusing now on the feedback that professional players give. If the developers only balance the game around the issues that top players experience, so the thinking goes, the game won’t be balanced for anyone else.

The problem with this train of thought can be found directly in our definition of balance. A problem does not exist if a player can reasonably improve their way out of it. The best players have already demonstrated that it’s possible to play the game better than everyone else, and therefore it’s always reasonable to expect others to resolve a perceived “balance issue” simply by improving their level of play.

In fact, this myth gets it backward – the truth is that professionals are the only players who are substantially impacted by balance problems. The more professionalized the game, the more likely it is that players at the top are reaching the physical and mental ceiling on how optimally the game can be played. Even if the minimum set of changes required to win a particular game is small, it’s conceivable that no human could ever resolve these issues without making additional mistakes somewhere else. Only professional players will run into this, meaning that the designers have a critical obligation to balance the game around their feedback.

Some readers may counter that this sounds like a circular argument – we disprove this myth by stating a definition that’s mutually exclusive with it. The key point is that the definition’s emphasis on optimal play is essential. If we limit ourselves merely to “equal” play, it’s very difficult to determine whether a loss was caused by a genuine balance problem or a difference in skill. “Whose mistakes were ‘more severe'” is an unanswerable question – furthermore, it’s very challenging to compare the impact of a balance problem with the impact of any given gameplay mistake.

The burden of proof is on those who want to demonstrate that a perceived imbalance exists. It’s very straightforward to show that losses outside of near-optimized play could have been reasonably avoided by fixing some simple mistakes; it’s very difficult, if not outright impossible, to demonstrate that a balance issue was a stronger contributing factor.

Myth: Good players understand balance better than casual players

This is a common line of thinking in many activities – people assume that someone who’s good at something understands it better than someone who’s not so good at it. This is not always the case, especially in a game so execution-focused like StarCraft.

Remember, there are two ways in which we can identify a balance problem. The first is to optimize one’s level of play until a problem can’t be resolved without an unreasonable or impossible increase in skill level. The second is to theorycraft about the game’s systems and predict what will become a balance problem once the meta has settled and play styles have been optimized.

Professional players are very good at doing the former – it’s their job. They’re also usually very good at the latter. Because they define and drive the meta rather than simply following it, professionals frequently have a deeper understanding than most of how a game’s systems work. This means they can more reliably predict what will become an issue before everything has been optimized.

Casual players don’t even attempt to follow the meta or play competitively, so they can’t conceivably take the first approach. But their unorthodox play styles allow them to encounter situations that better players often do not, giving them a unique insight into the way a game’s systems interact.

This might seem like a minor point because any serious imbalances will always be rooted out by professionals. But we need to think about how balance problems get introduced in the first place. Sometimes they stem from “minor fixes” introduced to “improve quality of life” or “add variety”. The Japanese civilization dominated Age of Empires 3 in WCG 2008 because it was overbuffed by a series of “minor gameplay improvements”. I think the overbuff to the Hydralisk in Patch 3.8 follows a similar pattern. It’s a unit that most good players rarely used after it fell out of the ZvP meta, so very few of them proactively provided negative feedback concerning its changes.

Casual players are often well-positioned to identify these kinds of problems ahead of time because they get themselves into situations that are far outside of the current meta. It’s not to say that all or even most of their feedback is inherently valuable – just to say that you can find a surprising amount of insight if you read enough of it.

The players in-between – “good but not great players” – often have the least valuable insight into balance. There’s little incentive for these players to understand how the game really works – the oft-repeated advice to this group is to copy strong build orders, focus on clean mechanics and work on macro fundamentals. This is a great way to get better at the game, but a terrible way to understand it better. Players in this category don’t have the raw skill to show balance problems through optimized games, yet they also have no incentive to understand the game well enough to appropriately theorycraft about it.

My point isn’t to claim that good-but-not-great players are incapable of understanding balance; it’s that their incentives drive them to follow the meta rather than thinking about why the meta is the way it is. As a result, there’s no good reason to place extra weight on their feedback based purely on their ranking.

Last word: Balance issues are often a symptom of systemic design problems

So far, we’ve proposed an approach for effectively identifying and resolving a balance problem which concludes with a series of numerical adjustments. What’s left is discussing the root causes of these issues – the design patterns that make balance tweaks more or less likely.

A high or unreachable skill ceiling is a good example of a design pattern that reduces the need for balance updates. It ensures that there are lots of opportunities to improve one’s way out of a losing situation.

Highly binary mechanics are an example of a design pattern that frequently necessitates updates. The range of outcomes in a binary mechanic, such as the Mothership Core’s Pylon Overcharge or the God Powers in Age of Mythology, is inherently more limited than something more incremental. This puts more pressure on the designers to balance the interaction perfectly because the range for improvement is also more limited.

An overemphasis on melee units is another good example of a mechanic that’s hard to balance. Melee units have a comparatively harder time finding damage because it’s difficult to use positioning to gain an advantage – one way or another, the unit needs to be adjacent to the opposing army in order to engage with it. Ranged units can stand at the periphery and pick off units one by one, allowing players with good control to trade efficiently and prevent small disadvantages from snowballing. This puts more pressure on the designer to balance a melee unit perfectly in order to make it work, and it’s worth noting that no new melee units were introduced by either the Heart of the Swarm or Legacy of the Void expansion packs.

(I previously commented that the Hellbat is an exception to this, but a commenter correctly pointed out that it has 2 range).

It’s important to look past specific issues and see if they’re a symptom of an underlying systemic problem. The strength of Zerg in early Legacy of the Void prompted calls for nerfs to all sorts of things, from Adrenal Glands to Tissue Regeneration. In the end, the problem was more systemic; the underlying map pool heavily favored Zerg. The race was even buffed in subsequent patches.

Conclusion

Racial balance in real time strategy games is always a tricky topic to discuss. Players get emotionally invested in making sure their race is treated fairly by the developers. That’s often a good thing – it ensures an open, vibrant discussion about issues. Every viewpoint will eventually find an advocate, making it much easier for the developers to identify the real problem.

I hope you’ve taken away a new approach to looking at this issue, or at least have some additional food for thought. Thank you for reading and I’ll see you next time.

(P.S. If you enjoyed this article, please consider following me on Twitter to receive regular content updates and checking out my game-design-focused Twitch or YouTube channels.)

RTS Design Principles and Protoss: A Call For A New Design Patch

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.

2016-10-24_playerracedata
Diamond League Race Distribution. Protoss in Yellow. (Legacy of the Void)

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.)

Why StarCraft II Feels Difficult To Play

Hey folks,

Today I’ll be talking about why StarCraft II feels difficult to play. I’ll be focusing on the design of the game’s mechanics and why they lead the game to feel hard. This is a spiritual follow-up to an earlier post on mechanics; if you missed it, I recommend checking it out first prior to reading this one.

How Players Experience Real Time Strategy Games

Let’s start by discussing the thought process most people employ when playing real time strategy games. In general, players:

  • Play the game as fast as they comfortably can
  • Execute tasks in priority order

Playing faster is better than playing slower. There’s always things that need to be done in a real time strategy game. Completing tasks is valuable in and of itself because it exercises the core mechanics of the game, something that RTS players inherently enjoy – similar to how players who play shooters enjoy the mechanics of shooting. Furthermore, completing tasks increases the player’s odds of winning – whether by controlling their army better, producing more units, or building more production facilities. Players are therefore incentivized to play games as fast as they can, with their physical speed and personal comfort threshold acting as the ceiling.

In addition to executing tasks quickly, players also prioritize the set of work in front of them. There’s always more to do than can reasonably be accomplished at once, even for the fastest professionals. Players are incentivized to do important work before unimportant work because it increases their chances of winning. A well-designed title will reinforce this by ensuring the most common, important tasks have strong inherent rewards as well – think of the smooth animation and satisfying plop of dropping a mule on a mineral line.

Putting these two things together, players tend to execute tasks quickly and they tend to order these tasks based on what they think is most important.

StarCraft II’s Design Decisions

Let’s think about how this thought process interacts with some of the core design decisions in StarCraft II. StarCraft II differs from older RTS titles in its streamlining of many basic tasks common to most real time strategy games. On the macromanagement side, multiple building select, rally points, and tabbing through production buildings reduces much of the work that used to be required to build and maintain a large army. On the micromanagement side, unlimited unit selection, smarter AI, and strong pathing reduce much of the hassle in getting units to do the right thing. Basic tasks like moving and attacking that previously required lots of hand-holding are now automatically handled by the game engine.

The design instead emphasizes more complex and technical execution. This is partly a natural result of reducing the time and attention required to complete basic tasks. For instance, consistent execution of efficient build orders has always been a consideration in real time strategy games. StarCraft II places more emphasis on it because players have more time to think about and perfect it, resulting in a near endless number of sharp timing attacks. This emphasis on complex tasks is also partly intentional, such as the deliberate shift in micromanagement focus toward abilities.

The result is that many rote, mechanical tasks have been replaced by complex, strategic ones. Players frequently cite the mechanical difficulty and emphasis on rote tasks as one of StarCraft’s downsides; this shift in focus toward more complex and strategic tasks should theoretically solve that problem and deliver a more satisfying gameplay experience.

In practice, this design approach has a number of unintended consequences, and they’re related to the thought process players employ when playing real time strategy games – playing as fast they comfortably can and executing on tasks in priority order.

One is that hard tasks feel harder than easy tasks. Easy tasks – like going back to your base, clicking on each building one by one, and queuing up a new unit – may be mechanically challenging at a high level. But they’re cognitively straightforward and deliver incremental benefits as the player improves. Hard tasks – like having enough game sense to accurately scout and predict your opponent’s unit composition – are cognitively complex and deliver their benefits discretely rather than incrementally.

Here’s a couple graphs that illustrate the difference:

2016-10-31_skillvsbenefits

Dropping mules consistently has a high mechanical skill ceiling, especially for a macro player. It’s an easy task – cognitively straightforward and with incremental benefits. Injects, spreading creep, and maintaining constant production are all examples of easy tasks.

Game sense and scouting have a relatively low mechanical skill ceiling. Waypointing a hallucination doesn’t require very much APM. However, making sense of what you see and choosing the correct response is neither cognitively straightforward nor does it offer incremental benefits. The player needs lots of experience to accurately understand the state of the game; even as the player’s skill increases, the benefits don’t necessarily accrue because the player doesn’t know enough to accurately choose a good response.

Hard tasks like scouting also typically lack an element of visceral enjoyment. Good game sense doesn’t deliver the same kind of satisfying, immediate reward as watching a creep tumor jump across the map.

Easy tasks feel good. They’re intrinsically enjoyable to exercise, players receive immediate benefits from any rise in skill level, and they lack an element of cognitive confusion of wondering whether they’re worthwhile to execute on. Meanwhile, hard tasks often lack an intrinsic physical element, deliver their benefits in a delayed and discrete fashion, and require relatively more thinking to determine whether they’ve been done correctly.

Remember, players tend to play as fast they comfortably can. They don’t suddenly play faster in a more mechanically demanding game like Brood War, much like Brood War players don’t suddenly take more coffee breaks in the middle of their Legacy games. Players fill in the time freed up from streamlining basic tasks by focusing on other things. The result is that, proportionally, players in StarCraft II are spending relatively more time executing on hard tasks than they were previously. This makes the game feel hard, or at least relatively harder than it would feel in the absence of this design approach.

The second consequence of this design approach is that it increases the number of punishing interactions in the game. The limitations on player time and attention are a core design feature in real time strategy games. Players respond to this by prioritizing the set of tasks in front of them. When basic, important tasks are streamlined, they become less costly to execute, which naturally makes them feel more punishing to play against.

Consider harassment in StarCraft II. Older real time strategy titles featured a trade-off – units in poorly controlled harassment would likely do almost no damage, for instance by pathing to god-knows-where instead of attacking workers. A well-controlled army would get more done, but soak up enough of a player’s time and attention to distract them from completing other tasks.

StarCraft II’s design approach lessens this trade-off by introducing a number of micromanagement niceties – waypoints, smartcasting, dropping while moving, intelligent AI, strong pathing, etc – that make basic unit control relatively straight-forward. The consequence is that harassment, even when poorly controlled, can rapidly do significant damage. Properly controlled harassment can clear a mineral line in seconds, and macromanagement niceties like multiple building select ensure this doesn’t have a proportional trade-off in the player’s production.

Miss a drop by a few seconds and a player can sustain game-ending damage while knowing that it didn’t cost their opponent very much in time or attention. Lalush describes this perfectly by characterizing certain kinds of harassment as disruptive – the yawning gap between the attention required to execute the attack and the attention require to defend it feels disruptive (i.e. painful) rather than feeling like a standard engagement. This is frustrating and punishing to play against.

The combination of these two consequences – a shift in focus toward harder tasks and a stronger sense of punishment from going up against basic moves by your opponent – create a game experience that is relatively more difficult and more frustrating than it would be in the absence of this design approach.

Case Study: Protoss

Protoss is an excellent example of this design approach in practice. For average players (Gold – Diamond), it features fewer basic mechanical tasks than the other two races.

  • Production occurs in bursts through warp-gate rather than waves, and Protoss armies tend to feature smaller numbers of sturdier units. This means Protoss players don’t need to constantly produce new units to the same mechanical degree as their opponents.
  • The core macro mechanic, Chrono Boost, is a toggle rather than an ability that needs to be constantly exercised like Inject or the Mule.
  • Base defense, especially in the early game and against multi-pronged harass, requires less mechanical moving of units thanks to the single-click Pylon overcharge of the Mothership Core.

Protoss is not, of course, in general easier to play than Zerg or Terran at casual levels. It has a stronger need for game sense, such as its inherent difficulty in countering mutalisks without proper preparation. Its production buildings, especially the Robotics Facility, may produce fewer units in absolute terms, but the cost of leaving them idle is also much greater. Chrono Boost may cost fewer actions than Injects or Mules, but it also requires more thinking in where it’s used and when.

(This discussion also excludes professional players, who employ a whole suite of skills that most players never touch. The mechanical differences, when considered in the context of all these skill sets and the impossibility of executing them all perfectly, do not exist at this level.)

StarCraft II’s design approach streamlines rote, mechanical tasks in favor of more strategic ones, likely under the assumption that this is more interesting and enjoyable for players. Player race data, especially at the average level, provides a clue that this is not, in fact, how most players experience real time strategy games.

2016-10-24_playerracedata

Let’s compare Zerg and Protoss. Zerg has lots of simple, high priority tasks – injects, spreading creep, moving overlords around, and maintaining constant production. I call the most important of these “power mechanics” – basic tasks that need to be exercised constantly and deliver a measurable, substantial boost to the player each time they’re employed. Injects and spreading creep are examples of what I’d consider “power mechanics”.

Protoss doesn’t have very many power mechanics – things players can do constantly to put themselves in a better position. The game’s design instead calls for the average Protoss player to focus on more complex tasks, such as careful placement of structures, appropriate game sense and scouting of the opponent’s composition, ensuring a unit is on hold position within their simcity, etc.

The mutalisk transition is a great example of how punishing this can be. If a Protoss player’s game sense and scouting doesn’t lead them to prepare the correct response to mutalisks, they’ll probably just die – or, blindly build phoenixes in every game, even in situations where they don’t make sense. There’s very few “power mechanics” that Protoss players can fall back on to reliably and consistently improve their level of play in this situation, or at least feel good about what they just executed on; they either get it right or they don’t. The skill of having good game sense delivers benefits in a delayed and discrete fashion, and the time gap between developing new skills and reaping the rewards can feel confusing, if not outright frustrating.

The Mothership Core is another good example – either it’s in position or it’s not, either the player built their Pylons in appropriate positions or they didn’t, with little room for incremental improvement.

“Power mechanics” get a bad rap because they’re mechanically challenging, but players often forget that they’re also very empowering. Spreading creep or injecting slightly better delivers slightly better results. They also feel easy, have an immediate sense of reward and can be incrementally improved with each game. Average Terran and Zerg players can spend endless hours working on the mechanics of their macromanagement. Each of these hours will feel relatively better and more satisfying than the Protoss player spending their time wondering whether they’re Chrono’ing the right structure.

While there are likely many reasons for the race disparity cited above, I’d argue that this is one of the strongest – the inherent lack of satisfaction in playing Protoss at average levels relative to the two other races leads players to do something else.

Takeaways For RTS Game Design

One of the takeaways of this discussion is that “quality of life features” that make basic tasks easier are not a free win for the gameplay experience  – they’re not even necessarily a win at all, and can actually detract from a player’s enjoyment of the game.

Players may note that this runs counter to one of the most common complaints about StarCraft II – that it is, already, too mechanically challenging. Personally, I interpret this as a truth that is misdirected. Dealing with a widow mine drop at the same time as a big attack may feel mechanically frustrating in the moment, but the lasting frustration with the overall gameplay comes from the knowledge that this devastating attack didn’t cost as much time and attention as it “should”, at least relative to its benefits.

Difficult mechanics feel difficult to execute. Easy mechanics feel easy to execute. Mechanically challenging games may be hard in aggregate, but the moment-to-moment mechanics feel easy and enjoyable. StarCraft II’s relative emphasis on difficult mechanics makes it feel harder than it necessarily has to be, while simultaneously making the game more punishing to play.

There’s nothing wrong with real time strategy games feeling hard, punishing, or even frustrating. Real time strategy is not for everybody, much the same way that no genre is for everybody. The problem occurs when there’s lasting frustration, even for people who generally enjoy these kinds of games – a sense that the game isn’t enjoyable long after the execution of the mechanics has ended. Power mechanics convey a sense of incremental improvement, a feeling that players can improve with every single game they play, even when they lose. Discrete, difficult tasks too often leave players with a sense of resignation or doubt.

It’s worth noting that this is an area ripe for innovation. We shouldn’t limit ourselves to thinking purely in terms of existing real time strategy games. I think it’s perfectly valid to think that a modern real time strategy game must feature multiple building select to avoid feeling outdated (for what it’s worth, I would disagree). However, from a design perspective, it’s important that when basic power mechanics are streamlined by these kinds of “quality of life features”, they are generally replaced by other power mechanics – this maintains the moment-to-moment pleasure of playing the game and mitigates its punishing nature. It’s perfectly valid to want more emphasis on complex tasks, but the implementation needs to be thought-through carefully to avoid frustrating the player and creating too many areas where the benefits of skill improvement are delayed and non-obvious.

What these “other power mechanics” and “well designed complex tasks” look like is an open question. I have some ideas, but I’d like to flesh them out a bit before discussing them in detail. I’d love to hear your thoughts – like I said, this is an area ripe for new ideas and creative thinking.

That’s everything I wanted to talk about today. If you enjoyed this blog post, I humbly recommend you follow me on Twitter and check out my game-design focused YouTube channel. Thanks for reading and see you next time.

Why Mechanics Are Critical To Real Time Strategy Games

Hey folks,

Today I’ll be talking about mechanics in real time strategy games and why they’re critical to the genre.

What are mechanics?

Mechanics refers to the execution of physical actions in a real time strategy game. This is a pretty broad umbrella: it includes effective army control and micromanagement, which rely on accurate and quick mouse control. It includes macromanagement, which relies on efficient use of hotkeys and reliably remembering to do things, like building units and researching upgrades. It even includes map awareness, which relies on fast eyes that can quickly see a blip on the mini-map and react accordingly.

Mechanics does not refer to decision making or strategy. Strategy is the plan that a player carries into a game; specifically, it’s the set of decision trees that a player considers viable. Decision making is the path along a decision tree that a player chooses as a game progresses.

A good rule of thumb is that if something requires conscious thought, it’s probably not something I’d consider mechanics. As a simple example, a player may decide that attacking as soon as a set of upgrades completes is a good idea. The player might construct a build order that intentionally lines up several upgrades to complete at once. The player might identify some timing weaknesses in this build and carefully scout their opponent to ensure they’re not exploiting these vulnerabilities.

All of this is strategy, not mechanics. Mechanics refers to the execution of this plan – physically building the units, moving them around, researching their upgrades, and so forth.

In today’s piece, I’ll argue that mechanics are a critical component of the real time strategy genre. Specifically, I claim that mechanical execution acting as the primary differentiator in player skill is an inviolable tenet of building a successful real time strategy game. Note that this claim implies an unreachable mechanical skill ceiling, to ensure this tenet applies across the entire ladder.

I’ll argue this by showing that the more a real time strategy game downplays mechanics, the more important those mechanics become – in fact, the only way to make strategy and decision making relevant is to intentionally design the game around the idea that mechanics are the most important component in player differentiation. I’ll argue that mechanics have intrinsic value and are a worthwhile and enjoyable inclusion all on their own. Finally, I’ll address some common counter-arguments to emphasizing mechanics.

Strategic Balance

To show why mechanics are so important, I want to first discuss strategic balance – the balance of different strategies in competitive multiplayer. My belief is that no real time strategy game has achieved true strategic balance – a state of play in which each race has multiple valid decision trees that are equally good. I believe all real time strategy games have a handful of extremely dominant strategies that are an order of magnitude better than other strategies.

This is largely due to the sheer complexity of these games. Real time strategy games are asymmetrical, meaning players can select different races with access to different units and technology. There is a near infinite number of possible interactions. It is impossible to effectively playtest and balance even a small number of them – for example, the imbalance of the Adept unit against Terran at the launch of Legacy of the Void didn’t get caught in playtesting, even though this was a brand new unit that received a great deal of attention from playtesters.

Contrast this complexity with Chess. Both players have access to the same pieces and the same starting position. The only difference between the two sides is that White goes first. In competitive play, this translates to a 53-55% win-rate. Even a small difference has a big impact. Note that this win-rate is on the borderline of what Blizzard considers to be a balance problem. A match-up featuring this kind of consistent success for one side would likely be patched.

It’s not necessarily intuitive to think about RTS games in this way, considering the excellent strategic balance in Brood War and StarCraft II. This is because StarCraft has effectively internalized the importance of mechanics to a successful RTS game and has consistently emphasized mechanics as the primary differentiator in player skill. Most players benefit from this design decision without consciously thinking about it. While reading this piece, it is a must that you do. Think about what every interaction looks like when mechanics are completely removed. The truth is that one side will decisively and predictably win, every time. There are very few, if any, perfectly balanced interactions.

Back-to-front: designing a non-mechanical RTS

Now that we’ve argued that imbalance in a real time strategy game is inevitable, let’s try to design an RTS that doesn’t target mechanics as its primary skill differentiator, meaning that a substantial mechanical advantage doesn’t translate into a substantial advantage in-game. Instead, we’ll focus on designing a game that emphasizes good decision making and strategy.

The player base doesn’t emphasize mechanical execution. Competitive players reach the mechanical skill ceiling, the point where no amount of improvement in execution confers an advantage. Casual players can work on their mechanics if they’d like, but they don’t concern themselves with it because it won’t have a substantial impact on their play.

Players instead focus primarily on finding the most dominant strategies, per our original intent. As we’ve already established, such strategies necessarily exist. They are also very easy to find. Differences in mechanical execution don’t confer a substantial advantage, so it’s easy to learn a new strategy and judge its efficacy. Theorizing about the game is straightforward because little consideration needs to be given to how well a strategy is executed – the only thing that needs to be thought about is how effective it is, since optimal execution can safely be assumed. The metagame develops very rapidly until the most dominant strategies are discovered. I’d argue that this is usually just one “super-dominant” strategy.

The metagame now gets stuck in this state. Even if a more dominant strategy is discovered, players simply switch to using it. There’s little incentive to sticking it out with other strategies because it’s difficult or impossible to make a sub-optimal strategy work on mechanics alone. Meanwhile, there’s a lot of incentive to switch strategies because mechanical differentiation isn’t emphasized, so effectively executing a new strategy is easy. Players have very little incentive to develop the metagame, and the handful that do it anyway don’t really change the fundamentals. Players simply switch from one strategy to the next with little thought.

Casual players tend to prefer to do their own thing and don’t necessarily follow the competitive meta, so the result for them is straightforward. Regardless of whatever strategizing they engage in initially, over time they realize that there’s no advantage to picking the less-good strategy. The winner of their games is whoever picks the more overpowered strategy. As time goes on, these players either switch to the best strategy, transition into games with friends who agree ahead of time not to execute the best strategies, or leave the game completely.

Competitive players try to win as much as possible, so they’ll be executing the most dominant strategy from the start. A competitive 1v1 game will consist of two players executing either precisely the same strategy, or at the very least knowing exactly what their opponent’s strategy is and the perfectly optimal counter to it. Decision making and strategy are irrelevant because they’ve already been decided prior to the start of the game.

The game has been “figured out”. The execution of the strategy(s) is all that matters.

We originally set out to downplay mechanics by trying to ensure that differences in mechanical execution were not the primary differentiator in player skill. The result is that mechanics are the only differentiator in player skill and strategy is completely irrelevant.

(Note that another possible, though much less likely, scenario is one in which several dominant strategies counter each other in a rock-paper-scissors fashion. In this case the deciding factor is either mechanics – rock-rock – or luck – rock-scissors or rock-paper. Strategy and decision making continue to be irrelevant.)

The problem now is that we’ve designed our game around lack of emphasis on mechanics, but paradoxically the way it gets played is with a single-minded focus on mechanics. This is a big issue because it’s not aligned with the game’s original design. Rather than thought-through differentiation in player skill in areas like macromanagement or effective army control, “optimal” mechanical execution is unintentional and often arbitrary. Exploiting bugs or glitches in the game to do things slightly better becomes a focus. Minute differences in execution suddenly take great precedence, creating a twitchy and frustrating gameplay experience. It’s rare for a gameplay scenario to work well without intentional design and implementation; there’s no reason to believe real time strategy games work any differently.

It’s not long before we arrive at the point where the game is neither mechanically nor strategically enjoyable to play. The game is “broken”.

It can’t be!

I think some players may struggle to wrap their head around this. What many people get hung up on is the imagery they have in their heads about how real time strategy games should work, even though it’s not necessarily how they do work. I had this problem, too – for me personally, I always think back to the first few weeks of Age of Empires 3. It was a magical time where many strategies were viable, decision making was the most important factor and no one worried about details like perfect marine splits.

The trouble is that such situations never last for very long. When the mechanics are not designed to be the primary differentiator in player skill, they eventually get figured out. This leads players to search for and find the most dominant strategy. The ladder devolves into what I described above – casual players leave while competitive players quickly master the meta. Mechanical execution is all that matters, but it’s not anything interesting like splitting marines or double dropping – it’s exploiting small, uninteresting and unintentional details to get every tiny edge over your opponent.

(For what it’s worth, I observed this pattern across five different game launches: Age of Mythology, Age of Titans, Dawn of War, Age of Empires 3, and Age of Empires 3: The Asian Dynasties.)

Front-to-back: the benefits of mechanics

Now that we’ve argued that mechanics are inevitably important in real time strategy games, it’s worth discussing what value they add in their own right. Designers shouldn’t think about mechanics in terms of avoiding the problem stated above. They should see them as a first-class feature, a worthwhile inclusion that make RTS games better.

The biggest benefit of targeting mechanics as the primary differentiator in player skill is that, paradoxically, this is the only way to enable decision making and strategy to be relevant factors in the outcome of games. This happens in a number of different ways.

One is the impact that mechanics have on the efficacy of different strategies. Engagements are much less predictable when their outcome is based primarily on mechanical control, meaning no engagement will ever go the exact same way twice. This leads players down decision trees that are situationally rather than strategically optimal, creating variation and more opportunities for decision making.

This applies to the entire ladder, too. Casual players are relatively much more likely to want to play the game their own way rather than following the meta. Mechanics make this possible. Players can focus on doing what they like to do and slowly get better at it. They understand that what really matters is how well they execute.

The execution cost of strategies also creates interesting decisions. Emphasizing mechanics ensures that no two strategies require identical levels of mechanical skill. Players’ time and attention is limited, and a more mechanically stressful strategy may be situationally disadvantageous even if it’s theoretically the stronger play. As a result, players focus on what’s better for them, given their personal style, personal strengths and the circumstances of each game. They practice to improve in the areas that they personally find interesting rather than what’s “optimal”. They understand that what really matters is how well they execute.

Competitive players take this to the next level, researching opponents and adjusting their play to compensate. Since execution is so important, players are incentivized to find holes in how their opponent likes to play the game and exploit those weaknesses. While there are more optimal and less optimal ways of doing things, players don’t fixate on this – they understand that what really matters is how well they execute. This furthers variation in the metagame and allows for interesting decisions.

Good decision making is incentivized when practicing and developing new skills, too. Since mechanics matter, players need to consider their own ability to execute when making decisions, meaning their view of what’s viable is dependent on their own level of play rather than the theoretical optimum. They tend to identify their personal strengths as a player and make adjustments to their existing strategies rather than blindly duplicating the best. Higher-level concepts like opening builds and general unit compositions may consolidate in the metagame, but the way in which players execute these concepts and what they choose to emphasize differs from person to person.

Players also have a stronger sense of agency and are willing to create innovative new strategies to surprise their opponents. Again, even if these strategies are theoretically weak, players understand that lots of practice will produce lopsided mechanical results, since their opponent isn’t well-practiced against a brand new strategy. Strategic diversity is furthered, not hindered, by an emphasis on mechanics.

Targeting mechanics as the primary differentiator in player skill also reduces the problem of strategic balance. The advantage conferred by choosing the “slightly more optimal” strategy is easily overcome by a player with slightly superior mechanics. This incentivizes players to play their own game and focus on doing it well rather than fixating on what’s optimal.

Intentional design can help here, too – rather than spending all their time theorizing about which strategy is the very best, designers can make rough estimates and then intentionally make those strategies harder to execute. They can play around with each unit and try to squeeze out as much mechanical depth as possible. The higher they can make the skill ceiling, the better, since this mitigates the impact of any (inevitable) balance problems. Mechanics don’t completely eliminate strategic balance issues, but they strongly mitigate them and make the problem of balancing the game much more tractable.

The key point to all of this is that decision making and strategy only become relevant once mechanics are the most important differentiator of player skill. Without mechanics, they simply don’t matter.

This isn’t a free win – good design of mechanics is still important. A highly mechanical game doesn’t necessarily need to feature strategic diversity. If many strategies are impractical or near-impossible to execute well, the metagame will still devolve into one or two strategies anyway. The benefits of practicing that one strategy never really run out since the skill ceiling is so high, so players rarely benefit from doing something else. What’s critical to realize is that strategic diversity will never happen in a non-mechanical game. At least it has a chance when mechanics are emphasized, depending on the skill of the game designer.

Aside from enabling strategic diversity and compelling decision making, mechanics offer other benefits. They’re highly proportional in their rewards. Playing slightly better almost always confers a slightly better chance at winning. This creates a very rewarding incentives loop with lots of knock-on effects: it encourages lots of play on the ladder, which makes games easier to find, allows players to encounter lots of different playstyles and enables them to come up against a wide variety of strategies.

In addition, mechanics encompass the physical method by which real time strategy games are played. Designing them intentionally and playtesting at high-levels of play ensures that they’re comfortable and enjoyable. I think it’s easy to underestimate how important it is for a game to feel nice to play. If the designer polishes a mechanic to the point that a professional who’s done it millions of times will still enjoy doing it again, then a casual player who only executes it a few times will probably find it enjoyable too.

Common counter-arguments

By this point, we’ve made the same argument in two ways. The back-to-front approach argued that mechanics will inevitably be the primary differentiator in skill, even when this is not the intention of the designer. The front-to-back approach argued why mechanics have intrinsic value in their own right.

I’d like to now address some of the common counter-arguments against mechanics as the primary skill differentiator in real time strategy games. Players frequently cite StarCraft II’s mechanical difficulty and high mechanical skill ceiling as reasons for disliking the game. I don’t think these complaints should be dismissed – instead, I think their focus is misdirected.

Real time strategy games – StarCraft II included – struggle to provide players with incremental rewards. The coarse-grained win-lose mechanic emphasizes winning over everything else, which is uncomfortable for many players. Losing several games in a row can feel like a waste of time, especially when compared to other games. Mechanics tend to take the blame because they are the most visible difference between real time strategy and other genres, but the root cause of the problem is more subtle. Other genres have designed much better rewards systems that enable players to have fun even when they lose. First person shooters are an excellent example, incrementally innovating in this area with each passing year. The combination of unlocks, avatars, skins, skill rating, achievements and so on ensure that it’s difficult to play an FPS for more than a few minutes without earning something, to the point that some players – myself included – argue that it’s too much*. Real time strategy games have made little progress in this area – de-emphasizing mechanics wouldn’t solve this design issue, yet it would simultaneously introduce plenty of other problems.

The appeal of co-op and the arcade are related to this. Players often argue that these game modes are popular because they de-emphasize mechanics. I would argue the opposite – players enjoy these game modes precisely because they enjoy the mechanics. These game modes feature very little strategy and decision making, and often intentionally constrain players’ choices as part of constructing an interesting gameplay scenario. If anything, they often emphasize mechanics more than the competitive ladder, where the player is free to do as they please. What makes them appealing is not their lack of mechanics, but their lack of the intimidation factor of losing. Losing is intimidating because it doesn’t offer many rewards to the player, and this is again a design issue in RTS games, not the fault of mechanics.

Players sometimes cite the desire to out-think and out-strategize their opponent as a reason for disliking mechanics. They don’t like to make better decisions but lose anyway because they miscontrolled their army or forgot to inject. This is a perfectly valid desire: after all, the genre is called real time strategy. The problem is, again, subtle: mechanical games punish players that fail to execute well, even if they make good decisions. But the alternative is worse: de-emphasizing mechanics eliminates the concept of good decisions entirely. The ability to out-think your opponent only becomes a factor when mechanics are emphasized.

Finally, the tenet that mechanics should be the primary differentiator in player skill doesn’t specify how this is accomplished. Mechanical execution is just as capable as any other aspect of a game of being poorly designed and implemented. Blaming the concept of mechanics for this is misguided. The real issue is their design and implementation. Furthermore, it’s also perfectly valid to prefer some kinds of mechanics over others – the differing appeal of Brood War, WarCraft III and StarCraft II is a good example of this.

Stay tuned!

In future updates I’ll be discussing the design of good mechanics and the identification and effective resolution of strategic balance problems. I’ll also be examining incremental rewards on my YouTube channel. Thanks for reading and see you next time.

*Rewards systems are complex to think about objectively because their result is a feeling, which may differ from player to player. Unlocks, avatars, skins, skill rating, achievements, etc – these are virtual items with no real world relevance. Their significance is in their emotional impact on the player. Meaning, a loss in StarCraft may tangibly benefit the player by exposing a flaw in their build, whereas an MVP award in a round of Global Offensive may be meaningless – but what matters, when judging the efficacy of the rewards system, is how it made the player feel. In that context, it’s also worth noting that many rewards are intangible to the point that the player is not consciously aware of them, such as the satisfying feeling of switching to one’s primary gun and seeing a fluid animation, a pleasing sound, a change in movement speed, etc. This will be covered in more detail in the incremental rewards video.

Content Schedule – September 2016 to May 2017

Hey folks,

I wanted to give you an update on what I’m working on as well the content schedule for the channel and blog.

My primary work for the next eight months is a series of six game reviews on one of my favorite franchises. This will involve playing each game multiple times to build understanding and generate the necessary footage, plus research, script writing, audio recording, video editing, and publication. The first of these videos will launch in November and the rest will launch on a monthly cadence with the exception of January.

I’m also working on some pure game design projects. I’ve got two ideas for focused design-concept videos, one on incremental rewards and accessibility in real time strategy games and one in the brainstorming phase. These’ll be similar to the Balance video I put out a couple months ago. I’ve scheduled these two for October and January, respectively.

Outside of YouTube, I’m also working on this blog. I’d really like to make more content focused on real time strategy games, but I find that the video format doesn’t always work for this genre. I think that discussion of RTS games often requires a highly information dense medium and doesn’t always benefit as much from the visual format of YouTube. To solve this, I decided to start this blog focused exclusively on the real time strategy genre. You can expect new blog posts on a monthly cadence.

I’m also investing time in some personal education. I try to balance producing content with investment in my long-term knowledge base and underlying infrastructure. I think this is a healthy practice for successfully developing content over a long period of time. I’m working my way through another game design textbook to build up my theoretical knowledge. I’m also committed to spending one evening a week playing a game I wouldn’t normally pick up. I find that if I don’t schedule time to do this, I naturally default to playing Souls or StarCraft – I think that in the long-run this would narrow my perspective and limit my ability to think clearly about games.

In total, you can expect new content every two weeks, alternating between blog posts and videos. This work involves a lot of time and planning, so I schedule out a pipeline in advance to ensure I can reliably deliver content.

Finally, I’d like to take this opportunity to thank everyone who watches, reads, or otherwise enjoys my content. I work hard on this stuff because I enjoy it, and because I feel that it makes people happy when they watch or read it. Your support and encouragement mean a lot and are really appreciated. Thank you so much! I hope to keep seeing you in the future. All the best.