Cold Take #46 - Giving and Taking Feedback
A lot of the polish in Zero-K is driven by player feedback. A single complaint can be enough to spark a re-investigation of some part of the game to check for improvements. Case in point, the recently upgraded build icons are a result of someone complaining that the icons were to
A lot of the polish in Zero-K is driven by player feedback. A single complaint can be enough to spark a re-investigation of some part of the game to check for improvements. Case in point, the recently upgraded build icons are a result of someone complaining that the icons were too hard to see. But it takes good feedback to see this kind of result, so today it is time for some advice on how to give feedback. Then, for balance, I'll talk a bit about how to use feedback.
Do not read this post as a strict demand. Giving good feedback can be difficult and not everyone has the time. My hope is just to avoid a few common types of bad feedback. Also, "good" and "bad" does not mean positive (praise) and negative (complaints). Good feedback is useful feedback, and complaints are often useful. Positive feedback can be bad in this sense, but it has additional psychological value, so my advice focuses on giving good negative feedback.
Here are my tips for giving feedback.
1. Treat the developer as if they are hearing this feedback for the first time. They'll forgive you if they have heard the feedback before and your take on it is still likely to be useful. I really just want to avoid statements such as "Can we finally fix the plasma cannon bug?" as the first time I hear about a bug. Give some context for the issue rather than skip right to complaining that it has not been resolved.
2. Give multimedia feedback. Why spend a thousand words describing an issue when a screenshot will do? I always ask for a screenshot when responding to visual feedback as half the time a vague complaint turns out to be a clear bug. Screenshots are great for bugs as well, but depending on the type of bug you might want to send an error log or replay link as well. Replays are a must-have for feedback on balance or wonky game mechanics as every extra piece of information helps identify the problem and devise a solution.
3. If your feedback is particularly long, or important, put it somewhere permanent so that you can link to it. Scrolling chat, such as Discord, is temporary and easy to miss. In Zero-K the main forum is the best place for general feedback, while GitHub is appreciated for reporting unambiguously technical issues. The Steam forums also work and Discord is fine as long as you accept that the feedback might be missed.
4. Start new threads rather than inserting yourself into unrelated conversations. There is often a bit of back-and-forth when giving good feedback, and trying to do so with multiple people simultaneously is a recipe for confusion. Adding feedback relevant to an existing topic is often fine, although I would be wary of adding good feedback on top of bad. People are allowed to give feedback at all times, and while some terrible opening posts have lead to threads with good feedback, the experience would have been better if people with good feedback had made their own thread.
5. Do not feel pressured into giving lengthy feedback. Each player is only one voice, and while more vocal players give us a better idea about what they want, volume of feedback does not inherently make their view worth more. It is rare that people give too much feedback, but I have heard from players who are concerned about their view being trampled because they don't write essays on the forum. A small comment is fine, especially if it focuses on how you feel rather than what you would change.
Consider the following when receiving feedback.
1. Feedback cannot be wrong, or right, it just is. Unless you are being trolled, feedback comes from somewhere. The player might fundamentally misunderstand the game or propose entirely backwards solutions, but nevertheless, there is some chain of cause and effect between a problem and the feedback. If you can unravel that chain, then you might find something to fix.
2. Solving the problem in front of you is not necessarily the end of the feedback. If enough people ask how to do something, and each time they go away happy having learnt an obscure key combination, consider how many people might be struggling in silence. Perhaps making the feature more obvious is warranted, depending on how important it is.
3. It is often said that players are great at finding problems but terrible at finding solutions, and I broadly agree, but I have two caveats. Firstly, it is often easier for someone to say "Glaive should be slower" than to unpick why they feel that way, so do not try to stop people giving feedback this way. As long as they follow up with more information, you have what you need. Secondly, some players have good solutions, so keep an eye out for them.
4. Some players are complainers and this is a good thing. Everyone has a threshold for how serious an issue has to be before it is worth mentioning it, and those with the lowest threshold will complain first. Eliciting good feedback from these players can uncover problems that make the game subtly better; do this enough times and the game is noticeably improved for everyone.
5. Hold fast to a core set of design principles, at least until the volume of feedback tells you to reassess them. Without principles the design will be buffeted on all sides as you try to please everyone, meandering the game towards mediocrity. Sometimes the best you can do is have complaints from one direction cancel out those from the other side. Make a game some people will love rather than a game few will dislike.
I naturally try to wring as much from feedback as possible. This has diminishing returns and can be unhealthy, so use the advice above in moderation as many more posts would be needed to paint a full picture.
Index of Cold Takes
Original post
Here are my tips for giving feedback.
1. Treat the developer as if they are hearing this feedback for the first time. They'll forgive you if they have heard the feedback before and your take on it is still likely to be useful. I really just want to avoid statements such as "Can we finally fix the plasma cannon bug?" as the first time I hear about a bug. Give some context for the issue rather than skip right to complaining that it has not been resolved.
2. Give multimedia feedback. Why spend a thousand words describing an issue when a screenshot will do? I always ask for a screenshot when responding to visual feedback as half the time a vague complaint turns out to be a clear bug. Screenshots are great for bugs as well, but depending on the type of bug you might want to send an error log or replay link as well. Replays are a must-have for feedback on balance or wonky game mechanics as every extra piece of information helps identify the problem and devise a solution.
3. If your feedback is particularly long, or important, put it somewhere permanent so that you can link to it. Scrolling chat, such as Discord, is temporary and easy to miss. In Zero-K the main forum is the best place for general feedback, while GitHub is appreciated for reporting unambiguously technical issues. The Steam forums also work and Discord is fine as long as you accept that the feedback might be missed.
4. Start new threads rather than inserting yourself into unrelated conversations. There is often a bit of back-and-forth when giving good feedback, and trying to do so with multiple people simultaneously is a recipe for confusion. Adding feedback relevant to an existing topic is often fine, although I would be wary of adding good feedback on top of bad. People are allowed to give feedback at all times, and while some terrible opening posts have lead to threads with good feedback, the experience would have been better if people with good feedback had made their own thread.
5. Do not feel pressured into giving lengthy feedback. Each player is only one voice, and while more vocal players give us a better idea about what they want, volume of feedback does not inherently make their view worth more. It is rare that people give too much feedback, but I have heard from players who are concerned about their view being trampled because they don't write essays on the forum. A small comment is fine, especially if it focuses on how you feel rather than what you would change.
Consider the following when receiving feedback.
1. Feedback cannot be wrong, or right, it just is. Unless you are being trolled, feedback comes from somewhere. The player might fundamentally misunderstand the game or propose entirely backwards solutions, but nevertheless, there is some chain of cause and effect between a problem and the feedback. If you can unravel that chain, then you might find something to fix.
2. Solving the problem in front of you is not necessarily the end of the feedback. If enough people ask how to do something, and each time they go away happy having learnt an obscure key combination, consider how many people might be struggling in silence. Perhaps making the feature more obvious is warranted, depending on how important it is.
3. It is often said that players are great at finding problems but terrible at finding solutions, and I broadly agree, but I have two caveats. Firstly, it is often easier for someone to say "Glaive should be slower" than to unpick why they feel that way, so do not try to stop people giving feedback this way. As long as they follow up with more information, you have what you need. Secondly, some players have good solutions, so keep an eye out for them.
4. Some players are complainers and this is a good thing. Everyone has a threshold for how serious an issue has to be before it is worth mentioning it, and those with the lowest threshold will complain first. Eliciting good feedback from these players can uncover problems that make the game subtly better; do this enough times and the game is noticeably improved for everyone.
5. Hold fast to a core set of design principles, at least until the volume of feedback tells you to reassess them. Without principles the design will be buffeted on all sides as you try to please everyone, meandering the game towards mediocrity. Sometimes the best you can do is have complaints from one direction cancel out those from the other side. Make a game some people will love rather than a game few will dislike.
I naturally try to wring as much from feedback as possible. This has diminishing returns and can be unhealthy, so use the advice above in moderation as many more posts would be needed to paint a full picture.
Index of Cold Takes
More powerful projectile dodging would involve tracking incoming projectiles and moving out of their way. There has been some experimentation in this area, but so far none of it has made it into the main game. Quite a bit of the technical work was done around 2021, first as 
Unfettered automatic dodging risks sparking an arms race between units' AI and their 
To bring automatic dodging down to the human level we would need to consider what makes it so powerful to begin with. One large advantage is the fact that code can read precise projectile positions and velocities, which for most projectiles is enough information to predict exactly where and when it will land. Humans are decent at this task, but it is made more difficult by the top-down camera. In any case, this precision is a feature of software, not a fact about the mechanics of the game world that the software is modelling. We could decide that units only ever have an approximate perception of projectiles, which would put them on equal footing with humans. We might also consider giving dodge AI built-in latency to further level the playing field.
The nice thing about deciding what units can see, effectively giving them perceptual 
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 
The other way automation can reduce strategic depth is by shrinking 
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 
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 
At Level 0 the player can barely read and rarely touches their keyboard. Most of their inputs are either context-sensitive right-click commands or structures selected through the build menu. Small buttons may as well be invisible, which for us includes state toggles and everything in the top left corner of the UI. Zero-K is not the simplest game, so it is not quite designed to work all the way down to Level 0, but we may hit something like Level 0.1, which involves reading the occasional tooltip and learning a 
At Level 2 the player has opened the ingame menu. The menu has Simple Settings enabled by default, which removes the vast majority of options. At this level players only see the most important options, as measured by what new players think to look for, such as locking the cursor to the window or picking whether the minimap is on the left or right side of the UI. Level 2 also includes the full hotkey and default unit behaviour menus, so if we were to apply these levels to other games, it would be hard to find a game that allows customisation beyond Level 2.
At Level 3 the player unticks Simple Settings. This is the first level that gives players the power to make their UI objectively terrible. This is achieved by enabling Tweak Mode, via a hotkey or button found in the menu, then moving and stretching their UI. There are also many alternate styles for in-world UI, such as unit selections, which come from a time when many widgets were being written and included. A lot of mostly superfluous bells and whistles, such as the attrition tracker and wind speed display, can be enabled here as well.
At Level 4 the player has fully "voided their warranty", meaning that they can now break things thoroughly enough to be told to reset their settings when they ask for help. This level is reached either by opening the 
In the beginning there was engine behaviour, which offered limited customisation, most of which involved hotkeys or UI colour files. Then 
The levels of customisation are also a way to think about the intended audience of features. In general our aim is to push as much 
The main role of reclaim is to dynamically create areas of interest around the map. Some units die in a skirmish, leaving a few hundred metal on the ground, which makes holding the area slightly more enticing. This leads to more battles that drop even more wreckage, which can even snowball into thousands of metal worth of incentive to keep fighting in that area. Eventually the feedback loop is broken by one side gaining enough control to deplete the whole field. The pacing of this dynamic is great: the stakes keep rising while the outcome is uncertain, then quickly dissipate once one side wins, releasing the tension.
A single wreck field, that everyone pours their armies into, would get a bit dull after a while. Luckily, there are often multiple fields scattered around the map. Reclaim essentially generates multiple shifting king-of-the-hill style objectives, but in a natural way that targets the most contentious parts of the map. Players shift their focus around to secure wrecks, which encourages the use of mobile armies that can make these kinds of strategic moves. The side that focuses more units on an area has a better chance at winning, but leaves themselves open to attacks elsewhere, which can trigger the creation of a new field of wrecks to fight over. Sometimes one side wins on all fronts simultaneously, but when this happens the reclaim lets them close out the game quickly, which is preferable to keeping the game going long after it is over.
Contestable wreck fields only form if players have a reason to be out on the map. Metal spots fulfil this role generally, but many maps also kickstart the process by starting with reclaimable map features. The classics are rocks and trees, but sometimes a map will contain old machinery or magical purple crystals. Trees tend to be energy-only, which can lead to constructors being more efficient than Solar Collectors early on, while rocks contain metal. A lot can be done with small amounts of reclaim, as every bit counts early on.
In addition to changing the value of an area, wrecks change the 
It can be tempting to think of reclaim as a comeback mechanism, and it is in some situations, but it is more useful to think of it as a mechanic that increases variance. It can certainly provide the metal needed to rebuild after a raid on your base. However, if the enemy knew that you would come out ahead, then they would not waste their units on diving your base in the first place. So reclaim softens the blow of effective assaults and deters marginal ones, but a similar effect could be achieved by buffing defences. It is hard to call this a particularly strong comeback mechanism, in theory at least, because players should avoid making raids that just feed metal. In practice mistakes can be made, but the advantaged team is not obliged to make them at any greater rate than an underdog.
Things get more interesting when we consider wrecks that have a reasonable chance of being claimed by either side. The long-term success of an assault often depends on who gets to reclaim the resulting wrecks, which introduces swinginess by widening the range of potential outcomes. So even if a player attacks with the expectation of a positive outcome, there is often a good chance that the defender will rally and take the reclaim for themselves, or at least take a sizeable chunk. This is the stronger form of comeback mechanism offered by reclaim, as uncertainty benefits the underdog. It has to, because if the game were to just plod along predictably, we would expect the disadvantaged team to lose. Base raids have less of this type of variance than fights out on the map because the defender is destined to get the reclaim.
The importance of reclaim depends on how much metal can be gathered from wrecks. Too much metal and the first bit of reclaim will snowball into a win, too little and the system becomes useless. In Zero-K units leave wrecks with 40% of their value when they die, unless they died to a massive burst of damage, in which case they leave 20% of their value. This value was picked very early on in Complete Annihilation, so perhaps the precise value is unimportant, although I suspect there is some leeway offered by tweaking the design of the rest of the game around a simple round number.
The mechanics of reclaim are also important, although I might not think so if we did not start with quite a poor implementation. The default system offered by the engine has reclaimers fill a progress bar over their target wreck, which yields a lump of metal when filled. This was an ugly system for many reasons, as lump sums require extra storage to process, and being hit by chunks of metal makes your economy needlessly difficult to manage. It gets worse when you consider the arguments and jank caused by multiple players trying to reclaim the same large wreck, as only the constructor that contributed the final tick of progress was rewarded.
Reclaim in Zero-K works by constructors gradually sucking the metal from wrecks. All constructors can reclaim, and they all do so at a rate equal to their 
I shouldn't complain too much about the defaults offered by the engine, as they were mostly inherited from Total Annihilation, and the engine was easy enough to extend. Some improvements even predate Complete Annihilation, such as area commands. Wrecks are much harder to reclaim without area commands, as the options are to either issue a patrol command, or to click on each wreck individually. Patrol was risky though, as constructors might decide to repair instead, or wander into turret range. Area reclaim gives you much more control over how far your constructors venture, and there are even keyboard modifiers to make them ignore trees and other metal-free reclaimables.
Precise control of your reclaiming constructors is vital because players are encouraged to put their constructors on the front line, reclaiming at the edges of the battle. This is great in that it gives the enemy targets of opportunity to snipe, but losing constructors this way would be frustrating if they were not where you meant them to be. Constructors also have other frontline tasks, including repairing, construction, and some can even resurrect units from wrecks. A large part of the game is judging how many constructors to build, and where to deploy them, but that will have to be a topic for another time.
This update adds wires between structures to visually connect energy grids. This makes grids easier to use and more satisfying to build. We have also added commander eggs, which let players rebuild lost commanders. The egg can also be transported and thrown, to take advantage of its disabling explosion.
On the more regular side of things we have a revert of the Hermit regeneration experiment, and numerous features and fixes. These include a new attrition graph for the endgame stats, and a lighting system update to fix the Pylon light bug.
Added grid wires between Metal Extractors and energy structures (thanks Licho and Anarchid).
There are many ways to avoid or reduce deathballing. At the strategic level, they can be discouraged by scattering multiple objectives around the map. These could be the 
An aura is an ability that applies a constant effect in the area around a unit. A scaling buff aura is one that boosts friendly units in some way, and that is more effective the more friendlies are nearby. For example, it has been suggested that Funnelweb could passively heal nearby allies, which would be a scaling aura since the total rate of healing would increase with unit count. There are auras for any kind of buff, and most of them are in Warcraft III. A lot of the auras found in other games would also be too 
The most aura-like mechanic in Zero-K, in terms of giving a scaling buff to allies in an area, may well be the lob of the Lobster. This is an active ability, but the threat of a lob makes the nearby units a lot safer. Lobster scales with unit count, as each unit in range feels the benefit of the lob, which is why Lobster is often included in shieldballs and other types of tightly clumped armies. So it turns out that, even with a rule against auras, an aura-like effect managed to sneak in. At least Lobster has a small area of effect, and as an active ability, has a cooldown.
Many things look like auras if you squint hard enough. 
The paradox of the retreat range bonus is that it was not added; it is just the inevitable result of the common type of game physics. If a game physically simulates its projectiles, then it probably has some form of retreat range bonus. Many, possibly all, first-person shooters have it, and there might even be a term for it in that space. Games like Supreme Commander and Planetary Annihilation should have it too, but to this day I have not found any discussion of retreat range in those games. I am often met with confusion when I ask people about it, even after explaining the generality of the mechanism.
The retreat range bonus is caused by units leading their shots. In other words, to hit a moving target, you need to shoot at where it is going to be, rather than where it is. In particular, for a unit to hit a fleeing target near the edge of its range, it would have to fire at a point beyond its range. Doing so would violate the 
So far so good. The retreat range bonus is baked into the game, and removing it would make less sense than leaving it in. The problems arise when we consider the tactical implications. The Chaser-Runner battle can be in one of three states, depending on the distance between the participants:
The retreat range bonus came up as part of a broader set of feedback about the swinginess of the early game. In short, some 1v1 players felt like too much hinged on the first few raider engagements, and that too few games made it out of this stage. This was by no means a universal take, but it was prevalent enough to be worth some experimentation, as we could end up somewhere that most people would prefer. Chasing feedback from players that are particularly sensitive to an issue can be useful, as this can reveal things that generally improve the game, yet were below the complaint threshold for most people. The feedback and testing culminated in the 
On the technical end we removed the retreat range bonus by forcing units to not lead their shots, then hacking physics to cause their shots to lead themselves. Every time a Bandit shoots, its projectile is reoriented slightly to point towards the predicted location of its target. This lets raiders shoot very slightly beyond their range, breaking the No Void Ray rule, but their high projectile speed makes the effect barely noticeable. Unless you pause the game, zoom in, take a screenshot, then draw some arrows. If you cannot unsee the small deviation ingame, then I am sorry, but that is the risk we take when pulling back the curtain.
As for the Superfluid Update itself, the rest of it involved making raiders and constructors take a bit longer to kill, and generally making units feel more responsive. These changes were walked back over time, to an average of the old and new states, but this was by design. I prefer to overshoot reworks to probe the outer edges of the reasonable area in the design space, to make a better map with which to navigate to the final state. The raider retreat range bonus has not returned though, and predictions of the raider game becoming trivial or pointless did not eventuate. Raider battles still involve a lot of position adjustment as players try to keep all their raiders firing on a target, while trying to block enemy raiders behind each other. Still, it would be good to hear some of the feedback from players who were there six years ago, to see how the changes have aged.
Some design principles encourage special abilities. 
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 
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.
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 
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. 
We managed to avoid having too many ability toggles, but went a bit overboard with behaviours. Early on in 
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.
It would take a bit of a redesign to see pure dedicated scouts in the early game. Such a scout would have to be either very cheap or very powerful to offset its drawbacks. This power could be relative, i.e. raiders could become near-blind, but the issue with blind units is that regularly blundering into the enemy feels bad. Ultimately we avoided forcing dedicated scouts into the early game as it would be too much to manage. Remember, 
Different types of scouts are good at different types of scouting, and players pick them based on what they want to discover. One type of scouting is "weakness scouting", i.e. scouting to find a crack in the enemy's defence. Raiders are particularly good weakness scouts because they are equipped to follow up on the weaknesses they find. Another type of scouting is "threat scouting", in which players seek to reveal and preemptively counter enemy plans. In fact the cheapest dedicated scout in Zero-K is a threat scout: the 
The nature of threat scouting changes over the course of a game, with the main distinction being how early the threats are revealed. All plans are revealed eventually (such as when the nuke launches), but plans that take longer to implement can be revealed earlier than others. Threat scouting for long-term plans is a big part of the dance around the 
A limit to how little it should cost to scout was found with the discovery of flying Flea scouting, which involved launching Fleas 
Scouts revealing themselves creates a weird situation when trying to determine which factory the enemy picked. You might spot the factory, or a unit from the factory, but the scout you send is guaranteed to give away your own factory. There are a few ways to get around this, such as with Sparrow, but they are impractical early on. In a 1v1, being scouted is the only reliable way to learn the enemy factory without revealing your own. Scouting and raiding is otherwise important enough for this to not be a concern though, and perhaps the interaction is not that unusual. Most multiplayer games reveal faction choice in the lobby, but some have a hidden random faction option which is only revealed when they scout. So the situation in Zero-K is more a result of factory choice (which is 
This release is mainly about tweaking a few overused units. Venom is slightly worse at stunning to counteract the overstun change, and other Spiders were buffed to compensate. Lobster now gives the enemy a little more time to react and Magpie should be easier to scare away. Terraform is also UI-nerfed against Missile Silo, as the Force Fire UI now warns you about unintended terrain interactions.
The engine was also updated, and it should stick this time as it was found to be quite stable in testing. The big feature is the adoption of quaternions for unit animation (just in the backend, no API changes), which makes units move and aim more smoothly. Missile trails are also much smoother, replacing the old jagged lines. These changes were blocked behind the game-side graphics update of a few months ago, and the work is ongoing. For example, this release includes a new shiny Likho texture by brunocb.
The power of strategic RPS is its generality, at least if we define it broadly enough. This requires a brief detour into the idea of economy. The standard economy of RTS involves extracting resources such as metal, ore, or minerals, then spending it on units and more economy. But the economy part of strategic RPS encompasses more than that. To start with, it is useful to think of construction capacity (
It is worth taking a closer look at the relationships between the three aspects of strategic RPS. In doing so I want to demonstrate the strategic RPS is something intrinsic to strategy games. Once you have economic investment, you have strategic RPS, and it takes extra work to downplay or remove. It all hinges on economic investment, so we will start there.
Offence beats economy because economic investment leaves the investor vulnerable to attack. RTS needs offence because otherwise there would be nothing to stop players funnelling all their income into more and more economy. Strictly speaking, a game with absolutely no offence would lack a win condition, as even the most economically focused strategy needs to turn its overwhelming resource advantage into a way to kill the enemy. This is how economy beats defence: if both sides leave each other alone for a while, the side with more economy will overwhelm the other. With the economy interactions of strategic RPS figured out, the relationship between offence and defence can only go one way.
"The best defence is a good offence", or so the adage goes, but this is not the case in strategic RPS. Offence already beats economy, so for offence to not be the dominant strategy it had better lose to defence. Strategic depth in RTS requires that there be ways to spend resources defensively, and defences have to be good enough to fend off a greater investment in offence. Note that this does not mean all games need turrets. Producing defence-oriented units counts as defence, as does building in a more defensive way, at the cost of some economy. Starcraft provides an example with ramp walling, since it takes workers longer to reach structures when they are built further away.
Strategic RPS is a decent model, but it is a bit unrealistic as players rarely go all-in on offence, defence, or economy. Back in the day we would use the term as a shorthand for related ideas. For our purposes we had better park the term here and start on the strategic triangle.
The strategic triangle is a map of strategy space, where strategy space can be imagined as a nebulous cloud that represents every approach players could take in a game. The strategic triangle adds structure by scoring each approach by how offensive, defensive, and economic it is. The space is then stretched and flattened into a triangular shape so that the most extreme strategies sit at the vertices of the triangle, while everything else exists somewhere in the middle. To simplify things we also discard the pointless strategies, such as that of blowing up your commander at the start of the game. If you want to get technical you could consider the triangle to be the Pareto frontier of the projection of strategy space onto three dimensions.
In other words, the strategic triangle is the nuanced version of strategic RPS. Players can do a mix of offence, defence, and economy. The strategic RPS relationships still hold though: we expect a strategy that focuses mostly on economy to lose to one that focuses more on offence.
The first thing to notice about the strategic triangle is that it is inherently unbalanced. Remember "the best defence is a good offence"? That turns out to be good advice, in a roundabout way. The most general type of RTS strategy advice often boils down to making as much economy as possible while investing in as little defence as you can get away with. Offence is often an effective way to tie your opponent in knots and trick them into making more defence than they need, reducing their expenditure on offence and economy, hence the adage. Economy is the best way to get a long-term advantage, and economy beats defence, so whoever builds the most defence loses. This bias in RTS is probably due to the focus on armies and quick combat, compared to other genres of strategy game.
The strategic triangle helps us create a sense of strategic freedom because, as a map of strategy space, its size reflects the range of options available to players. But its main purpose is to highlight and avoid strategic RPS. As you may have guessed from its somewhat pejorative name, players tend to complain about strategic RPS when it becomes too apparent. A satisfying game involves jockeying for position on the strategic triangle, trying to counter whatever the enemy is up to via scouting and intuition.
There is tension here: strategic freedom demands a large strategy space, while an aversion to too much strategic RPS demands that it remain small. The solution, used by Zero-K and many other games, is pretty simple: start battles with a small triangle and grow it as the match progresses. This is why there are relatively few options early in the game, with relative soft counters. It is only later that the hard stuff comes out, such as 
Take the very first unit of the game: the commander. Its laser and high health pool give players a baseline level of defence, while its income and ability to construct constitute economy. This starts players in the defence-economy area of the triangle, and there is a limit to how fast their decisions can them in other directions, limiting the extent to a player can go all-in on offence. At one point we experimented with starting players with an ordinary constructor, but the lack of the commander as "strategic ballast" resulted in too much strategic RPS.
Here is another example: constructors can build turrets, which makes sending a constructor out to build metal extractors a partially defensive action. Constructors can even end up taking on an offence role when they move close enough to the enemy base. So even the most greedy economic opening has built-in defence. Just imagine how swingy a Zero-K with dedicated economy-constructors and defence-constructors would feel. The cost of metal extractors has also gone up over time, limiting just how quickly a greedy opening can shore up its weaknesses.
Most units perform all three roles. A riot that sweeps raiders from a potential expansion site is performing an economy duty. Alternately it could defend existing metal extractors or trundle towards the enemy expansion. The most generic view of resources considers units to be resources that are spent by placing them in different parts of the map, since they can only be in one place at a time. This flexibility of deployment smooths over a lot of potential excess strategic RPS, as it means that decisions are not just made when a unit is built.
Our attempts to bound the strategic triangle often butt up against other design principles. 