• If you have a mod, tool or prefab, please use the Resources section. Click Mods at the top of the forums.

KingGen - A Random World Generator for 7 Days to Die

KingSlayerGM said:
@gpcstargate and others interested:

I tried setting a strict rule of no poi repetition inside the same city, but the result is large empty lots with no pois, which is very ugly. For now the system will remain as it is. If you really want to avoid repetition I suggest small cities, small towns, small vllages, large grid size, and long poi list. These settings will reduce the chances of repetition.

Any expert programmer that has an idea for an algorithm, please share. Keep in mind that when picking a poi for a specific lot there are 5 requirements:
1) it must fit in the lot,

2) it must be a city poi if building a city, or a town poi if building a town,

3) it must be compatible with the zone(downtown,iindustrial...) of the city,

4) it must be compatible with the biome

5) it should avoid repetition
Click to expand...


Got a suitable idea:

1) For a specific city create a list-of-poi-lists. At first the list-of-po-lists contains just one list with all pois available in it.
listofpois= [pois]
2) For each plot:
*) Cycle through the list-of-poi-lists until you have found a fitting POI:
for listnum in listofpois:
a) Find a suitable building for that place with the normal algorithm you use at the moment
(that algorithm must be able to report back if it can't find a suitable building)
poi= findsuitablepoi(listofpois[listnum])
c) if none is found, go to the next entry in the list of poi lists, otherwise remove the poi from the list it is in and move it to the next poi list in the list-of-poi-lists
if (poi != False):
if listnum = len(listofpois):
listofpois.append([])
listofpois[listnum+1].append(listofpois[listnum][poi])
del(listofpois[listnum][poi])
break





Practically it makes a priority list so that always the least-often placed poi suitable for a lot will be used. And it simply calls the algorithm used now, so it should be easy to plug in.

Changing the current algorithm (for example if counts for specific cities were added) would probably save on execution time and memory usage, but to know how to change that algorithm you first would need to know how it works currently

Maharin said:
I get this error when I run the program (from the console, not working through my GUI):

[28155] Error loading Python lib '/tmp/_MEIDc1As9/libpython3.8.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/_MEIDc1As9/libpython3.8.so.1.0)




So maybe it is a glibc issue instead?
Click to expand...


There is a very small chance that you could replace /tmp/_M.../libpython3.8 with a logical link to your libpython3.6 library in /usr/lib/x86_64-linux-gnu and it just works. (When you replace, just move libpython3.8 away so you can reinstate it again it it doesn't work)
 

Other solutions I can see are

1) installing a newer python3.8 from backporting repositories and reoving libpython3.8 in tmp as well

2) installing a newer glibc from backporting repos

3) updating Mint

 
meganoth said:
Got a suitable idea:

1) For a specific city create a list-of-poi-lists. At first the list-of-po-lists contains just one list with all pois available in it.
listofpois= [pois]
2) For each plot:
*) Cycle through the list-of-poi-lists until you have found a fitting POI:
for listnum in listofpois:
a) Find a suitable building for that place with the normal algorithm you use at the moment
(that algorithm must be able to report back if it can't find a suitable building)
poi= findsuitablepoi(listofpois[listnum])
c) if none is found, go to the next entry in the list of poi lists, otherwise remove the poi from the list it is in and move it to the next poi list in the list-of-poi-lists
if (poi != False):
if listnum = len(listofpois):
listofpois.append([])
listofpois[listnum+1].append(listofpois[listnum][poi])
del(listofpois[listnum][poi])
break





Practically it makes a priority list so that always the least-often placed poi suitable for a lot will be used. And it simply calls the algorithm used now, so it should be easy to plug in.

Changing the current algorithm (for example if counts for specific cities were added) would probably save on execution time and memory usage, but to know how to change that algorithm you first would need to know how it works currently
Click to expand...
The idea of lists as "levels" and when you have finished a level you move on to the next one, is pretty cool. Just a couple of thoughts:
1) it could grow forever because small pois keep getting selected to fill small lots, so they keep getting pushed to another list. Whereas large pois remain in the first list.
2) why the need for a list of lists? Why do you actually need to separate the pois in "levels"? You could just have a single queue and when you extract a poi, it gets pushed back to the bottom of the queue. Thus ensuring that you always get the least recently used poi.

Point 2 is basically what KG does right now. However cities are large, requirements for pois are strict, so very few are actually a good match for a specific lot, and what happens is that KG is forced to go back to pois already used somewhere else.

I've just had this idea. For each city, for each poi, keep a counter of how many times that poi has been used in that city. Sort the list of pois based on the value of that counter. Anytime you need to select a poi, scan the list from less used to most used and stop as soon as you find a suitable one. Update the counter.

 
Last edited by a moderator:
KingSlayerGM said:
The idea of lists as "levels" and when you have finished a level you move on to the next one, is pretty cool. Just a couple of thoughts:
1) it could grow forever because small pois keep getting selected to fill small lots, so they keep getting pushed to another list. Whereas large pois remain in the first list.
Click to expand...


Not forever. The position in list-of-poi-lists is just the number of times this poi was already placed in that town.

That can't be worse than it is now: If with the old algorithm you would have found 10 of the same poi in a specific city (and this was the maximum) then with this algorithm 10 would be the maximum size of list-of-poi-lists and that poi would be in that last list only if no better distribution among fitting pois were possible. But less if there were more than one POI fitting into that lot.

Example: Say there were 20 very small lots and only 4 pois available to fill that slot. And the old algorithm would set 10 to have poi1, 7 to have poi2, 3 to have poi3 and 0 to have poi4. The new algorithm would distribute them 5,5,5,5 and the list size of list-of-poi-lists would be 6, with all four of them in that last list.

2) why the need for a list of lists? Why do you actually need to separate the pois in "levels"? You could just have a single queue and when you extract a poi, it gets pushed back to the bottom of the queue. Thus ensuring that you always get the least recently used poi.
Click to expand...


As I said I don't know the orignal algorithm. If that algo for example picks pois through randomly starting somewhere in the list and taking the first poi it finds, it won't work with pushing back. Or if it creates a tree of pois from the list first.

I have been using the original algo as a black box. If you know how the original algo works, you can probably change it to work similar with much less CPU cycles, no question about that.

Point 2 is basically what KG does right now. However cities are large, requirements for pois are strict, so very few are actually a good match for a specific lot, and what happens is that KG is forced to go back to pois already used somewhere else.
Click to expand...


If it already places an optimal distribution of suitable pois then you can't change the problem with a new poi-picking algorithm you asked for.

You either need to increase the number of acceptable pois for a specific lot footprint or decrease the number of those (small) lots to be filled. That would need knowledge about the current way city layout is generated in KingGen and the rules governing that.

I've just had this idea. For each city, for each poi, keep a counter of how many times that poi has been used in that city. Sort the list of pois based on the value of that counter. Anytime you need to select a poi, scan the list from less used to most used and stop as soon as you find a suitable one. Update the counter.
Click to expand...



 
Last edited by a moderator:
meganoth said:
Not forever. The position in list-of-poi-lists is just the number of times this poi was already placed in that town.

That can't be worse than it is now: If with the old algorithm you would have found 10 of the same poi in a specific city (and this was the maximum) then with this algorithm 10 would be the maximum size of list-of-poi-lists and that poi would be in that last list only if no better distribution among fitting pois were possible. But less if there were more than one POI fitting into that lot.

Example: Say there were 20 very small lots and only 4 pois available to fill that slot. And the old algorithm would set 10 to have poi1, 7 to have poi2, 3 to have poi3 and 0 to have poi4. The new algorithm would distribute them 5,5,5,5 and the list size of list-of-poi-lists would be 6, with all four of them in that last list.
Click to expand...
 You are right, it wouldn't grow that much.

meganoth said:
As I said I don't know the orignal algorithm. If that algo for example picks pois through randomly starting somewhere in the list and taking the first poi it finds, it won't work with pushing back. Or if it creates a tree of pois from the list first.

I have been using the original algo as a black box. If you know how the original algo works, you can probably change it to work similar with much less CPU cycles, no question about that.

If it already places an optimal distribution of suitable pois you can't change the problem with a new poi-picking algorithm you asked for. You either need to increase the number of acceptable pois for a specific lot footprint or decrease the number of those (small) lots to be filled. That would need knowledge about the current way city layout is generated in KingGen and the rules governing that.
Click to expand...




The current algorithm divides pois into groups based on their properties. For example all pois that are "city","downtown" and "desert" are in a list. A poi can be in more than one list. Lists are shuffled. When KG needs a poi for "village","oldresidential","forest", it will go to that list and use it as a queue. Talking the last recently used poi.

 
Last edited by a moderator:
If we assume that the city generator just generates rectangular city blocks of same or a specific number of sizes and then automatically fill these blocks with pois, then I would suggest to add lot

KingSlayerGM said:
 You are right, it wouldn't grow that much.

The current algorithm divides pois into groups based on their properties. For example all pois that are "city","downtown" and "desert" are in a list. A poi can be in more than one list. Lists are shuffled. Then when KG needs a poi for "village","oldresidential","forest", it will go to that list and use it as a queue. Talking the last recently used one.
Click to expand...


Ok, then you really need to attack the algorithm which parcels city blocks into lots. I would guess this is just done randomly by placing pois until space runs out?

One idea could be to provide a lot of handcrafted parcelled blocks for the poi placer to use. Or automatically create a few random parcellations and drop the ones with too many small plots or other deficiencies.

 
Last edited by a moderator:
Umm, i just generated a few Vanilla maps, and there is NO Red Mesa in it 🤨 How is that possible?  🤯

 
Last edited by a moderator:
Version 0.8.0 released!

Here is what's new:

  • Added very wide biomes option
  • Added label to identify game version (for compatibility)
  • Added key bindings: "enter" to start generation, "escape" to stop generation, "escape" when not generating to close the editor, "tab" to switch to advanged settings and back
  • Added option to customize world border
  • Added option to choose output folder
  • Optimizations for smoothing world around pois
  • Added support for raw heightmap import
  • Added tools for map makers:

    png to raw
  • raw to 16 bit png
  • raw to 8 bit png
  • biomes file fix
  • splat file fix
  • preview generator for any world

[*]Optimized caching of native functions

[*]Improved mountains. Sharper edges, rougher terrain.

[*]Added dynamic elevation for cities. Now cities spawn at whatever height the terrain underneath is

[*]Added cities map import: you can now draw cities on a file and KG will generate cities accordingly

[*]Added zoning map import: you can mask zones on a png file and KG will use that to generate pois

 
Last edited by a moderator:
This is a new very cool feature of KingGen. You can paint cities!

aLY4MoA.jpg


 
Great work so far with this! I've used Nitrogen for a while and only just come across KingGen - initial impressions are great! I love the 'city painting' feature.

A couple of questions / suggestions; 
1) Can we have an option to change water start height and also city spawn height range please? I like to use real location heightmaps and being able to adjust these values allows for more 'realistic' placement of certain locations.

2) As mentioned the 'city painting' map is great - Can we also do the same for roads?

My goal is to re-create real world locations with somewhat accurate layouts of roads/pois/etc. 

Cheers! 

 
gavin11489 said:
; 

1) Can we have an option to change water start height and also city spawn height range please? I like to use real location heightmaps and being able to adjust these values allows for more 'realistic' placement of certain locations.

Ive been doing these maps for a few years, and Ive always found 1-to-1 mapping to real locations close to impossible. IMHO you wont ever get it to scale just right, your best option is try and recreate specific scenes tied approximately to their real world locations.

The other thing you want to strongly consider is prepping your height maps separate from tools like KG or Nitro, that editing step is really where you are going to come to realize how close you can get a place to original size and then scale the best you are able to.
Click to expand...

 
One thing I've not seen in any random generator, (be interested to know if any of the features here would allow it with some tinkering), is the ability to create random maps, where traders are outside of towns/cities?

 
KingSlayerGM said:
KG doesn't do that. But i can easily add it for next release.
Click to expand...
Yes would definitely love that. I always like the traders outside cities

1. as that's the trade off. Lots of places to loot, or near a trader, but not both.

2. cities are supposed to be dangerous so traders would set up away from those.

 
Dark_Shadow_231 said:
Yes would definitely love that. I always like the traders outside cities

1. as that's the trade off. Lots of places to loot, or near a trader, but not both.

2. cities are supposed to be dangerous so traders would set up away from those.
Click to expand...
Would it also be possible to allow a minimum distance between those traders? I don't like them to near each other.

 


That's all your opinion mate. I didn't say 1 to 1, I said 'realistic'. There are plenty of real world 16KM places that work fine for game maps, or it's a simple case of scaling to your needs.

Oh and of course I "prep" heightmaps in software other than KG/Nitro. I'm aware of the limitations. 

No offense intended, but your reply was not helpful and came across a bit elitist. I'm just asking for features to software we all enjoy...

 
gavin11489 said:
Oh and of course I "prep" heightmaps in software other than KG/Nitro. I'm aware of the limitations. 
Click to expand...
Of course I prep my map! Well excuuuuse me mate. You've got 20 posts. Almost no one knows to do prep. What in anything that you said would lead me to have any idea what you know or dont know? If you already knew to do any of that, I would imagine you would have been doing it with Nitrogen like the rest of us for the last 3 years.

Good luck with your map.
 

 
Last edited by a moderator:
Last edited by a moderator:
You must log in or register to reply here.
Back
Top