This update sports fancy new plasma cannon visuals and an engine update. The engine update is fairly well tested by this point, and should resolve a few rare crashes and improve performance. It might need a bit of time to scan your maps when you first launch the game. In terms of balance, the game seems quite stable and the recent Felon nerf is still being assessed, so we only touched the second-smallest and second-largest turret.

Balance

Picket requires an extra Ronin shot.

• Health 340 -> 375

Disco Rave Party almost turns as fast as it used to.

• Turn rate 3 -> 4 degrees per second

Features and Fixes

• Plasma cannon trails! (thanks ThornEel)
• Made a start on Japanese localisation (thanks syuumu200).
• Fixed the way a few units handle projectiles in Tech-K (thanks XNTEABDSC).
• Lobster cooldown is now shown in the selection windows (like other manual fire weapons).
• Big Bertha now only fires into terrain when force-fired a the ground.
• Added Skuttle as an option for automatic unit marking.
• The Reset button on the ingame menu now resets hotkeys as well as settings.
• Reorganised the camera change settings for and de-duplication and clarity.
• Units built in a factory while under a cloaker no longer take 8 seconds to cloak.

[ 2025-04-12 15:18:18 CET ] [ Original post ]

Light units are great at absorbing large amounts of burst damage. A burst, i.e. a single high-damage shot, from a Heavy Laser Turret may evaporate a Flea, but at least it only kills one Flea. Recluse also dies in one shot, and costs ten times more, so Flea is a comparatively efficient absorber (or rather, waster) of burst damage. High burst and wasted damage is used throughout Zero-K, in part to fill a gap left by our no-damage multiplier policy, but mostly to fulfil a desire for big impactful weapons.
Burst is nothing new, since reload time is fundamental to RTS, and most games have at least some variety. Discussions in Zero-K also use "alpha" as a synonym for burst, which a quick search suggests may be due to early cross pollination from Eve Online. In terms of balance, there is a tradeoff between burst and sustained damage (DPS), as burst tends to make a unit more powerful, with the large caveat of wasting damage to overkill. Burst lets units front-load damage, since they start the battle fresh, which increases their effective damage output and limits retaliation. In terms of the feel of the game, large units one-shotting smaller ones reinforces a sense of scale, and the potential for burst adds variety and excitement to battles. Zero-K likes to explore the extremes of design space, so we have ended up with some quite bursty units. Lance fires once every 23 seconds, significantly more than the six second fire rate of its ancestor in Total Annihilation. Such a long reload time would not be out of place on a manual ability in other games, and Zero-K players often use these weapons as manual abilities. This is done by toggling the hold fire unit state, which lets players take direct control when required, without fighting the UI the rest of the time. Units exist across a range of reload times, with units even as low as 10 seconds frequently being set to hold fire to snipe commanders.
As alluded to earlier, burst can be used to specialise weaponry against heavy units. Raiders swarming a Heavy Laser Turret is the classic example, but this applies whenever a projectile from a heavy tank or artillery piece would deal far more damage than necessary. Conversely, riot units should have low reload times, to deal with swarms of units. Raider against raider is an interesting case, since a bit of burst is quite an advantage, but one that can vary a lot across matchups. The bursty light raiders - Duck and Dagger - have been particularly hard to balance, and are yet to find a really good spot. The problem is not even due to raw overkill, but rather, the more subtle issue of breakpoints. Burst damage is important even when it is not dispatching foes in one shot. Consider Dagger, a light raider that deals 110 damage every 2.83 seconds. Light raiders have between 200 and 500 health, so the exact damage of Dagger compared to the health of any given raider can be quite important. For example Bandit has 340 health and Glaive has 230 health, letting Dagger kill them in four and three shots respectively. If, for some reason, Bandit needed a nerf against Dagger specifically, we could reduce Bandit health to 330. This would barely affect its other matchups, but would effectively reduce its "health" against Dagger by 25%. Alternatively, we could increase Dagger damage to 114. The current incarnation of Dagger has dealt as little as 95 damage, but no higher than 110, because we do not want to cross the Bandit burst threshold. Some weapons are so impactful, so ubiquitous, that they warp the rest of the game around them. The prime example is Raven, a bomber with an 800 damage bomb. Bombers shoot one shot before returning to base to reload, so their burst is very important. Raven was the dominant bomber for over a decade, so units lived or died on their interaction with it. The lightest riot unit - Reaver - has 820 health because being sniped by a single Raven leaves its factory too vulnerable to raider follow-up. Mace, which costs nearly twice as much as Reaver, has been plagued by only having 1400 health, and Light Laser Turrets have 785 health to let Ravens clear them out. The Recon Commander Chassis has 3250 base health, because commanders were balanced around how expensive they were to bomb. Factories have 4000 health because it is assumed that a nearby constructor can repair them mid-bombing, allowing them to just barely survive five Ravens.
Other sources of burst damage are important, but not as impactful. Lance deals 3000 damage with its heavy laser, further preventing commander health from dropping below 3000. Similarly, Phantom, a cloaked sniper, deals 1500 damage. Phantom demonstrates how balancing around breakpoints can become a bit silly, since Felon was buffed to 1600 health specifically to avoid being one-shot by Phantom. The Felon is the signature Shieldbot unit, and costs almost as much as a Phantom, the signature Cloakbot unit, so losing it in one shot was too punishing. Tuning Felon health to Phantom burst let us make a change that barely affected other matchups, since dealing an extra 100 damage is not too onerous for most other units. So burst is a good tool for precision-balance, however, overuse can make interactions feel gamey, less "natural". Imagine a Felon with 1501 health. At a mechanical level, such a unit is fine, but it would look odd whenever it survived a Phantom shot with one hit point. The injunction against Felon having 1501 health is akin to the verisimilitude principle from Aim and Fire, namely, that a "real" Phantom could surely "overclock" its rifle to eke out an extra 0.1% damage. So it is for this reason that we stick to reasonably round numbers for health and damage. A Felon with 1600 health looks more natural, even though 1501 health would achieve the same balance goal. There is a limit to how close damage can be to health, and that limit seems to be 20. Consider Reaver with its 820 health against Raven. Two other cases are evident in the precise light skirmishers: Moderator and Scalpel. These units deal busts of 460 and 660 damage respectively, and each have 20 more health than their burst. We decided, long ago, that having such units 1-shot each other was far too swingy, and that making units uniquely bad against themselves would encourage more interesting army compositions. Lance does not get the same treatment, since being unable to see as far as they can fire already creates enough counterplay, and artillery should be particularly flimsy.
Revenant vs. Engineer Commander is a notable recent example of balancing by burst breakpoints. Revenant is a tanky gunship that fires a burst of medium damage missiles, and it was a bit underpowered, so we gave it an extra missile. This increased its damage to 1980 (9 missiles, 220 damage each), which let it 2-shot un-upgraded 3800 health Engineers. This went unnoticed for many months, until Engineer gained the blueprint ability, increasing its popularity on the front lines, which in turn increased the viability of rushing a Revenant to snipe commanders. The resulting nerfs included reducing missile damage to 210, for total burst of 1890, leaving Revenant 20 damage shy of 2-shotting Engineers. Burst creates a threshold effect for health and damage, but it also creates thresholds for time. This is best seen with anti-air and bombers, since bombers only stay in range for a handful of seconds. The result is a sensitive relationship between the reload time of anti-air, and how long the planes hang around in range. A weapon can be good on paper, but be underwhelming in practice if targets tend to leave range just before it reloads. Burst also helps specialise anti-air into anti-plane and anti-gunship. Anti-plane weapons tend to be bursty missiles, with high alpha damage to deal their damage early, while anti-gunships weapons are geared towards high damage-per-second, since gunships hang around to deal their damage, and are likely to kill bursty anti-air before they get off their second or third shots.
Balancing by burst breakpoints runs the risk of filling the game with opaque and unintuitive interactions, much like an overreliance on armour classes can in other games. No player is going to know, without any experience or research, that Revenant can only 3-shot Engineer Commanders. Repeat for the 25-or-so units with reload times greater than five seconds, and there is a potential memorisation problem. Many of these units deal imprecise area-of-effect damage, which fuzzes the breakpoints, while others deal such large bursts that their damage may as well be infinite in most cases. For the rest, there is a part of the interface that shows the combined burst damage of the selected units. This also helps people who happen to have individual burst damages memorised. Even weapons with nominally precise burst damage are slightly fuzzy in practise. Projectiles can miss, and burst lasers deal damage over the 30 game frames that make up a second. This adds an asterisk to the relationship between Flea and Heavy Laser Turrets (as well as Lance and Grizzly), as a few tightly packed units can all die to the same laser shot. This anti-swarm capability is not ideal for Quant's Rule, but physical beams of death are far cooler, and lets players pull off tricks such as lining up two light turrets to kill in one shot. It would be easier, and more "balanced", to have lasers deal a single instance of damage, but, in the end, feel trumps balance. Index of Cold Takes

[ 2025-03-29 22:35:20 CET ] [ Original post ]

Zero-K technically has "space" combat. This is true of any game where units can end up high in the sky, and where being very high up has any mechanical meaning. In our case, extreme height makes units immune to weapon fire from below. Even missiles with cylindrical range have a fuel limit that gives them a maximum reach. As a result, advances in space travel tend to be patched out, which is notable because we generally err on the side of keeping creative special tactics in the game. But over time, the "Zero-K cannot into space" rule has emerged as a result of space travel being so non-interactive. Viewing space alongside the ground also causes interface issues. Complete Annihilation saw our only fully intentional foray into space. This was the original Owl, a spy satellite (probably) added by CarRepairer. [quote]This stealthy orb can serve as a spotter for your artillery or spy on an opponent's base. It uses a lot of energy to stay in the air but is safe from nearly all units. Vulnerable to advanced fighter planes and long range missile towers.[/quote]It flew 5x higher than the highest aircraft (Nimbus), moved slower than the slowest ground unit (Jugglenaut), and had a tiny 300 elmo sight range. It cost 300 metal at a Core Gunship Plant and, as per the description, could only be shot down by the heaviest ground-based anti-air and air superiority fighters. In other words, this unit only interacted with Artemis and the missile-based Raptor equivalent of the day.
Owl did not last, and became the namesake of the term "To Owl" something. It was nerfed to the point of uselessness because the main balance designers didn't have the heart to remove it, but could see how troublesome it would be if it were at all common. If the enemy had a Plane Factory, then it is just dead, but without access to planes it required very expensive anti-air to dislodge. The hard-counters were too hard and too expensive, while there were zero soft counters. So it was soft-removed, and did not survive the transition to Zero-K. The reception of Owl set the pattern of subsequent space exploration, and the lack of direct support fostered creativity. People would have to repurpose units to achieve their space dreams, with the main culprits being the gravity shenanigans of Newton, Lobster, and Placeholder. Each of these units has been patched to curtail space travel, although Newton has received the most attention, as the oldest of the three.
Newton is a turret that uses gravity guns to attract or repel targets. Units are allowed to aim and fire at anything, provided there is some reason they would want to, so Newton can target allied units. People quickly realised that Newtons could fire units across the map, with terraformed ramps to help aim and angle the shots. These Newton Cannons were the first form of "space" travel, yet they still exist today, which seems at odds with the injunctions above. What makes the current uses of Newton "legitimate", and what else had to be patched out? Space is a problem when it dominates entire parts of the game, with little or no counterplay. Newton cannons sometimes win games, but they are hardly a source of cheap, unblockable, death from above. Most Newton cannons launch jumpjet units, but these can be seen as they float down, and shot down in the sky or intercepted. It is a fine back-pocket strategy, but can be countered without too much more investment than it costs. It is also quite important that the units barely go to space, i.e., they can be seen at a comfortable zoom level. The worst cases of space travel let units fly so high that the map is merely a tiny square in the distance.
The first dominant Newton cannon strategy was due to Skuttle, which is a troublesome unit that can cloak, jump, and explode for massive damage. The first issue (mentioned last year) was that it used to be able to jump from space to float down, cloaked, onto the enemy base. The only theoretical counter was to hover gunships above everything important, and station overwhelming firepower nearby to kill the Skuttle in the brief proximity decloak window. So we invented jumplegs to stop Skuttle jumping while mid-air. But this did not stop people raining cloaked death from above. The next issue with Skuttle turned out to be a broader issue with gunships. A gunship can be pushed by Newtons, but cannot crash, which makes it great for safe space travel. A transport with a Skuttle could be shot high into the sky, beyond the range of anti-air, and flown over the enemy base. Then the Skuttle could be dropped onto important targets below, cloaking on the way down. This prompted a few changes. The first was a general nerf to gravity guns such that only 25% of the vertical component of their force applies to gunships. The second was a targeted nerf for transports, namely that they accelerate downwards towards their desired height faster (a buff in any other situation), and they give units a small random push when dropped, to remove the precision of orbital drops.
Gunships can cause issues without the help of Skuttle. After high-flying gunships were blocked, people began experimenting with horizontal "space". Newton cannons can be designed to shoot gunships sideways off the map, beyond the range of ground anti-air. This let transports and Krows sneak around to the back of the enemy base without having to penetrate front line defenses. The tactic has far more counterplay than orbital Skuttle, but by this point out-of-bounds tactics were established as an exception to the usual protection of creativity. So we put a stop to gunship slingshots by pushing aircraft back into the map, with a buffer zone of 400 elmos, which is approximately the turning circle of the most cumbersome aircraft. Planes could be launched off the map too, and the buffer even had to be halved with the more recent addition of Odin. Another borderline, yet still ultimately removed, tactic was the Flea launcher. Fleas are cheap and very light, which makes them cheap to launch with a basic Newton cannon. The issue here was that sight ranges are cylindrical, or 2D, by default, which made Flea launchers dominate other lategame scouting options. We were happy with the spread and effectiveness of other, more nuanced, forms of scouting, so the Flea launcher was nerfed. The nerf involved dynamically reducing the sight range of launched units, to approximate a form of 3D sight range (the actual shape is a cone twice as high as the sight range). Players are still free to scout by shooting Fleas at fast, low, trajectories, but this requires a much more expensive Newton cannon.
What of Lobster and Placeholder? Both units used to be able to create self-powering floating space stations, arbitrarily high in the sky. Lobster achieved this by continually firing a large enough clump of Lobsters, since it used to be able to shoot while mid-air. Placeholder can target allies, and tends to lift its target slightly above the ground. Enough Placeholders can form a self-sustaining clump that gradually drifts upwards. The major issue here is that disappearing into the sky makes defeat almost impossible, and Zero-K prides itself on having a better draw situation than Chess. Sky bases are also good places to give ballistic weapons a height advantage, although this is a cool ability, provided it does not become unreasonable. Space Lobstervator and Placestation were removed on the same day, shortly after Lobster's defeat-avoiding ability was showcased. The fix in both cases was to make the abilities of Placeholder and Lobster decay with height. Lobster cannot boost anything more than 400 elmos above the height of the target terrain, and since then lost the ability to fire while mid-air. A Placeholder shot exploding more than 1200 elmos above the ground has no effect. This happens to be the altitude of the old Owl, although the ramp down to 1200 means that in practice the mass will float around 1000 elmos up. So units can still be maintained quite high in the sky, just not arbitrarily high.
The last, and silliest, way to go to space is due to Dirtbag. The idea is as follows: Dirtbags drop a bit of terrain when they die, so why not stack 500 or so on a single position, then detonate them? The result is a very thin, very tall, spike. This became a problem when people figured out how to glitch Crabs up this spike, which let them shoot at absurd ranges due to their ballistic trajectory. This sort of thing is a neat creative way to create instant spires for Crabs, but the spires could be so high that the rest of the map becomes a few distant pixels. We patched this out by limiting the steepness of terrain created by Dirtbags. Such spires are now limited to 800 elmos, which is still significant, but do not turn Crabs into full-map artillery. That is it for ways to go to space, apart from simple bugs, such as a bug that let players store impulse and release it all at once. That is also about it for creative tactics that have been patched out, since by and large we try to keep them in, with Newton cannons being a prime example. Space is the main exception, since it is too far removed from the terrain and interactions that make Zero-K great. The same can be said of underground units, but since that was only an ability for one chicken, I would not expect an article on mobile burrowing any time soon. Index of Cold Takes

[ 2025-03-08 23:04:16 CET ] [ Original post ]

Strategy games sometimes offer extra ways to detect the enemy, beyond the standard line of sight, with radar being a classic example found in Zero-K. Radar reveals quite a bit about player interaction, but we will also have to flesh out vision itself, since the two systems complement each other. Both systems use the same underlying mechanics, which were covered last time, although the details are not strictly necessary for understanding how the mechanics are used.
Radar is great because it achieves a lot in the design, yet is mechanically just a variant of sight. In Zero-K radar differs from sight in one way: it only reveals the approximate position of units, nothing else. The type of unit is not even revealed, although this information is remembered for previously scouted "radar dots" (to avoid fighting the UI). In terms of how the mechanics are used, the two systems could not be more different: everything has a sight range, while only a few specialist units and structures have radar. Radar can also "see" a lot further, with most radar ranges being around five times that of the average sight range. The main purpose of radar is to allow for direct interaction outside combat. By direct interaction I mean interaction with a tight feedback loop, where you and an opponent can see and respond to each other in real time. Sight alone limits players to relatively short-range interactions, which are likely to turn into fights. Various forms of dedicated scouting can allow for more out-of-combat interaction, but that risks making information too cheap. Radar admits a middle ground, one where you can respond to large scale army movements, without being overwhelmed by information or cheapening the fog of war. Of course, if you know where the enemy is, then you should be able to shoot at them (again, to avoid fighting the UI), but to expand upon the implications of then we need to take a detour into sight.
The details of sight boil down to the following question: how far should units be able to see? Our answer is, for the most part, "Just a bit further than they can shoot". This is a deliberate reversal of the situation in many other games inspired by Total Annihilation, but the idea was that it is more satisfying to fight visible units than radar dots. A more thorough justification is that vision on the enemy is tactically powerful, and that scout units mostly gate such vision behind fiddliness rather than any significant tactical or strategic decision making. This stems from the fact that scouts are cheap, can see further than the average combat unit can fire, and are fast enough for death to be a Fighting The UI problem. Mixing scouts into an army is often just optimal, since it lets everything see their targets, but giving this job to scouts mostly amounts to giving them an extra way to be stupid. So to skip this whole rigmarole, we just let units see as far as they can shoot. A notable exception to the above is artillery. Scouting targets for artillery is satisfying, as the scout has to be sent somewhere dangerous. To support this dynamic, artillery cannot see as far as it can shoot. In fact, we have a general rule that units can see 10% further than they can shoot, to a maximum of 660 range, which is is around the range of a Heavy Laser Turret. However, there are many exceptions to this rule. Some are due to technical necessity, such as the granularity of the vision grid requiring that particularly short-ranged units see a bit further. Other exceptions are deliberate design choices, such as the uniquely long sight ranges of Radar Towers, Owl, and Toad. Others, well, unarmed structures have a sight range of 273 for reasons lost to time, and the sight range of unarmed constructors appears to be essentially random.
By this point artillery seems to have two conflicting constraints: that we want to encourage spotting, and that units should be able to fire at radar dots. The solution, revealed paragraphs ago, is to make radar only reveal the approximate position of units. This is implemented via "radar wobble" - a drifting random offset of the radar dot relative to the unit's true position. Wobble discourages pot shots at dots, since they are likely to miss, so spotters have to venture out to gain vision. Radar wobble brings its own problems though, which we try to mitigate with various UI features. The main one is that radar wobble is removed for scouted structures, since structures cannot move. There is also a state toggle to tell particularly precise artillery to avoid firing at wobbly dots, although it is not enabled by default, for reasons that would require a whole extra article. What about saturation artillery? A few artillery units are far too inaccurate to care about radar wobble. In this case, shooting at radar dots is a feature. An astute reader may recall a principle that comes up in the design of cloaking, namely that it is frustrating to spend all your time telling unit to shoot at unseen enemies that you know to be present. The same issue arises with area-denial artillery, and is mostly solved by shooting at radar dots, because doing so simulates players making guesses about likely targets just outside their vision. Situations without radar, or with jammed radar, can counter this ability, but this is acceptable because the goal is to make units handle themselves in the majority of cases, just enough to alleviate the repetitiveness of always handling saturation artillery targeting manually.
By this point, it is clear that radar is central to Zero-K, and we encourage this further by making radar very cheap. Not only do commanders have free onboard radar, but the basic Radar Tower almost free. This is a great example of balancing relative to how common a unit should be, rather than by absolute usefulness. Radar Towers also perform double duty as artillery spotters, with an unusually large sight range, which incentivises players to place flimsy structures in outrageous locations, which makes for great target practice. Advanced Radar Towers have even more sight, and 250% the radar range to boot, but cost a considerable amount of metal. This makes Advanced Radar much less common, but their utility lies in viewing the enemy base, which we are less interested in encouraging. Advanced Radar also used to reduce radar wobble, however this reduces the importance of spotting for artillery, so the ability was removed. The most incongruent part of radar is the fact that radar dots have team colour. This leaks information to the enemy, yet team games rest on the idea that ownership within a team has no mechanical importance. This means that, if you know that the orange opponent has heavy tanks, then a slow orange dot is more likely to be a tank. Supreme Commander solves this with grey unidentified radar dots, and there was talk of adding such a thing to Zero-K, but I have been coming around to the idea that perhaps team colours on radar dots improves the game. At least in casual team games.
Team coloured radar dots efficiently tell your team how many opponents are present on each front, and it adds to the community feel to see who you are up against. It helps distinguish the aircraft of enemy air players, although in this case the vertical position of the dot is often sufficient. The principled stance against coloured radar dots would also advocate for removing enemy team colour entirely, turning the opposing team into an anonymous blob, which certainly feels bad for a somewhat social game. In any case, I would like to experiment with truly unidentified radar dots, but I fear the effect might be too far-reaching to measure in a short-term test. In any case, such tests will have to be postponed until the engine supports such a feature. Index of Cold Takes

[ 2025-02-16 00:07:23 CET ] [ Original post ]

Welcome back to Cold Takes for 2025. The goal this year is to post one every three weeks, but to not fight for space with patch notes. Just about every real time strategy game has fog of war. Without it, you could watch the enemy base and start countering anything they do. This dynamic can work - there are whole genres built around perfect information - but it seems ill-suited for games with incremental real-time decisions that take time to pay off. But before delving into the role of vision, it is worth taking a look at how it works.
Fog of war can be dead simple. All you need to do is draw a circle around each unit and structure, then declare everything within a circle to be visible. Plenty of games stop there, but I suspect the majority take the extra step of considering terraces and trees. A terrace sight system has clearly defined levels of terrain, with units on lower levels unable to see onto higher ones, and games often block sight with opaque static features, such as trees and buildings. And such simplicity works great, up until the simulationists get involved. Games of the TA lineage are more simulationist than your Starcrafts or Command and Conquers. That is, they care more about mechanics that match reality, or at least seem to match reality. Zero-K often downplays this aspect, but it is still a bit too simulationist to use a terrace-and-tree sight system. For one thing, we care too much about terrain to approximate the expressiveness of hills and mountains by a series of plateaus with ramps between them. This makes the simulationist route attractive, but it is hard to know where to stop without clear guidance from other design goals.
Before thinking about those goals, it is instructive to consider what fully realistic sight looks like. Such a system would involve drawing straight lines between the "eye" of each unit, and everything the unit might want to see. If the line has a clear unobstructed path, then the unit can see the target, and we can even draw lines to the edges of units to see them when they poke around corners. This is a general technique called ray tracing, and it reflects how light behaves in the real world. But would such a system work for Zero-K, what does the rest of the design have to say about it? To cut the chase, we will appeal to fight your opponent, not the UI. In short, the interface is your friend, it should not get in the way, and it should tell you everything you need to know about your forces. This includes information about what your forces can or cannot see. An interface that fulfils this promise has to be clear and simple, which is a problem for realistic sight. The crux of the matter is that you need to know what you don't know. Any old sight visualisation can tell you what you know you know. If you can see a giant robot peeking over a cliff, then the UI just has to draw the giant robot. But how do you rule out the existence of a sneaky medium-sized robot? The UI has to tell you whether you would be able to see one if it were present. The standard solution - spooky black fog - is a great representation of the unknown, but it breaks if you try to do too much with it. Fog is inherently fuzzy, so how is it going to tell you that you could spot a giant robot, but not a medium-sized one? Shifts in opacity are hard to make out to any degree of accuracy, and clearer cues such as contouring or colour coding would be quite busy. So Zero-K straight-up avoids having the visibility of a unit depend on its size.
Here is the trick to line of sight, used by many games: units never actually see each other, they only ever see parts of the terrain. The line of sight shader blurs this fact, but vision works on a grid, with the visibility of a square determined by ray traces to the middle of each square. The ray starts at the "eye" of each unit, so tall units are better at seeing over terrain, while the end hovers a fixed distance above the terrain (or the surface of the ocean). Units are visible if they are on visible terrain, which makes the potential visibility of enemy units very easy to tell the player. Zero-K sight is still a bit janky compared to simple terrace-and-tree. Smooth terrain makes it difficult to precisely predict what one of your own units will be able to see when it reaches a given location, but this is significantly better than not even knowing what it can see once it arrives. To ameliorate this further we tune the heights of the hover ray trace targets to be fairly forgiving, although in theory they represent the height of an "average" unit. So there you have it, sight detection in Zero-K is based on whether a unit of "average" height would be visible, because doing it this way allows for simple binary fog of war to tell the player everything they need to know. Except, this is only actually true for ground units. It is time to talk about the exceptions.
Projectiles, explosions, and non-landed aircraft ignore the usual sight rules, instead, using a circular sight system called air line of sight. This is a parallel sight system, but we make sure the air line of sight range of everything matches their standard line of sight range. The system is a nod to realism, since it lets you see planes without being able to see the terrain underneath. On the visuals side, it is nice to have projectiles not blip out of vision when they are fired over a ravine. Why not add air line of sight for particular giant robots? Consistency and clear thresholds; a plane is clearly a plane, but there is no clear cutoff between giant and non-giant robot. Except, that is not quite true either, as giant robots can often be seen by air line of sight. In fact, anything that has fired a weapon in the last few seconds is visible to air line of sight. This is sensible, since muzzle flares are hard to hide, but it also solves a few edge cases. Without this mechanic you would be able to position turrets behind tall cliffs, making them very hard to target, but still able to shoot at approaching units. As a bonus, a giant robot that spots your base over the edge of a cliff is likely to start shooting at you, so it is almost as if it were visible to air line of sight to begin with.
Sometimes I wonder how many people know about air line of sight. It is one of those mechanics that smooths things over in the background, making the game look good and make sense. Being unaware of it seems fine, and there is a cost to making it more visible. I know from experience that varying the opacity of fog does not look great, because air line of sight used to be drawn as a lighter form of fog. The engine default for air line of sight is 150% of sight range, but we override it to match sight range so that we can avoid needing to draw it (see above). I picked a map with good contrast for these images, but in general it is hard to make half-opacity fog of war sufficiently visible on all maps. Zero-K also has radar and sonar, but they are nothing new to someone who understands line of sight. Radar is just a form of sight, ray tracing to the same points hovering above the terrain, while sonar is a simple circular system. It turns out the engine developers did not want to implement a full acoustic wave propagation and detection system. That is it for sight. Why units would want to see each other will have to wait, but at least there is now a record of how. Index of Cold Takes

[ 2025-01-25 23:53:39 CET ] [ Original post ]

This patch has a slew of balance changes and a new game mode. Shieldball and Phoenix are the focus of the nerfs, but there are many more tweaks that ended up touching most of the factories. Some more notable ones are Bulkhead being worse at short range, and some cost reductions for the surface-only short-ranged ships. The new game mode is called Tech-K, and it is a look at what Zero-K might have looked like with tech levels. There are infinite tech levels, because anything else would be arbitrary, with each level doubling the cost of units while slightly-more-than-doubling their power. Feedback during testing ranged from "Works surprisingly well" to "Not what Zero-K is about", so give it a try. It could be fun to run it as a tournament or other event. Tech-K can be enabled in any game type via the Experimental tab in battle options, and more information is available on the wiki. The mode was partially created to motivate improvements to the dynamic unit attributes system, so there are API changes and extensions that mods will want to take into account.

Balance

Thug and personal commander shield offers more protection from area damage.

• Shield radius 80 -> 90

Felon is slower and less efficient.

• Speed 45 -> 42 elmo/s
• Reload time 0.133s -> 0.166s
• Shield drain per shot 75 -> 78

Aspis mobile shields are significantly more expensive (no change to Aegis).

• Cost 600 -> 700

Bulkhead has more downtime while being swarmed by raiders and assaults.

• Cost 230 -> 240
• Turret turn rate 180 -> 120 degrees/s
• Reduced targeting priority against gunships.

Magpie enjoys round numbers.

• Rearm time 13s -> 12s

Phoenix is more expensive and takes much longer to fire twice.

• Cost 460 -> 520
• Rearm time 13s -> 18s

Locust exploits its unenviable balance position to experiment with speed.

• Speed 212 -> 250 elmo/s

Nimbus can see as far as it can shoot.

• Sight range 600 -> 660

Mason gains a unique power among the cheap constructors.

• Build range 180 -> 210

Ripper should fare better against heavy raiders.

• Range 280 -> 290

Bolas is slightly faster.

• Speed 96 -> 97.5 elmo/s

Flail kills Magpie, Phoenix and Thunderbird in one fewer shots.

• Damage 375 -> 475

Kodachi is slightly slower.

• Speed 108 -> 106.5 elmo/s

Cyclops is harder to manoeuvre, as befits its weight.

• Turn rate 82 -> 74 degrees/s

Cutter is swarmier.

• Cost 65 -> 55

Corsair hopefully still has a counter from the Hovercraft Platform.

• Cost 240 -> 220

Reef repairs aircraft much faster than land-based airpads.

• Repair buildpower 2.5 -> 10

Hacksaw responds to a bit of power creep.

• Cost 220 -> 210

Wind Generators can be built diagonally with slightly larger gaps.

• Grid range 60 -> 63

Features

• Added the Tech-K game mode.
• Manually shared units now clear their command queues.
• Chainsaw no longer avoids small targets by default.
• Players can now define multiple albums adding war, peace, victory and defeat folders to sounds/music/(thanks Helwor).
• Increased the maximum configurable fade height for healthbars (thanks amnykon).
• Added an option to reduce the selection rank of rearming units (thanks amnykon).
• Added build range to space+click stats.
• Added units to buildpower in space+click stats.

Fixes

• Fixed playerlist lag indicator (thanks Shaman).
• Workaround jumping units sometimes moonwalking when they land.
• Fixed minimap mex drawing when flipping the camera (thanks christianweinz)
• Mitigate a playerlist error caused by the host of an AI leaving (thanks Shaman).
• Fixed non-default music album selection (thanks Helwor).
• Fixed Nimbus gun flare (thanks XNTEABDSC).
• Fixed Bulkhead sometimes being unable to deploy when slowed (thanks XNTEABDSC).
• Fixed the default position of replay controls on large monitors (thanks ThingsWillCalmUp).
• Fixed bad socket error handling in the lobby (thanks saurtron).

Modding

Reworked the application of dynamic attribute modifiers.

• Attributes are now added via Attributes.AddEffect(unitID, key, effect) and removed by GG.Attributes.RemoveEffect(unitID, key).
• Effects are tables of attribute types. See the list here.
• Many more types of attribute can be modified, and many edge cases have been cleaned up.
• Spring.Utilities.GetUnitCost now takes GG.att_CostMult into account.
• The old method involved editing extra attributes into the unit_attributes gadget. The old attribute are still collated by this gadget, but all the effects are applied by the new system.

Other changes.

• Added gadget:UnitCreatedByMechanic(unitID, parentID, mechanic, extraData). Other gadgets should do gadgetHandler:NotifyUnitCreatedByMechanic(same signature) shortly after creating a unit. This allows gadgets to handle things like the difference between morph unit creation, and carrier drones.
• Added LuaRules/Configs/ModCommands as a unified place for mods to define commands, rather than via editing tables across a handful of files. See Tech Up for an example.
• Model scale, centre offset, and tint now survive /luarules reload.
• Fixed bugs with Lance and Crab model rescaling.
• The error caused by invalid reload times is now more informative.
• The command-counting use of Spring.GetCommandQueue(unitID, 0) is going to be removed. Use Spring.GetUnitCommandCount(unitID) instead.

[ 2024-12-23 08:31:08 CET ] [ Original post ]

Zero-K pushes the limit of team games in RTS, supporting up to 16 players per side - something that sounds impossible. Your average RTS caps out at 4v4, with a few going as high as 6v6. In Zero-K players regularly play games three times this size, and while such large games are not for everyone, I suggest trying them out just for the experience. There is a real sense of scale in a game with so many players, taking so many actions, in which you can only really zoom in and understand a relatively small part. But it is surprising that such games work at all, so in this article we are going to dive into the design that makes them possible.
The weirdest part of the story is that, for the most part, support for large team games came about accidentally. The rest of the Zero-K design philosophy just happens to inherently let teams have a large number of players. From time to time we added features aimed at large games, but most of the work is done by principles covered in previous cold takes. We could have deliberately removed large teams, but the attempt would warp the rest of the design, and it is not like they are hurting other game modes. Small games, down to 1v1 and 2v2, work fine, and the way I see it, supporting more game modes is good. The bulk of the work is done by Fight your opponent, not the UI, plus the realisation that players coordinate with their team via the user interface. Essentially, cooperation within a team should be free of artificial limitations or hoops to jump through, in much the same way as any other action in the game. Zero-K contains simple examples of cooperation UI, such as the nuke indicator that tells players where an allied nuke is expected to land, but not fighting the UI goes deeper than that.
Zero-K is the game that designs the stupidity out of units and uses designs weapons using unattainable ideals, and we take the same approach to cooperation. Like units, players have abilities that influence the game, and we consider it a failure if the mechanics of the game force players down the route of boring and arduous use of the UI. So while most games would happily add a nuke indicator, few would go the extra step of excising fundamentally anti-cooperative mechanics to the extent that we do. We inherited key player abilities, namely the ability to freely share units and resources, from Total Annihilation. This is a fairly standard function for RTS games, but the implications are far-reaching, and Zero-K has a penchant for taking ideas to the extreme and biting the resulting bullets. The issue with sharing is that sharing UIs are invariably some of the worst found in RTS. They tend to resemble big spreadsheets of fiddly buttons or sliders, which is not what we want in an RTS. So contact with this UI should be minimised, which relegates sharing to an almost "theoretical" ability, one that the game is designed around, but which players should rarely manually invoke. This generalises to the principle of the irrelevance of ownership: [quote]Nothing in the mechanics of the game world is permitted to depend on the details of ownership within a team, because then players would be incentivised to touch the unit sharing UI to gain an advantage.[/quote] Few games use this principle, since it is automatically violated by player-specific upgrades. Even within the TA-lineage, Supreme Commander lets units of the same player shoot through each other, but not through allies. Even Zero-K violates the principle, since unidentified radar dots reveal team colour, which can let the enemy guess the identity of unseen units. This is something I have wanted to be able to turn off, but it requires engine work, and to walk back the extremism a bit, dot colour may well improve the game. The principle of irrelevance of ownership sounds restrictive, but it is also quite freeing, and we were not going to add global upgrades regardless. A key implication of the principle is that resource income can be distributed arbitrarily within a team, without any theoretical impact on in-world game balance. In practise this let us fiddle with income sharing to "simulate" cooperation among strangers on the internet, which is part of what allows such large team games to work. For example, income from metal extractors is shared evenly between everyone on the team, which was called communism mode in early Complete Annihilation. Communism evolved alongside the rest of the game, and quickly became integrated with overdrive, since the overdrive formula benefits from shared resources.
The theoretical justification for communism is that securing territory is a shared effort, and much harder than merely building a metal extractor, so the team shares the benefit. The practical justification was more important at the time though, since we all had experience with people arguing over metal spots in Balanced Annihilation, which could escalate to teamkilling. A secondary effect in BA was the limited map pool; players tended to play a small set of maps, where everyone understood the meta of spot ownership, in part to lessen the potential for arguments over resources. It is worth mentioning that I snuck an assumption into communism: that players want to cooperate. What if people want to keep their income to themselves? This gets at the core of the design: we assume that the team wants to cooperate, teamwork is the default. If players want to argue and destroy each other's buildings, then they might not find support for these actions in the UI. There is also a bit of a paradox here, as anyone who has played a team game with a range of skill levels can tell you: who owns what is actually very important. But instead of trying to judge the worth of each player, we opted to make a game where part of the skill is in being a good teammate, rather than rolling over the weaker members on your team as you grow your own personal empire. Communism solved the metal spot arguments and opened up the map pool, but it suffered from the free rider problem. Some players would skip building metal extractors all together, hoping that their teammates would pick up the slack. Full communism was also not great at incentivising overdrive, even when it would significantly benefit the team. So we added rebates. For example, metal extractors refund 80% of their cost to the player(s) that built them, over a few minutes, in the form of a slightly increased share of the income. Energy structures offer a similar refund of 60% from their increased metal overdrive income. The numbers have been tweaked over the years, since a higher payback percentage can lead to perceptions of selfishness by energy spammers. We even recently introduced payback for the first few Antinukes built by a team, as a social way to nerf nukes in low-cooperation situations.
Shared metal extractors also helped with the "Tabula Problem" caused by some rotationally symmetric maps. Tabula has high terrain on its North and South, that is easier to take and defend from the North-West and South-East respectively. Before communism, Tabula was typically won by the team that invaded the weak low ground from the strong high groud, before their opponent did the same on the other side of the map. The low ground just lacked the metal income required to mount a defense, without players manually sharing units or metal extractors. Tabula continued to play a bit like this since communism, the low ground still has poor terrain, but the extra income makes the defense fairer and more interesting. Income sharing alone is not enough to make large games fun. For that we need the rest of Zero-K, primarily its unit and faction design. Our large number of faction-like factories lets players carve out a distinct role and set of units within the team, and factory plop lets everyone build a factory without "wasting" resources. There was concern that the recent addition of factory plates would destroy this sense of having a role within a team, but the fear has not come to pass. If anything they seem to have improved team games by letting players take on a role they are not sure of, with the safety of being able to switch out of it cheaply.
The coordination feature that came closest to breaking the game was shared control mode, where players own and control the same set of units. The campaign has shared control, but it can also be enabled in team games via an invite system. The danger with shared unit control is that it can be powerful, but it is also quite annoying when someone else accidentally uses "your" units. This is the dreaded trade-off, power at the cost of fighting the UI, but the mode is barely used in public games. Tournament and campaign games are different, since people can communicate enough to avoid the downsides, and in these contexts it is a great feature. As with many automation-type features, it is worth asking whether cooperation has been automated away. I think we are fine on this front; teammates send messages, flank, and otherwise help each other out. People still share the occasional unit to augment fronts that really need it. Mostly we have removed the excess UI interactions, and set a baseline level of cooperation so players can expand as much as they want without worrying about "stealing" metal spots. Perhaps the greatest benefit is too the map pool, as any map can be played with any number of players, for a really wide range of experiences. This marks the end of the first series of cold takes. Twenty is a nice round number and it is time for a short break. Look forward to the next series starting in January next year. Index of Cold Takes

[ 2024-10-19 23:59:38 CET ] [ Original post ]

This week's cold take is early, unusual, and short because Ludum Dare is this weekend. Ludum Dare is a game jam: an event where individuals or teams of people make games in a short period of time. They tend to run for a few days to a whole week, depending on the jam, and teams are given a short prompt or "theme" to incorporate into the game. There are many game jams these days, I just do Ludum Dare for the schedule and because I like rating other peoples' at the end. Everyone with an interest in making games should give game jams a go. The actual event only takes a weekend, although a bit of upfront investment to find an appropriate engine goes a long way. The barrier to entry is fairly low, and I even think game jams are a great way to learn certain aspects of programming and design. A jam is a microcosm of project management, where choices made at the start of a project tend to come back to bite you at the end. This process is particularly instructive when there are only three days between the choices and their consequences. And by the end, you get a game out of it.
I especially recommend game jams to anyone working on a long-term game, such as Zero-K, because speedrunning the whole process can clarify your progress on the longer game. It also lets you experiment with new ideas and flex your creativity, which probably helps prevent feature creep. Besides, making games is a matter of practise, and as the Go master said to the game designer: "make your first fifty games quickly". I got involved in game jams through the Spring Cabal, a group of Spring developers that used Spring in several Ludum Dares between 2015 and 2018. The release pages for most of them were lost in the LD site rework, but builds can still be found in the organisation's GitHub repositories. Dominic (aka Shadowfury333) was also kind enough to document most of them on his YouTube channel.

• LD 32 - Gravitas
• LD 33 Warmup - Hunted
• LD 33 - Area 17
• LD 34 - FLove
• LD 35 - Parts Needed
• LD 43 - To The Last Drop

The only video missing is LD 42, My Cube, which I recall being a tower/unit defense style game about defending an iceberg. I only made it to a few of these weekends, so only worked on Hunted, Area 17, and To The Last Drop. The main organiser was gajop, and with the gradual disintegration of the Spring developer community, plus the difficulty of organising team across multiple timezones, we were less able to get teams together. I am really pleased with To The Last Drop. The theme was "Sacrifices Must Be Made", so we thought up the idea of defending a town using magic powered by the lives of the townsfolk. It turned out to be a game, with a beginning, middle, and end, which kills idle players, but otherwise let you play around with different approaches. The success of To The Last Drop is possibly why I went on to make ten more games with people I knew locally, solving the timezone problem and making the event more social. For these games, we used the 2D Lua game engine LVE, since I have a lot of Lua experience, and because 2D art is easier to produce. You can check out the games on my games page. We tend to make games that sit somewhere between puzzle and sandbox, which might be called problem-solving or "strategy" games. But we are also careful to give the games goals, and make the basic actions of the game inherently fun. You can see bits of Zero-K in many of them, in the way they are about mastering simple systems with emergent complexity. I think they are all quite solid, at least the "Post Jam" versions (make sure to click the right download), so my recommendations would depend on what you are looking for. Here are a few:

• Seeds of Civilisation is a bit like asteroids, but with planets and space police.
• Vivere Computatrum is a take on simple colony management, and even has a goal.
• Regular Railway is the most puzzle-like: Pipe Dream but Trains.
• Warp Trash Flotilla is absolute mayhem.
• Crocodial is about spinning a wheel of spells as fast as possible, but you are the wheel.
• Compact Domain is another puzzle game, this time pretending to be a city builder.
• Euclid's Elementals can be hard to get into, but the payoff is you get to feel like a wizard.
• To The Last Drop lets you be an "evil" wizard, and shows off what you can do with Spring.

Another common feature of our games is hard mode, since otherwise we risk subconsciously adjusting the difficulty upwards as we get better at the game. It also lets me play the game after the jam, just to push the systems to their limits and see what is possible. This approach is probably why we end up with open-ended problem-solving games rather than discrete single-solution puzzles: you can't really play your own puzzle games. Anyway, I hope this makes up for the lack of a more Zero-K-focused topic, and perhaps you end up having fun with a few games, or even have a go at game jamming.
Index of Cold Takes

[ 2024-10-04 15:46:03 CET ] [ Original post ]

The diversification of bombers over the past year has been great, but it also highlighted some problems with a few mobile anti-air units. This patch tries to carefully resolve these deficiencies, and to shift things slightly away from Phoenix and towards Magpie. The two bombers finally agree on rearm time. This update coincides with an AI update and the addition of around two dozen new maps. Try them out, perhaps against the new AI, and give feedback on your favourites. If instead you prefer 1v1, check out Fight Club later today (Saturday) at 1900 UTC, and on every first and third Saturday for the rest of the year.

Balance

Gremlin creeps back towards its old low price.

• Cost 130 -> 120

Tarantula contributes more to mixed anti-air defenses.

• Damage 260 -> 270

Flail hits sooner.

• Range 800 -> 820
• Missile spends 16.7% less time flying straight up.

Magpie is a bit cheaper to support.

• Rearm time 15s -> 13s

Phoenix takes noticeably longer to shoot twice.

• Rearm time 10s -> 13s

Maps

These maps have been added.

• Wanderlust 2.1
• Rustcrown Canyon 1.3
• The Rock Jungle 2.1
• Crystallized Plains 1.1
• Hide and Seek 2.2.3
• Hellas Basin v1.4
• Flats and Forests v2.2
• Aurelia v4
• Moonshine Run v1.0.1
• The Tartar Steppe v1.1
• Pinch Point 1.03
• Canis River v1.4
• Salt Reef 1.1
• Ancient Bastion Remake 0.5
• World In Flames v1.8
• Kings Assault v1.3
• Great Divide V1
• Sinkhole Network v1.1
• Scylla and Charybdis 1.1
• Tau12
• Crescent_Bay_V2
• Jade Empress 1.41
• Esker Creek 1.3
• Hades Ponds 1.1
• Isidis crack 1.1
• Feast of Hades 1.0.1
• Hera Planum 0.91
• The Ditch Remake 0.5

Features

• Updated the skirmish AI.
• Experiment with new lighting on some energy structures.
• Added focal depth hotkeys for the depth of field widget.
• Added team selection to the cheat sheet (top left with cheats enabled).
• The startbox editor can now apply box transforms and save them directly to files.

Fixes

• The skirmish AI no longer crashes if it somehow gains and then loses a factory plate.
• Minor fixes for French translations.
• Fixed some tips for planet Blackmire.
• Fix tiny movement stutter when line-moving over wreckage.
• Fix a graphs bug that would sometimes overcount army losses.
• Fix spec team change when selecting unseen enemies.
• Fix a rare teleport bug
• Fix (ie remove) fog effect on a few maps.
• Fixed structures with move commands giving up on them before finishing their morph.

[ 2024-09-21 08:40:26 CET ] [ Original post ]

Zero-K maps set surprisingly few hard restrictions on unit movement. Instead, many of them mainly use terrain to influence the value of locations, as well as how easy they are to reach and defend. There is also plenty of space for huge cliffs and vast seas, but what really sets our terrain apart is the subtle effect of each hill and valley. This is before even considering how explosions and terraforming change the terrain during the game. Terraforming elevates terrain, but it requires a strong foundation of important and nuanced terrain to make any sense. So for now it is time to look at how Zero-K uses terrain.
Maps can be decomposed into three main parts.

• Shape: How high the terrain is at each point on the map.
• Texture: The colour, reflectivity, and graphical roughness painted onto the terrain.
• Resources: The metal spots, geothermal vents, and reclaimable rocks and trees.

The shape defines how units interact with the map, while the resources provide overall strategic goals. Well-designed terrain also gives players instrumental goals, such as to hold an important hilltop. The texture is purely visual, but vital for making the map look good and be easy to understand. One of the more striking features of Zero-K terrain is how solid it is. Very little can pass through a wall of solid rock, but in most strategy games units are able to shoot through cliffs with ease. But beyond physical projectiles, there is also the sense that the three-dimensional shape of terrain really matters. Terrain in the average strategy game amounts to little more than a binary mask that neatly splits the map into walkable and non-walkable. A sense of height is often limited to layers of plateaus, with ramps between them, which may block sight or impose a penalty for shooting up to a higher level. Zero-K terrain is not divided into levels, it varies smoothly, and the penalties flow from natural features of terrain, such as hills being opaque and difficult to climb.
Weapons being blocked by terrain is so important that many are designed around whether they fire in an arc or need a direct line of fire. Lasers travel in straight lines, so are blocked by small hills, while a large mountain might block all but the highest-trajectory plasma cannons and missiles. This effectively gives us a dynamic and directional cover system, one which depends on understanding the shape of the map rather than a more gamey type of bonus. This form of cover gives shorter ranged armies ways to close in on their targets, for example, by walking in a ditch or hugging the lee of a cliff. Cresting hills and ramps is also really impactful, since units climbing a hill can only shoot at the other side once they reach the top. However, everything in the valley below can shoot as soon as a target appears against the horizon. This creates shifting asymmetries all over the map, resulting in a complex system of positional advantages.
Units at the top of a hill are quite exposed, but the upside is that they can see everything around them. Terrain blocks line of sight and radar, which makes high places ideal for scouts and radar towers. Ridges create radar shadows that allow for stealthy army movements until they are crested. Even units that can shoot over terrain will need something to spot targets on the other side. A seemingly empty hill may actually be home to a cloaked scout, spotting for artillery below. Hills are also a good place to put many units, since a common weapon type, the plasma cannon, has ballistic trajectory. This gives it a range bonus when shooting down and a penalty when shooting up. Lasers do not fare so well, since their spherical 3-dimensional range causes them to lose range while shooting up or down, while missile range is unaffected by height. This is important for deciding which units to use where. When attacking up a ramp you might want to use missiles, while attacking downwards is best done with plasma cannons, all else being equal.
Units suffer a speed penalty when climbing terrain, which makes hills even more attractive. This can be a doubled-edged sword, as retreating back up a hill after a downhill assault is also more difficult. In addition to the tactical uses, bumpy terrain also slows units down while moving around the map. Terrain can also form hard boundaries by having slopes that are too steep for units to climb. This depends on the slope tolerance of the unit: vehicles have low slope tolerance, bots (walking robots) have moderate slope tolerance, and spiders are able to climb everything. Slope tolerance is a hard threshold in an otherwise smooth system, which is a dangerous thing to expect players to handle. We only use two thresholds, one for bots and one for vehicles, to keep things simple. As far as I am aware these values are unchanged since Total Annihilation. Maintaining compatibility across maps is too important and any change would break a lot of maps. Mappers need to be careful to stay away from the slope tolerance thresholds, lest we end up with frustrating pathfinding on spotty or ambiguous ramps. These thresholds can cause trouble for highly realistic terrain, since walkability can be quite hard to parse. Ideally the map texture helps players understand the terrain, and avoid misleading them. Many maps navigate the pitfalls without issue, and they tend to use slope rockiness to delineate the slope thresholds.
One of my favourite things about our terrain is that it makes the whole map playable. Every minor bump is potentially relevant to how units behave, there are no purely aesthetic set pieces off in the distance, away from the game. For example, a craggy cliff has more surface area than a smooth cliff, so it takes longer for a spider to climb. If terrain looks different, it plays different. This lack of "pure asethetics" may be seen as limiting artistic freedom, but I see it as tying art and mechanics together in a way that benefits both. The precise cragginess of a cliff rarely matters, but when it does, it emphasizes the mapper's stylistic choices. It makes the map feel like a distinct landscape, rather than a mere picture of a landscape. The mountains in Zero-K are not just eye candy that units have to walk around; their shapes really matter when the artillery starts flying. The result of all this is that two maps can have a similar resource layout, be fully walkable by bots, and play completely differently. Many 1v1 maps fit this description, with the differences coming from how hills slow movement and block weapons as well as line of sight. The natural battle lines and strong points created by hills and valleys give each map a distinct feel. We have even considered a mapping contest based on a single resource layout, and with the restriction that bots must be able to walk everywhere. Vehicles are rarely able to drive everywhere on maps, since their slope tolerance is so low, but this in itself is an important part of giving the factories different roles.
Working through the implications of solid and nuanced terrain was a long process, with blocking weapon fire alone introducing many broken interactions. Not the fun type of "broken", such as putting Outlaws in holes, but uninteresting exploits such as making turrets effectively invulnerable from certain angles. It took a lot of attention to detail to sort out all the edge cases, and I have not heard of any for years, so perhaps we got them all. The process was greatly accelerated by terraforming, as a player with the ability to freely manipulate the map is nowhere near as benevolent as the original mapper. We get a lot more out of terrain manipulation, but that topic needs its own article. Index of Cold Takes

[ 2024-09-07 23:57:03 CET ] [ Original post ]

Cloaking is awesome. At least, some types of cloaking. Depending on who you ask. Let me start again. Cloaking is polarising. Some love it, some hate it, and being on the receiving end of an invisible strike can feel pretty terrible. To complicate things further, the specific mechanics of cloaking vary wildly between games. Sometimes cloaked units are near-immune to damage and can fight with impunity, while cloaking in another game might be dispelled by the slightest touch. But where it gets really interesting is how a single set of cloaking mechanics can be used in different ways, within the same game. Zero-K has a lot of cloaking, which equates to a lot of ways for it to go wrong. In addition to personal cloak, cloaking fields were added early in Complete Annihilation as a way to differentiate Arm from Core, and we have been nerfing them ever since. Over time, we started thinking about cloaking in terms of two distinct use cases.

• Tactical Cloak: The enemy knows where your units are, but has trouble engaging them.
• Strategic Cloak: The sneaky sort of cloak, where the enemy is unaware that you have units in the area.

Dark Templars from Starcraft are quintessential tactical cloakers. It is abundantly clear when a base is full of Dark Templars, from all the dead workers and sci-fi noises, but they cannot be fought without being revealed by a special detector-type unit. This example relies on Starcraft having very few ways to damage cloaked units (they even remain cloaked while fighting), but the concept of tactical cloaking applies across all games. Tactical cloaking in Zero-K, and many other games, depends on uncertainty in the precise location of a cloaked unit. Sure, units should shoot at "empty space" if they know a cloaked unit is there, but it does not take much uncertainty to make such a shot highly questionable.
It could even be argued that Starcraft lacks "true cloak" (if not for the fact that arguments about the "true" anything tend to be pointless), since units reveal themselves to the enemy with a faint shimmer (except for burrowed units), which probably helps cloak feel fair. Mechanics like these are unavailable to Zero-K though, since such a disconnect between player- and unit-knowledge is against the rest of the design. Fighting the UI thrives on situations where the player knows something, but is unable to convey this knowledge to their units. Cloak is relatively easy to dispel in Zero-K for this very reason, with the goal being that a unit should only stay cloaked when there is real uncertainty about its position. To start with, structures cannot cloak, since nobody wants to walk their units through how to shoot at a cloaked turret. Units also decloak when they fire, since the sudden appearance of a projectile is a dead giveaway, and when they take damage, since a projectile disappearing mid-air is also quite suspicious. There are non-suspicious ways to take damage, such as walking through fire, but they also decloak for consistency and to provide cloak with more counters.
Cloak is also pierced by straying too close to the enemy, with "close" being defined by the decloak range of the cloaked unit. This range is an important balance factor for personal cloak, with some personal decloak ranges being quite large. Other units have a consistent size-based decloak range, for when they enter a cloaking field, and cloak fields also apply this range to personal cloakers, if it is an improvement. Cloak field projectors cannot have their decloak range reduced, and mobile projectors have large decloak ranges to keep tactical cloaking in check. Proximity-based decloaking allows Zero-K to completely avoid passive long-ranged detection abilities. Active detection abilities exist, such as napalm missiles and Sparrow's reveal-on-death ability, but cloaked units are usually countered by a combination of base design and patrols of light units. We like the nuance involved in this system, it has more play in it than having units that passively negate all cloaking in an area. A lack of widespread detectors allows strategic cloaking to be more viable late into the game. This is surely the dream of everyone who hears about cloaking, they want to be James Bond; sneaking into the enemy base to blow it up. This is great, but Zero-K also wants to be a fun multiplayer game, and having your base blow up out of the blue is not great. So strategic cloaking is tuned mostly for hiding army movements within your base, and in no-mans-land. Still, infiltration is the dream, so it is always on the table. Our goal is just to make letting a cloaked army into your base feel like an avoidable mistake, and besides, Antinukes still provide sneaky infiltrators a way to blow up an entire base.
As with most definitions, there are edge case that fuzz the distinction between tactical and strategic cloaking. A cloaked army might start out with strategic cloak, turn tactical when they strike a target, then shift slowly back to strategic after the survivors disengage. Particularly popular uses of strategic cloaking can even take tactical aspects when become standard enough to anticipate. DotA's Smoke of Deceit is a great example of this, since it has a massive decloak radius, so is clearly meant as a strategic cloaking tool, yet skilled opponents will anticipate smokes and respond when they feel they are a strong possibility. Edge cases aside, what is the point of these categories? The point is that player feedback tends to revolve around adverse events, and events involving cloaking tend to cleanly fall into one of the two categories. Sorting feedback is great, but where categorisation really pay off is in how it informs the sort of balance change that might be required. A problem with strategic cloak suggests nerfs to speed or detection range, as with Conjurer after it gained a cloaking field. Problems with tactical cloak suggest nerfs to recloak time and the area that a cloaking field can cover.
As alluded to earlier, cloaking fields have been overwhelmingly nerfed since their debut. In part this will be down to them being figured out, but there was probably also an initial bias towards making them powerful. Units used to decloak for much less time when they took damage, and cloak fields have been steadily getting smaller. Structures used to be cloakable until we realised that cloak is boring or frustrating on most structures. Cloaking your Antinukes and Singularity Reactors is obviously good, but removes the whole point of these structures being juicy weak points. Tactical cloaking with cloaking fields has caused more problems than all other forms of cloaking. Personal cloaking is fine, since any issues with it are tied to individual units, and balancing units is relatively straightforward. Even the Phantom's ability to fire without decloaking has been balanced. Cloaking fields are a different beast though, since they give cloaking to everything, and our principles prevent us from carving out arbitrary exceptions. Skirmishers and artillery have been an issue, since cloaking them can make it too difficult to retaliate. To solve this we nerfed the recloak time for non-personal cloak to six seconds. This still lets armies make a cloaked surprise attack, but leaves the units decloaked as they fight. Bombs are the most exciting units to put under a cloaking field, and the trickiest to balance. We have tended to nerf the field projector itself, decreasing field radius and movement speed, while increasing decloak range. The aim is not to remove cloaked bombs, since that would remove the joy of figuring out a cool combo, then realising that it works. Rather, the goal is to give the defender something to do. This is part of making cloak feel fair; the interaction between attacker and defender should not end as soon as the cloaked units are revealed. In the case of bombs, finding and destroying the cloaking field is a consolation prize. This is part of what makes Skuttle so hard to balance compared to Widow: they work alone.
In addition to structures being uncloakable, cloaking is disabled in a few more cases. One is the fact that shield-projecting units cannot cloak. This is a unit intelligence thing; if you can see the shield, then you should be able to pinpoint the unit that is projecting it. Technically the shield could cloak too, but then projectiles would collide mid-air, or shields would have to pop into existence when the unit decloaked, which would look messy. Another exception is cloaking underwater; fully submerged units cannot cloak. This is mainly due to a lack of good ways to detect underwater units by conventional means, and because underwater units already require sonar to detect. The relationship between cloaking and sonar raises a good point; is cloaking just an extension of line of sight? Vision, radar, cloaking and sonar could be unified under the banner of How Not To Be Seen. In fact, most of what I have said about tactical and strategic cloaking could apply to line of sight and radar. There are times when a lack of vision makes it hard to fight, and other times when a lack of vision hides the fact that there is anything to fight. So there are parallels, but also many differences, the exploration of which will have to wait for a future article.

[ 2024-08-25 00:02:44 CET ] [ Original post ]

it is finally time to talk about weapons, starting with how they are fired. The weapon design space is huge, thanks to projectile physics, and we put it to good use. But such freedom is a double-edged sword, since much of the full design space contains frustrating or incomprehensible mechanics. There are interesting games in this space, but Zero-K is first and foremost a strategy game, which means it needs to be stable and predictable enough to reward planning. So, to combat the full freedom of physics, we installed a few guard rails around weapon design; a loose set of rules that, if followed, limit how badly a weapon can break the game. There are rules for many aspects of weapon design, but those around aiming and firing are some of the most important. The rules consider the following three aspects of our design goals.

• Intelligence - Aiming and firing are just abilities, and units should be good at using their abilities.
• Predictability - Players should be able to learn how units aim and what causes them to fire.
• Verisimilitude - Weapons should feel like they can be used in ways that make sense within the observable fiction of the game world, rather than just being a bundle of arbitrary mechanics.

As you might have guessed, projectile physics causes most of the conflicts between these goals. This specific set of problems is mostly limited to descendants of Total Annihilation, since projectiles have a minor role in other types of games. The standard RTS projectile is a animation and a short delay between firing and dealing damage, since they are guaranteed to hit their target, and only their target (unless something unusual happens, such as death or teleportation). This limits just how stupidly units might misuse a weapon, and it allows weapon fire to be quite predictable.
Total Annihilation probably used projectile physics to enhance verisimilitude, but I would disagree that this means other games inherently lack it. Every RTS simplifies many aspects of reality, and simplified projectiles are quite popular. How closely a simulation hews to reality is only loosely related to the experience of a reasonably consistent and believable game world. There are, of course, many players that seek out strict realism, but Zero-K does not simulate projectiles to be realistic. We use physics to make intricate, yet fundamentally simple, mechanics that reward intuition and creativity. But I digress, physics generally seems to cause problems for the goals above, rather than solve them. Physical projectiles are hard to use. You shoot at the enemy, but then the enemy moves and the projectile hits empty ground. So you shoot where the enemy is going to be, but they dodge the other way, or you miss due to innate weapon spread. Units do a decent job at leading their shots, but many still miss. This makes deciding when to shoot of utmost importance, but this decision has to be quick, which risks making it unpredictable.
To make matters worse, the sense of verisimilitude subscribed to by Zero-K says that, ideally, weapons only provide two in-world abilities:

• Change where the weapon is aiming.
• Fire the weapon.

In other words, we think of units as having the same basic abilities as a player in a first person shooter. In practice the implementation does not go that far, but we do at least let units blindly fire at the ground, since a cloaked bomb might be there. But even this limited ability means that, in theory, players could manually control every shot, which raises the spectre of fighting the UI. So units have to be smart enough for players to not need to resort to manual control. We could write some whizz-bang first person shooter-level AI, but then battles would amount to little more than watching units careen around the screen. This brings us back to predictability, so perhaps intelligence and predictability are fundamentally opposed. Worry not, the deadlock can be broken by imposing limitations upon weapons that are designed to make them simpler, so that units can be reasonably smart without breaking the "intelligence budget" of predictability. These limitations tend to be quite gamey, beyond the realm of pure physics, which causes trade-offs with verisimilitude.
Consider the ubiquitous range ring and its implications for homing missiles. A Fencer can only fire missiles at enemies within a circle around itself, but an enemy that dances just out of this circle will still be hit, which is a bit weird. What happens if we let just the goals argue it out?

Verisimilitude: That's ridiculous! The missile can demonstrably hit units beyond its arbitrary "range". Fencer should be firing in more situations, at everything that it can physically hit. Intelligence: Hmm... sounds exploitable, we don't want to fire at things barely within physical range. Borderline targets could (and should) just step back and let the missile run out of fuel before impact. Predictability: We could just only let missiles fire at structures, not units. Those are sure to stay still. Verisimilitude: That's super arbitrary! Intelligence: How about we use the target's max speed, accounting for slow and EMP, hill climbing, facing, angular velocity.... Performance: uhh... Predictability: And how is anyone meant to know which combination of factors will or will not result in a Fencer firing a missile?

At this point we might placate verisimilitude with some mumbling about "missile lock range", but background lore is no match for what players can observe ingame. Besides, we have many ballistic weapons that could also shoot a bit beyond their range ring, and this cannot be explained by any sort of "missile lock". So the the fact is that verisimilitude lost this battle, and the best we can do is make these situations as simple and consistent as possible.
The verisimilitude of Zero-K demands that units can do everything that they look like they are capable of, predictability demands whatever is simplest to communicate to players, and intelligence only cares that the resulting ability is hard to screw up. Designing a weapon with these constraints in mind looks a bit like this:

• Imagine the ideal form of the weapon, packed full of verisimilitude. A Glaive holds a gun in its hands. It can actuate its arms in any direction and pull the trigger at any time. It is a real robot.
• Next consider the proper use of the weapon. Should Glaives spend their time shooting wildly into the sky? Probably not, unless an enemy is flying overhead.
• Then impose as many behavioural or mechanical limitations as you like, provided that you only cull the stupid or pointless ways that the ideal weapon might have been used. These should help the unit avoid being stupid. Shooting into the sky is almost always pointless, so Glaives only do it when there is an enemy flying overhead.
• Finally, add a small set of standard limitations, such as range rings. Consistency is key here, since the goal is predictability, and arbitrary limitations hurt verisimilitude the most.

In practise, the process is not as simple as working through four steps. Most limitations affects all three aspects simultaneously, and sometimes you need to revise the ideal version of the weapon to make the downstream implementation workable. It is also possible to start at the implementation, then work backwards to figure out what sort of ideal weapon would result in it. One of the most important corollaries of the process is that weapon behaviour cannot depend on the existence of a target. This is known as the No Void Ray rule, as it was developed back when Starcraft 2 had a unit that gained damage the longer it fired. The unit was redesigned in the first expansion, probably because shooting your own stuff is allowed in Starcraft, but incentivising players to do it looked a bit silly. In any case, Void Ray would not even make it into Zero-K, since there would be nothing stopping it shooting into the sky when idle. Maintaining its damage bonus is smart, so we could not in good conscience prevent it from doing so. This would make the mechanic pointless, so we would avoid adding it in the first place.
The same rule applies to lock-on mechanics, or mechanics that penalise a unit for switching targets. A weapon shooting down a line of enemies should not care which unit is "aiming at", since it all involves aiming in the same direction. Any mechanical distinction would drag the interface abstraction of "targeting" into the realm of the game world. There should be no "best command" among those that cause the unit to aim and fire in the same direction. Commands are meant to help the player manipulate the game world, not be themselves be something that require optimisation. There are ways around the No Void Ray rule. For example, the weapon could apply an escalating status effect on the target that causes the target to take more damage from that type of weapon. This would look a bit like a Void Ray, and even solves the problem of charging by shooting at your own stuff. However, this particular mechanic would be discouraged by Physics vs. Formulas, but in general there are often ways to make a design work within the weapon design guidelines. Perhaps it is best to think of the weapon design rules as a set of guarantees, rather than a set of restrictions. Working within the rules keeps Zero-K consistent and delineates a relatively safe part of design space. These restrictions can aid creativity, and not only via the usual refrain, but because the safety guarantees free up brainpower that would otherwise be spent making sure that an idea does not completely break the game. For example, the rules inherently disallow designs that incentivises players to shoot at their own base. So the rules can be bent, but more care is required, because the rest of the game is built on their assumptions.
Anti-air weapons are the most blatant violators of idea that weapons can be fired in any direction. Being so blatant is great actually, since a large and well-defined exception feels much less arbitrary. Every weapon falls into one of the following categories.

• Weapons that can only shoot at aicraft. Units with these weapons have "Anti-Air" in their two-word role description.
• All other weapons. These weapons shoot at aircraft if they have a decent chance of hitting. Melee weapons can and do hit planes, when the wielder is thrown high enough.

We could have avoided creating the special Anti-Air category. One approach would be to make aircraft significantly slower or flimsier, to allow their best counters to be weak enough to hit ground as well. Unfortunately this would make air units more like ground units, or just weaker overall, violating Quant's Rule. We also considered giving anti-air weapons upwards-facing firing arcs, to allow them to shoot into the sky without hitting the ground. This has poor implications for predictability, as an inverted cone would give anti-air variable range depending on terrain and cruise altitude, as well as make for great artillery against cliffs. An inverted cone also just kick the can down the road, as it raises the question of why this amazing weapon cannot be built at an angle. None of the alternatives to Anti-Air were as good as defining a simple category that gives air the freedom to be powerful and different. That said, most games with air have Anti-Air, so perhaps the more interesting part of Zero-K is the lack of strict Anti-Ground. This choice is a type of design minimalism, we started with projectile physics and then added as few mechanics on top as seemed necessary. We could have widespread Anti-Ground, either as a targeting category, or just by making planes fly so fast and high that nothing but Anti-Air could hit them, but the game works fine as-is. Truth be told, ground units shooting at planes is a feature, not a bug. The goal is not realism, the goal is the feeling of a fairly consistent world, and we like the extra interactions between different parts of the game. In a sense we picked our flavour of verisimilitude because we like where we end up when taken to its logical conclusion. But now it feels like this article is about to fold back on on itself. Just remember, for future articles or discussion, that Zero-K units are generally allowed to aim their weapons and fire at whatever they want, provided they agree to avoid using this freedom to do anything too pointless or stupid.

[ 2024-08-11 00:20:44 CET ] [ Original post ]

This week we're back to Sprung's series on unit improvement mechanics missing from Zero-K. After Mighty Morphing, it's time to tackle veterancy. This one still exists, well, sort of. Already in Zero-K's oldest ancestor, Total Annihilation, units could gain veterancy via kills. The TA interface was fairly cryptic as to what exactly this meant: it provided no further information beyond adding the single word "Veteran" when mousing over units with at least 5 kills. Those of us who spent days shelling enemy bases with Big Berthas often noticed the improved accuracy. With a lot of effort it was possible to discover a minor increase in health as well. Frontline combat units were out of luck though, with veterancy being quite hard to obtain and having barely noticeable effects.
Zero-K is not constrained by the TA engine though, it runs on Spring (now Recoil), which expanded upon veterancy from early in its development. So by the time Complete Annihilation came around, veterancy did three things:

• Increase the health of the unit.
• Reduce the reload time of the unit's weapons.
• Reduce the inaccuracy of the unit's weapons.

Spring also moved to a fairer system of doling out experience: damage dealt is counted rather than kills, and the cost of the attacker and defender are taken into account. This means a cheap glass cannon like Glaive can rack up a lot of experience by shooting at a commander, while a Detriment can destroy whole armies without learning much. In a sense, veterancy depends on how well a unit is expected to do, given the resources invested into it. Higher veterancy units also gave out more veterancy when damaged, and the bonuses were applied smoothly with formulas rather than at set thresholds. Veterancy was more attainable and impactful, but this revealed problems. Consider increased health, at certain health thresholds a unit starts taking extra shots to kill. On its own this is fine: C&C games, where veterancy grants both health and damage, tend to make anti-infantry units such as Tanya deal either 90% or 110% of basic infantry's health in damage per shot, specifically so that it flips between taking 1 or 2 shots depending on the shooter's and/or the target's veterancy. One of the things that prevents such elegance in ZK is that the rock-paper-scissor relationships between units are not as sharply delimited or as closely followed. You can't have simple rules like "basic infantry with 2 chevrons can survive a commando hit" if there is neither basic infantry nor commandos, nor discrete chevrons for that matter. Role counter relationships such as raider (roughly corresponding to basic infantry) and riot (Tanya) exist, but there is massive variety within them. Players would have to learn and memorise a huge relational spreadsheet of how each of Zero-K's dozen raiders fares in a fight against any other raider at any given pair of ranks to stay competitive, not to mention all the other unit types.
Reload time caused even more trouble, since time is actually discrete. In layman's terms, this means that reload times have to be in steps of 0.033 seconds. Again, raiders tend to be affected by this the most, as their fast firing weapons don't have much wiggle room. Glaive has a reload time of 0.1s, which is three steps of 0.033. From there, you can only reduce it to two steps, which represents +50% more fire rate. This is too steep! Another effect is that some units with slow projectiles were designed to land their projectile just before their reload finishes. This is a crude form of overkill protection, since if the target is dead you don't need to shoot it twice. A slight improvement to reload meant the unit would waste the follow-up shot on a unit that was just about to die. Inaccuracy was usually the least problematic of the three, since most units tend to be perfectly accurate. But some are inaccurate on purpose, and a mandatory increase in accuracy would drastically redesign the unit on the fly, leaving you with something potentially useless for its original role. For example, an accurate Tremor fails to damage most of its usual area of effect, making it useless against cloak or wide terrain deformation. (As an aside, the original CA Tremor was just a tiny Disco Rave Party on wheels.)
Specific issues aside, all veterancy bonuses further reinforce snowballing in an already snowbally genre. Losing units makes your army weaker, but with veterancy it also makes the enemy army stronger. This necessitates some way to avoid even battles snowballing into victory after a few early pickoffs, either by diminishing the advantage or facilitating comebacks. C&C seems to achieve it largely by having units counter each other very hard, such that even elite units cannot hope to stand against their counter; there is also a cap on veterancy level so a unit cannot grow into infinity. Warcraft and DotA heroes give more experience and take longer to respawn when killed at a higher level, and each level is progressively harder to attain. Of course we could come up with a decent system, but is the extra complexity worth it? Besides, ZK already gives you a little extra for killing enemy units; but where other games do that via veterancy, ZK gives you wreckage to reclaim. This may not feel as cool as getting elite units, but it is such a deep and elegant mechanic we are quite happy with it.
Another reason to avoid veterancy bonuses is that simple stat bonuses affect formulas rather than physics. C&C again has a decent approach there: veteran units that reach the highest "elite" rank sometimes get an improvement in behaviour in addition to raw numerical stats. For example, heavy tanks get splash damage, or RA3 infantry gets immunity to dog stun. But at that point you become something more, a different unit in some ways, which should be reflected in its visuals. Rank icons, the way they are used in every other RTS, are way too salient for mere stats, and too un-salient for behaviour differences. The main hurdle here is that ZK artwork is essentially a loose bunch of assets collected from a wide gamut of volunteers over years, and there is simply no manpower for introducing such extras. Historically we actually had some models with a handful of progressively stronger looking variants, but that was just a drop in the ocean with barely any consistency. This is also one of the big reasons why we don't have research - a stronger unit needs to appear stronger visually as well, whether via research, veterancy, or any other mechanic. What you see is what you get.
Soon enough, stat gains from veterancy were removed, and technical capabilities were fairly low at the time so it wasn't really possible to implement things like weapon type changes. But veterancy is cool, we must have it! As hinted in the article on morphing, the solution was to let units with enough veterancy morph into whatever was a bit stronger and looked vaguely appropriate, and then sometimes not even that. Flea morphed into Glaive, sine they both lived in the "cloaky" factory at the time, i.e. Arm T1 KBot. Glaive morphed into Reaver, then Knight. Knight morphed into Crab, since Knight lived in the "spider" factory, Arm T2 KBot. This chain ended at Detriment. Many units could upgrade this way via veterancy, and many upgrade paths stayed well after factions were merged and factories shuffled. People loved this! The fantasy of a Flea evolving into Detriment seemed really cool. Unfortunately, it remained a fantasy. Sure, people could do it in games vs AI, and there is one known case in PvP where a top 10 player did it as a show-off when toying with a first-timer, but chain-morphing never really happened in competitive games. There were just a handful of viable morphs that people aimed for. But in addition to being slapped onto effectively random units without any prior design, there were all the problems of morphing, and veterancy made it extra bad because it was so reactive. When your Knights get countered by skirmishers, Crab is the perfect answer - but you cannot plan for your Knights to get enough veterancy. You can merely hope one of them randomly happens to survive in combat long enough, and great power swings should not come from such unreliable sources.
Ultimately, these veterancy-based morph options were removed as well. As a fun fact, this revealed a minor factory design problem, which led to the creation of Redback. Spider did not have the "DPS riot" role filled by any spider at the time, but Flea was so cheap that you could reliably get one to high enough rank to morph straight to Reaver by shooting anything for about two seconds. The hole in the lineup became evident after losing access to Reaver, so Redback was quickly thrown together to fill it. Modern ZK units still gain veterancy, represented by rank icons above them. Mechanically, it does absolutely nothing (beyond inspire modders). But getting icons makes players intuitively feel good and rewarded, so we keep it. Often though, players start to suspect that there isn't actually any benefit to veterancy, and they ask questions. Should I aim to gain veterancy? Should I protect my veterans? To which we say: yes! The effect of getting ranks is that your enemy no longer has the units you had to kill to get those ranks, and this is already something that directly helps your goals. Veterancy is also a nice way to explicitly gauge how well a unit is doing, though there is some bias against categories of units like artillery and superweapons that often shoot into the fog of war, since in order to prevent leaking information, only visible damage is counted.
The final clue to why we avoid rewarding veterancy can be seen by looking at high skill WC3 or DotA gameplay. And after all, what is levelling heroes if not an extreme case of veterancy? In both these games, you often want to kill your own units just to prevent the enemy from getting experience. In DotA the metagame is optimised so that each hero on the team gets the "correct" amount of experience (and gold, which comes from killing enemies as well so can also be considered a soft form of veterancy), with supports sometimes forgoing it in favour of cores. In ZK we anticipate problems and immediately bite whatever bullets may appear in the future. The powerful UI would allow you to squeeze quite a lot out of veterancy optimisations such as selective self-destruction to prevent enemy veterancy, and holding fire so that units with worse scaling don't "steal last hits" from the better ones. High skill ceiling? Definitely. Mostly obsoleted by automation? Maybe. Do we want to find out, and possibly lead players into the weeds of optimising this kind of engagement minutiae? Rather not. Index of Cold Takes

[ 2024-07-28 00:20:09 CET ] [ Original post ]

Revenant was brought back from the dead just over a year ago, but it lurked in the background until the appearance of combat engineers. Killing these newly-popular commanders in two shots let people really explore what Revenant could do, and most of it looked fine, so the Revenant nerfs focus on early game power. One thing that ended up not being fine was Revenant spires, so its missiles now explode after a short time rather than fall to the ground. With Revenant moving towards a healthy place, it is time to revive another tricky unit. Scallop is the candidate this time and it is a dangerous unit to buff, so the changes are aimed squarely at it being a better riot. It now 2-shots individual Ducks and can stand toe-to-toe with similar riots. On paper it is still worse than Reaver, but knowing Scallop it will break the game anyway, so look forward to it. The last release was a bit too recent for many features to roll in. A notable fix is for aircraft wing trails, and a notable feature is the random selection of custom music albums, as well as the ability to play mp3s.

Balance

Scallop is much better against Duck and can even fight Ripper and Reaver.

• Range 264 -> 285
• Aim speed increased by 50%
• Reload time 0.8s -> 0.96s
• Damage 23*9 -> 28*9
• Maximum burst increased by 21.7%, DPS increased by 0.7%
• Spray angle increased by 20%
• Area of effect 32 -> 64
• Reduced area of effect damage falloff

Revenant no longer overshoots and no longer 2-shots Engineer Commanders.

• Speed 135 -> 130.5
• Reload 9s -> 10s
• Damage 220 -> 210
• Missile burn time 5s -> 2.8s
• Missiles blow up when they run out of fuel

Features

• Increased Buoy and Bulkhead auto-float depth to match their requirements.
• Added overkill prevention for Scallop shotgun.
• Renamed Scallop Flechette to Heavy Shotgun to match other shotguns.
• Added an option to choose music albums randomly (thanks Helwor).
• Custom music tracks now can now be mp3s.
• Made Trinity reload time match its animation.
• Tweakdef errors now appear in the infolog.
• Applied forced 60 fps vsync for ATI compatibility, and renamed the vsync option.

Fixes

• Fixed giant Tank Foundry model radius, which could disrupt jumping units.
• Fixed aircraft wing trail emit points shifting around incorrectly based on unit velocity.
• Fixed spectator panel positions when they are loaded while not in full view mode (thanks Helwor).
• Fixed set AI start position game options.
• Fixed final value alignment in graphs that go negative.
• A few campaign fixes (A unit pic, Solar, and Brutal on Old Kam, thanks Mach565).

[ 2024-07-13 11:38:32 CET ] [ Original post ]

Every game has to start somehow, and strategy games start with players acting before they know what their opponent is up to. I call this phase the setup, and in it, players tend to build up their base and deploy some forces, all without any outside interference. To be clear, the setup is everything that happens before contact with the enemy, or in other words, before you can make decisions in response to your opponent. Under this definition, giving player a free scout can make the setup relatively short. Games with more of an economic focus tend to have relatively long buildup periods, but mitigate it with the aforementioned scout. Total Annihilation-style games are on the more economic end of the spectrum, but lack this mitigating factor. They start players with a lone slow commander, which often has to build up some economy before it can afford to make a factory and a scout. This makes for a long setup, which was disliked by the Complete Annihilation developers, so we set out to shorten it. Before looking at solutions, we should first dig into what we were trying to solve, and ideally tease out the problematic bits. We also need to know how to measure success, which motivates the following question: just how long is the setup in any given game? The answer is a bit fuzzy due to the nature of "outside interference". Consider a 1v1 in modern Zero-K, technically you could plop an Airplane Plant and immediately send a Swift across the map, all in about 20 seconds. Both sides now have a good idea of what the other is up to, so they have left the setup.
But hold up, what about when a Swift doesn't fly over your base 20 seconds into the game? In this case, your opponent did not plop air and yeet a Swift, which is technically information. So, have you left the setup? No, because I want to get more out of this definition than that. The key is that Airplane Plant into Swift reveal is a terrible opening, so almost nothing is learnt by not observing it. In general, negative observations should be treated in terms of degrees of certainty. Seeing nothing for 30 seconds is fairly normal, so reveals essentially nothing. Seeing nothing for three minutes is much more concerning, and might warrant some blind anti-cheese measures. Likewise, if people invariably put a turret in a particular position, then scouting that turret means nothing. In short, the setup is about as long as it takes to narrow down the other side's behaviour from "they could be doing almost anything". As for what people spend this phase doing, it boils down to the following.

• Deciding what they want to have at the end of the setup.
• Executing that decision as optimally as possible.

The execution part raises some red flags in the context of Zero-K design, since in the absence of an opponent, failures of execution are caused by fighting the UI. As an aside, this is why orders can be queued before the game, and why factories automatically play their unpacking animation. The time spent unpacking gives players a chance to click on their factory and tell it to build something, without worrying about wasted time. This analysis of the setup reveals an aspect that we wanted to retain: the decision making. Ideally these decisions embody strategy, creativity, and customisation, which are important to Zero-K. Being "natural" is also important, and a brief setup phase is much more organic than some sort of pregame force deployment menu. The fuzzy boundary between the setup and the rest of the game is also quite neat. So the goal was to shorten the setup without removing the decisions.
Our first solution was the Boost mechanic. Commanders were given a personal supply of resources that was spent at a high rate, represented as a depleting red ring. This let players quickly boost out a factory, a bit of economy, and a few units. It sped things up, but was too creative. Players would transport allied commander across the map to boost out turrets in the enemy base. Other strategies involved teaming up to boost out a sizeable army from a single factory, which was very effective against teams which had spent most of their boost on other things. Boost rushes hammered home something we already knew about team games: factories are a waste of resources. What are the chances that an eight-player team needs all eight factories, when there are only two or three natural fronts? Very low, but spending the whole game assisting an ally factory is boring, so very few people did it. It would happen in tournaments, or be "abused" by the occasional clan stack, but people in public games decried it as "cheap", and it got old quickly. The general principle here is that people will optimise the fun out of games. In response, games need to have fun solutions to their goals, to encourage people to play in fun ways. The goal of competitive RTS is to win, so good strategies should also be fun strategies. The standard TA approach of having each player spend their valuable initial resources on a factory, just to have fun, violates this quite badly, and boost made it worse. So we went back to the drawing board.
The boost rush cemented a new rule for design, that factory ownership is a requirement for fun, so our next experiment was to just give everyone a free factory. This turned out to be enough, and as such the "Facplop" coupon has existed unchanged for something like 16 years. It mostly solved the setup problem, although we also increased innate commander income. A bit over one mex and two solars "moved into" the commander over time, making it easier to use your factory from the very start of the game. Facplop did not completely kill assist rushes, as they would still crop up from time to time, but now in the form of players reclaiming their free factory. We could not just make factories cheaper, reducing the amount of metal from reclaim, because that would work counter to factories as factions. We were also unwilling to make the free factory unreclaimable, or to give it a reduced reclaim value, as that would be arbitrary. Thankfully, the new assist rushes tended to be just barely on the edge of viable. Nerfing them was mostly a matter of balance tweaks, and sometimes we could even just wait for a counter to be popularised. The new rushes were so much worse because reclaim costs buildpower, only yields metal. This meant that energy structures had to be built to spend the extra metal in a timely fashion, sapping the rush of most of its power. Only Paladin rush required a notable change, which is how the Strider Hub ended up with a grid requirement.
Looking back at our reasons for shortening the setup, I sometimes wonder whether we made it too short. We may have missed the utility in giving newer players more breathing room, or in enforcing a form of break between matchmaking games. I even find fun in the execution challenge of the first ten minutes of an Age of Empires game, although I would not want to grind it competitively. The overall trend in RTS seems to be agreeing with Zero-K, particularly with the way the buildup phase of Starcraft 2 was shortened over the course of its expansions. Perhaps it all goes back to respecting the players' time. If we assume Zero-K shortened its setup by one minute, which seems like an underestimate, then doing so has personally saved me four whole days. The savings must be immense over the whole community. Index of Cold Takes

[ 2024-06-30 01:23:16 CET ] [ Original post ]

Likho has a new model by brunocb, giving it a proper singularity bomb. This update also has many fixes and a few balance changes. Some of the fixes are due to an engine update, such as a decades-old bug that caused reverse-built units to sometimes try to slide off the map. On the balance front, Bulkhead now has a bit more range than Stinger, Duck is a bit better, and Disco Rave Party spins faster.

Balance

Duck is no longer the equal-slowest raider.

• Speed 90 -> 93 elmo/s (no longer matches Bandit)
• Missile range 235 -> 232 (matches Bandit)
• Missile turn rate increased by 16% so it reliably hits Dart.

Bulkhead is more sturdy and can safely shoot at Stinger.

• Stays deployed while mid-air
• Range 600 -> 640
• Sight range 660 -> 700

Crab and Bulkhead can deploy mid-air. Kodachi is killed in one fewer shots by Dagger.

• Health 680 -> 660

Disco Rave Party has all its bearings replaced.

• Base turn rate increased by 25%
• Maximum fire rate increased by 6.7%
• Spin-up rate increased by 18%
• Increased minimum turn rate by 25%
• Can turn without spinning down so far, as a result of the above.

Features

• Added new Likho model (thanks brunocb).
• Added optional radar colour in LOS and fog stripes, under Settings/Interface/Map/Radar Color.
• Added animation-stun to most striders. They no longer return to a netural stance while stunned.
• Guarding units can now be automatically set to lower selection rank under Settings/Interface/Selection/Filtering (thanks Amnykon).
• Improved overdrive payback tooltip.
• Added metal shared, energy excesses, and energy shared graphs.
• Mods can now include their own modoptions files.
• Reordering factory queues no longer forgets Alt-insert.
• Cloaked units no longer try to shoot at unseen mexes.
• Free-For-All games are now not counted for ranking immediately, rather than being discounted when the server restarts (thanks Shaman).

Fixes

• Fixed rally points of factories with structures right in front of them.
• Fixed overlob prevention vs. jumpjets.
• Fixed a shadow bug caused by UI scaling.
• Slowed Detriment can no longer be stolen by transports.
• Fixed defense range circles for ballistic projectiles (thanks Helwor).
• Fixed Djinn deployment when told to stop while stopping.
• Fixed being able to click twice to start a skirmish game.
• Fixed reverse-built nanoframes sometimes sliding off the map (thanks marcushutchings).
• Fixed queuing dense line moves (recent engine bug, thanks marcushutchings).
• Fixed structure ground decals persisting after death (recent engine bug, thanks marcushutchings).
• Fixed an issue with action registering (thanks Helwor).
• Made UnitLeftRadar more consistent (thanks Helwor).
• Terraform construction can no longer catch fire.
• East-facing morphs no longer result in West-facing units.
• Fixed lingering noammo icon on wreck tooltips.

[ 2024-06-15 06:16:03 CET ] [ Original post ]

Zero-K has nukes. This should come as no surprise, since otherwise the genre police would revoke our sci-fi license. Even a few fantasy games have nukes, but wherever they are found, they all work basically the same way:

• Climb to the upper reaches of the tech tree.
• Build a nuclear missile silo.
• Build a nuclear missile.
• Launch it at the enemy base.
• The enemy is now down one base.

Total Annihilation, a game not known for keeping things simple, spiced things up with anti-nuke missiles that shoot down incoming nukes. This means a well-prepared enemy might not lose their base. The same system can be found in every single descendant of TA, with many of them building on it and making it more complex. As you might expect by now, Zero-K went the other way, paring anti-nukes down to their simplest form. We still have recognisably TA-style nukes and anti-nukes, but they are no more complicated than is is required to produce great stategic nuke gameplay. Strategically, anti-nukes have one purpose: to be a weak point that the enemy can hit for massive damage. At least, this is what we decided back in Complete Annihilation, when we were looking for ways to encourage surgical strikes into the enemy base. Anti-nukes are the ultimate weak point, indeed, bases tend to blow up shortly after their anti-nuke is destroyed. The closest contender is the violently explosive Singularity Reactor, but it can often be built to the side to minimise friendly fire, and there is relatively little profit in destroying one once reclaim is taken into account. Anti-nukes are also particularly vulnerable to Widows and tactical EMP missiles, since a temporarily stunned anti-nuke can be just as bad as a dead one. Without nukes and anti-nukes, armies would have to slog through bases to destroy them, which would drag out won games, and give underdogs little opportunity to make a comeback.
Strategy aside, anti-nukes are also great for the Rule of Cool. Ironically, giving nukes a hardcounter lets them be much more powerful, and more common. This is great, since players seem to love nukes, but not so much when they bring games to an abrupt end. Zero-K might even have the largest nuke, since it has only grown since TA, but it is hard to compare across games with different scales. Our nukes are certainly large enough to destroy a whole base or front, and drastically alter the course of a battle. An unblockable and highly devastating nuke would essentially be a Wonder from Age of Empires; something that puts the game on a strict time limit, then declares a winner. This is fine, and the fireworks display is a nice addition, but it becomes unsatisfying if too many games end like this. Wonders and other unblockable superweapons are insufficiently interactive, so it feels unfair to lose to one, whereas nukes with a clear counter give the defender more agency. Many games with unblockable nukes, such as Starcraft and C&C, avoid the issue by making their nukes relatively unimpressive. Zero-K even provides a direct comparison of blockable and unblockable nukes, since its three "true" superweapons cannot be blocked. The cheapest of them costs 4x more than a nuclear silo, so they are reasonably rare, and can only ever appear late in the game. Still, the true superweapons are more controversial in the community and have been harder to balance, even though nukes appear much more frequently. The fairness inherent in being able to block nukes seems to be important.
As previously mentioned, Zero-K anti-nukes are just about as simple as possible. This is no great feat, since anti-nukes are fundamentally just a missile that shoots at another missile. The complexity of anti-nukes in other games tends to come from:

• Multiple types of nukes and anti-nuke, possibly varying slightly between factions.
• Mobile anti-nukes, commonly found on capital ships or as vulnerable utility vehicles.
• Stockpileable anti-nuke missiles that must be produced before the anti-nuke can fire.

Zero-K has none of this paraphernalia. We used to have all of it, but it was steadily removed for acting counter to the design goals, or just for adding complexity for little benefit. Mobile anti-nukes are near-impossible to disable, when properly defended, so had to be removed. Stockpiling anti-nuke missiles prevents boosting, which is a valid purpose (see Artemis), but it has severe downsides. There is nothing worse than thinking you have an anti-nuke, only to discover that you forgot to stock enough missiles. Getting nuked is already not the best experience, so the least we can do is make it feel as fair as possible. Zero-K has a single anti-nuke, and it takes the form of a dedicated structure. It is extremely atomic, and relatively expensive, tipping the balance in favour of offense over defense. A nuclear silo costs 8000, each missile costs 3240, and an anti-nuke costs 3000. Two anti-nukes only provide bare minimum coverage on large maps, so reliable coverage can cost more than the nuke it is meant to block. This is intentional, since offense should grow in power as the game progresses, and nukes need to be common to give bases weak points. At least anti-nukes block missiles flying through their coverage, because otherwise using circles to cover the backs of a rectangular map would cost far too much.
The simplicity of anti-nukes extends to their physics, which is on the gamey end of the spectrum. Anti-nuke missiles pierce absolutely everything; allies, enemies, terrain, because the stakes are so high. A system has to be reasonably predictable to feel fair, and the importance of fairness increases with the cost of failure. So if terrain blocked anti-nukes, then the game would have to make it absolutely clear when this can happen. But such a UI sounds hard and pointless, so instead we gave anti-nukes a flight path that will very rarely clip into terrain, and called it a day. But a more unusual aspect of anti-nukes is to do with what they can fire at. Anti-nukes cover a simple circular area, with the guarantee being that no nuke will land in or pass through this area (provided fewer than three nukes are launched simultaneously). But the "attack range" of an anti-nuke, i.e. how close a nuke needs to be for the anti-nuke to fire, extends beyond this circle, so that it can shoot at nukes before they land. This is weird when you think about it in terms of unit physics, since surely an anti-nuke could technically offer protection to targets on its flanks. Indeed, a more physicy anti-nuke could fire at all reachable nukes, but this would give it a weird effective coverage area that depend on the direction and pitch of incoming missiles, and even on the shape of nearby terrain. Communicating such coverage would be a UI nightmare, and inevitably be misunderstood, making interception feel like a roll of the dice.
If you want to get really pedantic, then, technically, blocking nukes in Zero-K is far from simple. This is because every unit can do it, and I have even seen the following used to intercept nukes:

• Dirtbag
• Jack
• Raven
• Athena
• Funnelweb

Nukes collide with bodies, so anything with a body can block them. However, they do not collide with allies, since blowing up your own base due to an errant bomber is infuriating, while blowing up the enemy base with a jumping Dirtbag is hilarious. Most units intercept nukes by jumping or flying over the silo right as it launches a missile. Funnelweb is a notable exception, since its shield has enough charge to block a nuke. At least, if by "block" you mean "blow up at a slightly different location". Shields only halt projectiles, they still explode, so area of effect damage is unaffected. This means that a Funnelweb can only ever block one nuke. Still, it is a desperate technique that can mitigate some damage, especially if the Funnelweb is high up or flung into the air.
But enough about anti-nukes, what about the nuke itself? There is much less to say here since they follow the basic nuke formula, and refinements were mostly implemented via the anti-nuke. Check out the Core nuke in BAR, it has the same damage and area of effect, so the common ancestor dates back to at least 2007. There have been a few changes though. The nuclear silo opening animation was changed in the mid 2010s to nerf Athena nuke interception. Previously, nuclear silos would open only when told to fire, which let a watchful enemy fly a cloaked Athena over the top to intercept it. This decloaked the Athena, so timing was important. Players countered this by manually priming their silos with the Wait command. So silos were changed to open as soon as they have a missile stockpiled, making them ready to fire immediately, which is just a case of removing a way for unit AI to be stupid. The flashing "Nuke Launched" indicator is another somewhat recent addition. This was more of an accessibility thing than anything else, because we had always balanced nukes around a globally audible launch sound. But not all sounds are heard, and it became a source of unfairness. The alternative was to remove the global aspect of the sound, but this would have removed my favourite part of nukes; the mind games. Nukes take a while to land, so armies can just about dodge them if they guess the impact site correctly. This creates a whole guessing game of large scale army movements, which can even be exploited or corralled by the team that launched the nuke. But why would people even launch nukes at armies? Because anti-nuke coverage is easier to pierce around the edges of enemy territory, so sometimes an army is the only available target. All the mechanics support each other.
By far the funniest, and possibly oldest, nuke change happened back in CA. Have you ever wondered why nukes look like a rocket, but launch at full speed with no acceleration? This is thanks to a developer called det, the namesake of the Detriment, who launched a nuke at his neighbour in a free-for-all on Azure Rampart. His neighbour had an anti-nuke which was, unfortunately, within attack range of det's nuke. This caused the anti-nuke to fire immediately, so it promptly flew over and blew up the nuke right on top of det's base. Nuke gained more launch speed as a result, although these days the "new" anti-nuke opening animation might have made the increased speed redundant. More units and mechanics were changed as a result of things that happened to det on Azure Rampart, but they will have to wait for future articles. Index of Cold Takes

[ 2024-06-02 01:25:37 CET ] [ Original post ]

Players coming from other strategy games often find classic conventions broken and common systems missing. The three focused on improving units - morphing, veterancy, and research - are largely absent from ZK. Today is the first of a series of guest articles by Sprung that will talk about them. First, let's talk about the unit improvement system that still exists vestigially in ZK: morphing. Morphing is often called upgrading, but I won't use that term to avoid confusion since it can also mean research. Very generally, morphing lets you improve or modify a single unit, as opposed to upgrading all existing and future units of that type, like research does. This can be as little as paying three seconds of time to deploy a Terran siege tank; or as drastic as changing two Protoss Templar into an Archon. Of course you can have morphing as a major part of faction identity and aesthetics, but let's talk gameplay. When to have morph instead of just letting players build things normally?
An easy answer is that sometimes you already decided not to let players build more of the unit. In ZK you only get one commander, and there's a limited number of geothermal spots. Accordingly, they are the only two cases where morphing is just a straightforward upgrade. The astute reader may have noticed that metal spots are also a limited resource, and indeed mexes used to morph into Moho mines for a short period before overdrive was instated. Here morphing lets you decide to get more mileage while working within the limit. A nice example from another game would be the Chinese Overlord tank from C&C Generals. It has a soft limit by virtue of simply being too expensive to field many of them, but you can add extra weaponry on top for even more firepower. Allocating skill points for WC3 heroes can also be thought of as a form of morphing, and it's no accident that allocating modules for ZK commanders looks so similar.
The flip side of a unit limit is flexibility. RTS is, among other things, about making the correct units to adjust to a quickly changing battlefield. The flexibility of morphing lets players continue making choices about their unit composition in face of a limit. Warcraft heroes, Generals Overlords, and ZK Commanders all present multiple morph choices for this reason. Similarly, in Dawn of War earlygame, forcing the player to choose between Flamers or Bolters for their first tactical marine squad, blindly, would not be good design. Morphing some marines to equip weapons lets players make that choice later, while still having a squad on the field to capture points, scout, and do other tasks that don't yet involve picking a specific unit composition. Then, when you scout Orks? Brother, get the Flamer. The Heavy Flamer. Back to ZK though, since we don't really put any pressure on the player in the form of unit limits, there is barely any need for the flexibility. Ramping economy means that even the most expensive units can become somewhat affordable over time, and by that point you have all the flexibility in the world anyway. Would it hurt to have a little extra? The problem with flexibility is that it creates a sort of Schrdinger's unit that occupies multiple spots in design space at once, to be resolved into one of them when observing the enemy. The danger ZK sees here is that a monospammed unit could become a composition thanks to its own flexible morphs. Everything becomes much simpler when you can do Just-In-Time reinforcements of the correct type without having to do lame nerd stuff like "logistics" or "foresight". No travel time from the factory. Less risk of overbuilding a variant. Of course these can be adjusted via other stats, but that would all come with a reduction in flexibility.
What about "inflexible" morphs, where there isn't really a composition to talk about and you just want to add more stats? Say, why doesn't a factory have a +10 Buildpower upgrade? It would be more atomic than a Caretaker, who can also do other tasks such as repair! Or, if I want to upgrade Felon battery recharge rate, I have to either get Convicts and have to pay for buildpower I didn't sign up for, or Thugs with inefficient guns thrown in. Meanwhile, a +15 shield regeneration morph would be atomic while remaining a choice! Part of the answer is that units are physical entities in the world and thus there is more interaction between them. In particular, Convict buildpower and Thug guns nudge the player into using them, which then cascades into the usual complexity of the game when the enemy has to respond in turn. The other part is emergence. Felon wasn't initially designed to work as a standalone unit and get "batteries" added; rather, it was designed to itself be added to a shieldball as a way to spend charge. Batteries are a player discovery, if an extremely obvious one.
An interesting feature of morph is that it provides its own buildpower and can have different tech requirements, which then can be used to adjust the appeal of different options. If you require a unit to be built "normally" then it competes for infrastructure (buildpower, logistics) with other units that you may rather be building. Morphing is a way to avoid this, which makes the unit more attractive, or the usual infrastructure less attractive. To put this in concrete terms: say you want to encourage mobile cloakers, because cloaking is cool. If you require people to build them from a cloaky factory, then sometimes they'd rather build a different factory as a secondary, or if they already have a cloaky factory, they'd rather build a different cloakybot. Morph lets a unit be its own little temporary factory, and the elegance of this is that much like energy requirements, it touches just the infrastructure and not the unit itself. The morphs for mobile cloaker and shield, while originally created just as a way to let them redeploy, fall under this category. We try to avoid this type of morph outside of utility units since infrastructure exists for a reason, and while it is easy to manage it should not be obsoleted.
At the beginning I mentioned Siege Mode as an example of morph. In ZK, a handful of units - for example Crab, Fencer and Emissary - have a soft siege mode where standing still gives them some sort of benefit. They deploy so fast that not doing so would mostly be a matter of not having the APM, so rather than make the players fight the UI by spamming Deploy every time they want to move, the units deploy on their own. To let this happen, there is a deliberate large gap in unit design space where nothing has a deployment mode that would be long enough not to automate, yet short enough to make you miss the automation by being commonly desirable. On the other side of this gap we have Desolator, which can deploy into an armoured form, but it takes long enough to make it a rare decision that can afford to be manual. Thus, unit intelligence, or rather avoiding situations that would create unit stupidity, is what prevents sufficiently cheap morphs from existing. A final way morph can be used is to randomly change a unit into a completely different unit, apparently for no good reason. Why does Lurker morph from Hydralisk? The answer seems less to do with any explicit unit design, and more with how it just had to be crammed somewhere given there were no empty slots on Larva build GUI. Hydra was the least awkward place to put it. Surely ZK would not do something as silly as, say, let Knight morph into Crab without an extraordinarily good reason, right?
...right? But that is a topic for another week. Index of Cold Takes

[ 2024-05-19 00:35:12 CET ] [ Original post ]

This is a small patch that was released to fix the settings deployment bug. A few other things we were working on made it in too.

• Fixed a recently introduced issue that caused particular settings to be overridden on launch.
• Units far from the epicentre of a Shockley impact are now stunned sooner, to match the explosion visual. Which units end up stunned is unchanged.
• Added a cracked ground impact scar for Quake.
• Fixed inverted track stretching for, eg, Paladin.
• Moving a block in a factory production queue no longer re-applies the multiplicative key modifiers.
• Fixed the commander selector ending up off the edge of the screen on particular scaling settings when shifting from windowed mode.
• Simplified window resolution switching code to try to make it more reliable.
• Fixed sun and water settings overrides being too persistent between maps.
• Fixed the sun on Tempest.
• Fix thumbnail and minimap images for maps containing unusual characters.
• Fixed a bug caused by map searches finding no maps.
• Fixed the player name tags widget possibly being assigned incorrectly.
• Tweaked the draw order of name tags, health bars, and overhead icons.

[ 2024-05-06 09:25:31 CET ] [ Original post ]

Zero-K units are generally quite simple, with many of them designed around a single weapon or ability. The idea is that the complexity of an army should come from how it combines unit types, rather than having any individual unit be particularly complicated. I call this the principle of atomic unit design, because it characterises units as the building blocks of armies, and simple units are, in a sense, indivisible. Simplicity is a good enough goal on its own, but atomic unit design also has an important role in fighting monospam. Monospam, i.e. spamming a single unit type, can be a contentious issue in RTS. Many players consider such a strategy "unfair" or "cheap", and games are often designed to discourage it, including Zero-K. This makes Zero-K a bit unusual within the Total Annihilation lineage, since TA had a bit of a reputation for monospam, and many successors dealt with it by culling the "excess" units. Zero-K went the other way, and found ways to balance a large unit roster without the resulting monospam. But before we get to that, we need to pin down what makes monospam powerful in the first place.
Monospam derives a lot of its power from being easy to manage. The logistics are simple. Just set your factory to repeat-build Scorchers, spam Ctrl+Z to keep them all selected, then repeatedly hit your opponent with them. The Scorchers move at the same speed and want to fight the same types of battles. But mix in more unit types, and it becomes much more complicated. Even maintaining the right mix is a challenge, since different units often die at different rates, and reinforcements take time to reach the fight. A mixed army that loses most of one type has to wait for the build ratios to be adjusted, while monospam can rely on a constant stream of appropriate reinforcements. To skew things further, mixed armies are as bad as their weakest unit across many attributes. For example, mixed armies move at the speed of their slowest unit, and are as vulnerable to attrition as their most fragile. Consider an army of tanky Minotaurs and glass cannon Ogres. Such an army is either going to lose a lot of Ogres, or it is going to avoid taking fights that Minotaurs would weather without hesitation. In many situations, half an army wants to fight while the other half wants to run away. None of this is an issue for an army of a single unit type, with uniform strengths and weaknesses. Essentially, most units synergise best with themselves. So, why do we want to discourage monospam? In short, because there is no crunch in easy decisions, and Zero-K is largely about deciding what to build and how to use it. This is much more involved when dealing with multiple unit types, both on your side and in the enemy army. And, as mentioned previously, the goal is mixed armies of combat units. Mixing battle tanks and anti-air is fine, but the tactical goals for such an army are often quite simple, depending on the type of enemy that is coming at you.
Now that we know what makes monospam powerful, how can we avoid it? The first principle is that mixed armies are 'allowed' to be much more powerful than monospam. My gut says 1.5-2x as powerful, but there is no definite value. The principle is great for guiding balance discussion though. For example, say we are thinking about how Rover might counter Fencer. Scorcher is a decent suggestion, but then some theorycrafter objects that Scorcher is solved by mixing in a few Rippers. At this point, we can invoke the principle, and say that Scorcher losing to a mix of units is fine. Forcing your opponent into a mixed army is half the battle, with the other half being to wait for them to succumb to the extra complexity. So we are free to focus on whether pure Scorcher beats pure Fencer. Likewise, the second principle for avoiding monospam is that everything needs a hardcounter. It is not enough for a unit to have bad matchups, it needs some absolutely terrible ones. This because straight-up cost-for-cost fights fail to take logistic and self-synergistic advantages into account, and such fights in a vacuum are an important part of judging counter relationships. So any unit that manages to not lose too badly against anything is a prime candidate for monospam. This is not to say that hardcounters have to feature prominently in how the game plays, they just have to be lurking in the background, threatening players with annihilation if they invest too much into one unit type.
This is where atomic unit design comes into play. A unit that does one thing well tends to have weaknesses everywhere else, so must rely on other units to cover those weaknesses. Atomic unit design is not a strict rule though, as it often fights the Rule of Cool. This is a hard fight, especially when big units are concerned, but we still try to keep the abilities of complicated units pointed towards the same purpose. Sea has struggled the most with the Rule of Cool, since ships want to have multiple weapons, and the disparate weapons of Siren are a remaining nod in that direction. The worst offender was Envoy, which used to have a depth charge that acted as inbuilt riot support against anything on or below the water. Factory abilities further dilute the idea of atomic unit design. If you count things like personal shields, jumpjets, and spider legs as abilities, then a lot of units have two abilities; one weapon and one utility ability appropriate to their factory. However, this extra complexity is well worth it, as having an ability in common strengthens the feel of factories as cohesive factions. The same could be said of, say, Zerg Burrow. Besides, a "faction ability", one shared by many units, has a much lower complexity penalty than an ability that arbitrarily exists for a single unit. Atomic unit design also applies to structures. For example, Complete Annihilation had a few types of metal extractor, including an armed metal extractor. This structure was not atomic since it had two distinct abilities, metal extraction and a laser turret, so it was removed in favour of the more interesting method of defending a metal extractor: just make a Lotus. This confers all the subtlety inherent in atomic units, A turret might be built forwards to better protect the mex, or in a more defensive position and use the mex as cover. A weak raiding party might have to choose between killing the turret or the extractor. Armed metal extractors provide none of these decisions, approaching one is the same every time, and a fight with one only has two possible outcomes.
Commanders, being the opposite of simple, are a constant thorn in the side of atomic unit design. They are upgraded a bit like a composition of units, with each module adding a single weapon or ability, but fight like a single unit. A high level commander is akin to a one-unit monospam, with all the logistic simplicity and self-synergy, so it needs strong counters. This is hard to square with the feel of commanders, but that deserves its own whole article. By now you might be wondering, is this all just Quant's Rule? Yes and no, I would say that the ideas are complementary. Atomic unit design is more of a goal than a method, while Quant's Rule is not so strict about how many strengths a unit can have. Quant's Rule guides us through day-to-day balance changes, while atomic unit design is more holistic. Waffling aside, it is mostly just useful to look at things from multiple directions, and it should not be surprising that many of the principles behind Zero-K lead to the same place. So stay tuned for the third I can't believe it's not Quant's Rule article, where I expect to cover Moonwells and the nature of greed. Index of Cold Takes

[ 2024-05-05 01:50:10 CET ] [ Original post ]

Most player actions in real time strategy boil down to giving commands. After all, these are games about telling units what to do. But there is a subtle difference between RTS and most other genres, in that players tend to act indirectly, by assigning goals to units. The game world itself is only ever affected by units as they try to achieve their goals. This takes a certain level of unit intelligence, and the stakes are high. The fantasy of commanding an army can be shattered by a single unit wandering off in a weird direction. Issuing commands also has to feel good, since it is your primary way of interacting with the game. This implies that common commands should be small and simple, like short words. In fact, commands can be thought of as the language used by players to tell their units what to do. This analogy turns unit control into a communication problem; how can the player communicate their grand plans to the fragile bundles of code that stand-in for the brains of their units? The units of Zero-K are relatively smart. Here are some examples.

• Units in almost all games know how to close range with the enemy, but Zero-K units also know how to step backwards when the enemy gets uncomfortably close.
• They can be told to hold their fire against cheap targets, and know how to stop short of firing enough missiles to kill something twice over.
• They can be told to repair or reclaim everything in an area, rather than requiring that the player point out each target individually.
• Some can be told to avoid wasting their precious reload time on wobbly radar dots, while others can be told to fire in the general direction of distant targets.
• Units even know how to spread themselves out along a line.

The examples above hardly seem earth-shattering, but that is by design. Zero-K units are only much smarter than average because they understand a wider range of commands. The more complicated behaviours, such as the ability to move away from enemies, are optional. Set a unit to hold position and avoid telling it to Attack Move, and it will stay put. This is vital because the principle fight your opponent, not over-automated ingrained unit behaviours is just as important as fight your opponent, not the UI. In short, Zero-K units are smart by virtue of their expanded command vocabulary, rather than by making decisions themselves. Units should not be making significant decisions, those are for the player to make, because otherwise we start diluting the "Strategy" in RTS. To this end, the complexity of each command has to be quite limited. Notice how the examples above were explained in about half a sentence? You have to be able to to describe your intention when giving commands, otherwise unit control becomes a process of clicking random buttons while hoping for a good result. So unit behaviours need to be predictable. For example, the "keep enemies at a distance" aspect of Attack Move only considers the closest enemy, since a whole-battle view would be too chaotic.
Commands are great, but how do they relate to the smartest unit in Zero-K? Well, players assign goals to units, which the units then try to execute. Achieving goals seems like a good measure of intelligence, so we can think of the smartest unit as the one that is the best at using its abilities to achieve goals. This includes goals that the player has trouble communicating due to a limited command vocabulary, so as to not give a free pass to abilities that are trapped behind poor UI. Also, since we are talking about game AI, it is more useful to think in terms of "least stupid", where stupidity is the misuse of an ability in pursuit of some goal. The stupidity formulation of smartness turns abilities into liabilities. For example, if you tell a unit to move East and it ends up walking West, then we would say it uses its movement stupidly. But if the unit has no legs, so fails to move at all, we can hardly blame its failure to achieve the goal on its inbuilt AI. Thus, the only units with "perfect" pathfinding are those with the inability to move. And being incapable of failing is almost like intelligence.
So there you have it. The smartest unit in Zero-K is the humble Storage. It has a single ability - to blow itself up - and it is very rarely a good idea. Consider some alternative candidates. Most energy structures have impressive explosions, so it is more conceivable that a player would want to give them some sort of Fire At Will stance. Solar Collectors are out due to the wealth of agency bestowed upon them by the ability to armour up. But perhaps you have a more normal, less technical, definition of unit. One that involves the ability to move. In that case, I might have to argue for Aspis, the mobile shield generator, for the title of smartest unit. But if you have alternative candidates, be sure to post them. So let's take stock of Aspis's abilities. Being unarmed is a good start, since deciding where and when to fire is a whole can of worms. Then there is the issue of pathfinding, which I could have avoided by nominating a plane or gunship. However, with great mobility comes great responsibility, so even Owls need to be pretty smart to not fly into an untimely end. No, a slow ground unit is safer, as its low speed makes it less responsible for its fate. And besides, the pathfinding in Zero-K is pretty good. Aspis can also charge its shield, float, morph, and self-destruct. Floating and morphing are niche options for Aspis, and self-destructing is very rarely good. That leaves charging, which can be toggled on or off, and is integrated into the priority system. So Aspis has a pretty good command vocabulary in this area. Remember, it is not on Aspis to optimise its energy drain for the overall economy, it just needs to have a rich set of ways for the player to tell it what to do. So Aspis is very good at using its abilities. Now, those of you with some shield experience might be wondering, what about shield link? Aspis can share its shield charge with nearby shields, and there are some well known ways to exploit this ability.
Aspis' bid for the title of smartest unit hinges on the fact that shield link is a passive ability. Think back to Storage, is it "smart" or "stupid" for blocking projectiles? No, being hit by projectiles is part of being a Storage, it is a passive rather than an active ability. So too with shield link. If two allied shields touch, they share charge. Nobody can control it, and this sort of thing is a powerful technique for making units seem smart. Simply avoid giving units opportunities to be stupid. Imagine if Aspis could control when to link, it would be an absolute AI nightmare. Linking is great when you need to pump charge into a Felon, but it can send a shield cluster below the threshold required to block tacnukes. The decision to link or not would take global information into account, and the best course of action would change too fast for players to manually control. A configurable linking stance would be unwieldy and riddled with edge cases, making it unpredictable. So it is better to keep linking innate, and let both sides of a battle work its straightforward behaviour into their plans.
Shield link is the highest-profile case of making an ability passive to avoid tricky optimisations, but we have many other more subtle ones. For example, Snitch and Imp have the ability to hide themselves by burrowing when stationary. If they took a significant amount of time to unburrow, then whether to burrow would be a decision with many strategic factors. Rather than make this decision, or make players manually press the burrow button, we made unburrowing near-instantaneous. Here are a few more examples.

• Bulkhead and Fencer pack up quickly for similar reasons.
• Units cannot hurt themselves with area of effect damage, as firing safely has tradeoffs.
• Vehicles are very bad at moving in reverse, so that they do not seriously consider doing it.

To sum up, unit intelligence has three parts; vocabulary, competence, and not expecting too much. Think about what is going on next time you encounter a stupid unit. Does it lack the command language to understand what you are trying to tell it, does it lack the competence to achieve the goal, or do its abilities mean it has to solve complex optimisation problems which lack a satisfactory answer? Index of Cold Takes

[ 2024-04-21 01:04:20 CET ] [ Original post ]

The most experimental change of this patch gives Engineer Commanders the ability to build units out in the field. The goal is to make it more than the base building chassis. A much more normal change accentuates the speed of Strike Commanders by reducing the speed of the competing Recon Commander. Planes have been tweaked slightly, with the most notable change being Sparrow stealing Owl's radar jammer. Disco Rave Party has some ludicrous buffs since the newish spin-up requirement had a greater than expected impact on its power relative to Zenith. For all its weird experiments, this patch is more about tech than balance. The engine has been updated with a new decal rendering system that performs better and will let us do more with explosion scars. Unit selections are drawn much faster and many of their edge cases have been solved. A new ambient occlusion shader gives the everything a bit more sense of depth. This is on top of a bunch of fixes and polish that built up over the last few months. No Cold Take this week, because there was a lot to do for the patch.

Balance

Engineer Commander can now pick a unit to build out in the field.

• Use the Copy Factory Blueprint command on a friendly functional factory to select a unit.
• The unit can be switched during the game.
• A unit is automatically selected from the plopped factory.
• Set your plop selection under Settings/Unit Behaviour/Default States/Misc/Blueprint.

Recon Commander is slower to let Strike have an identity as the speediest commander.

• Speed 43.5 -> 40.5 elmos/s
• Jump reload time 20 -> 22/22/20/20/18/16 s
• Jump speed 180 -> 135/135/142.5/150/157.5/165 elmos/s

Lightning Gun is better, particularly against swarms.

• Reload time 1.83 -> 1.73s

Owl no longer jams, by popular demand.

• Removed 700 range radar jammer.

Sparrow is now the radar jamming plane.

• Now has a 540 range radar jammer.
• Increased manoeuvrability slightly to make coverage more consistent.

Hacksaw deals more damage to catch up to Phoenix.

• Damage per volley 1000 -> 1400

Phoenix was a bit too good, especially when reused.

• Rearm time 8s -> 10s
• One-shot by Hacksaw as per above

Thunderbird has more health to escape Hacksaw.

• Health 1200 -> 1600

Disco Rave Party spins faster, also by popular demand.

• Increased spin cap by 50%, increasing its peak rate of fire from 1 to 1.5 shots/s.
• The spin bar has been rescaled so 66% is the old maximum.
• Spin up to 66% is unchanged. It still takes 90s to reach its old spin.
• Spin from 66% to 100% takes 40s.
• Aiming is quite slow above 66%, so a fixed target is required to exceed the old spin cap.

Disco Rave Party is also deals more direct damage and is more accurate.

• Accuracy improved by 20%
• Red Killer damage 3000 -> 3500 (matches Eos)
• Orange Roaster damage 300 -> 250
• Orange Roaster duration 15s -> 8s
• Orange Roaster AoE radius 320 -> 400 (larger than static shields)
• Yellow Slammer damage 800 -> 1000
• Green Stamper damage 400 -> 600
• Green Stamper smooth radius 240 -> 300
• Green Stamper smooths more per hit
• Violet Slugger damage 450 -> 500
• Violet Slugger slow damage 4500 -> 5000

Aircraft can no longer fly so far outside the map.

• The external map border starts 400 elmos away, down from 800 elmos.
• The border is softer, so brushing it is less drastic.

Graphics

• Added new explosion crater scars to use the engine's new decal system. The new scars have better performance, stick to the ground properly, and have new features such as glow and variation by weapon type.
• Added a screen space ambient occlusion widget. Basically, it adds subtle shading to put shadows in every nook and cranny. The widget is enabled for hardware that supports deferred rendering, which is most hardware.
• Improved the walk animations of the Engineer and Recon Commanders.
• Disco Rave Party has firing dust and complains every time it tries to turn.
• Improved the look of Ogre missile explosions.
• Fixed jittery Detriment launch smoke.
• Improved Detriment and Jugglenaut stomp effects.
• Made a few effects that were simulation-limited run at >30Hz if able.
• Reaver aims more smoothly.

Interface

• Updated selection circle rendering (thanks moreginger, and Beherith for the original shader). Selections look similar, but render much faster and resolve a few graphical edge cases suffered by the previous widget. Selection visuals can be configured under Settings/Interface/Selection/Default Selections.
• Jumpleg units retain jump commands while midair so they can jump as soon as they find the ground.
• Hermit auto skirmishes from slightly further away, making it better at dealing with Redback (thanks Mach565).
• Improved replay controls (thanks moreginger).
• Improved Athena and Newton selection volumes.
• Control groups now obey selection rank.
• Added an option for control groups to ignore some ranks.
• Autogroups can now be used for buildings.
• Autogroups no longer override manual groups set during production.
• Added incomplete French and Ukrainian translations.

Maps

• Added lava to Stronghold because it looks like it wants it.
• Added boxes for Ravaged Remake v1.2

Awards

Some awards show up almost every game in nonsensical ways. To address this, the minimum threshold for a few awards has been raised.

• Spoils of War requires 3.3x more reclaim.
• Slow King requires 2x more slow damage.
• Peacemaker requires 4x more disarm damage.

Modding

• Add customParams.turn_accel_factor to control the angular inertia of units.
• Add Spring.Utilities.ConcatArrays to concatenate arrays.

Fixes

• Fixed split switching spectators to players in the split room.
• Fixed load order of replays so the most recent replays show up first.
• Fixed Bellicose Islands boxes (edge gap east).
• Fixed a rare issue with the external map grid (thanks AntlerForce).
• Fixed Newton launcher auto-jump sometimes causing jumps on the launch pad.
• Fixed Envoy overkill prevention.
• Fixed command insert not working with line formations.
• Fixed jumping units sometimes using their walk animation mid-air.
• Fixed shields sometimes not activating when rapidly thrown out of the water.
• Units no longer move to clear the "entrance" of plane factories when a plane is built.
• Units that start retreating are no longer automatically deselected for spectators.
• Fixed the select damaged/healthy hotkey presets.
• Fixed Fire Once leaving Set Target applied.
• Fixed Restore not working correctly on random maps and maps with changed water level.
• Fixed Sparrow's wingtip ribbons.
• Fixed teleportation sometimes leaving tracks.
• Fixed slow and Stardust heat rounding.
• Fixed missing ghosts for some campaign-only structures.
• Fixed orbital drops of ships trying to land ships on the sea floor.

[ 2024-04-06 14:57:36 CET ] [ Original post ]

Why does Zero-K have energy? The previous article stopped just short of asking this question, but it is well worth asking. Continuing on, everything costs equal amounts of metal and energy, so it would seem simple enough to drop energy from the equation. Doing so would certainly make the economy smoother. Look at the Command and Conquer franchise, it seems to do just fine with one resource. But hold on, that is not quite right, since C&C has another resource, power, which plays much the same role as energy in Zero-K. Both resources are used to control the pace of escalation in their respective games. Energy in Zero-K is like houses in Age of Empires, or Supply Depots in Starcraft. Fundamentally, these resources act as an expandable limit on some other aspect of the game, while being fairly unlimited themselves. The big difference is that houses limit the size of your army, while energy limits your rate of production. But we can call them both supply resources, and the effect of such a reason is to make it more expensive to build something for the first time, since infrastructure is needed to support it. Or to give it a more positive spin, supply provides a discount for rebuilding something up to its previous size. Many resources fit the supply mould once you see the pattern. Consuming supply is generally a good thing, as units would prefer to do so than cost an equivalent amount of resources. Consider the Supply Depots in Starcraft, which cost 100 minerals and produce 8 supply. Now consider two variations on the Marine, if we ignore things like build times and hard supply caps, which is more powerful?

• The original Marine that costs 50 minerals and 1 supply.
• A modified Marine that costs 25 minerals and 3 supply.

A point of supply costs 12.5 minerals, so the converted cost of each Marine is 62.5 minerals. Notably, the full price only has to be paid to expand your army beyond its previous size. If your army dies, then you only need to pay the base minerals cost to rebuild. The modified Marine much cheaper in this case, so it would usually be considered more powerful. Of course, factors such as the army cap and the build time of Supply Depots would make the original Marine better in some cases, but the general point holds. This is what it means for supply to act as a discount on rebuilding.
The same supply dynamic happens Zero-K, just with production and energy, rather than armies and houses. Consider a bare bones economy, with just solar collectors and metal extractors (mexes). A mex makes +2 metal while a solar makes +2 energy. All construction costs the same amount of metal as energy, so every single bit of metal has to eventually be paired with the same amount of energy, if it is to be spent. This makes solar collectors act as a supply structure for mexes. Increasing your total metal income, for the first time, is more expensive than rebuilding after a raid. Supply, in any game, exists to slow players down as they try to blast through the early stages of the game. It stops aggressive Starcraft players executing unbeatable all-in rushes with unreasonably large armies, and it stops Zero-K players greedily grabbing every single metal spot in an expanding cloud of constructors. This is vital for a game with income so strongly tied to territory, since the openings of such games can devolve into an all-out land grab. Overly explosive expansion runs the risk of determining the winner via early economic superiority, which feels bad and makes it hard to reach the midgame. Mexes have had their cost adjusted over the years with this balance in mind.
Metal extractors were quite cheap in Complete Annihilation, costing as little as 50 metal, but their cost rose to 75 fairly early on. Mex cost peaked at 90 metal in Zero-K and it has since dropped to 85. It takes approximately one solar, costing 70, to support a mex, so taking a new metal spot costs 155 in total, and 85 to rebuild, provided the solar is sitting safe in your base. It can be even cheaper though, as dead mexes leave 40% of their cost in wreckage, so rebuilding can only cost 51 metal. This might not seem like much, but a 100 metal discount on rebuilding adds up and stabilises the early game. Recovering from a raid would be much harder without this discount, however, reducing the cost of mexes to compensate would lead to explosive expansion. The game could probably be rebalanced with the discount removed, probably involving weaker raiders, but it would be a game of less back and forth, since losing a mex would be inherently more impactful. There are many ways to make a supply system. The most common implementation has you try to build a unit, hear a voice yell "Construct additional Pylons", and then has you sit on your hands until a pylon is built. Many people find this frustrating, and it looks a lot like fighting the UI, so Zero-K opts for a more forgiving approach. The main differences are:

• Energy and metal can be stockpiled.
• Energy is supply for the rate of production, not for the total amount you can produce.

Stockpiling lets you build up an energy buffer, and even if you run out, excess metal will be stored until the lack of energy is resolved. This would be like stunning units in Starcraft that exceed your current housing capacity, but still allowing them to be built. The basic properties of supply are still present, but overextending is not an immediate concern, which gives players more leeway. This is a bit of a double-edged sword though, since a blunt system is much easier to teach. Players are highly motivated to make a house when their entire production is being held for ransom. Storage makes it harder to correlate problems with their solutions, and people might even use their metal storage for long term storage, rather than as a temporary buffer. So there are legibility downsides to flexibility. C&C games may have found a good middle ground, since a lack of power shuts down your entire base, but it does not block structure production and can be mitigated immediately by selling a structure.
But wait, there's more! Energy powers cloak, charges shields, and lets constructors repair, just to name a few uses. This makes things a bit more complicated as, for example, cloaked units drain more energy while moving. But it still all adds up to some fuzzy concept of supply. A cloaked unit still has two costs; the price of the unit and the energy generators to cloak it. When it dies, you can rebuild it at a discount, or even use the freed up energy for something else. It is easy to get caught up in the theme, in how much sense it makes for cloaking and shields to require energy. But forget the theme for a moment and just consider how arbitrary this is. Costing supply is a good thing, it makes rebuilding the unit cheaper, and it seems weird to bestow this benefit on only a handful of units. To understand this, I must now reveal the full power of energy. the thing that supercharges its control of pacing and escalation; energy is expensive at the start of the game and becomes progressively cheaper. Do not be alarmed, the price of energy structures do not arbitrarily tick down over time. That sort of thing is so inelegant as to be near-nonexistent in RTS. Instead, energy becomes cheaper simply because more efficient structures are available later in the game. Players progress from solar panels to fusion generators, and sometimes even singularity reactors. Many games do this kind of thing; Total Annihilation did it with tech levels, but even that is insufficiently elegant. Zero-K just lets players build anything they want, and lets maths do the rest.
The trick is as follows: a 91% built fusion reactor produces zero energy, while the same value in solar collectors produces 26 energy, so the efficiency of fusion is balanced out by the time it takes to start generating energy. Solar production can outperform fusions for quite a while, with the duration depending on how rapidly they are built. This creates a breakpoint where you switch from solars to fusions based on how much income you can dedicate to energy production, and how much time you have for the efficiency to pay off. It is a fuzzier system than tech levels, which is how we like it, since it leaves more room for strategic judgement. Energy becoming cheaper flows onto everything that drains energy, effectively making them cheaper too. We use this deliberately to push units and mechanics away from the early game. Mostly this means allowing something to be so powerful that it would warp the early game, then adding energy drain to balance things out. Here are some examples:

• Cloak is best early on, when there is space to move around.
• Tough expensive units rely on repair, but can be hard to answer without a large enough force.
• Personal shields do not drain energy because Shieldbots do not need to be worse early.

Reclaim sort of fits the pattern since energy is required to spend the windfall, but this is forced by the rest of the economy rather than being a deliberate decision. Overdrive does not really fit, since it lets energy structures general metal, rather than using their energy as supply. In fact, the diminishing returns of overdrive counteract the cheapening of energy. I want to avoid the impression that energy is complicated. Many mechanics look complicated when analysed in detail, and while a lot of thought has gone into it, the goal is something that is intuitive and easy to use. Energy is basically supply, primarily for spending metal. Adding one solar per mex works quite well, and another good rule of thumb is to make 20% more energy than metal. Later on it is worth ramping up production to run overdrive, reclaim, and repair. Fusions are good at around 30 income, and singularity reactors are for when you feel extravagant. Energy can be managed quite easily.
Except... Recall how construction costs three resources, with the third resource being buildpower. It might warrant its own article, but in brief, buildpower is another form of supply. It just happens to be generated locally, rather than globally, and it cannot be stored. So it can be more complicated, but luckily it is also dead cheap. Increasing your metal income costs about 40 metal/income, and energy starts at 35 and can drop all the way to 18 with singularity reactors. Buildpower starts at 18 metal/buildpower, in the form of the static Caretaker, and mobile constructors cost around 24 metal/BP. This is on top of the fact that your commander and factory provide about 3x more buildpower than your base metal and energy income. So play loose with it, having far more buildpower than your income is fine. Just err on the side of mobile buildpower, so it can be sent out to expand, repair, and reclaim. The idea of supply can be taken even further. What is metal, if not a supply resource for the ability to construct in the first place? Every RTS can be boiled down a single "resource", time, however I am not going to go down that particular path to madness today. For those interested in doing so, ponder this: since constructors cannot build and move at the same time, does moving cost buildpower? If you would rather just spam singularity reactors, here is a bonus graph.
Index of Cold Takes

[ 2024-03-24 00:46:05 CET ] [ Original post ]

Zero-K uses a flow expenditure system, which is the system of choice for games of the Total Annihilation and Command and Conquer lineages. However, we break from the rest of the TA-like games by paying particular attention to making the economy flow smoothly, in stark contrast to the unforgiving economies that tend to define the subgenre. This is because Zero-K is about fighting the enemy, not about micromanaging your base, and it also demonstrates how flow economies are not necessarily daunting.
A flow expenditure system works as follows:

• The player issues a construction order, and the construction begins.
• Resources are spent over the course of construction, such that a task which is XX% complete has consumed XX% of its cost.
• If you run out of resources, then construction rates are reduced to balance your income with your expenditure.
• When construction progress hits 100%, the construction is complete.

For example, if you produce 16 metal/s (metal per second) but your total demand is 20 metal/s, then the each of your constructions builds at 80% (16/20) its maximum rate. Think of it like pouring water into a bucket. When the bucket is full, the construction is complete. Many games use an upfront payment system as it is the main alternative to flow expenditure. Examining it will reveal why Zero-K uses flow instead, so here is how upfront payment works:

• The player issues a construction order.
• The order is blocked if the player has insufficient resources to pay the full cost of the unit or building.
• Otherwise, the cost is deducted from storage, and a timer starts.
• When the timer finishes, the construction is complete.

Upfront payment is a very simple system, and there is strength in that, but using it well can be difficult and time consuming. As we saw in Making Metal, systems of simple discrete actions often end up being more complicated than systems that work more continuously. Mastering an economy is fundamentally about reducing downtime as any time your factories are not running is wasted time. Upfront payment gives players very few tools to do this, which leads to fights with the UI, and these fights can take over entire games. More specifically, to master an economy you want to keep your money low, and to do that without breaking your keyboard, you probably need command queues.
The saying "keep your money low" is good general RTS advice. The return on investment is so high in RTS, relative to the utility of waiting for more information, that stockpiling is rarely worthwhile. Investment could take the form of expanding your economy, defending it from attack, or attacking the enemy economy, it all helps. Sometimes stockpiling 100 metal to boost out a turret is warranted, but generally, to not spend resources is to fall behind. So how do the two expenditure systems compare? Well, flow expenditure makes having zero money easy, just make sure your demand exceeds your income. Upfront payment makes keeping your money low much more difficult. Approaching the ideal with upfront payment means watching your resources like a hawk, ready to pounce as soon as they hit the threshold required to buy something. This eats up a lot of attention and can even require training to truly master. Many games have production queues that let players queue up a list of things to be built, regardless of the spending system. Unfortunately, upfront payment queues leave a lot to be desired, as the standard implementation has you pay the full price just to queue a unit. A queued unit is making no progress towards being built, so this is just as bad as having the resources sit idle in storage. These queues are useful for freeing up attention, but they always come at the cost of efficiency, and long queues are terrible. Other upfront payment queues only spend the resources when the task hits the head of the queue, delaying it if there are insufficient resources. This is much more like a UI feature than an Ability, in the language of UI vs. Game World, since it simulates the player clicking the buy button when the threshold is reached. It also allows for infinitely looping queues, which removes a lot of busy work, but has some pretty dire side effects.
The issue with paying when a task hits the front of the queue is with low-money situations. Suppose you want to make an army of cheap infantry and expensive tanks. You queue a bunch of tanks and infantry, then go do something else, only to return to an army of only infantry. The tanks spent all their time blocked at the front of the queue, never reaching their cost threshold, since the cheap infantry would consume those resources first. Even worse, to build anything you now have to cancel all your queued infantry and let your resources stockpile. This is not entirely realistic though, since the only game I know of with this system Warlords Battlecry, and as a fantasy game it lacks tanks. Anyway, flow expenditure is great for queuing since construction rates fall uniformly in low-money situations, guaranteeing a mixed army of infantry and tanks. Flow also allows for infinitely looping queues, so your factories run themselves until you decide to change your army composition. This all begs the question, if flow spending is so great, why do so many games use upfront payment? Here is what I think.

• Flow is a bit more complicated than upfront payment, especially when it is not the expected default.
• Flow has a reputation for being a lot more complicated than upfront payment.
• Putting anything approaching optimality beyond the reach of most players is often the point.

Upfront payment is a quintessential "easy to learn, hard to master" system, since it makes you do everything manually. This is great for pro players pushing the limits of what is possible, and it also lets newer players slowly build their base without being overwhelmed. Contrast this to flow, which has momentum that keeps going when you stop clicking on it. Upfront payment is like stacking boxes, while flow is like driving a truck. The average player can get a lot more done with flow, but can end up in trouble if they push down too hard on the accelerator.
To be fair, the reputation for complexity is more for the TA-style economies rather than Command and Conquer. C&C only has one money resource and its build rates are high. TA economies effectively have three resources that must be kept in balance. Two money resources; metal, energy, and a third, build power, which is the rate that a constructor or factory progresses production. Construction rates are limited by the most in-demand resource, so stalling (running out of) energy means stockpiling metal until the problem is resolved. However, using up the stored metal requires extra energy, which puts you in danger of wasting energy. Managing these fluctuations can take up a lot of attention, potentially even more than an upfront payment system (depending on the game), and feel quite unwieldy. However, unforgiving fluctuations can be dampened. They are a design decision, not inherent to flow, and one that Zero-K aims to avoid. For starters, overdrive makes it very hard to actually waste energy. The most complicated part of many TA-like games is their love of seemingly arbitrary metal:energy:time ratios. One unit might cost 109 metal, 911 energy and take 19.6 seconds to build, while another might cost 150 metal, 2100 energy, and take 34.2 second to build. The former drains 5.6 metal/s and 46.5 energy/s while under construction, while the latter drains 4.4 metal/s and 61.4 energy/s. Those are some weird numbers, but what do they mean? They mean you might be happily building the first unit, switch production to the second, then crash your economy right into an energy stall. In many games the stall could even completely disable your metal extractors, adding to the chaos.
Zero-K avoids these economy-crashing traps by setting all costs in a 1:1:1 ratio. A unit that costs 200 metal must also cost 200 energy and 200 work. Build power, which is a constructors' ability to progress construction, is set to nice friendly numbers, such as 5 or 10. Since costs are 1:1:1, a constructors' build power is also its demand for metal and energy. Factories have 10 build power, which means they drain 10 metal/s and energy/s regardless of what it builds, and so any factory would take 20 seconds to build a 200 cost unit. This was one of the very first changes made in Complete Annihilation, and costs were rounded at the same time as well, because balancing the cost of units down to three significant figures is folly. Flow expenditure with 1:1:1 ratios gives us powerful queues and avoids unforgiving economic complexity, but this was all still a design trade-off. Variable cost ratios can be interesting since they feed back into which resources you focus on collecting. This creates strategic momentum and scouting opportunities, especially in games with extreme ratios such as Starcraft and Age of Empires. TA tends to use ratios for a few special cases in the economy, as well as for general thematic trends, such as hulking ships being metal-heavy, while lightweight aircraft cost mostly energy. I am not sure whether varying ratios and flow is a good combination though, since the complexity ramps up quickly. Also, varying ratios tend to need puzzling out, which leads to long inflexible openings (build orders), which is something else Zero-K tries to avoid.
Parallel production poses a few problems for flow expenditure. Recall how production slows down when your demand exceeds your income. Well, if your demand far exceeds your income, then it can be hard to build anything new. This is like the Warlords Battlecry queue problem, but much more palatable since everything is still built, and it takes an extreme deficit to get into real trouble. There is a subtle issue underneath though, which is that incomplete construction ties up resources, so building many things slowly can be as bad as a leaving the resources unused in storage. Zero-K, along with many other TA-style games, addresses the parallel production issue by emphasising assisting, which lets multiple constructors pool their build power on a shared task. They can even assist factories, saving you from having ten 90% complete tanks. The extreme deficit problem persists though, and in many games you have to go through your whole base shuffling around or pausing constructors to prioritise anything. This is a clear case of fighting the UI, so Zero-K has construction priorities, which were added all the way back in CA. Construction priority is a state toggle that let you set what gets first dibs on resources. High priority constructions are satisfied first, so they only slow down if too much is set to high priority. There are three levels of priority, and they can be set on constructors to control how they spend resources, or on construction projects to control how resources are spent on them. Priorities can even be given default values, so you can make metal extractors always be built with high priority. Once we added priorities it only seemed natural to add a reserve system, which lets you set aside resources for high priority use. Just Alt+Click on the resource bar. This is how you might set aside 100 metal to boost out some turrets.
Flow has worked very well for Zero-K. It lets players use proper production queues, and much of its reputed complexity is a decision designers make, not a fundamental part of the idea. Most of the magic is in the 1:1:1 cost ratios, with not-insignificant contributions from round numbers and construction priorities. It is harder to destabilise your opponents' economy, but on the upside, learning how to make a stable economy is much easier. The upside is worth it in our view, because it lets players get on with playing the rest of the game, and very few real in-the-moment decisions (as opposed to preset build orders) about how to grow your economy were lost. Index of Cold Takes

[ 2024-03-09 23:39:13 CET ] [ Original post ]

Jumping is old, going back to the early days of Complete Annihilation, which predates Zero-K. It is also a very stable mechanic, to the point where a player from 15 years ago would not see the difference just from using it. In part this is due to its simplicity: just give a unit which can jump a jump order, and it will jump to the location once it is in range. But it is also because surprisingly little has changed. So why write an article about jumping? Well, while there have been a few changes, each one reveals a further refinement in the design of Zero-K. Even more revealing are the ways that jumping has deliberately stayed the same, in the face of potential changes. So here are four mini-articles on the how, what, where, and legs(?) of jumping.

Which units jump?

Perhaps the most important aspect of any ability is the types of units that can use it. Jump is one of the many abilities associated with a particular factory, in this case the Jumpbot factory, but in an unusual way. Other factories with a unique movement ability, such as the Hovercraft Platform or Spider Factory, have that ability on all of their units, whereas only about half the Jumpbots jump. This makes Jumpbots more like Cloakbots or Shieldbots, which each only have a few cloaked or shielded units. Furthermore, the Shieldbots' Dirtbag jumps, as well as the Recon Commander, and the largest unit in the game - the Detriment. This smattering of jumping is also similar to cloaking and shields. To see why Jumpbots ended up like this we have to go back to CA, since only commanders and Detriment have gained jumping since then. Jump was an ability exclusive to the Core faction, to mirror Arm's exclusive access to all-terrain spiders. Each faction had two tiers of bot factories, with a few all-terrain options in the higher tier factory. Placeholder and Firewalker, two non-jumping Jumpbots, did not exist at the time, and Moderator existed in the skirmisher role, but with a different weapon. Technically we could have let Moderator jump, its role stopped us.
Jumping is not just a way to move around the map, it is also a tactical ability that bestows a burst of speed. So a jumping skirmisher violates Quant's Rule, since skirmishers are meant to be weak to fast units that negate their range advantage. Jumping is as an excellent escape tool that negates this weakness, so Moderator was not given the ability to jump. Firewalker is non-jumping for the same reason, and also because dislodging artillery from awkward cliffs sounds very annoying. Spiderbots lack true artillery for the same reason. In addition to violating Quant's Rule, using jumping skirmishers also sounds tedious. Jumping with a short ranged unit is a game of risk, reward, and sudden retreats, while jumping with a skirmisher sounds like game of routinely retreating when enemies get too near. Such a thing feels like it could be automated, which also comes into conflict with the idea of fighting your opponent, not the UI. We considered creating a combined jump and spider factory while CA was being merged into one faction to create Zero-K. The goal was to create a fleshed-out all-terrain factory, and on paper it worked quite well. The only spiders at the time were Flea, Venom, Recluse and Crab, which fill the scout, riot and skirmisher roles, which leaves the raider, assault and anti-heavy roles to be filled by Pyro, Jack and Skuttle. However, this idea did not make it beyond prototyping, and instead we settled on the Jumpbot and Spiderbot factories we have today. I do not recall the exact process behind the decision, but here are some likely factors.

• Jumping is a sudden bursts of speed, while spiders can constantly dance around cliffs. These are distinct styles so should be in different factories to let the distinctiveness flourish.
• The combined factory would be too full, and too flexible, with all the units it could contain.
• It would be tricky to find new homes for all the non-jumpers and non-spiders that we wanted to keep from the rest of the bot factories.
• Having two factions that can play very hilly maps, or areas of maps, seems much better for diversity.
• Jugglenaut and Crab would fight over the role of the factory's signature unit.

The solution was to add Hermit and Tarantula to flesh out the spiders, and make Widow all-terrain. Redback was added later to let Venom move more towards a raider role. As for the Jumpbots, they are essentially the old CA tier 2 Core bot factory, with a few new units added later. As for why there are no new jumping units, that goes back to the Zero-K approach to uniqueness. Many sci-fi strategy games use a weapon-chassis approach to unit design, where units can be boiled down to a combination of weapon and movement types. Sometimes there is even an in-game unit designer to make this breakdown explicit. Zero-K can be viewed through the lens of chassis and weapons, but there are so many holes in the matrix, and extra subtleties on top, that doing so is of limited use. Zero-K units aim to be more distinctive than combinations of weapon and chassis, and adding more jumping units for existing roles would work against that. Besides, jumping is primarilly a Jumpbot feature, and there are plenty of mechanics to build other factories around.

Jump physics

Jumping is surprisingly non-physical for a game with unit cannons and Lobsters. A jumping unit follows a set trajectory until it either dies or lands on a building, so unless that happens, it is guaranteed to end up safely on the ground. Its trajectory is calculated at the start of the jump, although the jump will be blocked if it would pass through terrain. This is all very deliberate, to the point where an impulse-based alternative was written by the developer xponen was not adopted. This new system used dynamically scripted physical forces to launch and guide units through the air, then slow them down at the other end to avoid taking fall damage. It was essentially a simplified and automated Kerbal Space Program. The impulse-based system was rejected for the unreliability inherent in its design. The goal of the system was to give units full physics while jumping, which meant that sufficient incoming fire could knock them off-course. Jumping multiple units was particularly risky since they would bump into each other mid-air, and even a slight course adjustment could lead to a unit bouncing away, down a cliff, and into a puddle. But how is this distinct from Lobster lob, which was added much later? Lobster picks up units and physically throws them in a direction, with the only nod to safety being temporary fall damage immunity.
The difference between Lobster and jumping lies in their centrality. Lobster is a somewhat niche midgame support unit, while many jumping units, particularly Pyro and Constable, are built from the very start of the game. As such, jumping has to be much more reliable. A Lobster causing part of an army to bounce down a cliff is recoverable, and to some extent it is the price of using Lobster. Armies are large enough by that point for things to average out. An early Pyro failing to jump up a cliff, or a constructor becoming stuck, would feel really bad and could be game deciding. The general principle here is that, if you want to build a faction around a mechanic, it had better be reliable. People have to be able to trust their units' basic abilities, since taking even a slim risk of complete failure into account is too taxing. On the other hand, tactics that appear later in the game can afford to have a bit more risk. There are more options later in the game, so using any particular one is more opt-in, and there are more ways to mitigate risk. As for the unused impulse-based jump code, there is a happy ending. Amphibious floating was originally implemented in the same way as jumping, with a set trajectory. This leaves a lot to be desired, and I could see xponen trying to get more physics into the game, so I suggested that the impulse jump tech be used for floating. This worked great since units bobbing around and bouncing off each other is a great feature for floating, and it cannot fail in the same ways as jumping. Floating is much better for it, and the impulse jump code still exists in the repository, so a modder could even pick it up for use in a game with a different set of goals.

What are jumplegs?

The lack of interaction between jumping and the rest of physics has a few weird effects. Units can jump from anywhere to anywhere, provided it is in 2D range, which includes flying through the sky after being launched from a unit cannon. Such units just follow their calculated trajectory, so turn sharply and float towards the ground. I remember launching Pyros across Victoria Crater almost as soon as Newton was implemented. However, there have been a few problems. Skuttle is a cloaking, jumping, bomb, which made it a particularly powerful unit to launch. Imagine the Sky Jacks of today, except they are cloaked and 1-shot their target. The best theoretical counter was positioning Hercules, or any other high-flying gunship, above anything important to decloak the Skuttle, and spamming Pickets. This was far too expensive, arduous, and silly, so we considered ways to nerf the tactic. Removing cloak was not an option since Skuttle needs to cloak while jumping for its mundane uses, so instead we removed its ability to jump mid-air. Thus the distinction between jumplegs and jumpjets was born.
A unit with jumplegs can jump, but not from mid-air. Skuttle was given jumplegs, along with some other units that looked like they use legs to jump. Notably, Pyro and Jack were given jumpjets, so retained their utility in unit launchers. This reflects the broader design philosophy of trying to retain as many of the creative combinations of mechanics as possible. It would have been easy to remove mid-air jumping entirely, but instead we surgically patched out the bits that would clearly break the game. Besides, jumping from anywhere has synergy with Placeholder, and saving units that are knocked off cliffs by enemy fire is cool. Splitting jets and legs also let us make jet break cloaking. This had to happen eventually, but was blocked by Skuttle needing to cloak, since the smoke and fire emitted by jumpjets ignore cloaking. Effects like these can be seen by players, but not their units, which gives players extra information. This leads to a form of fighting the UI where players want to tell their units to shoot at the mysterious smoke, but cannot. In these cases we either removed the effect while cloaking or make the effect decloak, to bring player knowledge in line with unit knowledge. The former is applied to damaged-unit smoke, which is suppressed for cloaked units for this very reason, but would look silly when applied to jets. The latter, decloaking the unit, was initially why units decloak when they take damage, since projectiles exploding mid-air is suspicious.
The existing jumpers were split into jets and legs on aesthetic ground. Basically, if a unit already had leg animations, then it was given leg mechanics. This was particularly good for units with a wind-up animation, since the animation caused them to actually stop mid-air to do their animation, which was too cartoony even for Zero-K. Detriment jump, which was added later, has a wind-up animation and a rocket jet, so mechanically it has jets and legs. It decloaks when it jumps and cannot jump mid-air. Recon Commanders was hit the hardest by the addition of jumpjet decloaking, since it can equip a personal cloak module. I recall this being a desirable change at the time though, as cloak made the commanders a bit too slippery. Jugglenaut and Detriment also decloak when they land, since their impacts create a visible explosion.

Where can units jump?

The question of where units should be able to jump is a tricky one, since both extremes lead to frustration. Highly restrictive jumping will cause units to annoyingly refuse orders that the "should" be able to carry out, unrestricted jumping results in players unintentionally ordering their units to become stuck on impassible terrain. The current system is as follows.

• Units cannot jump onto terrain that is too steep, since they would become stuck.
• Units can jump onto structures, however, the jump ends when they hit the structure.
• Units can jump into water, provided the terrain under the water is not too steep.
• Units cannot jump out of the water, except Detriment and commanders, since they are amphibious.

These rules work surprisingly well, and have been tweaked over the years. Originally units could jump out of water but not onto structures. Jumping onto structures used to be impossible. The issue with allowing it is that a jump trajectory would let units clip completely into structures, making them impervious to enemy fire. However, this had to be solved, since being unable to jump at structures felt like too much of an arbitrary limitation. Jacks were looking silly milling around the bases of terraformed turrets, and a Singularity Reactor in a hole should be more vulnerable to jumpers, not less. So we let jump target structures, but interrupt it as soon as the unit hits the structure. This lets Jacks jump up to get a few hits on a turret on a spire before bouncing back down, limiting its damage output by its jump recharge. Interrupting a jump when it hits a structure leaves units at the mercy of physics, so they could bounce off the structure and fall down a cliff, but I do not recall any complaints. Perhaps it is because such a jump is a deliberate decision, and one that rarely has to be taken early in the game. People naturally give jump orders on open terrain, when it is available. The bouncing is also much more restrained than full impulse-based jump, since the jump is always interrupted very close to the destination. It also used to be possible to jump out of the water, and there was even the idea of making jumping units fully amphibious. Jack could already be used amphibiously since melee weapons fire underwater. However, the idea of giving jump a small amount of underwater utility was dropped because it was too tedious. Babysitting units across the sea by chaining jump was a form of fighting the UI, which we resolved by removing the possibility. The idea of full amphibious movement was dropped because jump already bypasses cliffs, so if it bypassed large bodies of water, then there would be too few ways to make a hard barrier against it.
Units can jump into water because it seems like something they should be able to do, and there are more upsides than downsides. Sometimes it is worth saving a Jack or Jugglenaut by telling it to jump into the sea. Rescuing such units is just a matter of a little terraform, to give them a small platform of dry land to jump from. In theory these units can jump in any direction, so it stands to reason that they should jump into the sea if it is to their advantage to spend some time stuck underwater. Jumping into the water accidentally is bad, but water is visually distinct enough to make this very rare. There would be times when units would want to jump onto terrain that is too steep, where they would be stuck until they jump out again. However, terrain steepness is harder to make out than water, no matter how clearly it is shown, and there are far fewer advantages, since the main purpose of water is to block projectiles. Ability restrictions are about balancing the feel of units being able to freely use their abilities against the risks of each application. A niche use for an ability that has a high risk of being accidentally misused is not worth allowing.

Distilling some principles

Hopefully that was a useful insight into some aspects of jump design. Most of these articles involve dredging the principles out of my subconscious, which means at the outset I am not entirely sure how the concepts will be carved up. So I would like to take a moment to summarise a few of the new ones we saw.

• Jank Escalation - Mechanics that are central to some core set of units need to be reliable, so players can trust them. More niche mechanics, or those that show up later in the game, can have more risk involved. So jumping is reliable while Lobster is not.
• Disciplined Physics - Physics is great, but is should not be used at the expense of other considerations. Zero-K does not set out to apply the maximum level of physical simulation so usability often takes precedence, as mentioned in Physics vs. Formulas.
• Surgical Excision - Interactions that would break the game should be removed without affecting related mechanics that have not yet been shown to be broken. Doing so would hinder the creative toolbox feel of the systems. So Pyro can still jump mid-air.
• Practical Verisimilitude - Units should feel like they are free to use their abilities in ways that make sense within the game world as it is presented. But units with no restrictions can be told to do very stupid things, so applications with low utility and a high risk of misuse are restricted. So units can jump into the sea, but not onto steep terrain.

Of course, we also saw a few ways to use Quant's Rule and Not Fighting The UI, but they are going to show up everywhere and already have their own articles. Perhaps it is time to start a glossary. Index of Cold Takes

[ 2024-02-24 23:45:57 CET ] [ Original post ]

Projectiles in Zero-K are physically simulated, meaning that shots fly through the air and collide with anything that gets in the way. This is standard for games inspired by Total Annihilation, but Zero-K leans into the mechanic hard, and embraces the implications. Not content with taking only one thing to the extreme, Zero-K also has a strong aversion to armour classes and damage bonuses. We completely avoid damage formulas of the type that let pikemen deal extra damage to horsemen, or tanks take reduced damage from rifles. The goal is to create a game world that is visceral and intuitive, something that is best engaged with as a physical space, rather than as an abstract collection of numbers. Complete Annihilation steadily removed the damage formulas inherited from Balanced Annihilation, and it looks like BAR might head the same way too. These were mostly things like commanders taking extra damage from turrets, and various EMP resistances. Bonuses like these suffer from being confusing and hard to remember, especially in a futuristic setting with no historical precedent or clear notion of infantry to guide intuition. Besides, completely removing damage bonuses is just so elegant, and making it work is a fun challenge. So we saw damage bonuses as a crutch, they solved problems in BA, but we could use physics to come up with better solutions.
To stack hubris on hubris, we also wanted the units of CA to have roles. Roles in the sense of pikemen beating horsemen, which is a bit more detailed than the roles found in Total Annihilation and most of its progeny. The roles in TA tend to be big "theatre of war" style designations, with roles like "bomber", "fighter", "scout" and "artillery". These roles are about dominating air, land or sea, or about projecting force from one domain to another. Artillery even fits this description if you consider bases and open ground to be different domains. In any case, all this theatre-on-theatre action left little room for diversity within a domain. This limits the options for combat within a domain, and in particular, land armies designed to fight other land armies could end up quite similar. The generic "army unit" would change as the game escalated, but at any given point the unit selection felt slim. Armies in Zero-K should consist of multiple unit types, and it should be possible to exploit deficiencies of enemy armies, all within the ground vs. ground game. So Zero-K is designed around roles. Fast light raiders beat ranged skirmisher, which beat slow beefy riots, which beat fragile raiders. Whether these are "hard counters" or not mostly depends on how you define "hard", but I think they are mostly soft counters. Units can often beat their counters with a slight numbers advantage and a good engagement. We still have the "theatre of war" style roles, since cross-domain interactions are great too, but these counters tend to be harder. Artillery is very good against static defense, and fighters are very good against bombers. How does Zero-K have such roles, all without any bonus damages? What makes the horseman-equivalent particularly bad against the pikeman-equivalent? In many cases, the answer is physics. Game physics, not real world physics, as the goal is depth rather than realism. Physics means the way units move around the world and interact with each other. It is things like unit positions, ranges and speeds, weapon area of effect damage, and how projectiles move. This is not new, every RTS has physics, and without it they would essentially be spreadsheets. Physics is fundamentally what gives players any reason to care where anything is. Every game with time, space, and simple rules linking them together has some sort of physics.
Not only is physics used by every RTS, it is often a large part of their design and balance. Horsemen counter archers because speed physically counters range, and any arrow-resistant armour is just icing on the cake. Zero-K just takes this a step further, eschewing damage modifiers and relying more on physics instead. This is a design constraint, a rule we have set for ourselves, because it means that units need to be physically different to have different roles. Spearmen can be designed to counter horsemen with physics alone, but it becomes tricky when it is time to implement a physically similar swordsmen. There is still plenty of freedom though, since quite a bit can be done with basic stats such as speed, health, damage and range. On top of this, Zero-K uses projectile physics to a much greater extent than the average RTS. In most games, units shoot projectiles as a form of delayed damage, and to animate the act of shooting. A standard projectile will hit its target, and nothing else, unless the target does something weird (such as dying or, in some cases, teleporting). In Zero-K, each projectile is an independent entity with its own physics. Plasma cannon shots arc through the air, lasers fire in straight lines, and missiles try to track their target. If a projectile hits something, anything, then it explodes and deals its damage. The visuals are used to convey all this, rather than just being an animation to show that a unit shot. Projectile physics increases the importance of units' speed and model size. Many longer ranged weapons shoot slow or inaccurate projectiles, which gives small fast units a chance to dodge while closing in. The slow rockets of most skirmishers are tuned to hit large assaults and riot units. In turn, the even slower projectiles of assaults and artillery units give most targets a chance to dodge, with the notable exception being turrets. There is space for soft counters here. Skirmishers can still beat fast raiders, but it is more a matter of creating a blizzard of rocket fire than having individual skirmishers fire at and hit individual raiders.
The whole "Physics vs. Formulas" dichotomy is about which parts of the game are more important. It is about whether a player choosing which unit to build thinks more about how it moves and shoots, or about damage formulas that determine what it counters. Zero-K is on the side of physics because it is cool, and it seems so intuitive. Players can see whether a projectile hits a unit and extrapolate the results for other projectiles and units of a similar speed. On the other hand, formulas are invisible and can be arbitrarily complex, taking into account armour, unit type, weapon type, and upgrades. Enough of a reliance on formulas can make the physics of a battle irrelevant, which is a shame because it is the part of the game that players can interact with moment-to-moment. Exploiting a formula is more down to unit choice than unit usage. Great mechanics have more than one purpose, and physics of Zero-K has many. A big one is to fight Lanchester's square law, which essentially says that an army of twice the size is four times as powerful. All games have to grapple with this law, that is, unless they are happy with players just rolling a big ball of units around the map. The trick to fighting Lanchester's square law is that the "square" only applies in ideal situations, so to fight it we just need to move away from the ideal. Most games do this via units of inconveniently short range, to limit what can fire, and area of effect damage, as it deals more damage to dense armies - armies which are dense because everything is trying to get into range. Zero-K makes use of these approaches, but uses projectile physics to add even more. Unguided projectiles act a bit like area of effect damage, because dense forces take more hits. Consider how a large force of Ronin will fire more rockets than a smaller force, but also runs into more rockets. At least, unless the Ronin spread out, but that risks moving some too far away to shoot. This all fights Lanchester's square law, but in a dynamic way where there are tradeoffs between dealing and taking damage. A small force can hold off a large one for a while if the larger army is unwilling to take any damage. It also makes attacking from multiple angles even better, since it reduces your own density. But perhaps the most notable effect of simulating projectiles comes from allied units blocking each other.
Projectiles hit units regardless of their allegiance, and going this far with projectile physics is rare even among games inspired by TA. It means that a dense blob of units loses most of its damage to blocked lines of fire. This further encourages armies to spread out in a line. Density and facing is very important, since a good flank can leave most of an army unable to return fire, even if they are in range. High density is not all bad though, since it concentrates power and prevent units being surrounded by enemy raiders, so there is a constant tradeoff. Still, Zero-K tends to have lower density armies than the average game, which encourage spread out battles across multiple fronts. The advantages of low density even play a central role in the escalation from cheaper to more expensive units. Projectiles have a lot of parameters, which in turn allows for a large range of weapon types. To cut down on complexity, most weapons fall into one of three categories.

• Plasma cannon that fly through the air in a ballistic arc.
• Unguided rockets or homing missiles. Some are fired directly at the target, while others arc.
• Lasers and lightning that instantly hit and require a direct line of sight to fire.

These weapon types results in a variety of tactics, since each type has its own relationship with unit density. An arcing projectile allows units to clump and still be able to fire, but still leaves them vulnerable to return fire. An army armed with lasers or homing missiles needs to spread out to fire, but the inability to miss removes an opponent's incentive to spread out. Being unable to miss is quite powerful, but remember we still have non-physics balance tools, so such units tend to pay for their accuracy with poor raw stats. Direct fire weapons are also particularly weak to being blocked by terraformed walls.
This all sounds great, hopefully, but it also sounds fiddly. Luckily, Zero-K is built on fighting your opponent, not the UI, so we are careful to keep the physics manageable. We avoid implementing unnecessarily fiddly weapons, and provide powerful controls to deal with everything else. Line Move lets players create formations and dial in their density with ease, and becomes their default way of issuing orders. Attack Move lets players tell short ranged units to jink around to avoid projectiles, and longer ranged units to move away from enemies that try to close range. Anti-Bait lets players tell units with big important shots to not waste their time trying to hit a speedy raider. And it almost goes without saying that units have the intelligence not to fire when allies or terrain is in the way. I have been a bit misleading, and it is time to come clean. Zero-K has a damage formula. To start with, some units have an armoured mode that causes them to take 33% damage. I am not sure whether this counts though, since the multiplier applies uniformly. The most common damage modifier is for anti-air, which deals only 10% of its damage against ground units. But anti-air is not even capable of firing at ground units, which is a fine mechanic provided the target categories are clear. The anti-air damage modifier is mostly just insurance against anyone figuring out how to work around this restriction. Then there are shields, which have to convert status effect damage such as EMP and slow to ordinary damage. This is done at a rate of 33%, which is a bit arbitrary, but it has to be less than 100% because status effects have very high raw damage. Finally, gauss and flamethrowers deal extra damage to shields, because something something piercing something something... there is actually no excuse.
It gets worse though, as some units shoot through allies, or even terrain. And not in a consistent way, like how flamethrowers burn through everything in their path. Nukes and tacnukes pass through allies because having one explode on an errant plane sucks (although when they hit an enemy plane it is hilarious). Anti-nukes pass through everything for similar reasons, but also because they do not know how to try again if an anti-nuke misses its target. A few other weapons here and there pass through allies, although in most of these cases units still avoid shooting at allies. There is a difference between colliding at allies and firing at allies. A few units with fast ally-piercing projectiles still aim as if they would hit allies, so the caveat is more about edge cases. Some edge cases are bad, and the best uses of physics know when to relax and let things feel good. In short, know when to dial back the jank, because sometimes it just sucks. Speaking of jank, weapons can impart force on units, pushing them around. Clearly this means there should be gravity gun weapons that just push or pull units, and there is no reason not to let it target allies. The result is unit cannons made of Newtons (the gravity gun turret) and terraformed ramps, and it is my favourite incarnation of a unit cannon. Anything can be fired, anything, provided you have the resources and skill at engineering. Such a thing would get repetitive if it were common, but somehow it hits a sweet spot. It is often impractical, but sometimes it is time to fling Jacks into the back of the enemy base.
Gravity guns and edge cases aside, the goal of Zero-K's physics is to evoke a particular feel. The game world should feel like something that should be engaged with as a physical space, rather than an abstract collection of numbers and circles. Games can end up feeling quite abstract. Put more enemy units in your circles (ranges and spell radii) than your opponent manages to put in theirs, and you win. Formulas can vary the effect and suitability of each circle, but this just mixes up which circles are used, rather than change the fact that everything is circles. Zero-K fundamentally disrupts the circles, deforming them into weird and wacky shapes, the consequences of which are too numerous to cover in one article. But it is sure to come up again and again. Index of Cold Takes

[ 2024-02-10 23:36:20 CET ] [ Original post ]

Games in the Total Annihilation lineage almost always have the same two resources, metal and energy. Metal is produced by building Metal Extractors on deposits scattered around the map, while energy comes from power generators that can be built, by and large, anywhere. The more important resource is metal, simply because metal deposits, or "spots", are rarer than free space to produce energy. Metal is the limiting factor, which causes players to expand out onto the map, capture territory, and interact with the enemy. A game without metal would mostly consist of players sitting in their base, building energy. Many TA style games also have Metal Makers, economic structures that drain large amounts of energy to produce a bit of metal. Supreme Commander calls these Mass Fabricators, but mass and metal are just two names for the same thing. These structures are less efficient than metal extractors, otherwise players would have no reason to leave their base, but they allow players to scale up their economy without capturing more metal spots. The only requirement is space and resources, which makes them useful later in the game when all the metal spots are taken and defended. The early developers of Zero-K liked the idea of a growing economy, but not how it was implemented with metal makers.
Metal makers were removed from Complete Annihilation, the precursor to Zero-K, just about as soon as it forked from Balanced Annihilation. For context, the average 8v8 BA team game had a few players on each team fighting over unclaimed territory, while the rest of the team sat in the back and mostly built metal makers. The back players players were not slacking, they were necessary, because games were rarely won before metal makers became a deciding factor. Any team that ignored metal makers risked being overwhelmed by the compounding income they would eventually provide. Eventually, once a team had enough metal makers, territory no longer mattered. This did not sit well with the CA developers, as they preferred fighting and expanding to sitting in the back. Metal makers are fundamentally a way to spend resources now to be more powerful in the future. Every RTS needs something like this, some way to invest in the future. Investment can take many forms, from simply increasing income, to upgrades that increase how much power you can squeeze out of your existing income. Investment is vital because it is a dimension of the strategic triangle, with the other two dimensions being aggression and defense. Without investment, there would be no way to outproduce and overwhelm an overly defensive opponent, and there would be nothing for aggressive play to punish. So we knew that CA needed some form of investment. We tried subsisting on advanced metal extractors, another feature of the TA lineage, which are expensive income upgrades for basic metal extractors. These were a bit finicky though, and the ability to invest hits a wall when there is nothing left to upgrade, so we came up with overdrive.
Just as an aside, I recall discussion on the Planetary Annihilation forum about whether it should have metal makers. It ended up without them, and without a replacement, which might be fine, although I lost track of PA so cannot say for sure. I suspect relying on advanced metal extractors works because there is a lot more frontier to defend when playing on a planet, and PA was fairly spammy with its metal spots. So upgrades can carry the investment game, just in CA's case the maps tended to not have a ludicrous number of metal spots. Anyway, CA went with overdrive, which may have been invented by Licho. I know he at least wrote the first version of the code. The basic idea is that every metal extractor (mex for short) should also be a metal maker, because that links metal makers to territory. A complete system can then be derived by noticing and fixing a few immediate issues.

• Metal spots can be high or low yield. It would be weird for a map of low yield metal spots to allow more metal maker income than a map with fewer spots and the same total income. So the "metal maker" income of a mex is a multiple of its spot yield, rather than a fixed amount.
• The standard "drain 70 energy for +1 metal" style metal maker has the same issues as advanced mexes. In particular, economic investment hits a sudden limit when enough energy is being produced to run all your mex-metal makers. So we made mexes able to turn a variable amount of energy into metal.
• A variable input metal maker cannot have a fixed conversion ration, otherwise players would only ever need one. This would defeat the whole purpose, so we made a mex's energy to metal conversion efficiency worsen at higher rates of energy use.

The result was mexes that can drain X energy to multiply their income by 1+(X/16). We call the extra income overdrive income, so for example, a mex with +2 base income doubles its income by draining 16 energy per second, and would need to drain 64 energy to triple it. Actually, the original equation was (1+X/4)-1, but near the end of 2014 we discovered that it had not been solved correctly, and that the correct solution required the concept of "underdrive". So we switch to the simpler 1+(X/16). The diminishing returns of overdrive keep territory relevant throughout the entire game. Say there are two teams, one with 10 mexes and the other with 8, which each have 40 energy to spend on overdrive. The energy is automatically split between the mexes, as this yields the greatest return, so the teams spend 4 and 5 energy per mex respectively. Spending 4 energy on a mex increases its income by 50%, while spending 5 energy increases its income by 56%. Assuming +2 base income mexes, the team with more mexes produces 10 overdrive metal while the other team only produces 8.9. So territory is important because it lets the team with more mexes convert the same amount of energy into more metal.
Overdrive was also a break from the exponentially increasing income characteristic of standard metal maker economies. With metal makers, you can always spend a fixed amount of metal for the same increase in income, and this income can be reinvested in increasing your income, yielding exponential returns. With overdrive your income can still grow, but further growth becomes increasingly expensive. These two factors cancel out, leading to high initial returns followed by approximately linear growth, since spending twice as much energy on overdrive only increases your income by 41% (2). The graph above demonstrates the difference, with overdrive via Singularity Reactor pitted against a modded metal maker. The metal maker does not drain energy, rather, it represents an energy-neutral combination of metal makers and power generators. Removing metal makers was also great on the fighting the UI front. It takes skill and attention to scale up a metal maker economy since energy production needs to be balanced against expenditure. Overbuilding power generation is wasteful because the excess energy is lost, while overbuilding metal makers leads to a deficit. Metal makers can be turned off to avoid stalling, but idle metal makers represent wasted resources that could have been used to generate more energy. Truly optimising your income is hard. Overdrive does away with this. If you want to increase your income without more metal spots, just make energy and let your mexes automatically drain the excess. The underlying decision, to invest, is the same across games, but getting the most bang for your buck is tricky with metal makers. Players using either system still have to balance exploiting their existing territory against expanding into new territory, but that is an important strategic decision that involves the enemy, so Zero-K retains it. Overdrive also led to some interesting map design around high yield metal spots. Mexes drain energy to multiply their income, so better mexes are more efficient and should use a larger fraction of the available energy. The overdrive system figures this out automatically, with the optimum split being to weight each mex by the square of its income. So a +4 mex should receive 4x the energy of a +2 mex. Map makers take advantage of this system by putting high yield metal spots near the centre of the map, for "king of the hill" style objectives that become increasingly important as the game progresses. The high yield mexes are valuable early, but not unduly so, because excess energy is scarce. It is only later in the game, once people have built up their energy, that holding high yield mexes confers a significant economic advantage.
The initial implementation of overdrive had a few problems. The very first version presented players with a graph and a slider bar to control how much energy they sent to overdrive. That was quickly replaced with an innate system that spends a proportion of your net income that depends on how much energy you have stored. The first version might have also been per-player, rather than pooling team mexes and energy for improved efficiency, but if so, it was revised quickly. In any case, there were other reasons to have shared mex income. Overdrive had one tricky, nuanced, problem, which we solved by adding an energy grid. These days overdrive is synonymous with the energy grid, but the entire rest of the system was designed without it. Grid-less overdrive was a bit prone to snowballing. A small difference in the number of mexes controlled by each team results in a persistent income advantage. More precisely, the energy to metal conversion ratio is (X/Y) times better for a team with X mexes compared to a team with Y mexes, for the same input energy, assuming uniform mex incomes. This would compound into victory for the side with a slight advantage, before it "was time" for the game to come to a conclusion. The solution was an energy grid, so that overdriving a marginal mex required a bit more effort than just building the mex. Then a team with a slight advantage has to hold onto their mexes, and to build some vulnerable infrastructure, if they want to compound their improved overdrive efficiency into victory. The energy grid works by setting a simple constraint: the total energy used by mexes in a grid cannot exceed the energy produced by structures within the grid. This makes overdrive usage mirror the roll-out of advance mex upgrades in other games. Players start by upgrading their main base, and then expand to increasingly dangerous territory. It creates a satisfying wave of "double expansion", where you have secured territory well enough to fully exploit it for resources, and the extra infrastructure is also extra raid-able.
The first grid was designed around dedicated pylons. These pylons gathered energy within their radius, and were the only structure that could link to mexes and to other pylons. As well as being too complicated, the system suffered from the distance threshold problem. In short, previously irrelevant minor variations in map symmetry were now extremely important. A pylon might cover four mexes on one side of the map, but only three on the other, conveying a noticeable economic advantage. We tried imposing a hard connection limit of three, and tweaking pylon radius, but maps were too variable to cover everything, and our attempts were making pylon placement increasingly fiddly. So we let everything link to everything, letting pylons fade into the background. This all happened rather quickly, the grid as it exists in Zero-K today may have been complete as early as 2008. Letting everything link to everything turned out really well. Many RTS games have at least one spammy economic structure, most commonly houses or power plants, that can be built anywhere. Players will just pack these structure into the back of their base unless the game gives them a reason not to. Most games of the TA lineage let this happen to their power generators. Supreme Commander had a go at solving this with its adjacency bonuses, but personally I feel like they make base building a bit too prescribed, and packing a checkerboard of power generators and metal makers into the back of your base does not seem like much of an improvement. The way players make energy in Zero-K is so interesting, so flexible and alive, by comparison.
Players tend to start on their grid from the start of the game. They drag lines of wind generators between metal extractors, but these lines are perfect cover for enemy raiders. Expanding constructors might also build the occasional solar collector, which spices up expansion patterns and creates more targets for raiders. Two solar collectors are enough for a 50% increase income boost, so people often roll them out as cheap form of secondary expansion before fully gridding everything later. Placing energy in interesting ways becomes automatic, you can sometimes spot Zero-K players in other games this way. Giving players a reason to care where their energy is built creates so much nuance and variation in in expansion and base layout. Overdrive has a big drawback in that it can be harder to explain than metal makers. Telling someone about a structure that turns a fixed amount of energy into metal feels like a complete explanation, even though it leaves out all the detail of when you might want to use this structure, and how to manage an economy around it. The basics of overdrive can be explained with rules of thumb such as "build more energy than your metal income" and "link energy to mexes', but these are a bit too vague. Some players want solid numbers, even before they have the context for them. All we can give them is the energy conversion equation, and the way grids limit energy expenditure. The trickier explanation of overdrive goes hand-in-hand with its role in Zero-K. For all its apparent complexity, I contend that mastering overdrive is easier than mastering metal makers. In general, systems made of simple discrete parts, such as metal makers, tend to be more complex than systems of smooth equations. Zero-K exploits the emergent complexity of simple elements in much of the rest of its design, but not at the core of the economy. This is simply because Zero-K is not a game about micromanaging your economy to eke out an optimal growth curve. Such a curve can be solved, and the solution has nothing to do with fighting the enemy, so we consider it to be fighting the UI. Rather that metal makers we have overdrive, which solves itself, but which has enough going on around it to remain interesting after it is solved. The different energy structures, with their different incomes, costs and vulnerabilities, act as our simple elements with emergent complexity.
We try to ameliorate the complexity of overdrive with mechanics that help players play it by ear. Grids change colour based on how efficient they are, and energy structures show an estimate of their payback time as they are being placed. This seems to work for the majority of players, and the system is very forgiving, because overdrive cannot cause an energy stall. Hopefully we do enough to get new players over the hurdle of using something so different, until they realise how smooth it is and how many problems it solves.

[ 2024-01-28 00:46:32 CET ] [ Original post ]

This update follows the Corsair buff from last month with a wider range of ship tweaks. The largest are that Siren and Envoy are much heavier, and that Reef drones capture units. This should give smaller ships time to shine and make the larger ships more impactful. Many ship hitboxes have been fixed to better match their size and shape, some visual sizes were tweaked, and ship wakes have been improved for look and consistency. Beyond the shipyard there is an experimental Ronin buff that makes it much faster when out of combat, as well as buffs for Grizzly and Magpie. There are a few more Cloakbots buffs, foreshadowed by the matchup chart in last week's Cold Take. In terms of features, the ingame menu can be brought up over the Victory/Defeat screen in the campaign, and Comet Catcher Redux/Remake has the classic corner start boxes for 1v1.

Balance

Siren is larger and heavier. Even though its average damage output is unchanged, the increased range, rate of fire, and explosion radius are a noticeable buff against swarms of light units.

• Cost 600 -> 900 (+50%)
• Visually 20% larger
• Physically about 18% larger
• Health 5200 -> 7800 (+50%)
• Range 270 -> 290 elmos
• Now prepares to aim at units about to enter range.
• Reload time 1.7s -> 1.066s
• Damage 280 -> 175
• Explosion radius 95 -> 100 elmos

Envoy is larger, heavier, and fires in a burst. It can 1-shot Lance but is still vulnerable to them.

• Cost 850 -> 1200 (+41%)
• Visually 20% larger
• Physically about 9% larger
• Health 2000 -> 2600 (+30%)
• Turn rate reduced by 7%
• Burst 1 -> 2
• Reload time 5s -> 7.3s (damage output increased by 37%)

Reef size matches its model and drones now capture enemy units.

• Physically about 20% larger
• Each drone captures at 55% the rate of Dominatrix
• A drone reloads for 5 seconds after capture
• Capture control is transferred to the Reef
• Drone health 180 -> 260
• Drone altitude 150 -> 120 elmos
• Drone weapon range 360 -> 250 elmos
• Maximum drone count is still 8.

Hunter looked too large but was physically too small.

• Visually 10% smaller
• Physically 7% larger

Mistral now looks like it costs more than Hunter.

• Visually 15% larger
• Physically 42% larger

Corsair has the AI improvement many riots and raiders received a while ago.

• Now prepares to aim at units about to enter range.

Ronin is much faster when out of combat and half a recent health nerf has been reverted.

• Health 380 -> 400
• Speed 69 -> 84 elmos/s
• Reload slowdown 80% -> 66% (55.2 -> 55.4 with the base speed buff)
• Fixed the reload animation so it shoots as soon as it reloads, except when firing backwards.
• It is now slowed for the full reload, rather than speeding up for a split second at the end.

Reaver has a few of its recent nerfs partially reverted. The focus is on making it easier to build early.

• Regen rate 15 -> 20 hp/s
• Range 265 -> 270 elmos

Gremlin is better overall and cloaks for free.

• Cost 140 -> 130
• Cloak cost 0.1e/0.5e -> 0e
• Decloak radius 140 -> 125 elmos
• Speed 87 -> 93 elmos/s

Grizzly is healthier and cheaper to move it out of the Cyclops cost range.

• Cost 2000 -> 1900
• Health 8400 -> 8700
• Turn rate increased by 5%

Magpie is yet to break the game so can try rearming faster.

• Rearm time 18s -> 15s

Features

• Improved the look and consistency of most ship wakes.
• The mission Victory/Defeat screen is now displayed behind the ingame menu.
• Added N to toggle hold fire to the default hotkeys.
• Added classic corner 1v1 boxes to Comet Catcher Redux/Remake.
• Improved lighting on Izki Channel v1.0 and MiniChess_v2.
• Incidental ability sounds (such as Djinn) are now controlled by the battle volume slider.
• Added support for modded Push/Pull weapons on units with On/Off toggles.

Fixes

• Shielded Chickens now float, since shields are disabled underwater.
• Fixed Reef looking peculiar when it tries to beach itself.
• Fixed visual jitter for capture and Lobster effect lines on moving units.
• Fixed initial queue mid-queue removal.
• Fixed Battle Value Tracker rounding for numbers less than 10.
• Tweak map extension grid thickness to avoid triggering a hardware bug with GoogleFrog's screen.
• Modded tint and glow now survives reloading lua.
• Fixed some issues with shutting down the depth of field shader.
• Update json library for a bit better performance.
• Fixed a very rare healthbar bug.
• Fixed an overhead icon bug.

[ 2024-01-21 07:46:51 CET ] [ Original post ]

How many factions are there in Zero-K? I get asked this from time to time and am never quite sure how to respond. It looks like a simple question with a simple numerical, like two or seven, but it is actually quite complex. The questioner may not stick around for the full answer, and I might not have the time to give one, so what am I to do? Finally I have the solution: just link this post. Strictly speaking, Zero-K has one faction, but in many ways it has somewhere around eight to eleven. Many parts of the game are designed to satisfy most of what people want from factions, and it is these desires that lead to questions such as "how many factions are there in Zero-K?". This is why I have such trouble just answering "one", as it gives the incorrect impression that we have nothing to offer people who like games with many factions. The faction-like entities of Zero-K are the eleven factories that produce most of the units in the game. Here is a quick overview of factories.

• There are eleven factories: three for walker robots, two for vehicles, one for spiders, two for amphibious units, two for aircraft, and one for ships.
• Your first factory is built for free, instantly.
• The land and sea factories have enough variety to see players through to at least the midgame.
• The air factories are designed to support the other factories.
• Factories are expensive enough to dissuade people from building extra factories until the midgame.
• Production rate is best boosted by assisting with constructors, using construction turrets, or adding cheap parallel production plates that depend on the main factory.

Essentially, a factory is a technology structure that unlocks a "faction" of approximately ten units, and these "factions" are designed and balanced in much the same way as a faction from any other game. This has been called a soft faction system, since players start the game with one faction, but are free to dip into any others later in the game. It is similar to the way factions work in card games like Magic: The Gathering or Android: Netrunner, which have both distinctive faction and flexible deckbuilding systems that technically allow any two cards to appear in the same deck. Zero-K has a similar sense of factions, with the big distinction being that the decision to dip into a faction is made during the game itself. I would like to go into the history of how factories as factions came about, and will some day, but it touches too many parts of Complete Annihilation to cover in one post. For now just know that CA had two factions, and that Zero-K was born from the idea of condensing them into one. The original motivation was to reduce the amount of art we needed, but the idea quickly grew into a design direction that was justified in its own right. This justification is just as valid today as it was back then, so I can cover it without too much background. Then, when it is time for the background, I can refer to this post. There is a plan here, so it might not surprise you to hear that the two pillars of factories as factions are Quant's Rule and avoiding fights between the player and the UI.
The two factions of CA, Arm and Core, go back all the way to Total Annihilation, and they had quite a lot of overlap. Faction diversification was a major goal of CA, and we were making good progress by applying Quant's Rule across the game as a whole, as well as by add new faction-exclusive mechanics (such as area shields and cloakers). There was a limit to this though, since each faction needed access to everything required to play a full game. It is also hard to differentiate factions without creating powerful cross-faction combinations, since differentiated factions naturally cover each others weaknesses. This was particularly evident in team games, since each team almost always had players of each faction. Any difficulty in coordinating the units from different factions was just considered a UI limitation. So the principle of avoiding fights with the UI was telling us that team games already has a single faction - the full unit pool of the game. Worse, this faction still had very similar Arm and Core versions of many units, which goes against Quant's Rule. The Nuke Silo is a good example. Core, being all about brute force, had a larger and more expensive nuke than Arm. We could try balancing each into a distinct role, but there is a limit, since both factions need a full set of lategame options for when they are played on their own. A Core player might decide the team needs an Arm nuke, but to build one they have to ask a teammate to share a constructor, which is a terrible situation as few people play RTS to fiddle with the unit transfer UI. Situations like nuke occurred across CA. mostly for structures, but also for many staple units as such as the basic Raven-like bomber or the Ravager-like assault vehicle. In each case we either gave each side a perfect duplicate, which works for Wind Generators but is a bit unsatisfying for nukes, or we end up with a Quant's Rule violation plus the possibility of fighting the UI.
Most issues caused by factions were avoided in 1v1 since each side was truly only Arm or Core. In fact, condensing the factions was seen as an improvement for 1v1, rather than a fix, as condensing the faction would allow for a wider range of factory designs. In CA the capabilities of Arm and Core had to be fairly closely balanced, since one being clearly better on a particular map type would be unacceptable. So CA had four choices of initial factory in 1v1, a bot and vehicle factory for each faction, but each of bots and vehicles had to behave fairly similarly across the factions. It was not so bad that it felt like only two options, but it did not feel as diverse as a full set of four options either. Simultaneously balancing factories individually and across the factions was restrictive, since anything added to one faction needed some sort of equivalent in the other. With Zero-K we removed the restriction of factories fitting into a larger faction, so we were free to design each factory independently. It took some time to get here, but it paid off, as we now have eight land factories, each more unique than anything seen in CA. Players certainly treat the factories like factions, arguing about their viability and complaining about particular matchups, just as they would for factions in any other game. The remaining PvP game mode, free-for-all (FFA), was wild, and we might have lost something here by treating factories as factions. Might. I remember a match that soon turned into a 3-way Core-only game on Comet Catcher, between Saktoth, det and I. As Core we had shields, but lacked the EMP weapons to break them. The game was at least least three hours long, Zenith was not enough, and approaching the shields stealthily was not an option either since area cloaking was Arm-only. I forget who won, but there was a turning point when det found and resurrected an Arm constructor from a defeated player. I have fond memories of this game, but largely because it was exceptional. Most FFA games were played with all the units, since Arm constructors could capture and Core constructors could resurrect. Saktoth summed it up in a thread about condensing the factions. [quote]I just played a FFA where i started core ships, went core walkers, lost both those factories, ressed an arm con, went arm tank for a while and was down to a single Freaker for core tech. Made core tank factory, lost my arm tank Factory to nuke, played core tank for a bit, got an arm air con, made an arm shipyard, lost my core tech entirely, took over the sea, made an arm air plant, and captured a core hover con for the grand finale where i built a zenith.[/quote] The factory diversification enabled by merging Arm and Core was unexpectedly beneficial for team games. There are now enough distinct "factions" for each player to feel like they have something unique to contribute. Consider a large team game on a wide open map. In CA, most players would play Arm or Core Vehicles, with some air support, and maybe a few playing bots. In Zero-K, the most straightforward options are Rover, Tank and Hovercraft, which already feels nearly three times as diverse as Arm vs. Core vehicles. There are even more options though, as Cloakbot and Shieldbot work well anywhere, and there are niches for the remaining three factories to fill even on a wide open map. In general, any of the ten factories feel viable (eleven if there is enough water), which makes it highly unlikely that the players on any given front end up in a mirror match. It feels good to be one of the few players in a team with your set of units, it gives you a distinct role, and this is most of what I want from factions. The UI has also benefited greatly from treating factories as factions. Giving every constructor the same set of build options is amazing, it just solves so many UI problems before they arise. The build options are always in the same spot, with the same hotkey, and players no longer have to hunt around to find the right constructor to build what they want. Admittedly, condensing the factions also bloated the build list since we could not bear to discard the unique turrets. But I am sure many people see this as a benefit as well.
I sometimes worry that continuing to remove UI limitations will eventually remove the faction-like feel that we have managed to create. Factory plates were particularly worrying. These are a recent addition that lets players make cheap extra factories of the same type, using the main factory as a sort of tech hub. Factory plates can be placed for allied factories, as anything else would be a UI limitation, which makes switching into the factory of a teammate much easier. Thankfully, the faction feeling survived, and if factory plates are unable to kill it, then perhaps nothing can. There was opposition to factories as factions at the time, with some people even predicting that it would kill the game. Their main concern was that we lost the benefits of overall faction identities, the way a set of factories for Core or Arm that share design elements. People weigh things up differently, but I think this was a fine price to pay, and it has worked out better than anyone could have predicted. At this point we would not split Zero-K back into two factions, even if the art required for the extra structures magically appeared. I think Zero-K is about creativity, and stopping players mixing and matching units from any set of factories feels like it goes against that. This is before considering all the Quant's Rule violations and UI fights that splitting Zero-K would generate, and the fact that CA team games were secretly one faction all along. Again, apologies for glossing over the history, but this felt like enough for one post. It does create the opportunity to play a game in the comments though: try to guess the original faction of Zero-K units, using TA, BAR, or anything in between as a guide. Remember, the faction "Zero-K Exclusive" is an option, and to give a hint, if that were a faction of old CA, then it would be ridiculous and barely playable.

[ 2024-01-14 00:54:53 CET ] [ Original post ]

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 10x less, but rather that they can be 10x 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.
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.
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?
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.
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. This includes singleplayer games, but not games without intrinsic victory states. There is probably more to say about games in general since most games have some form of goal, but that is beyond the scope of this post. I am talking about strategy games, and possibly even any game where challenge is one of the primary engagements.

[ 2023-12-30 22:28:46 CET ] [ Original post ]

The Blastwing rework continues, with most of the feedback suggesting it dealt too much damage, although a few edge cases in its behaviour have also been fixed. There is also an overdue Corsair buff and tweaks to make Disco Rave Party less fiddly. The big feature is a command to split large autohosts with many waiting players, so everyone gets a game, and the big graphics update is darker, faster, and better looking "terrain" beyond the edge of the map.

Balance

Blastwing gained more damage than it needed to in the recent rework.

• Health 100 -> 80
• Speed reduced by 5%, which also reduces bomb toss range.
• Damage 320 -> 300 -> 280 -> 250
• Burn time 24s -> 14s -> 12s

Corsair is even better against Hunter and can stand up to Siren.

• Health 1350 -> 1500
• Speed 81 -> 90
• Range 293 -> 300
• Spread 1500 -> 2500
• Damage increased by 18%

Disco Rave Party no longer innately loses spin while turning.

• Instead, DRP now turns slower at high spin. There penalty ramps up from none at 50% spin, to 3x slower at 100% spin.
• DRP now has unit AI that voluntarily reduces spin to turn faster. The AI optimises for time taken to turn then spin back up to 100%.
• Reduced maximum turn rate by 25% to compensate, and to make the optimisation work out.
• This DRP should be much easier to control since it will spin up to a high minimum, and stay there unless large turns are required. Minor shifts such as radar wobble no longer reduce spin.
• Advanced DRP users also have more options. A 90 degree order can be issued to make DRP turn ASAP, or Alt+Ctrl+Shift attack can be used to drag 1-shot orders to walk slowly through the enemy base if punctuality is not a priority.

Waiting List Split

A new command, !split, is now available in large teams autohosts.

• Anyone can do a !split when at least 40 players are waiting (so at least 8 are on the waiting list).
• The command sends 40% of the lobby to a new autohost, so everyone has a chance to play.
• The top rated players are sent to the new host, to give everyone more evenly balanced games.
• The uneven split is an experiment. Experience suggests it will create more games. Send feedback.
• Everyone needs the update for this to work smoothly, so the first day may be rough if players don't restart to get the update.

Features

• Added Battle Value Tracker, a widget that tracks kills and losses in engagements as they happen (thanks citrine). It was useful for Blastwing. Enable under Settings/Interface/Battle Value Tracker.
• Reworked the offmap terrain. It is now a dark opaque grid of uniform squares that match the resolution of the terrain, rather than a stretched texture. It also costs less performance.
• Language can be overridden locally by copying files from the repository to LuaUI/Configs/lang.
• Added minimap preview tooltip.
• Enabled https for all external zero-k.info links.
• Update Italian, Polish, and Chinese/Taiwanese translations.
• Brightened first ally blue (in a previous patch).
• Improved thermite and flamethrower effects (in a previous patch).

Fixes

• Fixed various issues with Blastwing having trouble finding a place to land.
• Fixed Blastwing overshooting when told to attack something at the base of a cliff.
• Odin can no longer fire without ammo while touching down or sitting on a rearm pad.
• Cerberus now aims even when its current muzzle position is blocked.
• Reduced Cerberus and Lucifer hitvolume sizes, to keep them within their footprints.
• Lobster throw indicator no longer highlights structures and aircraft.
• Fixed Raise tooltip values for blocking vehicles and bots, and tweaked Alt snap to match.
• Removed Odin's redundant reload bar for its shield cluster.
• Fixed invalid events in action tracking camera.
• Particularly quick double-click-drag selections no longer ignore selection rank.

[ 2023-12-23 12:55:36 CET ] [ Original post ]

"Buff strengths, nerf weaknesses." - Quantum, Lead Developer of Complete Annihilation (CA) Quantum devised the rule above early in CA history, perhaps as early as 2007, and it is still at the core of Zero-K. I don't know exactly when, or even if, Quantum said the rule in its eventual form (I wasn't there right at the beginning). However I do know that Quantum was the lead developer (he responded to the ticket "Your lead developer is a nub" on the issue tracker). In any case, the rule is responsible for keeping the 100 or so units in Zero-K unique, useful, and interesting. Quant's Rule is about game balance, and vitally it is an active rule rather than an abstract principle. It tells us what to do when a unit is to be made weaker (nerfed) or made stronger (buffed). It was devised to guard against the concern that a balanced game is a boring game. The validity of this concern is up for debate, but if you play enough RTS you will see both extremes. At one end there are games with many exciting tools which barely feature in viable strategies. At the other end there are games that seem balanced, but at the expense of any interesting unit variation. Original Total Annihilation was towards the "zany but imbalanced" side of things, with tonnes of units, but few that turned out the be viable. Many games were like this in the late 90s. You might say that viability is only a concern for hardcore competitive players, but we think it matters for anyone who really wants to puzzle out the game. In other words, to strategise. No matter the game mode, it is a bit disappointing when the unit roster effectively shrinks as your understanding grows. Some TA mods tried to address this with balance overhauls, and Complete Annihilation comes from that lineage, so the question of how to balance many units was front of mind.
Take Lance as an example of Quant's Rule in action. Earlier this year it was identified as a bit too powerful, so needed a nerf. As per Quant's Rule, its weakest aspects were the first candidates for potential changes. We kept those candidates in mind while discussing and reviewing replays, watching for ways to make them worse that would affect its overall performance, without making it feel terrible to use. Other attributes may be nerfed, but not its main strengths, so Lance was extremely unlikely to lose any of its impressive burst damage. In the end Lance was mainly nerfed on cost and reload time, which are both significant weaknesses, with minor nerfs to range and speed. Stepping back, what even is a strength or a weakness? It seems like a silly question, but consider that units are made of numbers, and no number is objectively "weak". The answer is that strength is relative, based on comparisons to other units, but here is where it gets interesting. Units can be compared within roles, across roles, across factories, or even across the entire game. There is flexibility here, and it is where unit roles and factory identity are taken into account. Were the minor range and speed nerfs for Lance appropriate? On one hand, artillery is slow and and long ranged. But on the other hand, Hovercraft are fast and Lance has below average range for heavy artillery. Which attributes are sacrosanct varies by unit and role. Consider Bandit, the Shieldbot raider. As a raider, Bandit is one of the fastest units in the game, but within raiders, Bandit is one of the slowest. The interplay of speed between raiders is vital, which causes Bandit's speed to be judged as a weakness. This means Bandit is very unlikely to receive a speed buff, just like how Lance is not going to have its damaged nerfed. As an aside, Bandit is not going to have a speed nerf either due to another rule dating back to CA. [quote]Bandit Rule: Raider speed is at least 90 elmos/second.[/quote] There is a subtlety to Quant's Rule that highlights the difference between balance and design. A designer is like an architect, with a high level idea of how units should feel and interact. The balancer is like a builder, implementing the details of a design, finding numbers that make units behave as they should. The same people often do both jobs, but the mindsets are different. Quant's Rule is a guide for those deep in the weeds of balance, where things are made much simpler by not having to simultaneously think like a full designer.
As a design principal, Quant's Rule is about giving units space to be unique. Consider the design space of units, like the plot above, but with many more dimensions for things like health and cost, as well as for fuzzier attributes like firing pattern. Then realise that this is not a static space, for if Ronin were given more range then it would shift to the right. Balance patches bestow the space with concepts of "movement" and "force". Quant's Rule is a force that pushes units away from each other, since buffing strengths and nerfing weaknesses stretches units out along each dimension. This naturally expands the space, makes units more distinct. A more conservative, or directionless, approach to balance risks units gradually drifting towards each other into a black hole of banality. Quantum presumably saw such a drift towards the average as the default, and created a rule to counteract it. As good as it might sound, remember that Quant's Rule is primarily about balance. You can interpret it as a design goal, but it works best when telling balancers which types of changes to prioritise, and which are off-limits. But sometimes, balance fails. This recently happened to Blastwing, which previously dealt most of its damage via ground fire, but just lost its ground fire and gained significant direct damage. This change would seem to violate Quant's Rule, if not for the fact it is a design change rather than a balance change. The change was a result of the balancer going back the designer, saying "Quant's Rule has been tried for years and Blastwing isn't working", and asking for a new design. It was then time to don designer mindset and teleport Blastwing to a new point in design space, because the balancer should not be expected to make long treks to more fertile designs by themselves. Almost all the units are in a good spot by now though, so these events are pretty rare. It would be hard to claim that Quant's Rule is entirely unique to Zero-K. The formulation and centrality, perhaps, but similar ideas seem to have made it into other schools of game design. From time to time I come across mechanics or patch notes that have a definite flavour of Quant's Rule, and the games that do this regularly tend to be my favourites. It is also less demanding than I have made it out to be. In the end, it is a guide, and it is invoked less frequently as we improve at holding the balance and design mindsets simultaneously. It is still great for discussion between developers though, but only if we explain it to newcomers. Good thing there is now a 1000 word post on the subject.

[ 2023-12-16 14:20:44 CET ] [ Original post ]

This update adds fancy new flame effects, a Blastwing rework (it still sets things on fire) and a thermite bomb for Odin. It also has balance changes ranging from Metal Extractor to Disco Rave Party, and a bunch of features, fixes, and performance improvements from numerous contributors.

Hot Reworks

Blastwing always had a problem with chain exploding. The previous solution was low direct damage followed by high damage over time. This felt weak and niche. The new solution is to "safely" eject its bomb when it dies, rather than explode immediately.

• Cost 45 -> 55
• Increased deceleration rate by 60%
• Drops its bomb on death rather than exploding immediately.
• Direct damage 40 -> 320
• Explosion radius 144 -> 128
• Maximum unit-on-fire duration 1s -> 24s
• No longer creates area fire

Odin has its Disintegrator Bomb replaced with a Thermite Bomb. The disintegrator was prone to converting immobilisation abilities into delayed 1-hit kills, with too little counterplay. The new bomb deals damage over time in a small area, so a commander can be saved by preventing the second Placeholder shot, or with a nudge it if it is stunned. Thermite also hits shields, fully draining a few before it is blocked.

• Deals damage to everything in a small area around it over 30s.
• Damage ramps up over time, from 0 damage per second to 1000.
• Typical damage 8k -> 14k
• Its trajectory is blocked by obstacles, but continues on when they are "removed".

Balance

Claymore has a buff to fix the occasional distance-closing issue in sea,

• Seaborne depthcharge range 280 -> 300

Lobster is slightly less nimble.

• Relob time 12s -> 14s

Gremlin follows Toad by gaining enough vision to see the ends of its lasers.

• Sight range 660 -> 760

Jugglenaut and Detriment now decloak when they land, since they deal damage.

• Detriment already decloaked on launch, so this only really changes Jugglenaut.

Magpie hits more trick shots.

• Missile turn rate increased by 8.7%

Metal Extractor loses a bit of health so Blastwing can deal less damage.

• Health 600 -> 560

Picket is a bit cheaper to save us from Blastwing.

• Cost 100 -> 95

Disco Rave Party switches to comfortably outranging Zenith, but costs a bit more, and is much less accurate in high trajectory mode.

• Cost 42k -> 45k
• Range 7000 -> 9600 (Zenith is 8800)
• Projectile gravity reduced by 44%.
• Low trajectory spread at max range: Two Inferno diameters.
• High trajectory spread: Two Trinity diameters.

Features

• Units that are on fire now look more severely on fire depending on the remaining duration of the fire.
• Added a fancy animated flame effect (thanks Anarchid and engine devs) which has been applied to all flamethrower and napalm weapon effects.
• Antinuke construction is partially paid back from team overdrive, in the same way as the existing energy construction system. The first antinuke constructed by a team gives the builders 50% of its cost back over the next several minutes, with the proportion paid back dropping by 10% per previous antinuke.
• Moved the settings from "Settings/HUD Panels/Spectator Panels" and "Settings/Interface/Spectating" to "Settings/Spectating".
• Added an automatic action finding camera for replays and live spectating (thanks fiendicus_prime). Enable it under "Settings/Spectating/Action Tracking Camera".
• Added a widget to display player names over a unit on screen (thanks fiendicus_prime). Replaces commander nametags, but has a commander-only option. Enable under "Settings/Interface/Player Name Tags".
• The units that will be thrown by selected Lobsters are highlighted when the command is selected (thanks dyth68). Can be configured under "Settings/Interface/Falling Units/Lobster".
• Fire special weapon now shows range rings for all selected units, like Force Fire (thanks dyth68).
• Commanders spawned to the same location now spawn next to each other instead (thanks Shaman).
• Added a small drag threshold for terraforming to make Ctrl+Click surrounding buildings easier.
• Added an Alt modifier to the selected units panel to select/deselect half of unit group.
• Added the secret Ctrl modifier to the selected units panel tooltip.
• Added more descriptive short descriptions for missiles built in the Missile Silo.
• Changed the default self destruct hotkey from Ctrl+D to Ctrl+K. Only affects new installs.

Modding

• The new fire effects replace the existing cegs "napalmfireball_200" and "flamer". Mods that use these cegs as a base should get the new fire effects. Use "flamer_cartoon" for old style flamethrower fire.
• Exposed weaponDefID, projectileID, attackerID, attackerDefID, attackerTeam to widget:UnitDamaged. Spectators see everything, while players only see attacker stats if the attacker is visible, and don't get weaponDefID or projectileID.
• Removed the special techniques required to give weapons zero damage.
• GG.CheckStartBox returns true if startboxes are disabled. Set the 4th argument to true to read raw boxes.
• Added "/luarules battle " to spawn preset battles. The system could be extended to ease mass preset unit spawning.

Blastwing Fixes

• Blastwings told to fly quickly after landing are no longer stuck in their landing animation.
• Blastwings now have collision, like other gunships, to prevent them stacking on one location.
• Blastwing no longer cloaks mid air if it happens to come to a complete halt.
• Blastwings are now possible to use with area cloakers, instead of constantly cloaking and recloaking under them for no reason.
• Blastwings with a Force Fire order on the ground now explode, rather than just hang around.
• Blastwings told to attack a unit now consistently approach the unit and explode, rather than sometimes hovering next to it.
• Blastwings told to attack a moving unit now update their heading more than once a second, making them able to fly at and hit notoriously mobile targets like Lance.

Other Fixes

• Starlight only deforms the map every 5th frame. It looks a little weird, but is better than people lagging out while we wait for an engine fix for the deformation performance issue.
• Fixed Paladin causing an unreasonable performance hit (thanks Porkch0p).
• More damage dealt by dead units, such as bomb damage, thermite and fire, shows up in the endgame graphs.
• Fixed spectators seeing the player-facing, hax free, unit damaged/killed midgame graphs, rather than the real ones.
• Fixed airpad exclusion orders with an even number of aircraft selected (thanks Helwor).
• Fixed giant Desolator death clone collision volume (thanks dyth68).
• Fixed bombers sometimes failing to automatically return to a pad when idle, especially after a Stop command.
• Fixed personal commander shield not having any regeneration.
• Flamethrower visuals no longer penetrate shields.
• Fixed the little generator ball effect on area shield generators not disappearing off when the unit is stunned.
• Fixed santa hat lighting.
• Fixed Storage XP.
• Fixed lighting on Small Divide Remake and LLTA Complex.
• Fixed passworded games of friends that exist when logging in sometimes not showing up in the battle list.
• Possibly fixed the occasional ghost or missing player in battle lobbies, often after returning from a game.

[ 2023-12-10 14:10:38 CET ] [ Original post ]

This is the first in a new series of design blogs about Zero-K. We aim to release one every two weeks, when there isn't a patch, and by 'we' I mean me, GoogleFrog (others might contribute later). Expect posts about Zero-K development, design, history, and whatever else comes to mind. To start us off, why is Zero-K even called Zero-K? It started around 2009 when a mod called Complete Annihilation wanted to throw off the shadow of being "just another alphabet soup mod", the term for games on the Spring Engine that traces themselves back to Total Annihilation. The mod split off from Balanced Annihilation a few years earlier, which forked off Absolute Annihilation, which was based on Uberhack and subsequently ported to Spring. For those of you aware of BAR (Beyond All Reason), it is based on Balanced Annihilation and had the working name BA Reloaded.
Zero-K was picked after much discussion, deliberation, argument, and finally, a vote. We had a site at the time, called CaGov, where developers could create polls and vote on things. We voted on things from whether taking damage should decloak (it does) and whether all bombers should be replaced with laser bombers (only Thunderbird was replaced). The simple version of the Zero-K name is that it won, beating a few other proposals, the only other of which I can remember is Robocracy. There were a few arguments in favour of Zero-K. The more narratively inclined like the idea of robots fighting pointlessly over the scraps of a universe approaching heat death, or zero degrees kevin. That paid off in the lore for the campaign over a decade later (any more would be spoilers). We also coveted 0 A.D.'s alphabetically superior position on various lists, and thought we could force the shortening 0K. That did not work out. Most of all, we wanted a unique name that would stand out and win at page rank, as search was all the rage in the late 2000s. We at least won that battle, defeating a book about cryogenics and a brand of dangerously cold single-use towelettes. The towelette company even sent us a sample after a Twitter interaction; the book still makes it to the image search preview in DuckDuckGo.
We may have been a bit too clever with the name. Zero-K stepped out of the shadow of Total Annihilation only a few years before Planetary Annihilation embraced it. Nostalgia aside, the latter is still a more descriptive name, and such names are common for strategy games. Think of all the names to do with armies or conquest. War, command, force, settle, empire, company, division, legion... the list goes on. Generic names indicate genre, which we gave up in favour of being unique. Maybe that sums up Zero-K. Arguably the best aspect of the name revealed itself years after the decision was made - puns about low temperature - which far outweighs any downside. Zero-K: Nothing is cooler.

[ 2023-12-02 22:42:24 CET ] [ Original post ]

Zero-K began its life about 15 years ago as a mod built by volunteers, and development has continued in much the same way way, except now as a full game. Admittedly we have slowed down a bit in recent years, in part due to the greater focus on polish, but also because we've already combined the best bits of RTS into a cohesive whole. Including some things that seem like gimmicks elsewhere, but really just need several years of refinement to get right. Massive online battles and tight 1v1? Done. Campaign, AI, skirmish? Done. Spider-tanks, jumpjets, ships, planes and hovercraft? Done. Terraforming, cloaking, and 3D terrain that really matters? Done. Giant robots and superweapons? Done three times over. And there isn't much to do for the controls either, as we're so far ahead of everything else already. That's just what happens when people play for over a decade and improve what they notice needs improving. Not that there isn't more to do. We release 3-4 major updates a year and don't plan on stopping. Just this month we added two new bombers and tweaked some other aircraft that needed a bit of love. In the last few months we improved the controls for Lobsters and notifications for tacnukes, in Don't Nuke Your Allies. As well as all the extra modding support of the past few years, so things can go full circle. So there is plenty to do, and we plan to do it for as long as we keep playing. [previewyoutube=pHQkctGTm_A;full][/previewyoutube]

[ 2023-11-26 01:30:41 CET ] [ Original post ]

This update introduces two new bombers to fill out the aircraft roster. One is a bit like a light Likho, and another is like a heavy Raven, but there is a lot more to each. Other planes have tweaks and buffs, such as an area reveal ability for Sparrow, and a heavier Phoenix. Some gunships even got in on the action, with the most notable being a sizeable buff for Krow. Other balance changes include a bit more health for light assaults, and better spinning for Disco Rave Party. In terms of features, bombers are well-served here as well, with selection icons for whether a bomber needs ammo, as well as smoother landing paths. There are a few extra features for modding, such as scaling and tinting, which were technically in the previous hotfix. The campaign has the new bombers, a few features, and a new Records page which displays and aggregates your best stats for each mission. How fast can the campaign be completed, and with how few units lost?

New Bombers

Magpie is a light nimble bomber armed with a pair of missiles. It deals less damage than Raven, but makes up for it with speed, precision, and the ability to shoot from the edge of AA coverage.

• Cost 220
• Health 900
• Speed 252 (between Raven and Likho)
• Rearm time 20s
• Range 550
• Damage 180 x 2
• Can hit small raiders most of the time, and most aircraft.

Odin is a heavily armoured rocket zeppelin that can fire a slow moving disintegrator bomb or a cluster of temporary shields.

• Cost 1500
• Health 5200
• Speed 185 (between Raptor and most gunships)
• Rearm time 35s
• Bomb range 200
• Bomb damage, it's a disintegrator (5-shots Detriment)
• The bomb is very slow, even Detriment can dodge it.
• Special weapon fires seven shields at 550 range.
• Each shield has 3400 charge and a radius of 200.
• Shields decay at 40 charge/s, expire at zero charge, and do not link.

Aircraft Changes

Sparrow can now boost, and reveals and decloaks everything in an area when it dies.

• Boosts by 5x for 3 seconds.
• Destroys itself after boost.
• Reveals an area of radius 400 for 12 seconds when it dies.
• Revealed area scales up during boost, to a maximum of 640.

Phoenix is heavier and deals more damage over a longer run.

• Cost 360 -> 460
• Health 1060 -> 1450 (90 more than if just scaling by cost)
• Reduced turn rate slightly
• Rearm time 5s -> 8s
• Drops 15 -> 18 bombs over 0.93 -> 1.7 seconds
• Area of Effect 216 -> 320
• Damage per bomb 25 -> 40
• Burn time 10s -> 12s

Krow manoeuvrers a bit better and fires beam lasers with more damage.

• Improved brake rate by 25%.
• Pew pew lasers replaced with burst beam lasers.
• Damage increased by 22%

Raptor is more manoeuvrable and slightly more deadly.

• Increased turn rate while firing, to counteract the effect of slowing down.
• Firing cone angle 90 degrees -> 100 degrees
• Damage increased by 4.2%

Locust is a tiny bit better as raiding, as a great Locust is scary.

• Speed 207 -> 212
• DPS increased by 2.5%

Thunderbird is slightly healthier.

• Health 1120 -> 1200

Balance Changes

Bolas has 4.5% more DPS and can 1-shot Flea.

• Reload 0.366 -> 0.433
• Damage 34 -> 42

Ravager is tankier.

• Health 2000 -> 2200

Knight is a bit tankier.

• Health 2400 -> 2500

Hermit is tankier and faster.

• Health 1500 -> 1550
• Speed 51 -> 54

Skuttle can survive a single Jack poke.

• Health 250 -> 380

Zephyr is also tankier, and now has missiles.

• Health 1900 -> 2200
• Replaced its front laser turret with missiles.
• Missile damage 72 x 2
• Reload time 1.6 seconds
• Range 1000 (same as lasers)
• The missiles have 30% less DPS, but fire in a burst.

Disco Rave Party has an interpolation of its May spin rate nerfs.

• Aim speed 4 -> 2.5 -> 3 degrees/s.
• Spin up time 60 -> 120 -> 90 seconds.
• Spin drop while turning is unchanged, but less spin is lost for any given turn due to the increased turn rate.

Campaign

• Magpie is unlocked on Fel Diacia (the Thunderbird mission) and Odin is unlocked on Bavhakya (the Likho mission). Anyone with these missions complete will have their units unlocked.
• Added a Records tab to the Profile menu on the campaign screen. This screen can sort and display your victories with least units lost, in the shortest time, with bonus objectives and difficulties. Unfortunately the data is not retroactive.
• Removed a few Lucifers from easier difficulties on Onsally (the Phoenix mission).
• Worked around the Dominatrix build options bug for the Rover Assembly on Ganong (the Dominatrix mission).
• Clarified Lalata main objective text (the Jugglenaut mission).

Features

• Added Units Lost to endgame graphs.
• Unit pictures for bombers now have an icon showing whether it is ready to fire.
• Aircraft now smoothly glide and stop when landing on airpads. This is technically a nerf as they take slightly longer to land.
• Improved shotgun visuals, with minor balance implications.
• Grizzly now aims smoothly and holds its gun steady as it fires.
• Tweaked the automatic handicap mode to give lower handicaps for ratings above 2000.
• Moved Raptor to the AA slot (D) of the Airplane Plant and Sparrow to secondary scout/raider (S).
• Taught the opponent AI about Magpie.

Modding

• Units can now be tinted, rescaled and made glowing via the customparams model_tint ("R G B"), model_glow ("R G B A"), and model_rescale. Colour values are from 0 to 1.
• Free units (0 metal and energy cost) no longer need to explicitly specify a non-zero buildtime (previous release).
• Added a function to effects/napalm for generating generic fireballs ala Inferno.
• Air pads now call ReammoComplete, if it is a units script, when bombers are rearmed.
• Added command AIR_MANUALFIRE for aircraft, since they cannot use the in-engine type.

Fixes

• Fixed Tremor wheels not spinning.
• Gravity guns push and pull a bit more consistently.
• Jack can no longer pretend to be a missile in enemy Missile Silos.
• Slow damage makes shields charge slower again (it broke at some point)
• Fixed bombers sometimes seeming to ignore a move command.
• Attack Move on bombers is now is now removed after they shoot, unless the bomber is set to repeat. Previously this only worked for some bombers.
• Bombers are now much better at landing on Reef. Much better. Horrific things could happen before.
• Fix sun on Mercurial and Rogues River.

[ 2023-11-18 01:55:42 CET ] [ Original post ]

Lobsters have been taught to not fire when it would be redundant, making Lobster balls much easier to manage. Overkill prevention in general has a tweak, and some APIs were extended to make modding easier. The Artefact Control game mode which saw some testing about a month ago is now live. In terms of balance, Redback has a bit of a nerf and some of the least used units - Skuttle, Phoenix and Emissary - have small buffs.

Balance

Duck can now be dodged by a Glaive trying as hard as it can to run away.

• Missile fuel time 2s -> 1.5s

Redback is worse at taking map control and assaulting defenses.

• Cost 230 -> 240
• Speed 1.85 -> 1.75

Skuttle can see enemies before they break its cloak.

• Line of sight 280 -> 330

Emissary aims faster and no longer benefits from manually turning.

• Body turn rate reduced 105 -> 84 degrees/second
• Gun aim rate increased 40 -> 70 degrees/second
• Resets its gun between shots (as much as possible) in case it has to move.

Phoenix moves faster and hits its target sooner.

• Speed 8 -> 8.1
• Projectile gravity 0.7 -> 0.72

Unit AI

Overkill prevention, the system that prevents ten Scalpels firing at a single Glaive, is now available for Lobster and disabled for units set to hold. It is controlled by a state toggle that is hidden by default because there is very little reason to touch it. The state toggle can be enabled under Settings/Interface/Commands, and per-unit defaults to be set in Settings/Unit Behaviour/Default States, or by holding Space and clicking on a unit, then pressing Edit Behaviour. Lobster is smarter, no longer firing unless there is a visible valid target.

• This prevents it from firing when it would do absolutely nothing, provided there are no invisible enemies nearby.
• As a result, telling a tight clump of Lobsters to fire causes only two to shoot.
• This behaviour can be configured with the hidden Overkill Prevention state.
• Removed the Force Fire command by default. This can be configured via another hidden state toggle.

Overkill prevention is now suspended by default when units are set to Hold Fire.

• Added the "Enable for Fire at Will" and "Enable for auto targeting" states. Previously it just had enabled/disabled.
• Most units default to "Enable for Fire at Will". The theory being that if you set a unit to hold fire you care more about its target dying than about overkill.
• Nothing defaults to "Enable for auto targeting", but it may be useful to try out.

Impaler now has an even stronger preference for targeting structures over units.

Interface

• Added a minimum wind icon and number to the left column of the wind generator tooltip during placement (thanks Porkchop)
• Cleaned up some inconsistent unit highlighting and selection. Units under interface panels cannot be clicked on by default, tooltips do not appear, and units are not highlighted.
• Selecting through the panel at the bottom of the screen can be configured under Settings/HUD Panels/Selected Units Panel.
• Drag selection can still terminate over a UI panel.
• Add some translations for the commander selector.
• Updated Global Build AI with some fixes and documentation (thanks esainane).
• Added username team colour in chat and removed white outlines for dark names (thanks Birdulon)
• Local widgets are no longer disabled for spectators on rooms with local widgets disabled.
• Added Italian translations for the main menu (thanks fvasco)

Campaign

• Tweaked campaign text and replaced some Artefacts with more suitable structures (thanks Thorneel)

Maps

• Added boxes for Onyx Cauldron 2.0
• Improved lighting on Skulduggery (thanks Shaman)
• Improved water on Cull, Lost v2 and Lowland Crossing Revised v2.
• Fixed an issue with void water with new shaders on some graphics cards.

Artefact Control

Added a control point game mode called Artefact Control under Experimental.

• Several artefacts are spawned on each side of the map.
• Each team controls half at the start of the game.
• Artefacts have 11k health and heal at 100 hp/second.
• Artefacts respawned with switched allegeance when destroyed.
• If a team controlls all the artefacts, they win.

Modding

Changed some keys in unit def files to match the lua UnitDefs table. Mods with the old keys are still supported.

• buildCostMetal -> metalCost
• buildCostEnergy -> energyCost
• energyUse -> energyUpkeep
• metalUse -> metalUpkeep (vanilla ZK doesn't use this)
• maxDamage -> health
• maxVelocity -> speed

Other changes.

• Unit defs no longer require unitname since it must match the table key, so it is redundant.
• Unit defs are now also read from subfolders of 'units'.
• Set undefined burst rates to 0 (rather than 0.1) as it can interfere with weapon modding.
• The game exits to menu when unit defs fail to load, rather than crashing.
• Added game-side GG.UnitModelRescale(unitID, scale) from Unit Level Ups.
• Added backwards compatibility for Spring.GetUnitIsBeingBuilt.
• Fixed backwards compatibility for Spring.GetPlayerRulesParams.
• Added customparams.buggeroff_angle for factories, in radians.
• Added customparams.metal_extractor_mult to support the creation of higher tier metal extractors.
• Fixed modding away the Sniper reload move penalty breaking the script.
• Cleaned up the build icon generator gadget.
• Napalm effects now contain an example of sin (replaces taylor series).
• Improved modded energy generator tooltips.
• Mexes suport morphing.

Fixes

• Fixed commshare sometimes preventing resign or causing a crash when the game ends.
• War music no longer counts morph as violence.
• Fixed missing vote resign button.
• Marginal turret overshoot can no longer be circumvented with command insert.
• Fixed a few build icons incorrectly implying that a floating structure is built underwater.
• Fixed commander selector button image.
• Fixed backwards 'motion blur' on ejected shells.
• Fixed some large structure wreckages having much too large collision volumes.

[ 2023-08-26 07:12:48 CET ] [ Original post ]

Get ready for the next Zero-K tournament, a 1v1 tournament where dozens of commanders will fight for dozens of dollars. The format is bo1 double elimination but other details have not been fully finalised. Sign up with a comment on the thread and send any questions to Kingstad. If you are more interested in watching, then games can be spectated through the lobby or you can watch one of the commentary streams linked on Discord. Date: July 8th [Saturday] 2023 Time: (3 PM EDT | 9 PM CET | 1900 UTC) Countdown to Tournament Forum Thread A commentary stream There was also a minor update this weekend. It is mostly fixes for the previous update, but there are also a few features and balance changes.

Balance

Redback is worse at dodging projectiles.

• Increased collision shape width by 11% and length by 25%.
• Reduced turn rate by 5%.

Ogre now ignores terrain and wrecks when aiming and firing. It has sufficient AoE and arc for making the attempt to often be beneficial. Zeno now homes onto the actual position of a radar target earlier - early enough to hit it.

Features

• Holding Alt while selecting units now filters out rank 3 (ie army units).
• Added a sudden death mode game option, under Map. It causes the game to end shortly after a specified time via a contracting death circle.

Fixes

• Fixed a missile impact indicator error.
• Fixed a pathfinding issue to do with construction orders on terrible terrain.
• Tactical missiles no longer have inconsistent half-prediction of enemy velocity. They now fire exactly where they are aimed.
• Fixed contrast adaptive sharpening scaling with zoom level.
• Fixed moderator tooltip colour in the lobby.
• Improved Pylon collision and selection volumes.

[ 2023-06-24 12:37:51 CET ] [ Original post ]

The 3v3 tournament finished earlier today with an excellent turnout of 19 teams. The results and videos will be posted in this thread in the coming days. The upshot for this patch is that we are free to make a few balance changes. The aim of these changes is to work on a few of the more maligned units, while nerfing some of the most prevalent strategies. This mostly means buffs for Gunships and nerfs for Lance and cloaked Snitch. The update also has some exciting features. A big one for team games is that allied nukes and missiles now automatically show where they were aimed, which should halve the number of people that panic when a nuke is fired. Another is the ability to watch any game while waiting for a different one to start without missing out on the chat, as chat from non-started lobbies is now sent ingame. Superintendent has also added a few more tracks to his alternate soundtrack.

Balance

Snitch is slower to nerf its use with cloaker, without making it worse as a pure ambusher.

• Speed 117 -> 108

Iris is a bit easier to find and its area cloak radius now matches area shield radius.

• Speed 57 -> 54
• Decloak range 180 -> 210
• Cloaker radius 360 -> 350

Lance is less effective when set to fire at will.

• Reload time 20s -> 23s

Scallop is still the slowest riot but is a bit tankier than average.

• Health 1100 -> 1200
• Speed 48 -> 51

Emissary can afford to be fast since it takes so long to pack up.

• Speed 60 -> 63
• Range 1120 -> 1150

Blastwing takes less time to deal its damage and deals slightly more.

• AoE 128 -> 144
• Fire DPS 25 -> 32
• Fire linger 25s -> 20s

Gnat needs more health to survive long enough to stun the juiciest target.

• Cost 90 -> 85
• Health 370 -> 440

Revenant can be brought back now that commanders are more resilient.

• Health 3600 -> 4200
• Missiles 8 -> 9
• Reduced missile wobbly be 6.7%

Stardust has a small buff to its damage output but might still need a larger change later.

• Heat per shot 3.8 -> 3.5

Lucifer can see as far as it can shoot (thanks Majo).

• Range 780 -> 1280

Game Features

• Added predicted impact time and location for allied nukes and stockpiled missiles (thanks esainane).
• Added a new Superintendent music track.
• Hovering a unit with the mouse now highlights it slightly. This can be configured under 'Settings/Graphics/Unit Visibility'.
• Alt+N terraform preset is slightly higher to block Phantoms firing at Engineer Commander.
• Added Set Target (instead of Force Fire) on Right Click option under 'Settings/Unit Behaviour'.
• Added time and space leeway settings to make selection easier, under 'Settings/Interface/Selection'.
• Added an explanation of selection rank to 'Settings/Interface/Selection' as people find fiddling with it surprisingly useful.
• Embiggened cursor hitboxes of Grizzly, Jugglenaut, Cyclops, Shield Factory and Cloak Factory.
• Singularity Reactor size now fluctuates.
• Impaler fire sound is slightly fainter and only five can play at once.

Lobby Features

• Battles can now be watched by right clicking on them in the battle list and selecting 'Watch'.
• Chat from any lobby you are in is sent ingame if the lobby is not running.
• Added a new Superintendent track that plays when the lobby opens.
• Mention Imp burrow in the tips for the Imp campaign mission.
• Added a game option to override the names of teams for tournaments.
• Added a game option (under Experimental) called Notes that just writes text to a window at the start of the game. Use it to explain unit tweaks or other complicated set of options.

Fixes

• Preselection highlight (when hovering over units) now highlights units correctly in edge cases.
• Fixed the player count in the battle lobby status box updating slowly.
• Fixed units set to avoid radar wobble not firing at identified structure dots that left radar.
• Fixed Advanced Geo aim point (thanks dyth68).
• Fixed Mariner special build icon size.
• Healthbars and Build ETA now draw in front of unit outlines.
• Fixed an error that could occur when destroying all the units of the losing team.
• Phoenix gibs no longer include a near-complete copy of its fuselage.

[ 2023-06-18 10:38:28 CET ] [ Original post ]

This is mostly a fixes and tweaks update as the 3v3 tournament is only in two weeks. Everyone is welcome as each team must have a new player. Sign up in this thread if you are interested. There are two big balance changes: nerfs for superweapons and shields being disabled underwater. Aspis can now float, to give it some use in sea, and floating has been improved in general. The superweapon changes were motivated by some of the epic games on the large maps added in April. Starlight is much more expensive as it is the best at ending games, but games were ending a bit too early. Disco Rave Party and Zenith were differentiated by leaning into the slow aim and rate of DRP compared to the instant response of Zenith. Thanks for all the feedback in the thread on the forums. The most notable fixes are for the rare Zenith gathering bug and the Fencer/Bulkhead transition issue. There are also many backend improvements to scripting and the engine (which was updated earlier in the week), some of which are relevant to modding and listed in a section below. More Chinese translations have been contributed and a few campaign missions have been tweaked based on feedback.

Balance

Shields are disabled when the unit carrying them is submerged.

• The disable is the same as any other disable. Charge drops to zero and linking does not work.
• The unit must be completely underwater. This is the same threshold at which cloak is disabled and units are no longer detectable by non-sea vision.

Aspis can now float and floating in general has tweaks to help it stay above water.

• Units lobbed or gravity-gunned into the sea can float immediately.
• Note: This was already the case for sea-to-sea lobs and transport throws.
• Floating units no longer sink while teleporting.
• Note: Teleporting from land to the sea will still put the unit on the sea floor.

Cloak is cancelled immediately after a unit takes a decloaking action (such as firing). This was always the intention, but at some point action decloak gained a random delay of up to a third of a second. Cornea no longer pays for personal cloak while area cloaking.

• This reduces its effective energy drain by 1 energy per second.

Firewalker is less indiscriminate.

• Now checks whether a friendly unit is directly in front of both barrels before firing.
• Aims a little higher for more clearance.

Zenith costs a bit more as part of a general superweapon nerf, but has more range.

• Cost 36k -> 38k
• Range 8400 -> 8800
• Fixed a rare bug that would transform it into an expensive doorstop.

Disco Rave Party costs a bit more and leans hard into directionality.

• Cost 40k -> 42k
• Health 12k -> 8k
• Range 7500 -> 7000
• Aim speed 4 degrees/s -> 2.5 degrees/s
• Full spin up time 1 -> 2 minutes (via reduced acceleration at high spin rates).
• Spin speed is now lost while turning, with greater losses at high spin.
• Eg a 45 turn drops spin 100% -> 58%, a 90 turn drops spin 100% -> 33%.

Starlight is much heavier as it is the superweapon that truly ends games.

• Cost 45k -> 60k
• Health 7500 -> 12k
• Range 10k -> 12k

Campaign

• Allied AIs are now Hard AIs on Normal difficulty (previously they were Normal AIs).
• Replace allied Merlins with Dantes in a few missions as they are prone to friendly fire.
• Adjusted partially built superweapons to leave cost-to-complete unaffected by balance changes.
• Moved Disco Rave Party slightly closer to the enemy base to partially account for its lower range.
• The mission briefing box now expands to avoid using a scrollbar for the tips section.
• Added a hint about mex income sharing to some of the first planets with allies.
• Made the hints for the Krow mission say a bit more about how to use Krow.
• Added a hint explaining Retreat Zones to the Krow mission.
• Cut hints down to four for Kirdipan (since the window is now expanded to show all hints).
• Fixed Romolis victory condition not checking for Merlins.

Maps

• Added start boxes for Supreme Strait.
• Improved lighting on All That Glitters.
• Fixed Timna Island box names.
• Enable alternate diagonal boxes for Calayo.
• Fixed small teams boxes for Angel Crossing.
• Added boxes for Pillar of Doom.
• Improved the widget that lets people tweak and save water and lighting tweaks.

Graphics

• Aegis spin animation is now based on shield charge (thanks Mach56).
• Improved line of sight rendering with AMD graphics (many cards were using a shaderless fallback).
• Contrast adaptive sharpening weakens when zooming out to counteract the grainy effect.
• Reenabled contrast adaptive sharpening by default.
• Added a subtle bloom shader.
• Bumpmapped water is now default for Lowest graphics as the others barely work.

Interface

• Added huge nuke warning toggle ingame under Settings/Accessiblity (thanks dunno).
• Improved the "Skip pregame chat" button on the replay controls.
• Language change updates unit selection texts immediately.
• Added translation capability for Zeno.
• Updated Chinese (both simple and traditional) translations (thanks Kitty, evilblue, et al).
• Updated Polish translations.
• Tweaked unit reply volumes slightly.

Modding

• Zeno no longer counts for Turtle Shell (but would have needed to deal real damage).
• Custom submarines now detected as such for Context Menu properly (instead of as ships).
• Added LUS preprocessing which translate uses of SFX.*, COB.*, math.{pi,tau}, math.{rad.sqrt}(constant) into constants. Local optimisations for these functions or tables should be removed.
• "morphUnitCreating" is now a game rules param (was team rules param).
• Added gadget:GamePaused(playerID, isPaused) to gadget handler.
• Chicken drone morphs now done via customparams.
• Missile silo automatically works with any custom missiles you add to the buildlist.
• Custom missile silos can exist and have moddable stockpile capacity via missile_silo_capacity customparam (still needs script support).
• Removed old nuke/antinuke models.

Fixes

• Fixed Zenith occasionally failing to gather meteors.
• Fixed Fencer and Bulkhead occasionally failing to transition between states correctly.
• Fixed always-floaters that teleport to from land to sea not automatically floating.
• Fixed cloak not being disabled on units when they are reclaimed.
• Fixed area cloakers with personal cloak erroneously being charged for personal cloak.
• Fixed the live unit reclaim tooltip using the old value (50%) rather than the new one (80%).
• Fixed an error upon comshared resign (thanks Shaman).
• Fixed debris texture.
• Fixed Zeno not being autogroupable (thanks Shaman).
• Fixed a rare crash to do with terraform.
• Fixed a bug where disabling units could break a factory.
• Increased Lua memory limit.

[ 2023-06-04 07:28:23 CET ] [ Original post ]

Brace yourselves for the exhilarating Zero-K 3v3 Tournament, where battle-hardened veterans and fresh faces unite to claim victory! Gather your forces, for this is your chance to prove your mettle on the grandest stage of strategic warfare. Date: June 17th [Saturday] Time: Sunday, 18 June 2023 03:00 (1 PM EST | 7 PM CET | 1700 UTC) Forum Thread Challonge Registration Countdown to Tournament

Registration

Enlist your team in the tournament by posting on the dedicated forum thread or signing up on Challonge. Each team must include at least one new player, adding an exciting twist to the competition. Embrace the opportunity to mentor and fight alongside budding commanders. Don't forget to provide your team name to ensure your presence is duly acknowledged. Curious about the eligibility of new players? Fear not! A new player is defined as someone who meets either of the following criteria at the time of registration:

• Playing Zero-K for less than 10 days.
• Having played fewer than 30 PvP games.

Should your teammate not fit these criteria but you believe they deserve an exception, reach out to MDSK Discord or in the forum thread above.

[ 2023-06-01 15:13:48 CET ] [ Original post ]

For this update we looked through the new maps from the wider Spring (now Recoil) community and featured a bunch of them. Some will play better than others, but that's what feedback is for! The update also adds translations for Chinese and Italian, and includes an engine update that was benchmarked to improve framerate by 9%. In terms of balance there are nerfs for Reaver and Lance and a cost reduction for Krow. The unit reply sounds have also been rebalanced.

New Maps

We have featured 67 new maps, with many from BAR or raaar. Some are makeovers of classics, others are new takes on a theme, and many are completely new. There are many large maps suited to big team games or comp stomps: Alpha Siege Dry, Ancient Vault, Bismuth Valley , Carrot Mountains, Darkside (v3.0), Eight Horses, Fool's mate, Entrenched Plains, Heartbreak Hill, Highway 95 East, Highway 95 West, High Noon Remake, Ice Scream (v1.1), Ice Scream (v2.4), Omega Valley, Pawn Retreat, Red River Remake, Red Triangle Remake, Riverrun, Silveridge, Sphagnum Bog, Starwatcher, Taldarim, Two Continents Dry, Two Continents. These maps are a bit smaller, good for 1v1 or small team games: Callisto, Death Valley, Desert (3.25), Desolation, Ditched, Dockside, Hades Ponds, Hexian Arena, Lake Carne, Mithril Mountain, Scorched Crossing, Theta Crystals, The Halite Maze. Some particularly experimental maps are: Crucible, High Forts, Hooked, Sky Fortress Sigma. The maps Point of No Return and Timna Island are designed for chicken or coop games as they are asymmetric, with one side starting in a fortress. The following maps are updated versions of classics, although many will feel new as there are a lot of maps to play through: Altored Divide Bar Remake, Coastlines Dry, Comet Catcher Remake, Copper Hill, EmainMacha Remake, Incandescence Remake, Highway 95, Hotlips Remake, Icy Crater, Into Battle Redux, MoonQ20XR2, Nuclear Winter Bar, Ravaged Remake, Seths Ravine Remake, Supreme_Crossing, Tabula Remake, Tangerine Remake, The Cold Place BAR, The Hole, The Rock, Tumult Remake, Valles Marineris, Zed Remake. Predicting which maps will or won't work is tricky, so send feedback. Old versions of revamped maps were left up as they may be distinct enough to coexist or there could be a problem with a new map.

Balance

Live unit reclaim yields 80% of the cost of the unit in metal, up from 50%. Reaver is 7% worse both at firing and turning.

• Turn rate 1850 -> 1710
• Reload time 0.467s -> 0.5s

Conjurer is slower to nerf cloakbot expansion rate.

• Speed 57 -> 54

Thug is better at hitting things.

• Weapon velocity increased 200 -> 210

Rogue is also better at hitting things.

• Weapon velocity 185 -> 190

Ravager is also also better at hitting things.

• Weapon velocity 238 -> 245

Lance is probably due a nerf of some sort and cost is simple.

• Cost 1000 -> 1100

Krow needs a buff to make it relevant to modern Zero-K.

• Cost 4500 -> 4200

Superweapons have 25% less health to make them easier to snipe.

• Starlight health 10k -> 7.5k
• Disco Rave Party health 16k -> 12k
• Zenith health 12k -> 9k

Added an experimental game option that reveals superweapons that exceed 5% build progress. It isn't on by default, but could be interesting to test.

Interface

• Added Chinese and Italian translations (click the flag in the top right of the screen ingame).
• Cleaned up a few unit reply sounds and rebalanced them relative to each other. Most replies are a bit quieter.
• The tab playerlist share resource buttons now take your storage into account to display how much will actually be shared.

Mapping

• Added a game-side lava gadget so that mappers can create lava maps without copying code into the map file. Maps can add lava by including the file "mapconfig/lava_config.lua". See here for the parameters and here for an example. It even supports tides.
• The startbox editing tool can now be toggled under Settings/Toolbox. This makes it hotkeyable provides space for a hotkey explaining how it works.
• Added vertex-wise undo, snap to cardinal direction, and snap to map edge to the startbox editing tool.

Fixes

• Fixed UI scale detection for screen resolutions in the 2000s (ie 2560x1440).
• Reset everyone's UI scale settings to catch people who where affected by the issue above. Set Lobby or Game Interface Scale in the main menu under Settings/Lobby and Settings/Game.
• Fixed menu volume resetting when the track changes.
• Fixed and reset the non-functional Unit Reply Volume slider.
• Improved the performance of the map list.
• Toggling "Only Featured Maps" in the lobby updates a previously opened map list correctly.

[ 2023-04-12 15:41:15 CET ] [ Original post ]

This update introduces Zeno, the 5th missile for the Missile Silo, which homes onto a target, hits it for a massive dose of slow damage, and then leaves lingering slow in the surrounding area. Another major change is an increase in general unit visibility via a few nerfs for area cloakers. As usual, there are a few months of fixes, features and, contrary to the title, performance improvements.

New Missile

Added Zeno, a homing slow damage missile built in the Missile Silo.

• Has significant range, equal to Quake.
• Homes onto its target.
• Deals 10k slow damage to a single target.
• Interacts with shields similarly to Eos, as 10k slow damage is 3333 damage to a shield.
• Leaves a large area of lingering slow damage for 30 seconds.

Cloak Fields

Many players felt that cloak was a bit too prevalent and that whether to use it lategame wasn't much of a choice. We address this with a few targeted nerfs to area cloak. Most notably, Cornea has a directional cloak field rather than a huge bubble, and larger armies are slower to cloak. The latter is implemented with the new cloak rate mechanic.

• Area cloakers now apply cloak at a set rate, starting with units closest to the centre of the bubble.
• Cloak rate is in terms of mass per second, and only spent on units that are ready to cloak.
• For reference, Bandit has 90 mass, Lance about 300, Dante about 800, and Detriment about 2400.
• Cloak can still be maintained on any number of units.
• Units with personal cloak are unaffected. They don't wait to be cloaked, and don't spend cloak rate that could be used on other units. This includes units that cloak while stationary.

Cornea cloaks a much smaller area, but the area can be moved with Fire Special Weapon (D).

• Jamming range 550 -> 600
• Cloak field range 550 -> 400
• Can shift the centre of its cloak bubble up to 200 elmos away
• Has a cloak rate of 1200 mass/s

Iris has a small range reduction and cloaks at a slower rate than Cornea.

• Cloak field range 400 -> 360
• Jamming range 400 -> 360
• Has a cloak rate of 800 mass/s

Commander Area Cloak loses a similar amount of cloak range and has the same cloak rate.

• Cloak field range 350 -> 320
• Jamming range (with cloak field module) 350 -> 320
• Has a cloak rate of 800 mass/s

Conjurer is the most efficient cloaker in terms of cloak rate per cost.

• Has a cloak rate of 600 mass/s

Balance

Puppy now leaves wrecks and debris when killed, but not when it hits a target. Previously it left nothing. Imp now only barely "makes cost" against a lone Scorcher.

• Cost 120 -> 125

Snitch costs a bit more to spam.

• Cost 160 -> 170

Cyclops slowbeam had a bug that made it do 3x the intended damage to shields.

• Slowbeam damage to shields 2000 -> 666

Hercules can reach the ground and lift everything.

• Fixed a weapon bug that caused its laser to not reach ground units while cruising.
• Can now transport Shogun and Reef.

Advanced Radar is a bit too good after its cost reduction from 500.

• Cost 400 -> 450

Maps and Campaign

• Added Zeno to planet Nataa (the Missile Silo mission).
• Tweaked planet Mstaras (the Gunship Factory mission) to be a bit easier on difficulties below Brutal.
• Added startboxes for Angel Crossing, Calamity v1.1 and Supreme Crossing V2.
• The "Sun, Fog & Water" map tweaking tool now loads its defaults from map settings.
• Added shadow density to "Sun, Fog & Water" map tweaking tool.
• Added compatibility for more metal layout standards.
• Removed map fog by default. This is the type that was visible when zoomed out.
• Tweaked the lighting and water settings on a few maps.

Graphics and Interface

• Reordered battles in the multiplayer lobby to put empty autohosts below running games.
• Build spacing UI has more options, found under "Settings/Interface/Building Placement".
• Added a contrast adaptive sharpening shader. It can be enabled under Settings/Graphics/Effects with "Sharpening".
• Added notable death explosion to ingame unit help menu (accessed via space+click).
• Added better support for flipping the minimap, which is useful when used with a flipped camera.
• Added a widget that displays map info like a label on a painting. Disabled by default.
• Fiddled with the way line of sight adds to radar. This unlocks more ways to customise radar coverage.
• Tweaked war and peace detection to spend a bit more time playing peace music.
• Fixed slight visual misalignment when Missile Silo launches missiles.

Fixes

• Improved performance of game mechanics that handle orders.
• Fixed significant framerate drop (with certain settings) caused by many multi-weapon striders firing at once.
• Fixed kicking a spectator sometimes causing a player to resign.
• Fixed X-Ray shader issues on some hardware.
• Fixed a rare bug with jumpjet behaviour.
• Fixed a rare crash in the tab playerlist.
• Fixed missing text on shield charge bars.
• Blitz description no longer mentions its old EMP death explosion.

[ 2023-03-19 11:29:23 CET ] [ Original post ]

This patch has an engine update, some superweapon tweaks, and extra gridding. Strider Hub now requires 50 grid energy. This is targeted at rushes in big team games, as every other use of Strider Hub should not have trouble finding 50 energy. The engine update changes how graphics states are handled over multiple games, which should improve load times and performance. Bertha now requires a grid connection and is a bit better at knocking down walls. Grid for Bertha has been frequently requested for a long time, probably for thematic reasons, as finding 50 energy seems easy for most Berthas. Zenith had a large buff to knocking down walls just over a year ago, which turned out to be too much, so is slightly worse at it. Starlight aims slightly slower to give defenders a little more time.

Balance

Strider Hub requires grid to place striders and to spend resources.

• Requires 50 grid energy to function.

Big Bertha requires grid and is better at knocking down walls.

• Requires 50 grid energy to function.
• Smooth radius 96 -> 120
• Smooth effect increased 40% -> 50% (matches Zenith)
• Structure smoothing multiplier 0% -> 25%

Zenith is worse at knocking down walls.

• Smooth radius 140 -> 120
• Structure smoothing multiplier 100% -> 50%

Starlight has reduced aim speed to enable a bit more counterplay, and because slow means epic.

• Pitch rate 1.2 -> 0.75 deg/s (37.5% nerf)
• Yaw rate 3.5 -> 2.5 deg/s (28.5% nerf)

High Density Plating was erroneously applying its improved form to all chassis.

• Health for Strike, Recon, Engineer 2000 -> 1600

Features

• Added the lobby option 'Equalize team commanders' under 'Start' to balance uneven custom games.
• Improved performance and load times.
• Added GameID to game rules params (widgets can read it).

Fixes

• Fixed wrecks dropped by jumping units snapping to the ground.
• Fixed commander experience not being updated correctly when upgrading.
• Fixed water visuals on some maps (water was a bit too opaque).
• Energy content no longer effects reclaim highlight colour (for mixed resource map features).
• Ctrl-Click auto morph for structures is now disabled by Shift.
• Fixed blast radius indicator for EMP blasts (Imp).
• Improved the sun on Delta Siege Dry Deluxe V3.

[ 2023-01-21 05:18:18 CET ] [ Original post ]

Commanders are more diverse and generally a bit cheaper to morph. On top of this, each chassis has more effective versions of modules that align with the speciality of the chassis. Weapon and upgrade costs have been reworked at level 4 to make more sense. Modules were tweaked to buff most types of commander, with nerfs for builds that stack range and speed, as those were a bit too strong. Repeat modules are now limited to 5 rather than 8, and many have chassis-specific buffs. Range and speed modules are more expensive, eating into the cheaper morph cost at level 4, while other modules have the same or greater effectiveness. Campaign commanders can still stack 8 repeat modules, and gain the benefit of most speciality buffs, because that just seems like fun. There are some non-commander changes too, such as nerfs for Cloakbots, buffs for Spider, and greater restrictions on gunships leaving the map.

Commanders

Weapon and upgrade costs were shifted around to make a bit more sense. Level 4 is up to 200 metal cheaper than before.

• A "Beam Laser" option is now available at level 2, replacing "No Weapon"
• All weapons at level 2 are now free (cost 25 -> 0)
• Level 4 base cost 650 -> 150 (now base cost always increases by 50 per level)
• Picking "No Weapon" at level 4 actually results in no weapon
• Basic weapons at level 4 cost 25 -> 350
• Advanced weapons at level cost 100 -> 400

Generic modules now have a limit of 5, rather than 8. Commanders will generally be a bit more powerful earlier as many modules were buffed in some way, however, a few were nerfed. The module limit in the campaign is still 8.

Module Changes

Speed penalties for modules are now a percentage of speed - after flat bonuses - rather than a flat penalty. Overall this increases the speed penalties for commanders that stack High Powered Servos, while often buffing other builds. Damage Booster is more effective and usually costs less speed.

• Damage boost 10% -> 15%
• Speed penalty flat 1 -> 2% of total speed

High Density Plating costs much less speed.

• Speed penalty flat 3 -> 2% of total speed

High Power Servos is denser but slightly less efficient.

• Cost 150 -> 200
• Speed boost 3 -> 3.5

CarRepairer's Nanolathe is also slightly less efficient, but now it is nice and round.

• Cost 150 -> 200
• Build power boost 4 -> 5

Adv. Targeting System costs more metal and speed.

• Cost 150 -> 200
• Speed penalty flat 1 -> 3% of total speed

Personal Cloak usually costs less speed.

• Speed penalty flat 8 -> 12% of total speed

Chassis Changes

Some modules are more effective on appropriate chassis. The specialisation bonuses listed below are relative to the newly tweaked modules. Guardian gains 25% more health from modules.

• Ablative Armour health 600 -> 750
• High Density Plating health 1600 -> 2000

Strike gains more regeneration from modules but loses the buff by level 6.

• Autorepair regeneration boost 10 -> 12
• Rescaled innate regeneration 5/5/10/16/25/35 -> 5/8/12/16/20/25

Engineer gains more buildpower from modules, turning the module tweak into a buff.

• CarRepairer's Nanolathe buildpower boost 5 -> 6

Recon gains more speed and can lower its jump cooldown, at the cost of poor buildpower.

• High Power Servos speed boost 3.5 -> 4
• High Power Servos reduces jump cooldown by 1 second
• CarRepairer's Nanolathe buildpower boost 5 -> 4

Campaign Chassis is generally more powerful, as that seems fun.

• Gains all the module specialisation bonuses listed above, except for buildpower.
• Gains 5 buildpower from CarRepairer's Nanolathe, to keep its numbers round,
• Now has Strike-level innate regen (up from 5 at all levels)
• Removed Strike innate jamming, as it was added accidentally.

Weapon Changes

A few less popular weapons have been buffed. A bug that caused Shotgun, Flamer and Heatray to only benefit from every second range module has been fixed. Shotgun regains the range it lost for technical reasons, and fires faster.

• Range 264 -> 285
• Reload 2s -> 1.8s

Cluster Bomb has more damage in the form of an extra projectile, and more spread.

• Projectiles 8 -> 9
• Spray angle increased by 20%

Concussion Shell deals a bit more damage.

• Damage 750 -> 850

Balance

Ronin is slower when in battle and a little easier to kill.

• Health 400 -> 380
• Moves at 80% while reloading

Reaver cares more about incidental health loss.

• Regeneration rate 20 -> 15 health/second

Flea is more dangerous.

• Damage increased by 14.3%

Venom now has an Avoid Bad Targets toggle.

Fixes

• Aircraft that go too far off the edge of the map are now "gently" pushed back in.
• Shotgun, Flamer and Heatray now gain range correctly.
• Fixed Recon's shaky aiming while walking.
• Players and AIs that fail to place a start position are now cycled through defaults, rather than selecting the first.
• Fixed a few outdated module tooltips on the campaign UI.
• Renamed "Save / Load" in Campaign to "Profile".
• Improved the AI's commander morph choices.
• Speed is now displayed with a decimal place in Space+Click menu, as many units have increments of 0.5.

[ 2022-12-19 13:14:03 CET ] [ Original post ]

We have been testing an engine update since Wednesday, and this time it seems stable enough to adopt. The update corresponds to about ten months of work and mostly involves the graphics backend. As a result, performance has improved for many people and some AMD graphics issues have been fixed, although in testing we found the current beta graphics drivers to be unreliable. Be sure to ask on the forums or Discord if you encounter issues. The engine also has a few new features, with the biggest being the ability to shrink the space factories try to clear of allied units. The update also has some new music tracks from Superintendent and the commander morph rate nerf has been reduced.

Balance

Commander upgrade has its recent nerfs reduced, particularly at high levels.

• Morph rate 5/5/7.5/7.5/10/10/10... -> 5/7.5/10/12.5/15/15/15... per level

Features

• Performance should be improved for many people.
• Allied units can loiter much closer to factories without being told to go away.
• The auto assist toggle sends constructors directly sideways, to save time.
• Added more tracks by Superintendent.
• Show Selection Rank by default.
• Improve RoI tracker and add a hotkey to toggled it.

[ 2022-11-26 11:06:55 CET ] [ Original post ]

Dirtbag cannot go to space, commanders deal a little less damage, and economy coordination is smoother. New music tracks by the player Superintendent are now available ingame in the track list under Settings/Audio. Conjurer cloak has the largest nerfs since its inception, core cloakbots have small nerfs, and the assault vehicles are tankier. Paladin is a little harder to manoeuvre and Krow has a lot more damage, but with Krow being niche for so long it is hard to say how the balance will shake out.

Balance

Dirtbag hits slightly less hard and can no longer create very steep terrain.

• Health 580 -> 560
• Damage reduced by 13%
• Dropped dirt now has a slope limit (5x normal terraform slope).
• In particular, maximum thin spike height -> 700 elmos.

Conjurer is easier to find when area cloaking.

• Movement speed reduced to 66% while area cloaking.
• Area cloak cost 8 -> 10
• Jamming and area cloak radius 184 -> 175
• Decloak radius while area cloaking 184 -> 220

Ronin has reduced survivability.

• Health 420 -> 400
• Turn rate reduced by 15%

Reaver is worse at dodging and shooting.

• Turn rate reduced by 10%
• Range 270 -> 265

Mason is slower to slow down Rover expansion.

• Speed 72 -> 69

Ravager is tankier and better at hitting mobiles.

• Health 1920 -> 2000
• Projectile velocity increased by 5.7%

Minotaur is also tankier and better at hitting mobiles.

• Health 6800 -> 7200
• Projectile velocity increased by 2%

Krow bombs are easier to target and its laser now demands respect.

• Manoeuvrability while bombing 25% reduction -> 25% increase
• Speed while bombing is still reduced by 25%
• Reduced cluster bomb spray angle by 6.6%
• Increased laser fire tolerance by 10%
• Laser range 383 -> 395
• Laser DPS increased by 19%

Paladin is less manoeuvrable.

• Speed 46.5 -> 43.5
• Turn rate reduced by 10%
• Torso turn rate reduced by 10%
• Head turn rate reduced by 20%

Commanders

Strike chassis gains a unique attribute at level 1.

• Added innate jamming with 175 radius (matches Conjurer)

Guardian loses the free battle drone as it is too powerful.

• Removed free battle drone on level 5.

Morph is slower but cheaper at higher levels.

• Morph costs 75/100/650/200/300/400/500... -> 50/100/650/200/250/300/350...
• Morph rate 10/15/20/25/30/30/30... -> 5/5/7.5/7.5/10/10/10...
• Basic weapon cost 5 -> 25

The most common weapons mostly have damage nerfs while Flamethrower has a buff.

• Beam Laser DPS reduced by 4%
• Light Particle Beam DPS reduced by 8%
• Disruptor Beam DPS reduced by 6%
• Riot Cannon reload time 1.63s -> 1.8s
• Riot Cannon range 300 -> 285
• Rocket Launcher projectile velocity reduced by 6%
• Rocket Launcher area of effect 96 -> 90
• Flamethrower DPS increased by 13.6%

Team Economy

Constructing your economy as a team is easier as shared projects now generate shared payback.

• Temporary payback for constructing mexes and energy is now proportional to the amount of resources spent on each structure, rather than only paying the owner.
• Mex payback increased 50% -> 80%.
• Energy payback increased 50% -> 60%.
• Energy maximum payback rate increased by 6%.
• Fixed a bug that caused the old mex payback to be closer to 35-40%.
• Fixed payback sent to AFK players simply disappearing.

Unit AI

Some units gain the Ronin Lotus-fighting AI and other units shoot less at hidden mexes.

• Added Lotus and running away on firing to Moderator and Scalpel.
• Ogre only shoots at nearby hidden mexes, not though at max range.
• Crab doesn't shoot at hidden mexes.
• Krow now skirmishes everything to avoid enemies walking under it.
• Tweak move clumping to be slightly more lenient for large units.

Music

• Added a work-in-progress alternate music track by Superintendent.
• It can be enabled ingame under "Settings/Audio/Track list".

Campaign

Zhurou (DRP) is a bit easier on Easy.

• Shifted Detriments later on Easy.
• Added an allied antinuke on Easy.
• Added a player Fusion on Easy and Normal (for some energy leeway).

Hibiliha (Funnelweb) is also a bit easier on Easy.

• Added Ultimatum temporary unlock.
• Hampered initial enemy income on Easy by removing backline mexes and the remaining Fusions.
• Thinned out initial enemy army on Easy.

Features

• Improved Pyro firing animation.
• Ctrl+Click formation move now obeys current maximum move speed.
• Merged unit spotter widget improvements from rollmops.
• Adv Geo blast radius shows while placing Geos.
• Tweak the antinuke range lines to be slightly thinner.
• Placing a morphable structure with Ctrl held now queues the morph after completion.
• Antinuke now gains one level per nuke interception.
• The stealth tag is now supported for modding.
• Right clicking on a unit in a factory now guards the factory. This avoids accidentally repairing rather than assisting. Queuing a command after guard cancels the guard, so the common use case is preserved.
• Self destructing a large portion of your stuff now blocks the command and prints a warning, rather than automatically resigns. Note that resign is bindable for those that want it.

Fixes

• Saved 10% or so of allocated Lua memory.
• Limited the commands created by large area attacks for performance reasons.
• Reduced the complexity of Dirtbag animation at high unit counts.
• Fixed overwriting existing guard commands with Shift sometimes not removing the command.
• Fixed Caretaker guard order dropping logic.
• Fixed rare build ETA crash for spectators.
• Fixed a crash for mods that try to set fractional stun times.
• Fixed some changes to the ingame menu for player based hosting (Skirmish and Steam Coop).
• Fixed a mixup in skirmish behaviour between 2D and 3D range.
• Fixed a value in the terraform raise/lower tooltip.

[ 2022-11-19 14:56:46 CET ] [ Original post ]

The Rogue nerfs continue, Redback can now beat a Reaver, and Firewalker has its first change in years. Phantom slows to 66% speed to reload its gun (maybe the auto-loader broke?) to make them a bit easier to find, while Blitz and Pyro are a bit tougher in an attempt to bring them into the raider game. The skin swap 'easter egg' is gone, some animations are improved and some GC fiddling resulted in a performance improvement. A few new or remade maps now have start boxes, and the matchmaker map pool has been updated.

Balance

Ronin is a bit smarter.

• Steps away from Lotus while reloading (with Hold Position disabled or Attack Move).
• Updates aim direction more frequently to cut down on friendly fire.

Reaver has slightly less reach and manoeuvrability.

• Turn rate reduced by 10%
• Range 275 -> 270
• Projectile velocity increased by 5.5% to compensate

Phantom is easier to catch.

• Moves at 66% speed while reloading.

Rogue is costlier and a little easier to hit.

• Cost 125 -> 130
• Turn rate reduced by 10%

Thug requires more downtime between uses.

• Shield regen 14/s -> 13/s

Redback kills Glaive in three shots.

• Damage 70 -> 80

Pyro is tougher.

• Health 670 -> 690

Firewalker deals less damage.

• Direct damage reduced by 15%
• Ground burn damage reduced by 5%

Blitz is tougher.

• Health 1250 -> 1300

Emissary takes less time to pack and unpack.

• Gun turns 14% faster.
• Increased projectile velocity by 1.6%.
• Slightly lower arc.

Lance is less likely to be overshot by inaccurate projectiles.

• Lowered aim position.

Picket is no longer 1-shot by Rogue.

• Health 300 -> 340.

Previous Changes

Zero-K v1.10.7.0 had some balance changes as well. Rogue has a slower and less damaging weapon.

• Damage 345 -> 330
• Projectile velocity 190 -> 185 elmos/s

Outlaw is faster and deals more normal damage at the cost of slow damage.

• Speed 57 -> 60 elmos/s
• Normal damage 27 -> 30
• Slow damage 81 -> 75

Map Rotation

The matchmaker map pool has been rotated and map bans have been reset. You can set your map bans by clicking 'Set Map Bans' in the matchmaker window or directly on the site here. The following maps were added to the pool.

• Reptilian Battlefield
• Altair Crossing v4
• Rainbow Comet
• Eye of Horus
• Aurelian

The following maps were removed from the pool.

• Dune Patrol Redux
• Sertaleina
• Desert Rumble
• Frosty Cove
• Trojan Hills
• Shimmershore

Features

• Improved Impaler, Phantom and Tidal Generator animations.
• Added a reload animation for Phantom (to give it a reason to slow down).
• Added start boxes for Lava Highground and Pentos.
• Added start boxes for remakes of Emain Macha, Flooded Valley, and Trefoil.
• Fixed uninspired name for kamikaze award.
• Fiddled with garbage collection settings to improve performance.
• Optimised drawing for morph effects and removed some redundant tables.
• Increased thickness of antinuke coverage indicator, so it is harder to miss.

Fixes

• Removed the unintended easter egg where units would occasionally swap skins.
• Blastwing cloak now breaks when the unit is launched.
• Reduced the linger of the map erase effect.
• Fixed the worst cases of units trying to shoot at underwater Amphibious Factories.
• Fix lights on Mount Dustmore.
• Fixed Spidermonkey web not rendering.
• Fix a crash in outline shader error messages.
• Fixed part of the cloak transition effect that had been disabled for engine compatibility reasons.
• Fixed geothermal vents not reacting to terrain changes on some maps.
• Fixed underscores causing issues for abuse reports sent via the ingame playerlist.
• Fixed inconsistent colours on team endgame graphs for spectators.
• Fixed ambiguous AI team names in AI vs. AI games.
• Fixed Missile Silo missiles not being removed from control groups as soon as they are launched (technically they only die after landing).
• Fixed a rare situation where command queues could be lost by adding a keybind to set units On or Off, then using the keybind with a selection of units that do not all have an On/Off toggle.

[ 2022-08-28 10:43:43 CET ] [ Original post ]

This update has nerfs to address the abundance of Lance in teamgames and Rogue in 1v1. It also has small nerfs for Bandit and Dirtbag, buffs for some underused units, and less effective area cloaking in combat. The release is a little early to avoid being too close to the upcoming 3v3 tournament (18:00 UTC, Saturday 9th July, sign up here), so some features didn't make it. We hope to have a fixes and features patch some time in July or August, which would ideally include an engine update, Adv. Options for mods, and some dodge AI.

Balance

Units without personal cloak now decloak for longer after acting (firing, building, etc).

• Non-personal recloak delay 6s -> 8s.
• Non-personal recloak delay for proximity is still 3s.
• For comparison, personal recloak delay is 3s for actions and 1.5s for proximity. Units with personal cloak use the personal delays even when under an area cloaker.

Dirtbag is slightly less tanky.

• Health 600 -> 580

Bandit has a range nerf that may be overdue since the pre-aim update.

• Range 235 -> 232

Rogue is easier to catch and slightly more expensive.

• Cost 120 -> 125
• Health 540 -> 520
• Speed 57 -> 54
• Turn rate reduced by 5%

Scalpel is more manoeuvrable.

• Turn rate increased by 5%

Claymore deals more damage at the edge of its area of effect.

• Reload time 3.2 -> 3.1
• Edge effectiveness increased to match Ripper
• Disabled avoid bad targets by default

Mace sight now matches the +25% weapon range rule of other riots.

• Sight range 407 -> 431

Lance is easier to catch when out of position, and is worse at hitting aircraft.

• Speed 52.5 -> 49.5 elmos/s
• Turn rate reduced by 10%
• Range 1000 -> 980
• Vertical aim speed reduced by 66%

Jack is worse at picking off raiders.

• Range 125 -> 122

Gremlin has better damage for its cost and slightly more range.

• Cost 150 -> 140
• Range 700 -> 720
• DPS increased by 3%

Locust deals more damage but is worse at healing.

• Autoheal 10 -> 6 hp/s (still activates after 5 seconds)
• DPS increased by 4%.

Harpy can more reliably snipe riots.

• Range 350 -> 360

Phoenix is tougher.

• Health 900 -> 1060

Fixes and Features

• Added Curacao flag.
• Unit marker can now be enabled for Widow.
• Scorpion and Ultimatum are now marked by unit marker each time they appear.
• GG.addUnitSlow now handles overslow.
• Made circular map API more reliable.
• Fixed a GL4 shutdown error on old hardware.

[ 2022-06-28 11:41:21 CET ] [ Original post ]

This release has a few fixes and improvements, and brings us up to date with around four months of engine work. We are keeping pace with the engine, which means each update is relatively small. This one fixes a few uncommon bugs and might improve performance slightly.

Fixes

• Icons not appearing on a quarter of the minimap for some people should be fixed (engine).
• Possibly fixed the openAL issue for Linux people (engine). Remove "UseEFX=0" to check.
• Starlight no longer sinks itself into soft maps.
• Improved auto-aiming for Starlight, Disco Rave Party, and Bertha. They now prefer to target units close to their old target, to cut down on traversal time.
• Caretakers and Strider Hub now give up on commands that are too far away. This could be caused by trying to reclaim a wreck as it flies through build range.
• Fixed godmode and global LOS buttons on the cheat panel in multiplayer.
• Fixed Widow thinking it is 50% larger than it is for the purposes of pathfinding.
• Fixed reclaim field aggregator sometimes not drawing anything.
• Improved the font sharpness of reclaim field aggregator.
• Improve the performance of the minimap.
• Added a widget (disabled by default) that highlights hovered units called Highlight Unit GL4.
• Fixed custom formation bug caused by fog of war and godmode.
• Wind touches the ground.

[ 2022-05-30 12:56:49 CET ] [ Original post ]

In this update we work through the backlog of graphics and performance improvements made possible by the engine update three months ago. Outlines and reclaim highlighting should run (and look) better, although exact results will depend on hardware. Compatibility fallbacks exist for players with particularly old hardware. Many other bits of code have also been tweaked for performance. Other fixes and features have been worked on in the meantime, the most notable being formation ranks. It can be enabled through the ingame menu, and it is a bit rough around the edges, so send feedback. In terms of balance, the 1v1 oriented changes are minimal as the pick- and win-rate stats are looking quite good. Shields have a nerf and Hover have a buff, and both sets of changes are partial reverts of buffs and nerfs from 2021. For dense teamgames, Impaler projectiles are slightly slower to cut down on their effectiveness against mobile units.

Balance

Bandit has half a revert to its recent damage buff.

• Damage per second 8.35 (pre-August 2021) -> 8.6 (recent) -> 8.48 (new)

Rogue is slower and also has half a revert to some recent buffs.

• Speed 58.5 -> 57
• Projectile velocity 185 (pre-August 2021) -> 192 (recent) -> 190 (new)
• Damage 340 (pre-August 2021) -> 350 (recent) -> 345 (new)

Bolas has its recent health nerf reduced.

• Health 720 (pre-October 2021) -> 680 (recent) -> 700 (new)

Scalpel has both its recent nerfs reduced.

• Health 680 (pre-October 2021) -> 650 (recent) -> 660 (new)
• Damage 660 (pre-October 2021) -> 620 (recent) -> 640 (new)

Impaler has a slower projectile.

• Projectile acceleration reduced by 11%.

Interface

• Added optional front-back ordering for line formations. Set it with Formation Rank ingame under Settings/Unit Behaviour/Default States, or set it per-unit with a state toggle that can be enabled ingame under Settings/Interface/Commands.
• Added a modoption to disable resurrection.
• Tweaked the tutorial mission to be a bit more informative, and removed the Lance.
• Added selection filtering for global build command.
• Added an option to show rating in the Tab Playerlist.
• Added hardware cursor to main menu Settings/Game.

Graphics

• Replaced unit outlines with an opengl4 shader (a non-opengl4 fallback exists).
• Replaced reclaim highlight with an opengl4 shader (a non-opengl4 fallback exists).
• Improved Rogue walk animation.
• Added a unique death clone for Imp.

Modding

• Updated Stinger model, with a small compatibility change required for how it aims.
• Removed 3do model support and converted existing 3dos to s3o.
• Unhardcode mex from pregame queue widget. A customParam for this exists.
• Fixed a potential crash caused by adding morph to a variety of units (mostly cloakbots).
• Add Spring.Utilities.CMD table for custom command lookup.
• Added a warning for buildings with brake, acceleration, and turn rate tags set.
• Remove QueryNanoPiece from LUS.

Fixes

• Lance avoids hovering downwards while firing, to avoid 'accidents'.
• Removed flat rectangles that could sometimes form under killed structures.
• Commanders with skins no longer leave a ghost behind when they leave line of sight.
• Removed 'Dev' from the name of the in-use AIs.
• Fixed weird looking impact explosions for Ogre, Behemoth, and Shogun.
• Settings that exist in the main menu and ingame are now under advanced settings ingame.
• Fixed an error in the ward fire toggle related to shooting at metal spots.
• Fixed Gauss turret spamming functions.
• Automatic guard remover no longer applies to factories.
• Fixed some minor Legacy AI configuration issues.
• Fixed feature ghosting not obeying distance fade.
• Fixed Imp underwater explosion effect.
• Optimise some code in Gauss turret, units catching on fire, selection shapes, attack AoE, economy overlay, decloak range, reclaim field summary, pause screen, newton firezone, radar dot height, and geothermal highlighter.

[ 2022-04-19 09:06:02 CET ] [ Original post ]

Most people report significantly better framerate with the engine update, but there are still a few lingering bugs. This update addresses many of them and re-adds commander skins.

• Reimplemented commander skins for GL4.
• A line to the nearest matching factory is now shown even when outside plate range.
• Fixed factory plate command conditions for underwater placement.
• Fixed transported units temporarily snapping to the ground when flown over factories.
• Fixed weirdness in Ogre (and similar) weapon explosion effects.
• Fixed factory facing arrow underwater.
• Fixed path cache issue on some popular maps (such as Tangerine) that lead to desync.
• Fixed trees missing textures on some maps.
• Fixed disappearing cursors, possibly related to the first campaign mission.
• Fixed radar icons sometimes displaying at the wrong size.
• Improved detection for GL4 support.
• Fixed some crashes on hardware without GL4 support.
• Fixed a rare longstanding bug with hit detection for fast projectiles and small units.
• Fixed reclaim-blocked structure placement squares showing as red rather than yellow.
• Fixed /debuggl.

[ 2022-01-30 05:18:08 CET ] [ Original post ]

There was an engine update for Zero-K this weekend. There are a few lingering bugs as we don't have the coverage in focused testing, which are being patched as we go. The main feature is improved performance, especially for newer graphics cards, and the general promise of more performance once we use more of the capabilities of the engine. Being up-to-date with the engine is also of great benefit to other parts of development. Unfortunately, while we're trying to support as much as we can, graphics cards older than about a decade, or old laptops with integrated graphics, may run into trouble. Players with graphics bugs and performance issues should first try updating their graphics drivers, and then ask for help in #support on the server or on Discord.

[ 2022-01-24 11:16:56 CET ] [ Original post ]

This is a balance patch on three fronts. On the ground, hovercraft have worse movement and nerfs to their most generic units, while spiders have cheaper early game units. In the air, light gunships receive some much needed attention and Raven no longer dives. Superweapons now require an energy grid, are much more vulnerable to being stunned, and Zenith swapped its cost with Disco Rave Party again. Other features include more options for line formations, better unit tracking and first person control, APM stats at the end of the game, and some fixes to do with saving campaign missions.

Ground

Hovercraft movement was buffed in v.1.9.11.0. This patch partially walks back the changes.

• Speed maintenance while turning reduced from 85% to 80%. Other vehicles are still at 60%.
• Slowdown while climbing hills is now halfway between the pre- and post-v.1.9.11.0 values.

Bolas is still a bit too much of a generalist so has minor nerfs to health and damage.

• Health 720 -> 680
• Reload time 0.333 -> 0.367
• Slow damage reduced by 1/6.

Scalpel gained a lot of power from improved movement and overkill prevention, so has similar nerfs.

• Health 680 -> 650
• Damage 660 -> 620

Ronin is a bit smarter.

• Now steps back while reloading (with Attack Move or or idle without Hold Position).

Flea is harder to spot.

• Decloak range 160 -> 130.

Venom is cheaper to help spiders expand safely.

• Cost 200 -> 190

Redback is cheaper to help spiders field armies early.

• Cost 240 -> 230
• Speed 1.8 -> 1.85

Pyro deals slightly more damage because some people just want to watch the world burn.

• Main DPS increased 3.3% (lingering damage unchanged)

Air

Wasp is now only slightly less efficient than the average constructor.

• Buildpower 7.5 -> 10

Blastwing now deals enough damage to kill a Metal Extractor.

• Explosion damage 80 -> 40
• Ground fire initial damage per second 18 -> 25
• Ground fire duration 20 -> 25

Locust has more raiding uptime.

• Idle regeneration 5/s -> 10/s

Harpy has noticeable buffs as it been outclassed for a while.

• Health 1100 -> 1200
• Improved brake rate by 20%.
• Damage 200 -> 220.
• Improved unit AI with preemptive breaking and better riot avoidance.

Raven no longer dives. Instead it has a guided bomb that glides downwards, homing onto targets in a cone below it. Raiders are fast enough to dodge by leaving the area before the bomb hits.

• No longer dives.
• Cruise altitude 330 -> 270 to fit under area shields.
• Bomb speed reduced by 32.5%.
• The bomb now has significant homing, but it cannot fly more than about 45 degrees off vertical.

Phoenix bombs hit slightly sooner and in a larger area, increasing its reliability.

• Cruise altitude 270 -> 240.
• Increased spread slightly.

Superweapons

Disco Rave Party must spin up to fire at full speed and swaps its cost with Zenith.

• Requires a connection to a grid with 400 energy.
• Cost 36k -> 40k
• Initially spins 20% speed, reaching a maximum of 100% after about a minute of firing.
• Maintains speed without firing, unless it is stunned or loses power.
• Buffed the smoothing of Green Stomper slightly.

Zenith is less accurate when fired continuously and swaps its cost with DRP

• Requires a connection to a grid with 400 energy.
• Cost 40k -> 36k
• Range 9000 -> 8400
• Increased the effect of launch distance on meteor spread. A meteor launched while it is still high in the sky is significantly less accurate than one floating in the swarm.
• Meteors wander down from space to the swarm faster, and are generally more energetic.
• AoE 240 -> 256
• Added smoothing. The radius is small but it can move structures.
• Meteors are visually 40% larger.
• Meteor reclaim increased 10 -> 20.

Starlight requires a large grid and resets its aim when stunned.

• Requires a connection to a grid with 600 energy.
• Glint falls and docks whenever the laser is not firing. This includes disarm, emp and low power.
• Aim speed is now reduced by slow damage.

Singleplayer and Coop

Chickens now regenerate at 20 hp/s after 10s of idle time. Adjusted some campaign missions for the superweapon changes.

• Added enough energy to reliably power the enemy Zeniths on planets Caderical and Pendust.
• Added barely enough energy to power the player Zenith and Disco Rave Party on planets Caderical and Zhurou.
• Added radar to assist the Disco Rave Party on planet Cipher, for difficulties Hard and Brutal.

Taught AIs about superweapon grids and updated the lower difficulty levels.

• AIs can now build Starlight.
• AIs know how to place Pylons around their superweapons.
• Updated beginner and novice AI to use the latest build.
• Added AI builds that are compatible with the latest engine, which is still being tested.

Features

• Moved line formation settings to 'Settings/Interface/Line Formations'.
• Added an option that turns right-click drag for selected commands (as opposed to context commands) into a line formation, rather than deselecting the command. Disabled by default.
• Added an option to evenly distribute different unit types along line formations. Enabled by default.
• Added an option to merge small categories of units for the purpose of evenly spreading unit types along line formations. Defaults to 1.
• The previously hardcoded behaviour in COFC that disables unit tracking mode when the camera is rotated can be disabled under 'Settings/Camera/COFC Following'.
• Icons that smoothly draw over models as you zoom out, rather than suddenly switching, can now be enabled under 'Settings/Graphics/Unit Visibility/Icon Zoom Transition'.
• Added keep target command for Raven, since it now makes sense with its guided bomb.
• Bombers can be now be set to retain the target of cancelled attack commands in 'Settings/Unit Behaviour'. This is how other units behave, but it was disabled for bombers to reduce accidents.
• Starlight stops moving its beam when given a Stop command, rather than continuing on to its most recent target location.
• Added direct unit control support (FPS mode). It can be enabled in the lobby in game options under 'Silly'. To enable in the campaign do /cheat, open the cheat sheet on the top left bar, tick the appropriate option, and do /cheat again (to reenable victory conditions).
• Added a tab to the game over screen with command speed summaries, such as APM.
• Added splashes for units entering or exiting water at speed.

Fixes

• Fixed complete mission objectives being broken by save/load.
• Workaround for the ramps on Lovaza Jira disappearing when the game is saved and loaded.
• Fixed some bugs and jitters with COFC unit tracking mode.
• Fixed icon distance and volumes not being carried over to externally launched games.
• Fixed an issue with connecting to the lobby for a few players.
• Improved unit movement for reclaim, attack move and repair commands.
• Fixed some typos in the space+click unit guides.
• Fixed Zenith space+click guide reporting incorrect reload time.
• Fixed incorrectly reported cruise altitude in the space+click unit guides.
• Fixed units with free cloak not listing cloak as an ability in the space+click unit guides.
• Added translation for 'shields'.
• Added startboxes for Coast To Coast Remake.

[ 2022-01-20 09:19:33 CET ] [ Original post ]

This is a small update with some AI fixes, just in time to take a break over the holidays to wander through the campaign. Perhaps even invite some friends.

• Fixed Strider Hub eventually not working. The AI forgot that striders can move, so was not able to reuse open space to place additional strider nanoframes.
• Increased the placement distance between Solar and Wind Generators. This makes the AI much less likely to block its base on maps with narrow passes.
• Construction delays for Easy, Normal and Hard now reduce to about 75% their maximum after about 20 minutes. This causes the AI to ramp up slightly in the lategame.
• Reduced initial construction delay for Hard, to make it slightly harder early on.
• Fixed an inverted comparator which was causing AIs to make Solars (rather than Singus) in the late game.

[ 2021-12-21 06:22:06 CET ] [ Original post ]

The previous patch had a few changes to bring Hovercraft more into the game. It was so successful that we felt the need to make this small followup update. The reduction in while turning seemed to particularly boost Bolas as it likes to dance around at max range, so it has lost some range to compensate. Minimum turn speed was also walked back from 100% to 85% for all hovercraft (other vehicles still turn at 60% speed). Bolas is less adept at poking other raiders.

• Reduced turn rate by 5.4% (now lower than Dagger).
• Range 232 -> 225
• Damage reduced by 3%.

A few other changes snuck in.

• Paladin gains 20 hp/s combat regeneration.
• Tweaked Kodachi overkill prevention to hold fire less frequently.
• Fix the Dvorak key layout.

[ 2021-12-08 12:55:22 CET ] [ Original post ]

The November patch is a large one, with four new maps added to the matchmaker pool, numerous balance tweaks, and many other improvements and fixes. The most notable balance changes are:

• Armour now reduces damage by a factor of 3 rather than 4. This is to increase counters to armoured turrets and Crab, and to give Halberd space to be tankier while firing.
• Hovercraft have their uniquely terrible slope climbing replaced with uniquely fast speed while turning. A bonus feels better than a penalty, and the old penalty was pretty obscure as well as limiting for map diversity.
• Limpet received its prophesied nerf now its power and general utility has been discovered.
• The ongoing small tweaks to vehicle raiders continue in an attempt to share some of the success of Rover with Hover and Tank.
• Swift no longer fires while landing. Its weapon maybe have to be buffed in the future to compensate.

New features include a command for easier factory plate placement and improved effects for Halberd and Buoy. Modding for many niche special abilities is much easier and a few edge case bugs have been fixed.

Matchmaker Pool

1v1 pool:

• Added Faultline, Doldrums, Random Plateaus, Shimmershore, Trojan Hills, Mecharavaged.
• Removed Intersection, Ravaged, Crubick Plains, Frostburn, Izki Channel, Anvilwood.

Teams pool:

• Added Faultline, Doldrums, Random Plateaus, Shimmershore, Trojan Hills, Mecharavaged.
• Removed Intersection, Ravaged, Crubick Plains, Frostburn, Aurelian.

Balance

Armour damage reduction reduced 75% -> 66.6%. The following units were partially compensated.

• Halberd health 1250 -> 1600
• Crab health 4000 -> 4200
• Solar Collector health 500 -> 600

Hovercraft have increased mobility.

• Rather than slow to 60% while turning like other vehicles, they keep all their speed.
• They climb slopes as quickly as other vehicles, rather than climbing much slower.

Quill turns faster because large turning circles are needlessly annoying on constructors.

• Turn rate 920 -> 1100.

Dagger deals more damage, but not enough to affect its matchups against most raiders.

• Damage 100 -> 110

Scalpel is smarter.

• Overkill prevention fires less often at targets that are probably going to die.

Dart swarms are slightly less deadly.

• Damage 35 -> 32
• Slow damage 140 -> 128

Fencer is the backbone of Rover, which seems particularly powerful, so can afford a small nerf.

• Cost 140 -> 145

Kodachi is cheaper but finds it harder to deal free damage.

• Cost 175 -> 170
• Range 215 -> 210

Limpet took years to be noticed, and it is finally time for its first nerf.

• Cost 150 -> 160
• Speed 123 -> 120
• Damage 150 -> 120
• Slow damage of 1200 unchanged.
• Overslow 5s -> 2s (matches Moderator)

Cutter should not be outclassed by Hunter so early.

• Cost 70 -> 65

Swift is no longer a form of artillery, and boost is consistent with other abilities.

• Can no longer fire while landing.
• Boost recharge rate now obeys status effects.

Faraday has less damage and stun uptime, on top of the general armour nerf.

• Damage 1200 -> 1100
• Reload 2.7s -> 2.9s (stun uptime 74% -> 69%)

Faraday and Gauss have more appropriate collision shapes.

• They now have flatter collision volumes when closed.
• If they can shoot over a wall, their aim point is now adjusted so that enemies can shoot back.

Commander Disruptor Bomb is now consistent with Limpet.

• Damage 350 -> 210
• Slow damage of 2100 unchanged.
• Added 2s overslow to Violet Slugger for consistency with Limpet.

Disco Rave Party is now consistent with Limpet.

• Added 2s overslow to Violet Slugger.

All slow pulses, besides the more continual pulse of Outlaw, now have a slow to damage ratio of 10:1, and 2 seconds overslow.

Interface

Dagger and Bolas radar icons are now consistent with other light/heavy raider pairs.

• Icon type Raider/Support -> Scout/Raider.
• This will be confusing at first, but the consistency should be worth it in the long run.

Factory plates are easier to place with the new factory plate command.

• Added a generic factory plate command that turns.
• It turns into the factory plate of the nearest factory in range of the mouse.
• It exists in the grid construction menu with hotkey BV.

Fixed some texts:

• "defense" -> "defence" (rather than a mismash of the two options)
• "minimun" -> "minimum"
• "stun time" -> "max stun time"

Other features.

• Self-destructing a selection of units costing less than 1000 now never triggers autoresign.
• Rectangle terraform now turns red when too large.
• Added Swift boost and jumpjet cooldown to selections panel.
• Landed Swifts refund their boost.
• Add Fire Towards Enemies to the hotkey menu.

Graphics

• Improved projectile effect and muzzle flare for Buoy and Halberd.

Modding

Many previously hardcoded abilities now have customParams or are configurable in LuaRules/Configs. While it was possible for mods to copy gadgets to configure such behaviour, it is now easier to do so in a configurable way. This includes:

• Dirtbag mound.
• Full interactions for sonar, radar and radar jamming (eg being disabled when disarmed).
• Phantom firing while cloaked.
• Air transports.
• Teleport beacon.
• Overshoot prevention for turrets.
• Gravity weapons being allowed to Set Target allies.
• Torpedoes not jumping out of the water when they hit the shore.

Fixes

• Fix ward fire error spam on metal maps.
• Krow and Thunderbird now decloak during bombing runs. Previously Thunderbird would only decloak when bombing via attack order.
• Clean up metal spot detection code.
• Improved base64 encoding memory usage.
• Fix Scylla firepoint offset/clipping.
• Fix special weapons not updating their image and text in some cases (eg select a Swift then a Charon).
• Fix SLAM rocket model.
• Fix stretched Dart track texture.

[ 2021-11-21 14:35:26 CET ] [ Original post ]

[previewyoutube=9ZQzgLy4Pjo;full][/previewyoutube] Here is the Zero-K news for October.

• GoogleFrog talks about the background and design philosophy of Zero-K in an interview by StealSpeaks. This is the first Zero-K developer interview, and there was a lot to cover, so expect part two in a few weeks.
• There will be a 1v1 tournament at 19:00 UTC on Saturday 23rd October. It is open to everyone. To sign up post in this thread. Here is a countdown timer for timezone conversion.

[ 2021-10-17 12:35:00 CET ] [ Original post ]

We've finally solved a minor bug that caused anti-air missiles to sometimes penetrate aircraft. While quite rare, it was causing Vandal to make unfortunate mistakes against Thunderbird. Besides the fix, there are a few buffs for Hover and Shieldbots, and nerfs for Rover and Amphbots. Badger is of particular concern as it needs adjusting after its unit AI improvement. We are also experimenting with extra initial resources, with the goal being to give players more freedom in the early game.

Balance

Increase starting resources slightly as an experiment.

• Initial resources 250-> 325 metal and energy.

Metal Extractor is lighter and cheaper for quicker and riskier expansion.

• Cost 90 -> 85
• Health 640 -> 600

Felon is better shielded and matches Thug's recharge time.

• Max shield 1600 -> 1800
• Recharge rate 16 -> 21

Convict matches Thug recharge time too.

• Recharge rate 9 -> 10.5

Vandal is better at shooting in dense clumps.

• Shorter collision volume.
• Higher angle of fire.

Limpet is a little worse against assaults.

• Slow damage 1500 -> 1200

Bulkhead is even less tanky.

• Health 1650 -> 1540

Dart aims faster.

• Turret speed 200 -> 320 degrees/second

Scorcher has regained the status of 'very good' so it can be returned to its previous price.

• Cost 125 -> 130

Badger is easier to catch.

• Speed 60 -> 55.5

Claw (Badger's mine) is worse at hitting small nimble units

• Sight radius 64 -> 120
• Decloak radius 50 -> 80 (consistent with 2x2 footprint units).
• Flight time 1s -> 1.7s.
• Initial projectile speed 50 -> 70
• Final projectile speed 300 -> 130
• Projectile acceleration 200 -> 50
• Turn rate reduced by 28%
• Toned down projectile lighting

Dagger fully loses some nerfs from last year. Its price nerf (75 -> 80) remains.

• Speed 143 -> 144
• Range 210 -> 212

Bolas has small buffs as it is easy to overdo.

• Cost 185 -> 180
• Speed 95 -> 96
• Range 230 -> 232

Engineer chassis is slower.

• Speed 39 -> 36

Lotus is slightly worse when built under fire.

• Added 0.8 second post-construction deploy time.

Planes have some important fixes.

• Fixed all anti-air, Ogre and Picket projectiles sometimes passing right through aircraft.
• Reduced the size of plane hit volumes to better match their model now that the underlying issue with anti-air inconsistency resolved.

Modding

• Added modoptions to set innate income and initial resources.
• Added a modoption to randomly set initial resources.
• Added a modoption to set seeds for random maps.
• Added support for weapondefs_mod and explosiondefs_mod. Mods can define these files to act on the weapon/explosions tables as they are loaded.

[ 2021-09-27 14:31:31 CET ] [ Original post ]

This update solves a few recent issues with ground targeting. The easy fix was for Duck, which was previously able to fire torpedoes out of the sea and onto land. The trickier changes solve the unfairness of ground targeting widgets by making the interface more powerful in ways relevant to humans, while reducing its power for widgets. Other balance changes include Felon tweaks and slower transport speed for Jack. The AI has been updated to fix a bug, and all the configs are now based on the previous bleeding edge test version.

Balance and Behaviour

Duck is no longer able to ground fire torpedoes. This is consistent with other torpedo and depth charge weapons. Bandit now leads targets at close range correctly. Felon has improved burst and DPS, but less efficient charge to damage conversion.

• Reload 0.16s -> 0.13s
• Damage 110 -> 94 (DPS 660 -> 705)
• Shield energy per shot 80 -> 75 (damage/charge 1.38 -> 1.25)

Reaver aims more smoothly and is smarter.

• Aim period 5 -> 3 frames.
• No longer automatically fires at walls protecting enemy mexes.
• Jinks when fighting units such as Rogue.

Phantom aims faster than it turns to cut down on firing mishaps.

• Turn rate reduced by 5.4%.
• Aim speed 360 -> 480 (no scope).
• Aim period 5 -> 1 frames.

Added the state toggle Fire Towards Enemies for the following units. The toggle is off by default.

• Kodachi fires towards nearby enemies that are behind it, to avoid running into its own fire.
• Badger fires in the direction of the closest enemy, whatever the distance.

Many units that could deal damage slightly beyond their maximum range, usually by using area of effect damage, now have reduced range for ground firing with the Set Target command. Added a weight category - medium - to further differentiate transport speed penalties.

• Light units cost up to 500
• Medium units cost more than 500 and at most 1000.
• Heavy units cost more than 1000.

Transports carry units of each weight at the following speeds.

• Charon transports Light/Medium units at 70%/50% speed.
• Hercules transports Light/Medium/Heavy units at 75%/65%/50% speed.

The light and heavy speed penalties existed previously, they are unchanged. The medium units that were previously light are Jack, Skuttle, Felon, Phantom, Minotaur, Emissary, Lance, Impaler, Siren, Envoy, Aspis, Iris and Djinn.

Campaign and Coop

• Updated the skirmish AI to fix an idle factory bug - for real this time.
• Removed time constraints on bonus objectives for the first five planets of the campaign.

Interface

• Units can now be told to fire towards an enemy or location. To do so, issue a non-area Set Target order with the Ctrl modifier. This behaviour is paused when enemies are nearby, unless the unit is set to hold fire.
• Improved the smart nano turrets widget Auto Patrol Nanos v2. This is still disabled by default, pending more live testing.
• Improved some widget descriptions.
• Added an option to hide chat.

Modding

• Added explode on victory modoption.
• Fixed the example model scaling gadget for dae.
• Added an unused root to the piece hierarchy of Glaive, Iris, Conjurer, Gremlin, Scythe to allow for easy model scaling.
• Exposed Spring.Utilities.CommandNameByID(cmdID) and Spring.Utilities.Traceback() to widgets.

Fixes

• Saved some memory in the UI framework.
• Fixed torpedoes sometimes falling through the map.
• Fixed imaginary numbers in the ballistic projectile solver.

[ 2021-09-19 09:22:39 CET ] [ Original post ]

Back in February we reduced the starting resources and commander income, with the aim of extending the early game slightly. After six months of data and feedback we suspect balance suffered as a result, so the income change has been reverted. We also addressed another ongoing balance project - Shieldbots - with a few buffs. This patch has the usual smattering of fixes and UI improvements, with the most notable being improvements to Area Mex and fixes for the AI. Area Mex now works pregame and has a terraforming mode. To counteract the terraforming mode a few units have been given wall-defeating behaviours. The AI fix is more of an update that started as a fix, and includes tweaks to the difficulty levels. Feedback about the difficulty progression would be appreciated.

Balance

Increased starting income back to pre-February 2021 levels.

• Initial metal income 5 -> 6.
• This was done via increased commander income (3 -> 4).
• Initial stored resources is still lower than before (300 -> 250).

Bandit DPS is now closer to Glaive than Duck.

• DPS 83.5 -> 86 (+3%)

Outlaw slows more rapidly.

• Real damage 26 -> 27 (+3.5%)
• Slow damage 78 -> 81 (ratio unchanged).

Rogue regains its weapon from a few months ago, but not its body.

• Projectile velocity 185 -> 192
• Damage 340 -> 350

Felon aims faster and can tank a Phantom shot.

• Health 1400 -> 1600
• Removed artificial 133ms aim delay.

Sling is slower.

• Speed 48 -> 45

Badger is slower and more expensive.

• Cost 260 -> 270
• Speed 65 -> 60

Bulkhead is less tanky, now dying to two Stinger shots.

• Health 1720 -> 1650

Cutter is better at picking off Hunters.

• Range 260 -> 265

Stardust fires at full speed for longer.

• Heat decay 14.28% -> 16.67% per second.

Reaver, Pyro, Crab, Archer, Ripper, Claymore, Kodachi and Ogre now automatically shoot towards obscured or terraformed metal spots. Some of these units bypass or smooth terrain, while others simply have the AoE to deal a bit of damage through walls. Reaver, Archer, Venom, Crab, Firewalker, Badger, Kodachi, Scalpel, Dante, Merlin, Mistral and Siren now aim through terrain when told to target the ground.

Matchmaker Rotation

• Removed Jurassic Sands and Calayo.
• Removed Aurelian from 1v1 (still in Teams).
• Added Ravaged and Frostburn to 1v1 and Teams.
• Added Izki Channel to 1v1.
• Added Banana Republic to Teams.

Interface

Area Mex has the following improvements.

• Added Area Mex to the pregame queue.
• Point clicking now snaps to the closest point, the same as using a metal extractor blueprint.
• Point clicked Area Mex commands have the same key modifiers for queuing adjacent energy.
• Shift-release behaviour is now consistent with structure placement (it deselects if an order has been issued).
• Added a terraform mode.

Area Mex terraform works as follows.

• It exists as a separate command (default hotkey Alt+W).
• By default it does not appear as a UI button.
• The basic command builds a wall after the mex is complete.
• Issue with Alt to dig a hole prior to placement instead of a wall.
• Issue with Ctrl to increase height/depth of terraform.
• Configure the height/depth in Settings/Interface/Building Placement.
• Has the same point click improvements as base Area Mex.

Other interface changes.

• Unit markers report the progress of things under construction.
• Freed up F6 and F7 for hotkey binds.
• Starlight and Disco Rave Party now have a directional placement arrow (like factories).
• Claymore has anti-bait against free units by default.
• Unit descriptions now consistently say 'Anti-Sub' for units that can reasonably fight submerged Ducks and Seawolves, and 'Undersea Fire' for units that can fire while submerged.
• Tweaked the default Alt+N terraform wall slightly higher.
• Added a Alt+M default terraform hotkey, which is like Alt+N but high enough to protect Stinger from Lance.

Modding

• Local widgets can no longer use Spring.GetVisibleProjectiles.
• Local widgets no longer receive enemy projectiles from Spring.GetProjectilesInRectangle.
• Ploppable factories now have the 'ploppable' CustomParam, rather than ploppability being determined by a config file.

Fixes

• Fixed AI factories sometimes 'breaking' lategame. This required an AI update, so post feedback about the migrated difficulty levels. Beginner and Novice are unaffected.
• Removed Economist AI as it is now bundled into Brutal.
• Fixed Quake (seismic missile) being able to crash Glint (Starlight's satellite) back to earth.
• Fixed Raven sometimes failing to dive against Aegis.
• Fixed unit AI internal commands sometimes cancelling user commands via duplicate orders.
• Fixed uneven and misnamed startboxes on Stronghold_V4.
• Fixed Conjurer wreck being indistinguishable from Gremlin.
• Fixed dying terraform anchors dealing 0.0001 damage.
• Fixed garbage being rendered with Outline Shader enabled.
• Fixed the cheat menu not appearing on its own if the Null AI had a different name.
• Fixed spectator panel numbers bobbing up and down.
• Fixed mex placement widget eating too many mouse buttons.
• Fixed some gray labels in missions with locked units.

[ 2021-08-14 10:39:44 CET ] [ Original post ]

This is a small update to the matchmaker and planet Kirdipan - the terraform mission. Kirdipan is a bit fairer with tweaks such as clear Pylon lines, Owls to scout the map, and no underwater units. The 1v1 matchmaker now looks like a single queue with two option for a wider search range (handicap and ranked). The 'Match Available' status should reliably report the game type, with '1v1' corresponding to a narrow search range game, and '1v1 Handicap'/'1v1 Wide' corresponding to the two options. Both can be ticked to accept both types of game. The standard search range has also been increased from 330 to 345.

[ 2021-07-10 04:24:15 CET ] [ Original post ]

Income multipliers can now be set for each team under Options to serve as a form of handicap. This is a commonly requested feature for coop games, but to take it a step further we're trying out a new matchmaking queue. The '1v1' queue now generates even matches up to a certain skill gap, beyond which it creates unranked games with an income boost for the lower-ranked side. To stick to even games use the new '1v1 Narrow' queue, and for the best queue times use both at once. The '1v1' queue allows a slightly wider skill gap than previously, while '1v1 Narrow' allows a slightly narrower gap. Update: There is now a '1v1 Wide' queue with the same match range as '1v1', but without the handicap.

Handicap and Matchmaking

• Per-team income multipliers can now be set under Options -> Multipliers in battle lobbies.
• Added a '1v1 Narrow' matchmaking queue that creates more evenly matched battles than the previous system.
• The '1v1' matchmaking queue can create either handicap or non-handicap games. If a match would qualify for '1v1 Narrow' then a normal match is played, otherwise the match does not affect ratings and the lower skilled player receives a small income boost.
• Added a '1v1 Wide' matchmaking queue with the same match range as '1v1' where games are always ranked and without a handicap.

Behaviour

• Added anti-structure overkill prevention for Lance, Lucifer, Ravager, Crab and Cyclops.
• Reef and Shogun try to stay at max range against all targets.

Other Tweaks

• Added NW vs. SE startboxes for Archsimkats Valley.
• Calayo is back to just being NW vs. SE.
• Tweaked metal spots on Battle for Planet XIV and DeltaSiege Island 8 Way.
• Tweaked the sun and water parameters for a few maps.
• Tweaked welcome text.
• Better support for modding a few things related to the economy (fewer files to override).

[ 2021-06-27 16:35:38 CET ] [ Original post ]

Everything should go just a bit smoother with this update. The AFK detector now has a countdown and disables construction, bringing harmony to teams. A number of unruly fonts and boxes have been brought into line, bringing harmony to the interface. The normal difficulty AI has chilled out. Singleplayer and multiplayer can be as one with skirmish and campaign autosaves during matchmaking. Most harmoniously, maps can now (effectively) be nice smooth circles rather than pointy squares.

Balance

Flea has a bit more map presence to make up for the previous Venom nerf.

• No longer slightly leads its target, removing a small retreat disadvantage.
• DPS increased by 7.1%

Conjurer is in slightly more danger from its own cloaked bombs.

• Area cloak and jammer range 192 -> 184

Scorcher is slightly worse at poking other raiders.

• Range reduced by 1.9%
• Projectile speed reduced by 1.9%

Badger is more vulnerable and has a slower rate of attrition.

• Speed 67.5 -> 65
• Reload time 5.5s -> 5.6s

Quill gains more speed advantage.

• Speed 84 -> 87 (2.8 -> 2.9)

Dagger has another range change.

• Speed increased by 0.35% to a round number.
• Range 205 -> 210

Bolas is slightly cheaper and faster.

• Cost 190 -> 185
• Speed increased by 0.53% to a round number.

Mace regains its old range.

• Range 340 -> 345

Halberd has a better matchup vs. Metal Extractors.

• Damage 150 -> 160

Claymore has more burst and has 13.8% more DPS.

• Reload 2.8 -> 3.2
• Damage 400 -> 520
• Increased edge effectiveness.

Singleplayer

• Normal AI is now noticeably easier, with the goal of reducing the jump from Easy to Normal.
• Hard AI is slightly easier. Brutal is unchanged.
• The player has more defenses in campaign mission 2 to give them more breathing space.
• Added a few extra things to destroy in campaign missions 2 and 3.
• Singleplayer games are now automatically saved when a matchmaker match is found, for players that would like to play singleplayer while in the queue.

Unit Behaviour

• Added Anti-Bait toggles for Knight, Dagger, Cutter, Hunter, Blitz.
• Fix Bandit unit AI, it now idle flees itself and Duck.
• Urchin can no longer Force Attack the ground (both on land and underwater).
• Gauss now aims down cliffs properly.
• Units can no longer guard themselves.
• Fixed retreating Attack Move units occasionally returning with Move after being repaired.
• Fix Ronin and Rogue on Attack Move jinking too fast to aim and fire.

AFK Detection

• Renamed the lobby option toggle to "Inactive Player Unit Sharing" and added a default that enables it in PvP while disabling it for Coop.
• Increased AFK threshold from 30s to 40s.
• Added a visual warning that start at 32s of inactivity.
• Fixed typing in chat erroneously not counting towards activity.
• Shared constructors and factories are now given a Wait command, which is removed when they are shared back.

Mapping

• Maps can now define a playable area, restricting unit movement and construction. Circular maps can be created with a config file and functions for arbitrary shapes have been exposed.
• Added a circular playable area to BlackStar.
• Cleaned up metal spot inconsistencies on Pinewood Derby, Archsimkats Valley and Altair Crossing.
• Added startboxes for Stronghold, Throne, Tundra, Rysia, Battle for Planet XIV, Vernal 3-way, and Small Supreme Battlefield Dry/Islands/Original.

Added the following two functions for dynamic start boxes and metal configs, but technically they can be used for all mapping and modding.

• Spring.Utilities.Gametype.isCompStomp() returns true if there is exactly one team that only contains humans.
• Spring.Utilities.Gametype.isTeamFFA() returns true if there are more than 2 teams and at least one of them has multiple players.

Modding

• Added warnings about LaserCannons with ranges not equal to a multiple of their speed. The next release they will get turned into erroring on load
• Script.IsEngineMinVersion returns true correctly on bleeding edge (i.e. versions X.1.Y-Z).
• Projectiles are no longer filtered for spectator widgets.
• Added a detonate command to an unused kamikaze submarine.

Fixes

• Tweaked numerous ingame and menu font sizes and button dimensions for consistency.
• Improved font management to cut down on memory usage.
• Improved the load time of the map list in the game lobby.
• Fixed map and mod downloads occasionally needing to be retried near completion.
• Made cost and time more prominent in construction tooltips.
• Right mouse button now takes precedence over Alt on the factory build queue.
• Fixed large build queues adding units uncontrollably with Alt and some rapid clicking.
• Improved Fusion, Antinuke and Trinity smoke effects and Zenith beam effect.
• Fixed Antinuke and Area of Effect visualisation being slightly off-position when targeting water.
• Fixed a bug with persistent build spacing with non-default settings.
• Fixed how the ingame abuse report window reports FFA.
• Fixed a rare commshare bug that could break team FFA.
• Fixed negative damage showing up in endgame graphs.
• Fixed Strider Hub not aiming correctly.
• Fix the Wait indicator not appearing over factories.
• Fix the Wait indicator not appearing over transferred units.

[ 2021-06-13 15:54:31 CET ] [ Original post ]

This is the first big balance patch of the year, just in time for the second tournament series of the year. Shieldbots are better early and have more tools in their arsenal, but the standard shieldball is less powerful. Hover and Tank have buffs for improved unit variety and to bring them up to the power level of Rover. Spider has a few small tweaks to make them less reliant on Venom.

Lobster Roll Series Two

Lobster Roll series two will start on the 17th of April and is open to everyone. There is a round robin warm-up tournament this coming weekend, on the 10th of April. Sign up to the round robin here. Join the Discord server for announcements about the upcoming series.

Map Rotation

The following changes have been applied to the matchmaking pool. The full pool can be viewed here.

• Added - Crubick Plains, Aurelian, Calayo, Red Comet Remake, Fairyland, Sertaleina.
• Removed - Sparkles Reef, Prestige, Otago, Iced Coffee, Ravaged, Mechadansonia.
• Updated - Cobalt Dream, Dune Patrol Redux, Fallendell.

Bot Balance

Shieldbots are the main issue among the bot factories, and it was not just an issue of overall power. Players in the middle of the ladder were having trouble against the Shield midgame, while those at the top found Shield to be at too much of an early disadvantage. To solve this we buffed their early game while nerfing the standard shieldball. We have also tweaked Spiders to make them less reliant on Venom. Bandit is a bit better to help Shieldbots through the early game.

• Health 330 -> 340
• DPS increased by 2.5%

Convict is faster to assist early expansion.

• Speed 60 -> 61.5

Rogue has a nerf to save some matchups from mass Rogue supported by the buffed Bandit.

• Health 580 -> 540
• Turn rate reduced by 10%.
• Projectile velocity 192 -> 185
• Damage 350 -> 340

Thug regenerates slower to make shield charge more valuable.

• Speed 57.75 -> 57 (what a weird number, now same as Outlaw)
• Shield capacity 1250 -> 1200
• Shield regen 16/s -> 14/s

Felon has 18.8% less DPS and charges slower.

• Shield regen 18/s -> 16/s
• Aim time 0.3s -> 0.166s
• Reload 0.13s -> 0.16s
• Charge per shot 75 -> 80
• Damage 108.4 -> 110

Outlaw takes on more responsibility for riot power from Felon.

• Cost 260 -> 250
• Health 1050 -> 1100
• DPS increased by 13%

Vandal takes on more responsibility for anti-air power from Felon.

• Range 880 -> 900

Racketeer is slightly easier to field.

• Cost 350 -> 340
• Speed 51 -> 52.5

Snitch is slightly harder to position.

• Speed 120 -> 117

Dirtbag is better at spotting and harassing.

• Speed 78 -> 84
• Sight range 560 -> 600
• Reload 2s -> 1.9s
• Damage 45 -> 55

Reaver has a buff to help Glaive deal with Bandit.

• Cost 220 -> 210
• Speed 1.71 -> 1.75
• Reload 0.5s -> 0.466s

Flea is harder to spot when burrowed.

• Decloak Radius 200 -> 160

Venom has less stun uptime, as well as slightly less DPS.

• Reload time 1.1s -> 1.133s.

Hermit is one of the more maligned assaults, so gains some assault power.

• Cost 160 -> 150
• Health 1400 -> 1500

Widow drains more energy to make it harder to field early on.

• Cloak cost 12/4 -> 15/5 (Moving/Static)

Vehicle Balance

Rover is dominating the vehicle matchups, yet there were few complaints about Rover itself. We took this to mean that Rovers feel fun and well balanced, even when losing to them, so opted mostly leave the factory alone. Instead, we took a look at Hover and Tank. Hover has a decent earlygame but a lack of transitions, so we buffed some of their more niche units, while Tank has the opposite problem, so we buffed Tank earlygame. Fencer is more vulnerable.

• Health 560 -> 530
• Setup time is 6.6% longer

Quill is now only slightly more expensive than a standard constructor.

• Cost 130 -> 125

Halberd can be unleashed now that Anti-Bait makes it less annoying to fight.

• Cost 240 -> 210

Mace is a better riot at the expense of a little range.

• Health 1300 -> 1400
• Range 345 -> 340
• Aims 20% faster
• DPS increased by 10%

Kodachi feels fairer to fight so can afford a buff.

• Cost 180 -> 175
• Health 670 -> 680

Welder is cheaper but also more vulnerable to raiders.

• Cost 200 -> 185
• Health 1800 -> 1700
• DPS reduced by 4%

Ogre needs a buff to fight Mace 1v1 and win.

• Health 1850 -> 1950

Interface

There are now some optional resource panels to enable under 'Settings/HUD Panels/Economy Panel' with Simple Settings disabled. They need to be positioned with Ctrl+F11. There are two panels to track constructor activity, a panel for overdrive, and a panel for wind speed. Other Changes:

• Added Shield Charge/Maximum to aggregate selection stats and switched some rows to improve order stability.
• Added Avoid Bad Targets toggle for Claw, Ultimatum, Scorpion and Nimbus.
• Nimbus flies a little closer to make it reliably fire at tall turrets.
• Artemis overkill prevention is more careful about wasting missiles.
• Mace skirms more unit types.

Fixes

• Fixed two bugs that caused some terraform shapes to stall at 99% completion.
• Fixed commander drone duplication upon morph.
• Crab is better at uncurling.
• Clear Factory Queue now works with factories set to Wait.
• Fixed Artemis not firing when on land of height zero.
• Landbound Urchins are better at firing into the deep ocean.
• Fixed transports having trouble unloading tall units.
• Fixed some edge cases with antinukes.
• Fixed Ravager suspension.
• Tacnuke sounds now play at higher priority.

[ 2021-04-06 08:40:50 CET ] [ Original post ]

The big feature in this update is bait prevention. Units and turrets, such as Artemis, should be significantly better now that they can more precisely obey your wishes. Felon is a beneficiary as it can be told to avoid armoured units, but it may be kept in check by another new behaviour: Most units now fire at the edge of small shields if there is nothing else in range. There are few actual balance changes to better observe the ramification of the latest advances in unit command. Apart from that there are a few features and fixes, such as the ability to click on names in the endgame stats to highlight a line, and improved map filtering.

Balance

Advanced Radar moves towards justifying its cost, as an experiment.

• Cost 500 -> 400
• Sight 800 -> 1120
• Range 4000 -> 5600

Claymore has a smaller collision volume. Duck missiles have less fuel, but still enough to hit land targets. Jugglenaut and Newton now have aim lookahead (aiming towards targets that are about to enter range).

Behaviour

Units and turrets with reload time or costly projectiles can now be told to avoid low value targets. This can be configured under Settings/Unit Behaviour or controlled with the Avoid Bad Targets state, which is shown by default. The states are:

• Disabled.
• Free - Avoid light drones, Wind, Solar, Claw (Badger mines), Dirtbag, nanoframes up to 50 metal and armoured targets (except Crab).
• Light - As above, as well as units costing less than 90, Razor, Sparrow and unidentified radar dots.
• Medium - As above, as well as units costing less than 240, except Stardust, with the addition of Raptor.
• Heavy - As above, as well as units costing less than 420.

Some units default to Free and a few default to Light. The behaviour is overridden by Attack Move as well as manual targeting. Units are also more opportunistic when it comes to fighting shields, now firing at nearby small shields if nothing else is in range. Most non-artillery do this and it is essentially a range buff against shieldballs. This behaviour, called Ward Fire, can be configured in Settings/Unit Behaviour or enabled as a state toggle under Settings/Interface/Commands. There are also a few improvements to Attack Move.

• Siren brings its main gun into range on Attack Move.
• Most skirmishers and assaults no longer engage drones on Attack Move, however they will still fire at them if nothing else is in range.

Interface

• Individual players can now be highlighted in the endgame graphs by clicking on their name.
• Improved the filter box of the map list.
• Renamed 'Map Selection' to 'Set Map Bans' in the Matchmaker Tab.
• Selecting Puppy, Athena, Caretaker and Strider Hub enables the reclaim highlight overlay.
• Unit info screens now show movement type.
• Clarified Reaver and Hercules helptext.

Fixes

• Greased Tremor rotary drive.
• Fixed Crab curling?
• Fixed Adamantine Mountain team names.
• Fixed newly constructed units sometimes not following factory waypoints.
• Fixed overkill prevention sometimes knowing too much about unidentified radar dots.
• Fixed trouble toggling Puppy Goo.
• Fixed some parts of long terraform queues being cancelled prematurely.
• Removed Leaper Chickens from planets Sapphire and Vis Ragstrom.

[ 2021-03-05 11:59:20 CET ] [ Original post ]

This is a balance patch, with changes to raiders, artillery, turrets, cloaking and drones. Each of the medium turrets has been nerfed, with a large nerf for Stinger, a fancy nerf for Stardust, and small nerfs for Faraday and Gauss. Most of the raiders with high burst damage have less range, as they may have been buffed a bit too much by the aiming improvements of last year. Some of the more oppressive artillery is a little worse, area cloaking is harder to use in general combat, and commander drones should be less annoying to fight. Other changes include an excellent new walk animation for Outlaw and some behaviour fixes for Attack-Move.

Units

Duck reliably hits units as small as Glaive, but lost a little range. It is a little sad to see a physics trick go, but Amphbots should not be balanced around around swingy raider interactions.

• Land range 240 -> 235
• Projectile velocity increased by 10%
• Projectile turn rate increased by 39%

Venom lost some range and health.

• Range 245 -> 240
• Health 750 -> 740

Dagger lost the most range because it is the fastest.

• Range 212 -> 205

Blitz didn't lose any range because it is not as popular as other burst damage raiders. Claymore is more reliably useful, but we are taking care to not make it too powerful too quickly.

• Health 1260 -> 1300
• Projectile speed increased by about 50% (both on land and sea)
• Range 300 -> 280 (both on land and sea)

Sling loses some damage in sympathy with Stinger.

• Damage 150 -> 140

Badger loses most of the 25% damage buff caused by fixing its 5th Claw bomblet.

• Mine damage 200 -> 170.

Tremor finally loses the ability to fire while moving, and must pack up to move.

Turrets

Stardust now 'heats up' as it fires, reducing fire rate as it does so. This allows it to retain most of its power against raiders while dealing less sustained damage to tankier assaults.

• Gains 3.8% heat per shot.
• Loses 14.3% per second.
• Slow scales up to 50% at max heat.
• Starts with 100% heat.

Faraday is more of a weighty choice.

• Cost 250 -> 260

Gauss deals less damage to lean into its anti-artillery role.

• Reload 2s -> 2.1s

Stinger is less efficient and easier to assault.

• Cost 420 -> 450
• Health 2475 -> 2250

Mechanics

Starting metal is lower to give small units a bit more space to breathe.

• Income +6 metal, +8 energy -> +5 metal, +8 energy (-1 metal income for commanders).
• Initial resources 300 metal and energy -> 250 metal and energy.

Cloaking an army for general combat is now harder and less effective.

• Iris radius 440 -> 400.
• Increased recloak time for area cloaking 5s -> 6s.
• Default decloak radius for area cloaking is now 12*footprint + 56, instead of 75. This means most units have a decloak radius of 80, 92 or 104.
• Imp and Snitch have their decloak radius increased 75 -> 80. Other units with personal cloak are unaffected by the decloak radius change.

Companion Drones are cheaper and easier to catch with raiders.

• Cost 300 -> 200
• Range 180 -> 150
• Cruise Alt 100 -> 85
• Guardian progression 1/1/2/2/3/3 -> 1/1/2/2/2/3

Battle Drones are also cheaper, but Guardian Chassis only receives one for free.

• Cost 500 -> 350
• Range 240 -> 200
• Cruise Alt 100 -> 95
• Guardian progression 0/0/0/1/1/2 -> 0/0/0/0/1/1

Fractional reload times resulting from status effects are now rounded to the nearest frame, rather than round down. This buffs units with slow damage, particularly against units with a high rate of fire.

Behaviour

• Moving now consistently grants immunity to being kidnapped by enemy transports.
• Units on Attack-Move now periodically reset their target. This ensures that they don't end up chasing retreating enemies through enemy lines.
• Improved Emissary movement packing.
• The Alt+N default terraform hotkey makes slightly higher walls.
• Added a Caretaker deathclone, it blocks movement like most deathclones.
• Made it a little easier to shoot Lotus and Stinger from the bottom of cliffs.
• Tactical AI is off by default for Emissary.

Visuals

• Improved Outlaw walk animation.
• Increased Bulkhead icon size slightly.
• Added checkbox options for unit halos, platters, selection halos, and selection shapes.
• Teamplatter widgets use the same base scaling as selection shapes.
• Map dimension and type are now shown below the map in the lobby.

Fixes

• Fixed EMP breaking factories.
• Fixed Archer unit AI sometimes closing range inappropriately.
• Fixed Puppy Gather settings under Unit Behaviour not being applied.
• Damaging or killing drones no longer counts towards endgame stats.
• Reduced the permeability of the side walls of Shielbot Factory, Cloakbot Factory and Hovercraft Platform.
• Fixed camera state recall and ctrl/alt+MMB rotation jitters for COFC (the advanced camera).
• Fixed build spacing widget crash on rapid camera rotation.
• Disabling a selection widget no longer enables the basic selection squares if any other selection widget is enabled.
• Fixed Area Mex with Space, and no other modifiers, held.
• Fixed map terraform masking not applying to smoothing.

[ 2021-02-14 09:43:12 CET ] [ Original post ]

Tanks have been oppressive lately, with their ability to exert a lot of early pressure. Bakuhatsu suggested a slower Kodachi and organised some testing, which went fairly well, so we're going with this large yet simple change. In other news, playing new mods is now as simple as a single button on the mod page, Dirtbag is the guinea pig for a new animation system, bombers are a bit easier to control, and various lingering bugs have been fixed.

Balance

Kodachi no longer outruns Glaive and Scorcher.

• Speed 117 -> 108

Features

• Bombers are smarter about rearming. They now temporarily skip to their next Move command after bombing, ignoring intervening Attack commands. This makes queuing a safe retreat after bombing a group of units much easier.
• Added a 'Play This Mod' button to mod pages on the site. See Future Wars for an example.
• Improved Dirtbag walk animation.
• Added Disarm Award.
• Added some Portuguese translations.
• Updated Russian translations.

Interface

• Save channel topic to avoid re-displaying it multiple times a session.
• Added a filter field for the map list.
• Added a toggle for excess metal flash under 'Settings/HUD Panels/Economy Panel'.
• Added a toggle for Attrition Counter under 'Settings/HUD Panels/Extras' so it can be bound to a hotkey.
• Added free stockpile to '/luarules nocost'.
• Added a few tip window settings under 'Settings/HUD Panels/Unit Stats Help Window' - useful for tutorial videos.

Fixes

• Fixed a premature victory bug on Planet Tempest (as well as a few other missions).
• Fix terraform mex placement UI.
• Fixed airpads not working slower under slow/emp/disarm.
• Fixed a few poorly configured projectile lights.
• Fixed Slow Award damage calculation against commanders.
• Fixed team names on Adamantine Mountian.
• Fixes for the WIP Caretaker AI. It can be tested by enabling the widget 'Auto Patrol Nanos v2'.

[ 2021-01-30 11:06:15 CET ] [ Original post ]

Here are a few fixes to round out the year. Seawolf behaves better around coasts, Metal Extractor placement is smoother, and a lingering graphics bug has been resolved. This is probably the last patch of the year so I'd like to thank the community for helping each other through an otherwise difficult year.

Fixes with multiple dot points

Submarines can no longer traverse shallow water, reverting a recent experimental change. Unfortunately it resulted in Seawolf needlessly revealing itself to surface weaponry while skirting islands.

• Minimum depth 5 -> 15.
• Seawolf now has a higher aim point and fire point. This solves various weapon blocking bugs that could occur around coastlines.

Metal Extractor placement is now consistent with other structure placement.

• If you click where a mex can be placed, the mex is placed, otherwise the click is ignored.
• Previously, whether the click was used depended on the ghost under the mouse cursor.
• This caused issues such as being unable to click on a blocked location near a free metal spot to place a mex.

Fixes with one dot point each

• Writing a report description is now mandatory.
• Replaced the 'Clan List' button in the Profile tab with 'Contact Admins' as this seems more useful.
• Fixed reclaim failing to be highlighted during start position selection.
• Filtered out the low quality part of the construction unit reply.
• Fixed the problems stemming from the outline shader update, possibly even correctly. This fixes the non-default widgets that were missed by the previous patch, such as Bloom and Blob Shader.
• Modding in extra shields is now a bit easier.

[ 2020-12-17 02:00:31 CET ] [ Original post ]