What people consider to be automation can be quite hard to pin down since, technically, almost everything in RTS is highly automated. These games run at dozens of frames per second, with many units using their abilities on every single one of them. The player is not consulted about every incremental step their units take when told to move to a position or every swing of their gun when trying to track a target. As such, "too much automation" often means "more automation than I am used to". Multiple building selection, a feature decried by Starcraft players, is a perfect example.
In Zero-K we try to avoid the subjectivity of automation by being guided by the rest of our design goals. One of our main goals is to focus on the strategy part of RTS. Players should be making plans, observing how they pan out, and adapting them in response to new information. This is not uncommon among games in the genre, but it often feels like it is gated behind intense micromanagement and rote learning. So, at least as a starting point, automation is good when it helps players engage with the strategy of the game, without first having to drill unit control or memorise build orders.
The automation in Zero-K seeks to emphasise strategy by reducing the impact of other forms of skill. This does not mean that clicking quickly is unimportant, far from it, but it means that good decision making comes first. Players at the top of the ladder still click quickly to react to information and fine-tune their approach. More generally, automation frees up time to think when players might otherwise drown in micromanagement. But giving players time to strategise means nothing if there is no strategic depth in the first place, and inappropriate automation can even reduce depth.
To think about how automation can make a game less strategic we need to know how it interacts with decision making. There are two things to look out for: automation can make decisions harder to implement or it can reduce the number of options available. One thing automation cannot do is make choices on behalf of the player, because, by definition, a choice is only something players can make. This might seem a bit pedantic, but strictly defining choices as player-only will help us avoid category errors.
If automation cannot make choices, then what is happening when an idle unit shoots at one enemy over another? It sure looks like the unit chose its target by itself, but in fact the player chose implicitly by leaving the unit idle. The player could, in principle, understand the automatic targeting system well enough to know how their units would respond to any combination of enemy units. Leaving these behaviours as-is constitutes a choice, as the player could tweak some state toggles or take manual control if they wanted something else. There is no space left for the unit to decide anything for itself.
Of course, it would be ridiculous to expect players to memorise an arbitrary list of targeting behaviours, which is why good automation hinges on trying to make these lists as sensible as possible. Players should know, or at least be able to intuit, how their units will respond to the orders they give. A player with no idea how their commands translate into behaviours is effectively making random choices, which makes implementing a strategy very difficult. In other words, automation works well when automatic unit behaviours match what the player would have done if they were directly controlling the situation. Behaviours also need to be learnable, to get new players to the point that they know what their units will do.
The other way automation can reduce strategic depth is by shrinking strategy space. In general, automation skews the set of strategies that players can feasibly implement, which can either increase or decrease the number of viable strategies. Automation gives players more options in any given situation, as it can reduce the cost of a decision from hundreds of clicks to a mere handful. But having extra options does not always mean deeper strategy as, for example, a unit may become completely overpowered when automated, shrinking the set of viable strategies to monospam. Alternatively, a dominant strategy might only be powerful because its counters are too taxing to execute. So automation does not inherently pull the set of feasible strategies in either direction.
Players only ever play in the space of feasible strategies. Most RTS games are content to treat this space as the definitive strategy space, and not worry about all the degeneracy that would result if their UIs were a bit more powerful. But the space of feasible strategies has problems, most notably, that it varies from player to player based on ability. This is the source of the feeling that players need to drill their micromanagement before being able to strategise: without a certain level of execution ability, you are playing in a different strategy space.
Other genres, such as turn-based strategy, operate under perfect execution. Automation has no impact on the strategy of these games as all combinations of actions are equally feasible, at least for a sufficiently motivated player. Zero-K is weird among RTS in that we like to imagine what the game would look like with perfect execution and take it into account when designing the game. Our principle that "players should fight their opponent, not the UI" could just as easily have been "players should strategise as if they have perfect execution".
Automation in Zero-K will never reach the point of perfect execution, but perfect execution is not required to approximate playing in its strategy space. Our approach is to imagine what the strategy space might look like with perfect execution, then use automation to warp the space of feasible strategies to match. For example, players may want some of their units to poke at the enemy from a distance or to charge in to deal more damage. A lopsided application of automation would make either of these options dominate, and in most games fighting at range against an advancing enemy requires a lot of clicking, which makes charging in the default. We want both approaches to be on the table for all players, so we have automation that makes it easy to tell units to keep their distance. More generally, when there are two obvious approaches, we try to make sure both take about as much work to execute.
Designing with perfect execution in mind is harder, but it is also rewarding. It restricts the design space and it means we have to keep track of an imagined strategy space as well as the one players actually use. We have other approaches as well, such as making the strategy space of perfect execution easier to approximate by avoiding mechanics that would require a disproportionate amount of clicking, which is a generalisation of designing away stupidity. As for the benefits, our approach makes Zero-K resilient to future automation, as we have already considered what a game with more automation might look like and have tried to avoid making it degenerate.
Automation has a deeper purpose than those stated above, which is to deal with two sources of frustration: the feeling of being unable to adequately tell your units what to do, and the frustration of noticing idle units do stupid things. Everything reduces to this level eventually, since game design is fundamentally about what happens inside players' heads. The purpose behind all the code, art, and mechanics bottoms out at player experience.
We seldom need to scrape the bedrock of game design by talking about feelings, but in the case of automation it helps us avoid a few traps. Specifically, players are not frustrated simply when their units do stupid things; they can only become frustrated when they notice their units do stupid things. Without noticing, there is no problem, and besides, stupid behaviour is subjective. Losing sight of this can lead to excess or useless automation.
It is tempting to treat automation as a well-defined optimisation problem. For example, units have to "decide" what to shoot when idle, so surely they should pick the "best" target. But defining the best target is tricky business and ultimately depends on overall strategy. If, say, you are planning a bombing run, then you might want to prioritise killing anti-air units. The only way around the idea of "best target" is to realise that the ideal automation system is the one that elicits the desired thoughts and feelings in the intended audience. In our case the desired feelings are related to feeling in control of your units and being able to tell them to implement your plans, so the best automation is as we described above: powerful and predictable.
For another example, consider path finding: when you tell a unit to move from A to B, what is the best path? The solution might seem obvious: the one that takes the least time, and players might even be frustrated when they notice their units take a slower path. But, as above, the answer is that units should take the least surprising path, because knowing whether your unit is going to wander into turret range is more important than saving half a second. In fact, the question is too narrow, because the ideal is to design movement and terrain systems such that the sensible paths are not too much slower than the fastest path. This allows us to avoid two sources of frustration: surprising paths and noticeably bad paths. This is just another form of designing away stupidity, but at a systematic level.
Ultimately we want players to feel like they are strategising without being interrupted to deal with frustrating behaviour. We set our sights on strategising in the space of perfect execution, as there is no execution-related frustration to be had there, but this is only an abstraction which guides design. The main risk of this approach is forgetting that Zero-K is played by actual players, and that they enjoy the non-strategy bits as well. Everything above is balanced against other considerations, which can be found in past and future posts.
Index of Cold Takes
