Cold Takes/3 - Fight your opponent, not the UI

Cold Take #3 - Fight your opponent, not the UI

Posted December 30, 2023

Error creating thumbnail: File missing

Many players mention Zero-K's powerful controls when asked what they love about the game. Some even joke that we spoilt other RTS for them. By now there are a few other games with parts of the Zero-K suite of controls, but I know of none that are driven by the same underlying principle. That principle is Fight your opponent, not the UI (user interface), and it goes back to the early days of Complete Annihilation. It is as central to Zero-K as Quant's Rule and was possibly coined by Saktoth, an early developer who liked to cite it.

A player is "fighting the UI" when they have a clear idea of what they want their units to do, but the controls make it difficult to tell their units to do it. Zero-K tries to resolve this fight, this conflict between the player and UI. This involves eliminating busywork and making simple ideas require few clicks to implement. The principle is the antithesis of things like clicking every 12s to build a worker, or routine frenzies of active ability targeting. At its most extreme, the principle advocates for a direct telepathic link between the player and game, removing all intervening interfaces. Putting aside the current state of psychic technology, other design goals prevent us from going that far.

The principle is not about removing micromanagement, as the 1v1 community can attest, Zero-K can be fast and frantic. Rather, it is about giving each click as much meaning as possible. Consider line move. Spreading units out along a line requires many clicks in most games, since numerous subgroups have to be selected and told where to go, while in Zero-K a line takes one click. If an "average line" takes 10 clicks to create, then each of the clicks has 1/10th the meaning of the one click required in Zero-K. The effect of this efficiency is not that Zero-K players click 10× less, but rather that they can be 10× more expressive with their unit control. This capacity feeds back into the rest of the game. We can expect more expressiveness from players, so the the game can be that much more nuanced as a result. Basically, Zero-K made surface-level micro easier and found more interesting micro underneath.

Error creating thumbnail: File missing

We need a more precise definition of UI to know exactly what is being fought. This involves drawing a distinction between the game world, the abilities units use to affect the world, and the UI itself.

• The game world is everything that describes the state of the game. This include the state of the terrain, the position of all the units and their statuses, and global things such as metal storage and innate income. Fundamentally, a game is some number of players trying to manipulate the game world into a state which counts as victory.
• An ability is any action that may be taken by a unit. Jumpjets and Swift boost are abilities, but so are moving, firing, and building. Players indirectly affect the game world by having their units use abilities. Characteristics such as health and sight range are part of the game world, not abilities, because they are innate.
• The UI shows the player a summary of what their units can see, and players use the UI to tell units to use abilities. The UI is their eyes, ears and hands, players never see or touch the game world directly. The UI also has its own states and can show them to the player. For example, command queues are not abilities or part of the game world, they are owned by the UI.

Chess provides a nice example. The game world of chess is an abstract list of piece positions (plus things like the draw timer), the abilities are the ways pieces move, and the UI is the physical chess board and pieces. Distinguishing between these three parts of chess makes the concept of a UI sound a bit silly, but that is the whole point. People rarely consider the "UI" of chess, since strategy stays the same regardless of whether the board is made of stone, wood or plastic. Chess players already fight their opponents, not the UI (except in blitz), so it fades into the background. This is foreign to RTS players, who seem to love arguing about UI.

Error creating thumbnail: File missing

The key difference between chess and an RTS is that chess expects the player to perfectly micromanage everything their pieces do. At the risk of heating up this take, chess is only a sedate game because very little happens. Strictly speaking, every step taken by a unit counts as an ability, so more abilities are used in the first few seconds of an RTS than in an entire game of chess, and games only gets more complex from there. RTS UIs have to filter and aggregate these abilities since the game would be impossible to manage otherwise. Turn-based strategy players might be aware of this issue, as these games sometimes end up in an awkward spot between RTS and chess, with too much to do each turn relative to the tools provided by the UI. At least RTS designers have a hard real-time constraint, whereas designers of turn-based games have to deal with the more nebulous constraint of the player's patience.

The filtering applied by RTS UI has a significant impact on the feasible actions within the game. Consider line move again, if it were suddenly added to a game, then area of effect damage would be much worse. Or to flip it around, poor area of effect damage was being propped up by a UI that made it difficult to split units. Fights between the player and the UI bias strategy away from a pure expression of what units can achieve with their abilities. and this bias is often particularly strong for new players, which can delay how long it takes for someone to start playing the "real" game.

How many people remember looking for Starcraft II advice and being told to focus on macro (Starcraft speak for micromanaging the economy)? People were basically told to fight the UI before even considering fighting their opponent. That said, fighting the UI is fine, it is a preference. Many games and genres are built around it. The solitary battle between player and UI can be rewarding, and has more reliable progression than fighting opponents. Zero-K is just the crazy project that asks whether the fight is necessary in RTS. Can we have fast, real-time, action in a strategy game, without a UI that new players have to overcome, and which avoids biasing strategy?

Error creating thumbnail: File missing

Time for some examples. Back in the early days of CA, Lurker and I talked about the disguise ability of the Spy from Red Alert 2 (which appeared later as the Changeling in Starcraft 2). Enemy Spies look like your own units, but are not actually under your control. We decided that disguises just create and then exploit a conflict between the player and UI, so they never made it into CA. The argument was that, since Spy is only controllable by its true owner, a powerful UI could constantly attempt to control every unit that seems to be yours, and flag any that refuse.

A mechanic that did make it in to CA, briefly, was radar spoofing. This was an ability that generated fake radar dots. The problem was that players were pretty decent at spotting fake radar dots after a bit of observation, but there was no nice way to tell this to their units. Players were forced to work around their units constantly firing at invulnerable radar dots, revealing their positions and wasting reload time. We could have solved this conflict by giving the player more powerful tools to fight the UI, but what would be the point? The fakes were fairly easy to spot, so we would be putting in a lot of work to end up with basically the same game. A Red Queen's Race against ourselves.

By now we have seen two approaches for solving conflicts between the player and the UI. The first is to make the UI more powerful, such as with line move. This gives the UI fewer ways to get in the way of a player trying to tell units how to use their abilities. The second approach is to remove conflict at the source, as we did with radar spoofing, or to avoid creating it altogether. This barely looks like work from the outside, so whenever we considered adding a mechanic we tried to imagine what perfect play would look like. If the game seemed like it would be worse, or not change at all, then the mechanic would be rejected. Sometimes we would come across mechanics that seemed good, but which would require a lot of UI work to deal with new conflicts. In these cases we would try to tweak the mechanic to put less strain on the UI without otherwise modifying its effect.

Error creating thumbnail: File missing

So far you would be excused for thinking that we simply figured how the UI should work, then implemented it. This is far from what happened. The principle itself was put in place fairly early, but it served more as future proofing than as an action plan. We did not know how powerful the UI could become, only that we were ready for it. This meant avoiding designing new conflicts, and assuming that existing conflicts would be solved eventually. We had, and still have, an open approach to players modifying the UI, with the expectation that people share anything useful. Sometimes an advance in UI causes a problem, but we approach these cases with the idea that powerful UI just reveals issues with game mechanics, so strive to fix the mechanics.

It took over a decade for the UI to reach its current state. Overkill prevention was only added in 2015, and anti-bait was as late as 2021. These were not small changes, but they still failed to upset the overall balance and design of Zero-K that much. Admittedly, Lance has been nerfed since then, but prior to anti-bait players were still using Hold Fire to manually snipe commanders, so it was already using its abilities well when doing so mattered most. Artemis has not even been nerfed since it stopped wasting shots on Gnat. This is because Artemis was bad for quite a while, but being bad was better than the alternative. We try to balance units under the assumption that they use their abilities well, because otherwise we would have powerful but unwieldy units enticing players into fights with the UI.

In the end, Zero-K was never going to reach the level of control characterised by chess, but we have found fertile and relatively unexplored ground along the way. Powerful controls (hopefully) make the design resilient to players improving at micromanagement, and basic unit intelligence eases the difficulty of balancing for both new and experienced players simultaneously. The opponent part of Fight your opponent, not the UI is a bit of a misnomer though, because the principle is really about closing the gap between what players can tell their units to do, and what their units are really capable of. The idea can be extended to games without opponents, and even to games without units.

The principle touches every part of Zero-K, from the economy to the tech tree to movement mechanics. It is also at the centre of a few ongoing questions, such as how good units should be at dodging projectiles. If this post seems a bit light on detail, worry not, because this principle is going to come up throughout the rest of this series.

P.S. This did not fit in the main post, but my thoughts about UI were refined by Achron, the time travel RTS. I started playing Achron from the end of 2009 and it handles the UI in a very interesting way. In Achron the player is a time travelling commander, jumping around and giving orders throughout time. An order given in the past costs a global resource, "chronoenergy", and has a continual effect on the timeline by activating whenever a parallel world "hits" it. The details are complex, and a lot of can be done with this system, but the important thing for now is that the order exists in the game world. But if that is the case, where is its UI?

Commands in Zero-K are not part of the game world. They are UI constructs used to track which units are going to be told to use which abilities. But the commands in Achron work differently, so it actually has a very simple UI, which led me to make some weird feature requests. One of my requests was a way to delay issuing a command, because this could be used to save chronoenergy. Essentially, a sort of "command queue" of commands to queue later. Trust me, a desire for this sort of "meta-UI" makes sense with time travel. A similar thing happens with the Psychic Sensor in Red Alert 2 (mark your bingo sheet). Once you see the distinction between UI, abilities, and game world, you start seeing it everywhere.