Topic: New resource indicators

Hey, very interesting discussion.

Indeed splitting wells is not a must. I am not 100% sure it is good idea. But if we are going to do it, my idea is:

1. Well - mines only actual water (as resource), once it is exhausted we can leave 5% probability - same as mines. But I would prefer 0% (no water mined anymore)
2. Deep Well - mines actual water (as resource) and if this fails, based on humidity.

Question of atlanteans - they can be allowed to build directly deep wells (No need for them to be identified as 'deep')

Question: Should be a "Deep well" upgrade of "Well"? What about make Deep Well separate building of medium size?

Two deep wells in vicinity - this might be problem. Best approach would be create new value for field saying how many deep wells are in vicinity and how its yield (~humidity) should be divided... But this makes things complicated...

I found a term "dug well" - are you familiar with this term? Can it be used for small wells? Just an idea....

Top

Quote

so, how do we decide whetherto do something that has been proposed or not? i'd suggest voting or something, but I am under the impression what happens in practice is that a programmer arrives and decides to actually do it.

Top

Quote

kaputtnik wrote:

king_of_nowhere wrote:

Real productivity will vary between 60% and 90% depending on humidity.

This applies only to deep wells then, is this correct?

yeah, that's the idea. deep wells would give similar productivity to current normal wells - with some moderate variation depending on humidity - so as to make old maps playable and to not screw up players without water. Normal wells would give productivity between 5 and 25% depending on humidity, so that players would be encouraged to make wells on water resources and upgrade them when the water runs out. new players would still be able to play fine without having to know which terrains are better for wells - deep wells would never produce less than 50%, on any land - but strong players would be able to squeeze some extra productivity through clever placement.

Top

Quote

SirVer wrote:

Just 2c here: Humidity is probably not useful as a true model for 'wetness' of the terrain. We sorta arbitrarily adjusted the values till tree growth was feeling okaish. Tieing that to wells will probably not feel great in the game without adjustments - and those will in turn affect tree growth again.

that was true when a computer fit the values. now those values are given to be realistic, according to principles that were mostly agreed among players. Summer meadows have high fertility and humidity, because they are the most fecund terrains; those values decrease in going to steppe and barren steppe, while mountain meadow is wet (on the mountains it generally rains a lot) but less fertile (mountains generally have poor soils). Desert terrains are rather dry and sterile, except for steppe and meadow who are average. wasteland terrains are dry but very fertile, because the closer equivalent to them would be volcanic ashes, which have those traits. And winter terrains are wet (with little evapration, most cold ecosystems are bogs) but relatively sterile (bog ecosystems have low nutrients in the soil).

I've been reading a lot of wikipedia articles about climate and ecosystems in the last few years, and I've tried to give the terrains values that made sense. it was the trees that were adapted for the different terrains. I believe those terrain values are as realistic as they can be in a videogame.

Top

Quote

Starting to catch up, so some of my posts might be a bit outdated re. the conversation.

wl-zocker wrote:

I like the idea that the productivity of wells depends on the terrain next to it. But we have to be careful not to break old maps (e.g. wasteland maps, where wells will produce little water). And this requires some coding, and I am unsure whether this task is worth the time.

Is someone noting topics "to do" for build 20? Can we do that on Launchpad?

I guess the easiest way to to target a bug report to a milestone "build20-rc1", which has yet to be created.

We should open a bug report once we have some consensus of what we want. Then link this discussion to the bug. Target can be left open - we will create a new target once we have a separate branch for Build 19. Once we have a branch, we will reassess the bugs that are currently targeted for build19 to see which ones are must-have, e.g. critical bugs.

Busy indexing nil values

Top

Quote