Terraforming

[byorgey]

Now that we have custom terrain (#1775), and especially if we add something like #205 , it should be possible for robots to programmatically change the terrain.

This would require reworking the way that we store terrain values, since currently there is no way to store/remember any terrain values other than the ones that are generated by the world function. We could probably do something similar to the way that we currently store entities.

[xsebek]

The natural solution would be to add a terraform command that would require God's capability. 😇

I am not sure what is the best structure to represent tiles or if we even need to optimize it if can not measure it realistically yet. I suppose we could run one tick with a mutable array and get back a normal one by using runSTArray. 🤔 EDIT: As would need to make a copy if it is ever edited - laziness might be enough to protect us from the performance penalty.

EDIT2: Actually we probably could simply collect the updates and execute them all at once at the end of the tick - if more are in the same tile then it will be very efficient.

[xsebek]

I think a good performance test would be to run a line of robots across the screen and change the terrain of every visible location.

We could run that a few times, left to right and back again, like windshield wipers.

Compare that with the same run with the terraform replaced by noop and see if it is even noticeable to the player.

[byorgey]

Using actual mutable arrays for the terrain seems problematic; see the discussion at #30 . Another possibility would be to do something similar to entities: we have a base, immutable array storing initial terrain values, and then a map of "overrides". To look up the terrain value for a particular cell you first look it up in the override map, and then fall back to the base array if you don't find it.

[xsebek]

I think with terraforming the common use case will be doing sweeping terraforming of an area once and then leaving it as is.

See my EDIT2 - if we collect the terrain updates at the end of the tick, we can update the pure immutable array once. So if you have a lot of robots changing the terrain at the same time it will be more efficient but the data can stay immutable. This will be particularly useful for As which must not change the original immutable array and in fact, it will never even get to it because it does not run in ticks.

[xsebek]

As another thought, we should add a counterpart function scanTerrain: cmd (unit + text). Should be trivial to add. 🙂

[byorgey]

I think updating the immutable terrain array once per tick is probably too frequent. Imagine you just have one robot walking back and forth changing the terrain - it can only affect one square per tick and you would be regenerating the entire tile every tick. But I can imagine buffering a bunch of terrain updates and then regenerating the immutable tile array once enough updates have accumulated.

[xsebek]

I bet it would not be so bad, especially if the compiler can figure out that we will not need the original array anymore. But we will have to try measure it and see. 🙂

[byorgey]

I think it will be bad 😄 But yes, we will have to benchmark it!