Build Destribution Across the Zones

[rePewtr]

After the tests of the last few days and a few discussion we are running into something that needs a decision and implementation. That something is how builds are destributed across the zones. ( I am also stopping to use the word "context" here and start to use only "zones".)

Now I know that this is more work again, but i think our initial apporach is too flawed to proceed with it.

As it is now: Right now we just set multiple zones for one build and save it. What happens however is a uncontrollable amount of off-zone builds in a certain build. Example:

5 Pure Highrise builds 10 Pure Midrise builds 10 actually midrise builds but also marked with "highrise" 20 actually lowrise builds but also marked with "highrise, midrise"

Now for the generator every build marked with "highrise" seems perfectly fine to place in highrise. It doesn't actually know wether a build would normally be lowrise but just placed in highrise or a real highrise build. We would end up with an unnaturally big amount of lowrise builds in the highrise zone just from the numbers speaking.

Approach Nr.1:

A global zone weighting which decides how much of midrise, lowrise, etc. builds will actually be in the highrise zone. Additionally to this every build gets only one zone in the .json. Example:

5 highrise builds 10 midrise builds 20 lowrise builds

The global weighting for highrise is: 25% highrise, 50% midrise, 25% lowrise.

We end up with a nice and controllable destribution of builds.

Downside: Since we can't decide which schematic out of lets say midrise will be placed in highrise we might end up with unfitting builds in highrise which will look odd.

Approach Nr.2:

Every schematic gets an own chance for each zone it gets used it. Example:

skyblocklow.schematic.json:

"zones": [ "HIGHRISE: 15", "LOWRISE: 100", "MIDRISE: 40" ],

Or something like that. What we get is a precise and controllable amount of each build in each zone.

Downside: probably hard to implement, hard to keep track of/maintain and overall more work.

Approach Nr.3:

Global weighting like in approach nr.1 and every schematic gets a main zone and IF needed zone exceptions. Example:

"zone": "LOWRISE", "zoneException": [ "HIGHRISE", "MIDRISE" ],

So now generator tried to place a lowrise build in a highrise zone, picks a build from but sees the exception in the .json file and moves on to the next build.

Those exceptions would only be used for certain builds.

Downside: Dunno, can't see one. Am I missing something?

[rePewtr]

Figured a downside for approach 1 and 3: Filler builds like parks etc wouldn't have multiple zones anymore. So every zone would need a lot of own fillers. Which in the future is maybe a good thing for setting a certain setting for the zones. But right now we don't have sooo many fillers. So i guess its a "half" downside^^

[trichner]

Approach 2 seems legit. But this will still be based on chance. How I'd implement it:

1. Choose a fitting build for current parcel (size, context, road, ...)
2. play odds -> success: Place schem -> fail: try to place another fitting schem or partition parcel

Seems legit?

[rePewtr]

Personally I would love approach 3, just because its the least repetitive work with all the features we need. Approach 2 would be bearable but a lot more work and error sensitive, just imagine managing 200+ schematics each with own chances for each zone they are placed in. Seems like a nightmare to me. But maybe i am overestimating it, it would be of course the best control.

as of how to implement: seems right to me. How I imagined the whole thing would work is that we would work with very low odds for the builds.

Lets say gen picks a 48x48 parcel in highrise. There are 10 builds that would fit the requirements. Each build has a chance of 10% to be spawned. The gen runs throguh all 10 builds and tries to place them at 10% and THEN starts splitting the parcel.

I don't know however how that would work out in the long run if you got lets say 30 builds. 30 x 10% makes it pretty much impossible for the gen to ever get to split the parcel. Maybe just a few tries? Like try this requirements only 5 times, if all failed > partition parcel or something.

[trichner]

There is an chance that a place gets split before even trying to place anything, so thats covered. Other than that, your imagination is right. I don't like approach 3 because I don't now how to handle it properly and it fills up the .json with no real gain over 2. Approach 2 would be straightforward and one can understand how it's handled.

[rePewtr]

Is the order in which the gen tries to place a fitting build random? Lets say he sees 5 schematics fitting for a parcel.

schem.schematic cheese.schematic 11.schematic rain.schematic cracker.schematic

Does it always start from "top to bottom" or chooses it randomly which schem to try first?

[aaron-bts]

From what I can tell it tries to do larger schematics first, then continues down until all the parcels are filled.

[aaron-bts]

This will probably end up as

{
    "contexts": [
        { "name": "HIGHRISE", "chance": 15 },
        { "name": "LOWRISE", "chance": 100 },
        { "name": "MIDRISE", "chance": 40 },
    ]
}

[israelcurtis]

i gotta admin #2 is going to be a pain from CMS perspective. also hard to do mass-changes really think global weights would be better. also, divorcing the zones and contexts for example - the generator would act like city planner, doing zoning regulation and each build would simply declare what it is (hi rise, mid rise, low rise, industrial, residential, municipal) generator would just have zones 1,2,3,4,5 whatever (which also allows for future expansion) then global rules would determine what assortment of build contexts would appear in each zone that way, we don't have to go through the CMS for each build, one by one, to make sweeping changes to how the city distribution works just one global set of ratios, tweak, regen world, rinse repeat

so for example, global config:

"zone1" : {
    "contexts": [
        { "name": "HIRISE", "chance": 40 },
        { "name": "LOWRISE`", "chance": 20 },
        { "name": "MUNICIPAL", "chance": 40 },
    ]
}
"zone2" : {
    "contexts": [
        { "name": "MIDRISE", "chance": 10 },
        { "name": "LOWRISE`", "chance": 50 },
        { "name": "RESIDENTIAL", "chance": 40 },
    ]
}

[israelcurtis]

also, we should revisit the build contexts, as the generator has evolved. We may have 3 "types" of contexts now:

primary building assignments should be limited to these: HIRISE MIDRISE LOWRISE INDUSTRIAL RESIDENTIAL

then the filler assignments MUNICIPAL (we have much more than parks now, soccerfields, swimming pools, parking lots, utilties, etc) RURAL (includes the old "farm" plots and purely forest plots, could be used more at the outer boundaries of cities)

and of course ROAD HIGHWAY