Loading...
  OR  Zero-K Name:    Password:   

How to calculate cost of terraform?

28 posts, 1161 views
Post comment
Filter:    Player:  
Page of 2 (28 records)
sort
9 years ago
What is a rough formula of altitude change and tiles covered that would let me guesstimate how much a terraform would cost?

Do the slopes created by a terraformed pillar also add into the total cost as the terraform gets bigger, or are the slopes auto generated?
+0 / -0
Make it simple: Terraform costs makes it ineffective, just in special situations it makes cost.
+0 / -0
ROrankForever
quote:
in special situations it makes cost.


That's what I want to calculate for. Once I have a general cost formula for given sizes of terraforming, i can figure out how certain terraform ideas could make cost.

This is for fun.
+0 / -0
Skasi
9 years ago
quote:
Terraform by default costs 1 metal, energy and build power to raise or lower 1 heightmap grid, each vertex of the blue grid maps onto a point on the heightmap grid. Due to the sloped sides it will be costly to make a very high spire. Equal volumes of terraform will have the same cost regardless of shape. Cost can be changed with the "terraform cost multiplier" ModOption.

As a general guideline, assuming the base value for terraforming cost, creating a 15 deep wall (or trench) will cost roughly 19 resources per 'segment'.

According to the Terraform cost manual entry.
+0 / -0


9 years ago
That description is likely out of date. AUrankAdminGoogleFrog added a ground area cost element (later changed to perimeter, IIRC) at some point and I don't remember it being removed.
+0 / -0


9 years ago
This is a difficult question.

Firstly you should be familiar with elmos. Spring distances are measured in elmos, you see them in the range of units within the detailed info screen. They are quite small, for example LLTs are 32 elmos wide and have 460 range.

The heightmap has a resoultion of 8 elmos. So maps are a grid of points 8 elmos apart and each point has a height value. The grid that appears during structure placement has a spacing of 8 elmos. Talking about volumes of terrain smaller than this resolution does not map much sense. Terraform cost is calculated at this level.

Resources are spent on terraform by nanolathing nodes on the ground called "Terraform". These units exist only to provide constructors with a target. I call them terraunits. Each of these terraunits handles its cost independently. If you make a large area of terraform it will be split into many terraunits but the cost is calculated as if each unit was designated by itself.

There are also 4 types of terraform (Level, Raise, Smooth and Restore) which have two distinct ways of being implemented (area or wall) as well as a special one; Ramp. The method which you use you give the terraform order has no relation to the cost of the terraform. Each order is translated into a set of points which want to be moved to certain heights. I will call the set of points the terraform points. The terraform points are the points which are selected when you give the command, if you give a Level or Raise command they are the vertices, edges and interiors of the blue boxes (because the blue grid has a spacing of 16).

Terraform has 4 components to its cost:
  • Base Cost
  • Perimeter Cost
  • Volume Cost
  • Pyramid Cost
These costs are set here: https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/unit_terraform.lua#L115

The Base Cost and Perimeter Cost are set when the terraunit is created. This cost has to be paid before any terrain is deformed. Volume Cost and Pyramid Cost can change during construction and the terrain is deformed to indicate how complete these costs are.

Base cost is the simplest of these. The current Base Cost is 12 so every terraunit has to have 12 metal spent on it before it does anything else.

Volume Cost is the next simplest. Every terraform point contributes cost equal to its required height change multiplied by the volume cost multiplier. Terraform points with a structure on them set their required height change to 0. Terrain changes during construction (such as structure placement/death or other terraform) can cause Volume Cost to recalculate to take the new required height change into account.

So for example say you want to build a 100 elmo high spire for your LLT. The blueprint grid for an LLT has 25 vertices so there are 25 terraform points. Each has to be raised by 100 elmos so the Volume Cost would be:
25*100*0.0064 = 16

Pyramid Cost is like Volume Cost but occurs for the supports form around high terraform. A terraform point can have up to 4 edge points, these are heightmap points which are adjacent orthogonally to the terraform point but are not themselves terraform points. If the difference in height between a terraform point and an edge point is greater than 30 then the height of the edge point has to be changed such that the difference is 30. This is done on the fly so Pyramid Cost is hard to calculate in advance.

The cost of changing the height of an edge point is the same as a terraform point, it depends on the volume cost multiplier. Edge points can have their own edge points which have their height restricted based on their distance to the terraform point that sits at the top of their family tree. This is what causes large and rounded pyramids. I won't do an example of Pyramid Cost because it is too messy to work through.

Volume Cost and Pyramid Cost are almost the same thing. The cost here is simply the total heightmap change caused by the terraform multiplied by the volume cost multiplier.


The complicated cost is Perimeter Cost. It exists as a fudge to make vehicles have a chance against bots who terraform long lines of terraform 6 elmos high across the entire map. With the costs stated so far it this would be a very inexpensive tactic. The first 6 elmos of height for terraform points with edge points incurs an extra cost. So if you terraform is 3 elmos high the cost is halved but anything over 6 elmos is no more expensive. The extra cost for each terraform cost is as follows:

#EdgePointMultiplier * min[height, 6] * PerimeterCostMultiplier

The #EdgePointMultiplier is 0 if the terraform point has no edge points, 1 if it has 1,3 or 4 and 1.4 if it has 2 edge points. PerimeterCostMultiplier is currently 0.05. If you wanted to make up some fluff to explain this cost you could say that the edges need a bit of extra reinforcement to prevent fraying.

This description of Perimeter Cost was probably not that useful. The upshot is that the Perimeter Cost of any height over 6 for LLT shaped terraform is a mere 5.28. From experimenting with walls I think the Perimeter Cost contribution for a wall is about 0.09 metal/elmo by the length of the wall.

It may be more useful to test this and see what happens. Cheat yourself a game with an economy at equilibrium and make terraform to see how much it costs.
+4 / -0
Terraform seems to be one of those features where you ask yourself "Does it really need to be that complex and precise?".
I greatly admire AUrankAdminGoogleFrog 's effort to implement it, and i know a number of updates have been done to make it more user-friendly, but i still dont think i have ever seen it actively used in serious games.
And i believe it is still mostly because of how much time it takes to properly set up, not because of ingame balance. Terraforming always becomes quite a heavy burden on APM, something you cannot afford in a serious game.


One of the problems i have always had with terraforming is my OCD for fine shapes when playing simbase. It always looks great to have your defences hidden by some neatly laid out walls and moats, but it gets completely ruined if something is out of shape.

I wish there was some sort of terraform overlay activating when using a terraform, that would clearly show the heightmap grid and the squares that would be affected by the current chape.

Right now you get that information only AFTER confirming the shape, so if you missed, you have to redo it again and again, until you get it right. When making a complex shape, this wastes a lot of time, from an action that is already often considered too complex to bother.
+0 / -0


9 years ago
You would have to figure out a fast way to calculate what is going to happen.
+0 / -0
avoid unit get stuck in current raising terrowall somehow.

i did not think of aggressive terrorform, yet. what i meant was

e.g.:
1) create terraform (ghost unit).
2a) con units walk close
2b) maybe friendly units position (while moving) is in an terraform area
3) terrain raises. cons/units get stuck if they are right there when terrorform raises/lowers

=> (freindly?) units should know about the area which is modified and dont walk there , or even better clear the area like they do for a real building/starting nanoframe. else its just annoying.
+0 / -0


9 years ago
Rephrase that.
+0 / -0
9 years ago
quote:
Rephrase that.

I think he meant that units might get stuck when terrain is being terraformed right underneath them. This might happen intentionally as some sort of defence (as seen in some FFA games, where a bunch or rectors insta-bury a detri), or unintentionally, when friendly units path through an area slated for terraform right as it starts getting terraformed.

Another bug with terraforming happens when making ramps. I often find my units (especially vehicles) unable to climb onto the ramp. The ramp itself is veh-pathable, but there is a thin border between ramp entrance and the regular ground, blocking the way onto the ramp.
+2 / -0


9 years ago
Units not standing right "on" terraform territory often get caught up in the pyramid segment.

I think it should be rather easy to precalculate terracost, all those factors are pretty deterministic. Some errors might occur due to deformation events after the terraunits are created, but i think that's allowable.
+0 / -0
RUrankYogzototh I would not call either of those things bugs.
+0 / -0

9 years ago
reference that.
+0 / -0


9 years ago
quote:
I think it should be rather easy to precalculate terracost, all those factors are pretty deterministic. Some errors might occur due to deformation events after the terraunits are created, but i think that's allowable.
By all means go ahead and do it. It has to be done in the widget because otherwise terraform could be used to scout terrain changes and structures.
+0 / -0

9 years ago
I have to agree with RUrankYogzototh's points here.
1. Without manual micro, you risk your cons getting stuck on the steep sides of the terraform. Not only is it annoying, but it costs a lot more micro to get them out of there (or reclaim them). If they get lifted up on the main part, that's fine as it can be intended. Getting your cons stuck on the side is never intended imo.

2. As RUrankYogzototh described, even if you build a perfectly passable ramp, you often have to spend multiple iterations of terraform until the end points become passable, especially for vehicles. The necessary amount of micro for that is not justifiable in a serious game.
+2 / -0


9 years ago
Proposed hackfix: non-allterrain non-flying units get pushed off the pyramid section?
+0 / -0


9 years ago
1. Impassible terrain in the new engine pushes units off it. This pushes units off pyramids so I think it counts as what you want.

2. What do you expect if you build a ramp starting on non-flat ground? Describe exactly how this is fixed.
+0 / -0
RUrankYogzototh
I feel your pain.
My deepest desire is to create "terraform templates" and "building templates" that can be combined together to produce one click wonders of engineering.

Example here:


This, automatically, by opening a seperate widget menu, and selecting a saved template, and clicking on the ground, with the build order retained appropriately.

This shouldn't be much different than replaying saved actions, similar to replays, right AUrankAdminGoogleFrog ???

Also, i think that building the walls via boxes might loophole around paying the "Perimeter Cost" by not having an inside perimeter to calculate in addition to outside perimeter.
+4 / -0
9 years ago
Yeah, i was also thinking of suggesting a "template" tab on builders, where custom templates could be added.

For me these would certainly include a mex+4solars combo, a stardust on a 30 elevation behind a 30-deep moat, a simple 1x1 (smallest possible) wall, so i could build it in 1 easy click without going in depth, maybe also some defensive combos with walls/moats/turrets.


I wonder where one could set up their blueprints though. I assume the easiest solution would be to have a "record a blueprint" icon in the blueprint tab. You press it and it remembers the next few buildings/terraforms you queue up. Up to 8-10 shouold be enough. Press again to finish and save the blueprint. And to delete a blueprint, uhh... i dunno, right-click on a blueprint, receiving an "are you sure?" prompt.
+4 / -0
Page of 2 (28 records)