I am a huge fan of terrain manipulation, even in real time strategy games. At its best, terraform is a supercharged form of map modification which belongs to nobody when built, allowing both sides to adapt to the new terrain. A wall to shelter from artillery might be a great idea for the moment, but it becomes a liability when the enemy uses its shadow to send spiders swarming over the top. The creative problem solving and strategising encouraged by terraform are perfect for Zero-K, and as a result the construction of walls, ditches and ramps has become a core part of the game. Reaching this point took over a decade though since terraform is fraught with issues.\n\nWhen I try to be unbiased about it, terraform in RTS tends to suck. A number of games experimented with it in the 90s, and it mostly served as a barely functional gimmick. Base building is already enough to let players stamp their presence on the map, and base building is a much safer prospect than full free terraform. To start with, the shape of the terrain has to actually matter for modifying it to be important. Few games satisfy this requirement, and with good reason, because making the terrain matter too much is a far greater risk. Too much detail is overwhelming, and the ability to manipulate that detail exacerbates the problem.\n\n\n\nFreely manipulating the terrain is a UI nightmare. Drawing 3D shapes on a 2D screen is not easy, and players tend to jump right in with no preparation. This, plus the immense number of manipulations available, can easily result in a fiddly UI. The inherent freedom of terraform is also at great risk of being used in boring ways. A fortress complete with crenellations and moat might look cool, but it is surely cheaper to scatter thin spikes all over the battlefield to utterly confuse enemy pathfinding. Singleplayer and slower paced games have an easier time, as players are willing to learn more complex UIs, and there are no opponents to call foul on cheap tricks. But for a multiplayer RTS, terraform is at great risk of being unfun to use and even less fun to play against.\n\nThe issues above are solvable, but we only did so after years of iteration. The very first terraform replaced the Dragon\'s Tooth with a buildable block of terrain, and it dates back to 2008 - the height of Complete Annihilation . The Dragon\'s Tooth was a wall section that worked by turning into a crush-resistant wreck when built, and the new system worked the same way except with terrain modification. There were two block types, to raise or lower terrain, and both had a 2x2 footprint, which is the smallest footprint in the game. Building a wall involved dragging a line of blocks, and building a tall wall required players to place blocks on previously built blocks. This is where things started to get fiddly.\n\n\n\nThe terraform gadget was probably added on a whim, as was the norm, although in this case it happened to be added by the lead developer, Quantum. The terraform block was an unusually conservative feature, but this was soon remedied by his next addition: the jankiest form of level terraform imaginable. Quantum made a new type of block, still with a 2x2 footprint, but which levelled something like an 8x8 area around itself when built. The new height was based on the centre of the block, so it was usually used in conjunction with a deep hole or tall spire. This was very powerful, and personally very fun, but also very broken. The modern limitations that allow for sustainable terraform fun were yet to come.\n\nAt this point terraform was free in the sense that it only cost worker time. It could also move structures, so the standard play was to build something like a Singularity Reactor, dig a deep hole with trench blocks, then make level terraform at the bottom, moving the structure deep underground. The process was even repeatable, which let Antinukes dodge up and down in response to threats. This was not as common as you might expect though, as busted terraform was not even the roughest part of Complete Annihilation. Why terraform your nukes when you can just cloak them?\n\n\n\nI was a big supporter of terraform and wanted more, so I added a block that created a small ramp, much like the level block. The ramp was enough to inspire the first Pyro launcher , on the North side of Victoria Crater if I recall correctly, but it was far too limited, being fixed at 45 degrees and only able to point in cardinal directions. So by late 2009 I decided to rewrite terraform from scratch. The goal was to make proper versatile ramps, fix the fiddliness of wall creation, and to add lasso UI as a more sensible form of the level block. The bones of the rewrite survive to this day and, unfortunately, so does most of the old code. The system endures due to a strict division of labour.\n\nThe first half of the terraform system is packed with command modes and rules about what terraform is allowed to do. The player has access to ramp, level, raise, smooth, and restore commands, and these commands are modifiable and limited in certain ways. The entire purpose of the first half of the system is to specify generic terraform segments, which are just lists of \"move position (X,Z) to height Y\". The second half of the system then handles the creation and progress of these segments, without any knowledge about where each segment came from. So behind the scenes, all terraform types are built and priced the same way.\n\nThe new system served as a good foundation, but there were still many problems to solve. Some were solved by the choice to match the resolution and implied limitations of the 2x2 block system, which cut out a chunk of excess freedom . The remaining issues came in three flavours, although the solutions often attacked all three at once. The issues were:\n

\n
• Units being stupid , especially about targeting .\n
• Encouraging interesting uses over uninteresting ones.\n
• Nobody will bother with terraform if the UI is terrible.\n

\n\n\nOne of the first tweaks was the addition of the Shraka pyramid, named after the player who suggested it after I put a Razorback (a Dante-sized Reaver) on a very tall spire during a FFA on Desert Triad. Tall terraform was too powerful for its cost, and my extreme application amounted to going to space . One potential fix was to make terraform more expensive further it reaches from the original map, but this reference to old terrain felt too arbitrary and opaque. Instead, we added the requirement that terraform shore itself up by constructing a sort of skirt around itself. The extra dirt costs resources, which naturally makes tall terraform more expensive, as well as take up more space. The limited slope was also great for unit AIs that did not take kindly to being asked to aim directly up or down. Plus, the sheer cliffs suffered from extreme texture stretching, and tended to make spiders freak out.\n\nThe Shraka pyramid ruined the prospect of computing a precise cost estimate, but that drawback pales in comparison to all the issues it solved. There were other unit AI issues, and some surely remain today, but they are often solved by aim position tweaks so that, for example, units can return fire against walled defenses. Resolving these issues also has the neat side effect of jank-proofing maps, since if units can handle adversarial player-driven terraform, then they should be able to handle anything a reasonable mapper might throw at them.\n\n\n\nBuffing fun terraform and nerfing degenerate uses has mostly been a matter of cost. The first cost adjustment was quite easy: if terraform is going to be easy to use and powerful enough to bother with, then it should cost metal and energy to reflect that, and the rest of the design demands that these costs be in equal ratio . But from there it quickly degraded into formulas that resist anything more than a vibe-based understanding. It would be nice if terraform cost was directly related to the volume displaced, but this is one of the least viable approaches.\n\nRuining the map is inherently easier than opening it up, which is bad news for anything with fewer than four legs. Vehicles suffer the most, so the terraform cost formula contains hefty penalties for terraform that specifically targets them. We want to see strategically placed walls and ramps that open up the map, not cheap fields of impassable tank traps. The protection of vehicles focuses on one particularly harmful case: the knee-high vehicle-blocking wall. Such a wall is high on perimeter and low on volume, so terraform is penalised for having a large perimeter. There used to be an area cost penalty too, but thankfully it was removed for being redundant.\n\n\n\nBehind the scenes, the map terrain consists of a grid of points, each spaced 8 elmos apart (where elmo is the elementary unit of distance). The smallest terraform block is 32x32 elmos (2x2 in footprint units), which corresponds to 25 individual points. This 5x5 grid of points has four corners, twelve points along edges, and nine internal points. So if we want to raise such a block by 100 elmos, that will cost:\n

\n
• 25 x 0.0064 x 100 = 16 metal for the volume cost of each of the points.\n
• 12 x 0.75 = 9 metal for the twelve edge points.\n
• 4 x 1.05 = 4.2 metal for the four corner points.\n
• A base cost of 6 metal.\n

For a total of 35.2 metal, plus whatever pyramid is created during construction, paid for at the volume rate of 0.0064 metal per elmo. For a 100-elmo high block the pyramid would cost 24.6 metal on flat ground, but if cliffs are involved, then all bets are off.\n\n\n\nThe terraform cost calculation is a bit complicated, but it does the job. Take a look at the image above, each wall costs 250 metal, yet the flattest one has by far the least volume, and 250 metal is comparable to covering the same distance with turrets. The cost factors of 0.75 and 1.05 for edges and corners are not static either, but are reduced for points on the edge that modify the terrain by less than 10 elmos. This buffs terraform that sits flush with existing terrain, which mostly means smooth and restore.\n\nThe perimeter cost is reduced below changes of 10 elmos because this is the height required to block vehicles. The vehicle-blocking threshold has actually changed a few times, which is surprising for a game that can run maps from two decades ago and still play as the mapper intended. The first threshold change was the result of fixing some edge cases in pathfinding. Commanders could walk up chest-high walls back in 2009, while vehicles could phase up cliffs that modern bots struggle with. This was only a problem for sudden terrain changes; smooth ramps were fine. This was solved by engine developer and lua wizard jK, who incidentally also let units walk along the top of terraformed walls. The added consistency was great, but it meant a cliff as low as 6 elmos could block vehicles.\n\nThe vehicle blocking threshold was increased to 10 as part of a larger change to the Shraka pyramid. The original pyramid was not great at letting units shoot into holes, especially long flat vehicles like the Scorcher and Dagger. This became a problem as UI improvements increased the popularity of burying mexes, which made it very tough for vehicles to raid effectively. The solution was to add a sort of flange, or reduced slope, around the outermost edge of the pyramid. Vehicles could mount this slope to peer into the hole and shoot at whatever is inside, and as a side effect, they could climb higher terraformed walls. A flange was also added to the inside edge of trench-type terraform to give attackers a better angle of fire. Not only did this make it easier to shoot at mexes in holes, but it also gave defenders more space to shoot at Sky Jacks.\n\n\n\nTerraform could not be improved without improving the UI. Not only does the UI have to be good for the feature to be good, but terraform was only tested and abused once the UI was good enough for it to be worth the effort. By now we have hotkeys and presets for all kinds of terraform. Alt+Mouse Wheel lets structures be placed at any height and they can even be queued on currently unsuitable terrain. The height selection UI is a bit fiddly, so the Alt+V/B/N/M/H presets create terraform of a variety of convenient heights, with the first two blocking vehicles and bots respectively. Alt+J digs a hole while Alt+G matches the height of wherever you first click. The default behaviour of the ramp UI has been through a few reworks, and there is even an area mex mode that buries or walls mexes.\n\nConstant playtesting was vital to the development of terraform. Players need time to adapt to UI improvements and explore the possibilities they open up, which fed back into the mechanics and drove further UI improvements. Mechanics were changed in response to unfun discoveries, while UI changes were built to support fun ones. We also support the powerful and unavoidable uses, even if they are not fun, because terraform should not involve fighting the UI . The required years of iteration might be why RTS mostly gave up on terraform. A designer with only a few years of mostly closed development is at a significant disadvantage.\n\nThe design work is only half the story, as terraform would not even be possible without a lot of work on the engine side. Map deformation itself is no easy feat, since units have to update their pathfinding data to navigate any new terrain, so it is impressive that the paths update fast enough to take large-scale terraform into account. Another amazing project is kloot\'s vision-restricted heightmap, which means that you have to actually scout the enemy base to see their changes to the map. Terraform would still be possible without this, but it would always feel bad to globally reveal your Antinuke when you put them in a hole or behind a wall. He also added the ability to modify the map texture which, in conjunction with jK\'s slope fix, made it possible to texture terraform based on what can walk there.\n\n\n\nBy now the terraform system is rock solid and I have yet to see any game do better, at least under the constraints of fast-paced competitive fairness. Populous: The Beginning might come close, but it is a very different game, although it did inspire the Zero-K ramp. The last major tweaks were in 2020 with the addition of pyramid flanges and the prohibition of terraforming near enemy units. The enemy terraform prohibition is interesting in that it took so long to become necessary. There used to be a game of reverse whack-a-mole, with Caretakers or swarms of constructors trying to trap encroaching tanks. This was partially addressed by giving terraform a high base cost, but not fully, so we bit the bullet and added the somewhat arbitrary restriction on terraform with enemies nearby.\n\nFor all my misgivings, blocking terraform with enemies nearby turned out great. It ended up reinforcing my favourite part of terraform: that nobody owns it. Previously a defender had plenty of time to tear down a wall once it became a liability, but now that is impossible if the enemy is already in your midst. Players have to plan out and commit to terraform before the battle, which gives your opponent time to consider how to exploit it to their advantage. It is simply amazing that Zero-K players regularly spend resources on something that they fundamentally do not own, and that may even be turned against them in the future. These kinds of choices are a real test of strategic thinking, which is why it\'s such a shame that so few games experiment with terraform, or even with any form of ownerless map modification, despite the challenges.\n\nIndex of Cold Takes

[ 2025-08-24 00:29:10 CET ] [Original Post]