Complete rework of Terraforming

[LienRag]

What about making Terraforming a real engineering project ?
Instead of one Building, have many parts (buildings, Policies, specials, techs) progressively transform an environment until it reaches a breaking point and becomes another environment ?

[Ophiuchus]

How about reading old topics about this?

[Oberlus]

How about reading old topics about this?

+1

Also FOCS files.

[LienRag]

How about reading old topics about this?

I vaguely remember them (or at least some of them) but couldn't find them (searching for "Terraforming" brought irrelevant discussions; I may have forgotten to tick the box "only in subject titles" due to exhaustion).
And my proposal is different from everything I remember, I'll expose it more clearly when I'll have the concentration to do so.

[Oberlus]

I vaguely remember them (or at least some of them) but couldn't find them (searching for "Terraforming" brought irrelevant discussions; I may have forgotten to tick the box "only in subject titles" due to exhaustion).

Have a rest and then come back to the search panel with renewed strength.

[LienRag]

Actually, in the oldest discussions, there was some interesting points (and yes I've also read recent discussions, notably the Oberlus idea of having two types of Terraforming).

But what I mean is that since Terraforming is such an important part of SpaceOpera fluff and of FreeOrion, we probably can do better.

So not have one "Terraforming" building, but a variety of Terraforming processes, corresponding to different Techs, Policies and strategic resources, whose combination would be necessary to completely move a Planet from an Environment to another.

Starting when a planet would reach a certain level of Population, a partial process of Terraforming would (very slowly¹) naturally occur (though it could be halted when under certain Policies, or under Protection focus).
Then some Techs could allow other processes to happen, either naturally or by unlocking Policies and/or buildings.
Finding some strategic resources (alien plant seeds, for example) would then help starting/accelerating certain Terraforming processes. Influence projects could also accelerate some processes, or even start new ones.

It's probably worth, considering the importance of Terraforming, to have a specific panel for it (like there is a Design panel and a Research panel).
In it we'd have the different Environments and the state of the Empire's abilities to transform them into the next, and the current allocation of the Empire's efforts to the Terraformation of each of them (through "terraforming points" or anything similar).
Also, the different planets currently in the process could be in that panel, with a presentation of the state they are, and with sliders (linked together, so adding on one would remove on the others) allowing to allocate the Empire's effort specifically on each planet.

Certain Terraforming processes ("green barrier" in Desert planets for Terran-oriented species, for example) would help Population, other could help Production ("Atmosphere Removal" for Tundra to Barren, for example) and other Influence ("Ocean lilies") or Research ("Greenhouse effect").

So Terraforming would become a big part of the game, not just "build a building".
It would also make different Environments really different, which would be much more immersive (using biological processes to get a planet from Desert to Ocean is way more logical than using them to turn a planet from Barren to Radiated).

"Uplifting" Species being also a core part of Space Opera fluff, the same Panel could have on its other half a similar presentation of the state of genetic modifications to Species that are already done, and sliders to set where the effort should be put (adding aerial lungs will help your Scylior adapt to Terran planets, not really helpful for Barren).



¹ I'd say one hundred turn to finish the partial process

[wobbly]

I personally wouldn't want an over complicated process for terraforming. Mostly on the grounds its a mismatch with other mechanics where the game strives for simplicity. What I would like to see is a way to terraform using exobots. One of the issues I have with terraforming as is, is that you need to research the green techs to make it habitable in the 1st place. Having done that you no longer need to terraform the planet. I'd prefer to see it be an alternative to the growth techs. You drop exobots on an uninhabitable planet, they terraform it, you replace them with your species.

[Ophiuchus]

I'd prefer to see it be an alternative to the growth techs. You drop exobots on an uninhabitable planet, they terraform it, you replace them with your species.

I like the narrative. But for gameplay i would rather cut out having to really having to deploy exobots. So either allow terraforming on any outpost. (terraforming on outpost could require access exobot tech/colony)

Anyway, the main reason for requiring a species on a planet for terraforming is specifying the target environment.

[wobbly]

Anyway, the main reason for requiring a species on a planet for terraforming is specifying the target environment.

Terraforming and terraforming revision. Functionally its either stepping clockwise or anticlockwise round the planet circle. It could be presumably replaced with the planet environment names.

[Oberlus]

Anyway, the main reason for requiring a species on a planet for terraforming is specifying the target environment.

Terraforming and terraforming revision. Functionally its either stepping clockwise or anticlockwise round the planet circle. It could be presumably replaced with the planet environment names.

Yeah.

Two different terraforming buildings, one to move clockwise and one anticlockwise, and the player can queue several at once (but only one gets PP each turn) to not having to revisit the planet after each terraforming step.

Or 9 different terraforming buildings, one per each planet environment, and the building performs all the needed steps (cost depending on that) until work is done and the building self-scraps.

I'm all in for any of the two ways. I think at least the first can be implemented already in FOCS (dunno if the queue-several-give-PP-only-to-one is doable).

[Ophiuchus]

Anyway, the main reason for requiring a species on a planet for terraforming is specifying the target environment.

Terraforming and terraforming revision. Functionally its either stepping clockwise or anticlockwise round the planet circle. It could be presumably replaced with the planet environment names.

Yeah.

Two different terraforming buildings, one to move clockwise and one anticlockwise, and the player can queue several at once (but only one gets PP each turn) to not having to revisit the planet after each terraforming step.

Or 9 different terraforming buildings, one per each planet environment, and the building performs all the needed steps (cost depending on that) until work is done and the building self-scraps.

I'm all in for any of the two ways. I think at least the first can be implemented already in FOCS (dunno if the queue-several-give-PP-only-to-one is doable).

yeah, discussion is also going circles (not sure if clock or anti-clock wise).

both should be possible in FOCS, both would be fine to me

queue-several-give-PP-only-to-one should be doable. Like with the shipyards, enqueue and build conditions are separate.

somebody should implement this

[Grummel7]

What cannot be done in FOCS (AFAIK) is to enqueue identical buildings and to assign PP only to the first.

After some trying I figured out how to implement 9 different buildings that works (almost) as expected. I've prepared a PR.

[Geoff the Medio]

Like with the shipyards, enqueue and build conditions are separate.

Yes, but there would also need to be a way to distinguish the different copies of the same building at the same location to make one producible but the others not. Possibly the Enqueued condition could be extended to have a minimum or maximum position on the queue, to allow checking if there are thing on the queue at certain positions, and the ScriptingContext would need to also include the position on the queue of the item being tested, to check above/below that position... And that would also need a default value... Might be possible, but could have some quirks to work out.

[Ophiuchus]

Like with the shipyards, enqueue and build conditions are separate.

Yes, but there would also need to be a way to distinguish the different copies of the same building at the same location to make one producible but the others not. Possibly the Enqueued condition could be extended to have a minimum or maximum position on the queue, to allow checking if there are thing on the queue at certain positions, and the ScriptingContext would need to also include the position on the queue of the item being tested, to check above/below that position... And that would also need a default value... Might be possible, but could have some quirks to work out.

Wouldn't it be possible and simpler to have a EnqueuedAbove condition for use in the location specification? When going through the build queue it would check those entries until the current one. So you could guard your BLD_TERRAFORM_CLOCKWISE with a

Code: Select all

location = And [ Planet OwnedBy empire = Source.Owner EnqueuedAbove high = 0 type = Building name = "BLD_TERRAFORM_CLOCKWISE" 

which would disable spending PP on the all but the first queue entry.

I guess for the implementation we would have to pass something like the current index into the build queue using the context.

currently we do not have a use case for exactly specifying positions in the build queue. and I rather not go there

[Geoff the Medio]

Wouldn't it be possible and simpler to have a EnqueuedAbove condition for use in the location specification? When going through the build queue it would check those entries until the current one. So you could guard your BLD_TERRAFORM_CLOCKWISE with a

Code: Select all

location = And [ Planet OwnedBy empire = Source.Owner EnqueuedAbove high = 0 type = Building name = "BLD_TERRAFORM_CLOCKWISE" 

which would disable spending PP on the all but the first queue entry.

The meaning or name of this condition is unclear. I'm also unsure if it will in general be possible to use such a condition for all cases where producibility checks are done. There are probably some that don't check for a particular position on the queue, or for a particular item on the queue, but rather in general want to know if something would be produbile at a location. For general use, this sort of condition would probably need to have a parameter for the position on the queue, which could then refer to the context, rather than have a dedicated context value lookup within it.

I guess for the implementation we would have to pass something like the current index into the build queue using the context.

That's probably possible, but not enough, as another problem is that the production queue update checks if everything is producible on the queue, and then remembers that for simulating future turns. It would instead need to re-calculate that for each simulated turn. But to do that, it would probably need to include the whole production queue in the context, since it can't just use the current turn queue for producibility checks that will apply to future turns after the queue has changed, and instead would need to pass the current state of the simulated queue for simulating future turns.