A conflict has been brewing over the course of this series. Half the cold takes, those on general design principles, often imply that Zero-K avoids special abilities, while the other half shatter this impression by being about specific special abilities. In this post we will try to resolve this apparent disagreement by exploring how special abilities work and what makes an ability suitable for Zero-K.

The set of design principles arrayed against special abilities is truly daunting. To start with, abilities that require frenetic or precise clicks are rejected by the idea that players should not have to fight the UI. Many other potential abilities are ruled out for being too numbery, making units too stupid, or for imposing arbitrary target restrictions. Atomic unit design pushes us towards having few abilities, special or otherwise. But despite all these restrictions, Zero-K has many more special abilities than other games with Total Annihilation ancestry.

Some design principles encourage special abilities. Quant's Rule reflects a desire for units to be unique and interesting, and special abilities are certainly a way to achieve that. More importantly, special abilities are fun, and not just to use. Zero-K steadily accumulates special abilities as a result of its open source laissez-faire development style, with many contributors working on whatever they find most interesting. This process predates Complete Annihilation, as early engine developers added features such as bubble shields and the deformable terrain that makes terraform possible.

The pace of special ability development ramped up with the advent of Complete Annihilation and Lua scripting. Many of our design principles were also being hammered out around this time, but the purpose of them was more to channel this outpouring of creativity, rather than attempt to stem the tide. This period gave us area cloakers, morphing, jumpjets, terraform, and a host of manually fired weapon-like abilities. It is hard to overstate how satisfying it is to mess around with new abilities, I have even written abilities that my designer side knew had little chance of making it into the game.

In fact, the design principles that seem to restrict special ability design actually let it flourish. We were free to experiment within the guidelines without worrying too much about whether the result would be fundamentally at odds with the rest of the game. Our experiments could still fail, but less catastrophically; the game would not break. Without any guidance we may have been too scared, or disorganised, to try anything new.

So Zero-K allows, and even encourages, special abilities as long as they fit into the design. In practise this means abilities have to pass two tests: they need to make sense within the game world and they should not be too hard to use. Whether an ability makes sense is the easier of the two to judge, since we have reasonably clear rules about things like armour classes, and the "theoretical ideal ability" test from Aim and Fire can be used for more than weaponry. How hard an ability is to use, i.e. how fiddly it is, can be harder to judge, since it involves tradeoffs against how much the ability adds to the game. The two guiding principles for fiddliness are that players should not fight the UI, and that abilities should avoid making units implicitly stupid. A lot of fiddliness comes down to how much attention is required to use it.

The least fiddly type of ability is the passive ability. Damage types such as slow and disarm can be considered passive abilities, as could uncontrollable abilities such as shields. There is little risk of fiddliness or stupidity with such abilities, however the risk is not zero. For example, Racketeer needed quite a bit of AI work to make it smart enough to stagger its homing disarm missiles to maximise uptime. Technically the issue with Racketeer boiled down to firing being an active ability, but all units use their active abilities to control how their passive abilities are expressed, so accepting this technicality for this definition would render the concept of passive abilities useless.

The next-best thing to a passive ability is a toggled ability that is designed to rarely need disabling. In practice this works a lot like a passive ability, but it is theoretically quite different due to the UI/Game World split, pictured below. Units are free to choose when and how to use active abilities, which opens up the possibility of units failing to do so correctly, either while idle or in response to player commands. The advantage of an automated rather than passive ability is that it can be disabled in edge cases, and that being able to disable an ability often makes more sense within the logic of the world. For example, Solar Collectors have a state toggle to keep them open under fire, because closing feels like a choice rather than something that is forced.

The third type of ability, beyond passive abilities and automated active abilities, is manual abilities, which require direct player intervention to use. This category causes the most trouble, with the fiddliness of a manual ability largely depending on two things: the type of command used to control the ability, and how often the ability is used.

There are broadly three types of command, categorised by the type of target they usually require: no target, ground target, or unit target. The simplest type of commands are those with no target. Examples include Swift boost, Krow cluster bomb, and the self-destruct button on crawling bombs. Just click the button (or press the hotkey) and the ability fires. This does not mean it is easy to know when to use an ability, just that issuing the command is not the hard part. The special abilities in Warlords Battlecry are all untargeted, which may have been an influence for Swift boost.

State toggles can be considered as a sub-category of untargeted commands, but the mental overhead of tracking the state makes them a bit harder to use. Most toggled abilities, such as cloaking and floating, can be left on their default state, but there are a few that require toggling to use their full mechanics. The Pull/Push toggle on gravity guns is a good example, as is the manual hunker down ability of heavy turrets.

Ground targeted commands are the next-easiest type of command, the reason being that the ground is large and static while units are relatively small and often mobile. Ground targeted commands could be broken down further into line moves and area commands, but the added complexity of dragging a line or a circle trades off against increased expressiveness. Every targeted manual ability in Zero-K can be shot at the ground, and most are designed with this use in mind.

Unit targeted commands are the hardest type to use. Structures are easier to click than units, and allies are easier to click than enemies, but they are all harder to click than the ground, so very few of our manual abilities are meant to be shot directly at units. Only a few of the most expensive units (Reef, Scorpion, Detriment, and some advanced commander weapons) have this type of command. The result is that players will rarely need to click enemy units, however, the word "need" is doing a lot here.

Strictly speaking, players do not have to click the enemy units to have their own units use their abilities, however, this leaves the choice of target up to the unit AI. In practice players often tell their units to pick off a particular enemy unit by right-clicking it to issue a Force Fire command. The target priority even persists until overridden by another attack-type command, which is neat. But Force Fire has another use, one that, in conjunction with Hold Fire, circumvents the aforementioned guidelines for manual ability design. This is because, in Zero-K, if a unit has a single weapon, then it will (almost) always be treated as an ordinary weapon, regardless of how "special" it is.

Quite a few of the ordinary weapons in Zero-K would be implemented as special abilities if they were to appear in other games. Some artillery units have reload times in the teens, with Lance even taking 23 seconds to reload. Firewalker fires bursts of fire that linger on the ground, while Placeholder launches miniature black holes to trap units in place. Players frequently set these units to Hold Fire and use them manually, just like a special ability. Even our nuke and missile silos use ordinary weapons, although these structures are set to Hold Fire by default. The only weaponless unit with a targeted special ability is the Lobster, as it caused too many accidents back when it responded to Force Fire.

Using Hold Fire to turn ordinary weapons into special abilities might seem like a bit of a hack, but doing so has many benefits. To start with, using an ability by right clicking is more fluid than the two-step process of selecting the ability then left clicking. Hold Fire also lets players opt-in to complexity, and unit AI toggles such as overkill prevention and anti-bait let players configure how eager units are when told to use these abilities on their own initiative. The usual pattern is for players to micromanage a handful of units early on, then set groups of them to Fire At Will later.

Returning to special abilities, weapons that are regularly used with Hold Fire work in much the same way as automated active abilities. They are expected to work in the hands of unit AI, which makes them much less troublesome than manual abilities. These weapons would actually make terrible manual abilities, because they regularly want to be fired as often as possible, which is one of the clearest indicators that a manual ability requires too much player attention.

A good manual ability for Zero-K is one that players regularly have available, but do not use. Consider the alternative, if an ability takes 30 seconds to reload, and your aim is to use it as much as possible, then you now have a chore that requires your attention every 30 seconds. There is no decision in whether to use it, even though there may be some decisions to make in how it is used, it is just something that needs doing. This is why there are no ground-based sprint abilities: it is too easy for a sprint to be spammed to cross the map faster. Swift only gets away with it because it does not need boost to cross the map very fast.

This brings us to a simple rule for manual abilities: they must have long reload times, or at least have some sort of opportunity cost, to prevent them from becoming chores. Jumpjets avoid this problem by being barely faster than walking, on flat maps, so that the distance gained is rarely worth the risk of being caught without a jump. Particularly expensive units can get away with breaking this rule, such as the Paladin's spammable EMP missiles, but rules like these can be broken by big expensive units that are expected to be the centre of attention.

The design principles of Zero-K significantly constrain the special ability design space, but we still manage to have fun within it. Passive and automated abilities are relatively safe, with atomic unit design being the main hurdle, whereas too many manual abilities risk becoming chores. We currently have few enough manual abilities to put almost all of them on the same hotkey. The best way to add more would be to add more units, or even factories, to give players different abilities to manage, rather than more to manage at once.

Index of Cold Takes[zero-k.info]

Almost everything players do in RTS is done by issuing direct commands or by toggling states. Direct commands give units a temporary goal, and include classics such as "move to this location" or "shoot at this enemy until it dies". State toggles make more permanent changes to how a unit behaves, at least until the state is toggled back. Examples include auto-cast toggles, toggleable abilities, and the stance and formation buttons used in the Age of Empires series. Toggles can be fine when used sparingly, but Zero-K did the opposite, to the point that we might have more than any other RTS. The upside is that we learned a lot about how and why to avoid state toggles.

The allure of state toggles is that they seem to epitomise the idea of Fight Your Opponent, Not The UI. Players should be able to express their wishes with minimal commands; in Warcraft III you want a Priest to use its extra mana to heal, then being able to tell it to automatically heal implements that desire with one click. In Zero-K, players often want units to keep the enemy at their maximum range, which is much easier to do with a state toggle than a constant stream of redundant move commands. We can also think of state toggles in terms of the demarcation between a unit's abilities and its behaviours. For example, shooting feels like behaviour, so it makes sense to have a Hold Fire state toggle.

There are broadly two types of state toggle: ability toggles and behaviour toggles. This is a useful distinction despite the fact that, at a fundamental level, everything a unit can do is an ability, and every different way it can choose to do it is a behaviour. In practise there is a often clear difference between controlling a specific ability or generic behaviour, although some toggles end up in between.

Ability toggles are found in many games and include cloaking, burrowing and deploying. To be precise, we can define an ability toggle as a state toggle that is a necessary part of using an ability. You cannot set your tanks to siege mode without touching the siege mode toggle, but you can cast spells in Warcraft III without toggling auto-cast, so auto-cast is a behaviour toggle. On the topic of Warcraft and Starcraft, their Hold Position command is not a toggle at all since it has to be re-issued each time you want your units to stay still.

Total Annihilation was one of the earliest games which put behaviour toggles such as Hold Position front-and-centre. Everything that moves had a move toggle with three states: Hold Position, Manoeuvre and Roam, with the latter two effectively being "move around a bit" and "move around a lot". Everything with a weapon also had a fire state with three states: Hold Fire, Return Fire and Fire At Will, with return fire causing units to shoot back after they take damage. Total Annihilation also had ability toggles, such as cloaking and the ability to turn Solar Collectors on or off.

The problem with state toggles is that they are fiddly and are, for the most part, the least satisfying way to control units. Issuing orders, say to set up a flank or to unleash an ability on a group of enemies, is much more fun than fiddling around with buttons tucked into the corner of the interface. Many state toggles have subtle effects, which makes it hard for players to see that their actions had any impact. Seeing the states of units is itself a problem, as there is no good way to fully display the more abstract states. Zero-K fails to show all the different ways a state is toggled in a mixed selection of units, and while there is an option to show states overhead when shift is held, it is very messy so not something we would want to enable.

The lack of visual feedback can be solved by reflecting the state of units in the game world, and games that limit themselves to a few high-impact ability toggles tend to do this well. Think transparent cloak effects or unit deployment animations. However, this solution does not scale, as it is most effective when the entire body of the unit is transformed, so multiple states end up fighting for space. It also does little to alleviate the fiddliness of toggling the state, or the mental overhead required to make sure your units are in the right state. Units with high-impact ability toggles require more player attention, which is a recipe for fights with the UI.

Compounding these issues is the inexpressiveness of state toggles. A move command contains a lot of nuance about exactly where you want your units to go, and a line move contains even more, whereas a state toggle can only be in one of a few states. State toggles are a woefully inefficient way to communicate your intentions to your units. Admittedly there are exponentially many ways to set the states in an army of units, but toggling them all would take time better spent issuing many commands. We want to translate player intention to unit action as effectively as possible, and for this, state toggles are not the way to go.

Zero-K uses relatively few ability toggles and is a recovering behaviour toggle addict. Our use of ability toggles is curtailed by the idea that state toggles should be as optional as possible. This would seem to rule out many abilities, such as deploying to fire, but strictly speaking it only rules out versions of the ability that require a manual toggle. A toggled ability can have an automatic behaviour provided that toggling is never a bad idea. For example, our deployable units avoid state toggles by having their pack-up times tuned so that deploying is almost never wrong, so they may as well deploy automatically when idle. This restricts our design space, but removing a toggle is worth it.

We have some true ability toggles, but many of them are designed to rarely need toggling. Cloaking is one example, as beyond the very early game it is rarely a good idea to turn it off. The cloaked constructor even has free cloaking to avoid micro-optimising it in the opening. In the case of necessary toggles we try to limit them to expensive units. These include the gravity gun push/pull toggle, high/low trajectory fire for particularly heavy artillery, and the hunker down ability of heavy turrets. The most common important ability toggle is probably the Float/Sink state for amphibious units, which is like deployment, but the transition takes a bit too long and it makes units vulnerable to surface fire.

Sometimes a new ability toggle can be avoided by piggybacking on an existing one. For example a handful of light units and turrets can also hunker down to reduce incoming damage, but they do so fast enough for the behaviour to be automatic. Most of the time this lets them use the ability without touching a toggle, and in a situation where the units should stay armoured, they can be set to Hold Fire. The Float/Sink toggle works similarly since, by default, units only float to fire at the enemy. In more extreme cases we redesign units to remove state toggles, or avoid adding a toggled ability in the first place. Raven dive is an example of the former, while shield link is an example of the latter.

It is important that state toggles can only be toggled by the player. This sounds obvious, but the default engine behaviour does not adhere to it. Cloaked units used to toggle themselves to "decloak" when out of energy, but revert back to "cloak" if energy became available. I assume the intent was to have the state of the toggle tell the player the state of an ability, but consider what happens when you want to decloak some units during an energy stall. Units that seem to be told to decloak are actually in a secret "cloak when there is enough energy" state, and this state was impossible to detect, let alone toggle. Trying to turn off a group of fluctuating cloaked units was a nightmare, so the player-facing state cloak and on/off states are now handled by Lua, and always reflect what the player told their units to do.

We managed to avoid having too many ability toggles, but went a bit overboard with behaviours. Early on in Complete Annihilation we had many developers adding all kinds of behaviours, so as a form of safety, each of these behaviours got their own toggle. Many of these behaviours were meant to be strict improvements, but we were humble enough to not expect everyone to want the new behaviour. The result was a number of toggles that were designed to never be touched, since the new behaviour should be better, and more flexible, to encompass everything a player might reasonably want their units to do.

The behaviour toggle situation was dealt with in 2020. The more obscure toggles were hidden by default and the interface was changed to show at most twelve at a time, which is a limit that is very rarely reached. By this point few players could say where the engine unit AI ends and Lua takes over. The tactical AI gadget extends a lot of Attack Move and idle behaviour, including causing ranged units to stay at maximum range. Its toggle can be hidden because it is overridden by Move commands, and partially by Hold Position. Overkill prevention also has a hidden toggle, but is overridden by a Force Fire command. During the cull we also hid the mostly redundant third options for move and fire state, as a toggle with two states is much easier to use than one with three.

The acceptability of a toggle depends on how it is intended to be used. Construction priority is one of the toggles we expect players to touch the most, but it is fine because it is rarely toggled in the heat of battle, and it implements a simple decision for which there are only a few options: high, low or medium priority. Construction is a long-term action and controlling its flow manually would involve a lot of redundant commands. For faster-paced situations, such as battles, the toggles are designed to be overridden by direct commands, to let players give commands rather than fiddle with toggles.

The silver lining to all this state toggle proliferation is unmatched customisation of unit behaviour. Early on we added a section of the menu that lets players set their own default state for each unit type. Some players, including myself, like to set everything to Hold Position, while others set up preset construction priorities to make sure their metal extractors are built as fast as possible. The extraneous toggles that nobody wants to tweak in the heat of battle found their home here. Players can disable various bits of the unit AI on a per-unit-type basis, for every future battle. What started as a mess of widgets, all with their own toggles, ended up being a vast set of options to tweak unit behaviour to your liking.

Index of Cold Takes[zero-k.info]