Resource range overlap?

[Vesper]

When you dive deep into any planet, you might see that the range of resources are clearly denoted, say at ~45 depth you'll see an emerald and then a ruby, and then no emeralds past that depth, same for ruby/topaz, topaz/diamond and basically all the metals barring aerials, where say iron and silver coexist at about the same depth range. The worst in this sense is aquatic, as you can only see orichalcum at 170+ depth in the rocks, this becomes pretty boring after a while - you get down there to see one mineral and not a trace of any other. Maybe extend the ranges of all the materials to deeper side, say for emeralds instead of 0-50 make them be able to be found at say 0-170 or 0-80, and for rubies instead of 50-110 make then be found at 50-200, so that the minimap won't be as dull when it comes to high depths? After all, in reality there is no dedicated range for iron, silver, gold or titanium, they overlap and can be found at any depth past a certain value.

[leguma]

This is the way things were done in Glean 1, and it sounds nice in theory, but there are significant implications to doing things this way:

One, it makes it harder to balance recipes since there is less of a clear distinction between early, middle and late-game ingredients.

Two, it makes it harder for players that want something specific to get exactly what they want. Right now when you go to a certain depth, it's easy to see on the minimap where the crystals and minerals and everything is, and because it's very tiered, you know exactly what those minerals/crystals are. With big overlaps, you could see tons of crystals, but when you go to them, none are what you want.

Three, it reduces the quantities of specific desired ingredients and creates an excess of others; generally creates excess resources. Planets are randomly generated. For each one we specify what number of tiles should have resources, and which percentage of those should be minerals, crystals, etc. If 15% of tiles are resources, and 1/5 of those are crystals, and there are multiple types of crystals, you get less of each kind (and an excess of ones you don't need). To offset this, we can increase the overall number of resource tiles, but that would mean more of everything, and one in three tiles being a resource, again leading to excess resources and cluttering, and 90% of them being ignored/avoided.

[Vesper]

You can offset this by using weight system. Say, for terrestrial planets you give emeralds 100 weight for 0-50 depth, ~40 for 50-110 depth, ~10 for remainder; rubies will have 100 for 50-110, ~40 for 110-170, ~15 for remainder; topazes 100 for 110-170, ~30 for 170-210 and ~15 for 210-250, and diamonds 100 for 170-250 depth. This way a chance that a crystal at depth 170-210 will be a diamond will equal 100/(100+10+15+30) = ~63%, big enough to not drop diamonds' quantity, and small enough for the player to see resources galore. The same principle can be applied to all the other resources and environments.

[leguma]

Funny that you go and mention weight. That's what I used for Glean 1, and the hooks for it are still in the engine, but their influence is minimal because the ranges for resources are set to not overlap. The system you are proposing though simply would not work for us, since it would require a TON more calculations than are done at present.

If you're really interested I can go into details about how the current system works and why your suggestion would increase the calculations done when dealing with maps by several orders of magnitude.

[haloboy01134]

Is that why this one seemingly runs faster? Because it isnt trying to use these calculations you speak of to work out stuff for resource overlapping stuff?

(I seriously have no idea )

[Vesper]

Yep, I'm interested, because I don't see "several orders of magnitude" increase in the seeding algorithm. The resource selection is just 1 more random number per resourceful spot, and only minerals/crystals ones should be affected.

[leguma]

Not really just one number... one attribute, but many different numbers. Right now, for Copper there is a min and max depth for each of the planet types. With your proposed system, we would add a weight, but that weight can't be universal... So from 0 to 25 depth there would be a weight of say 1, then from 25 to 50 a weight of .8 then a weight of .5 from 50 to 75, and so on.

When generating right now, we can just work in chunks of 25, designate where resources will be and then just plonk them down, with no regards to anything else. So pick X empty tiles and mark them as copper, and then move on to crystals, and no on. With what you are proposing, we would have to look at the depth of the individual tile, look at the list of minerals to see what could possibly go there (check each individual mineral and see if it has a weight greater than 0 at that depth, and then take note of that weight), then do the weight math and pick one of the possible resources for that tile, and then move on to the next tile. And this would have to be done for each and every tile. Once all that is done, you move on to crystals, and repeat.

It's not that it's impossible, but it would be a lot of extra effort, for a change that the vast majority of players won't ever notice. There's about 10-15 tiles of overlap as it is, There is really no need to extend it.

[Vesper]

It's a weird way to generate the resource set IMHO, it'll be a lot better if you generate not by "copper, then coal, then emeralds" principle, but by "copper or coal or emeralds" principle. So, for each resource you anyway have a matrix of weights per environment, why not use that to determine chances that this particular cell will be a copper or emerald?

[leguma]

See that's the part that is not coming across... We do NOT have a matrix of weights per anything. Right now, all the resources in the game have the same weight. What we do have are Min and Max values for each environment. So copper is 0-50 on earth and 0-0 on water, and 25-50 on air. This is all we use to generate the maps, the weighting is still int he code, but it basically has no effect.

[Vesper]

Well, you might try making a simple matrix like this:
public static const TERRESTRIAL_MINERALS:Vector.<Vector.<int>> = Vector.<Vector.<int>>([
   [0,0,0,0,0,0,0,100,0,100,100,0,0,0,0,0], // one element per mineral/crystal, one row per unit of depth
   ...
]);

Or you can generate this matrix at runtime based on weights code, say you will have an array of (min,max,weight) per mineral per environment - you already have such an array of (min,max). Then when you generate the world, you have an easy time gathering total weight (even precalculated in another vector), then you throw a random, then you go by the Nth row of weight matrix until the sum of columns passed will exceed the random value, and then say "this will be the type of mineral for this cell". Then you'll need to set the amount of the mineral (1-3), you can even do that uniformly, giving the weights for 3 to be 1.2*(depth-mindepth)/(maxdepth-mindepth)-0.3, for 1 to be 1.0-1.5*(depth-mindepth)/(maxdepth-mindepth) and remainder into 2. Yes, this will increase the static data volume by a bit, but it'll be a lot less than having such hassle like I've heard you have in your code. Note, this will only have an impact on minerals and crystals, not gasses or fuels or trophies, you have there the logic which shouldn't be impacted by this.

[haloboy01134]

Mar 6, 2014 6:10:56 GMT Vesper said:

Well, you might try making a simple matrix like this:
public static const TERRESTRIAL_MINERALS:Vector.<Vector.<int>> = Vector.<Vector.<int>>([
   [0,0,0,0,0,0,0,100,0,100,100,0,0,0,0,0], // one element per mineral/crystal, one row per unit of depth
   ...
]);

Bringing in example codes??? **** just got real