Bay 12 Games Forum

Dwarf Fortress => DF General Discussion => Topic started by: teatime on June 23, 2020, 09:34:54 pm

Title: Automatic Fort Generation
Post by: teatime on June 23, 2020, 09:34:54 pm
I am maximally lazy; as I perform a repetitive task I think of ways to automate it, and this has been the case when making fortresses. I don't want to do this for my own fortresses, because I am the program that bests makes new exciting forts, but it feels like there is a general enough structure to what I do, regardless of the goal of my fort, that I could abstract it into a program, and that program could then generate groovy NPC fortresses that evolve with the world.

First off, I'm virtually certain someone else must have posted about this, but being new here and not knowing the exact lingo, my search-fu is lacking. If someone can point me towards a thread, I'd be greatful. Other than that, I intend to just put some thoughts down here; I like thinking about creative problems, and I'm sure having more opinions on it would only make the end result better.


Automatic Fort Generation: A Problem Statement

So, in essence, what do we want from an automatically generated fort?

When the fortress generation starts there will be initial conditions guiding its evolution based the motivations of the settlers (nomads, expanding the borders of a nearby settlement, an advance outpost for an invasion, a remote new settlement far from the homeland, a mining colony, etc).
The race influences the fortress structure (eg. dwarves are more likely to make underground fortresses, humans are more likely to channel out pits for stone and build buildings, but if the area doesn't allow it, anything is possible to survive). In the long run the fortress should evolve to suit the races preference*.
Relics of the fortresses evolution in this case refers to things like gradually replacing materials that become available over time, or having the goal of the settlement evolve, like an advance outpost that becomes a keep surrounded by farms after a war, or a small villiage that gradually grows to a city over a long period of time. Each of those scenarios would leave footprints depending of the nature of the changes at each step (like having wooden inner walls that used to be outer walls).

The goal here is then to find a framework to encapsulate all of this so a small working version can be written that, although intiially limited, could grow to accomodate all of these variables. To satisfy the requirement of "looking designed" will require some way to creatively mutate the base structure. Ideally if I could encapsulate this in a configureable way, so that I only leave a minimum of fingerprints on the fortress generator, then some kind of community sourcing action could generate parameter sets to finetune certain aspects of the final forts.

While I have a lot of pretty cool ideas for for this could generalise to other races and terrains, as a very bare minimum, the least this thing would have to do is create a fortress, for dwarves, underground.

A Simple Model For Fortress Evolution

For this to work properly, I can't just generate a fortress, I have to show my work. A good starting point is the same as Dwarf Fortress itself, the embark. I would need to know how many dwarves are coming, why they are coming and what they are bringing. A site may be built by royal decree, in which case the king could send a hundred laborours with several caravans of prepared materials and it would just pop into existence; or seven rugged, wild spirited dwarves could march into the mountain with two axes, two picks and a bag of seeds.

The motivation of the group and the materials they have will affect what happens when they reach the area to build their fortress, but this area will also affect what they can do**.
Ceremaic and clay industries can only exist if there is clay and sand.
Terrain that has large wobbles all over is not suitable for big surface structures (or rather, would be preferentially selected against in that environment, unless there was a motivation otherwise).

Realistically the first phase should involve shelter. Dwarves can either gather materials to build a building, or dig down/into the side of a mountain for shelter, leaving the food and wagon outside for too long isn't a good option. This is not necessarily housing yet, just somewhere to exist that isn't ouside and exposed - a meeting place, indoors. The cave is underground, safe, and eminently useful to your stone industry; but a lot of my forts have had some kind of keep-like structure, and it normally evolves from a little hut I built to protect my caravan.

Once there is somewhere to exist that isn't outside, the next priority is food. There are limited options on what to do here depending on the environment and the items you embarked with, but ignoring the complexity of what you brought along, in general you can get food by hunting, foraging, farming, owning animals and fishing. Owning animals yields continuous food in the form of milk and eggs, and discrete amounts of food in the form of meat, that if properly managed, doesn't reduce your flock size. Bees are counted as animals in that list, but cannot be eaten (yet?).

The food industries chosen by the group will related to what's most readily available in the area; but will also be affected by the motivation for creating the fort. You can't have 20 herbalists and fishermen roaming the country side when you're an advance outpost for an invasion; in such a case you either need a secure food supply behind your walls, or a reliable trade route to get supplies to sustain your war effort***. The size of this industry would be also affected by the groups motivation (plans for a big city needs plans for a lot of food, initial farm area might be small, but space is left for expansion because the city is planned to be large, a city that was planned small but grew large would bare the scars of inadequate spacing, and might necessitate creating a "second fortress" somewhere else that can accommodate the increased numbers comfortably).

Alcohol is a vital offshoot of the food industry, and all dwarven fortresses need a supply. All dwarven fortresses should employ a progressive strategy for acquiring alcohol.
Depending on the chosen food industry, dwarves may have the means to create alcohol.

From this point on though, things become less clearly defined, and depend more and more on the motivations of the group. City builders may want to focus on getting their stone-industry up and running, which may have gotten a kickstart from the initial digging of a cave. A dedicated mining operation might treat the initial fort as a starting point for going down to the magma, require shafts to dump ore down and a minecart system to transport it up. A military fort close to enemy lines might want to prioritise defences.

In summary, up to this point most fortresses would follow a similar path, but at this point they diverge. The problem involves capturing the trajectory of that transformation in a way that allows you to not only quickly and easily encode scenarios like the ones I've been dreaming up into the fortress builders "plan", but does so in a general enough way to be able to grow with the game. It may be possible that the embark is a single wizard, and he casts 50-level slade tower in the middle of the map, or that in the future you could embark with vampires only, and not need food, shelter or beds.

So, at the moment the model we are working with for the fort generator is looking something like this:

The first version of this model was and could only be made from my experiences designing a fortress, but at this stage is still sufficiently vague to not constrain the end result much. Essentially, a fortress has a reason for being built, there are stages to its construction, and events affect how it grows. Mention was made of above and below ground structures, but nothing has been said about the sizes of areas, the spacing, the choices of materials, the relative layout of rooms, or other important factors, such as how the fortress survives economically¶ and whether they have requirements on who can migrate there (no children on the front lines...). These are important questions, and while it's very important to consider them so they are able to fit into the final generator, they are outside the scope of an initial implementation.

Some additional random thoughts on this topic: The population of a city affects the speed at which it is constructed. Food sources have a "rate" attached to them, and once the rate of consumption approaches the rate of generation, a need to expand the food industry is created. For simplicty this is checked on a yearly basis to accomodate the average # of animals roaming the country side, the average plant growth in the area, average fish available, etc. Food industries expand horizontally at first, if motivations allow it, and then vertically to increase capacity.

So, now that a basic model is in place, and we have a feel for the lay of the land, it's time to consider...

The Minimum Viable Fortress Generator

If someone came up to me and said, "Hey dude, I have an automatic fortress generator for Dwarf Fortress", what is the absolute least I would expect, given the title was technically accurate? I would imagine it would be something that spits out QuickFort blueprints; that doesn't care about what the map looks like, but tells you how to build. I would expect it to be either configurable or randomisable, else it's just a single blueprint, and I would expect it to generate structures compatible with a finished fortress of some size... bonus points if I can specify a number of dwarves. Double bonus points if I can specify casts and have the housing be dynamically created in zones near their industries with dining areas for individual groups (on top of a central meeting hall).

If I were dreaming a bit bigger I'd like it to have knowledge of different kinds of abstractions, and give me high level controls for determining how they are generated, eg. for a farming area I'd like to control the generation by specifying a capacity for how much food it should generate, a control for the varity of food sources (varity and capacity interact like civs in world gen with world size), perhaps some kind of seed, and a "wealth" control to determine the value of the chosen materials.. then some geometry of farm area should be generated with floors and plots and assigned to whatever vegetables were available for selection.

If it had knowledge of these abstractions, and a way to control how they interact, then we are in business. There are degrees of abstractions, and they can be deepened over time, given you plan their structure and interactions correctly. I think you can catagorise the motivations in the early game loosely as, in approximate order of priority:

I would expect a fortress generator to lay out structures to fulfill these needs, in a logically connected fashion. The kitchen and still must be close to the area the plants are stored, but also to the place where the prepared meals and alcohol is stored. Space must be left for future expansion, but supply lines need to be short. Structures exist within a fort; a meeting hall, an entrance, a sleeping area - and these structures contain substructures; seating areas, decorations and bedrooms. A properly designed hierarchy of rooms and rules for their connectivity will give rise to various configurations of fortressses. Making these rules dynamic in response to a set of key parameters relating to their connectivity and parameters should then give the control needed to generate fortresses of a varity of scales and shapes. If this can then be adapted to suit an external terrain, with a random geometry and geology, the road from the minimum generator to implementing the above model becomes clearer.

The lynchpin in this whole thing is going to be figuring out how to effectively translate motivations into structures. Ideally I'd want to use things similar to what's already in Dwarf Fortress; I don't know if groups as a whole can have a motivation yet, but perhaps it could be adapted from the structure of the personal motivations, or reflect the desired of the king through the competancies of his underlines. Facinating as sourcing the real motivations from the game can doubtless prove to be, I'd have to pick a few general abstraction to work around, so this thing can comfortably slide into an external system, that way it can continue to grow outwards.

PAUSE
There's a bit more to develop here, there's still something to be thought about the minimum fortress generators minimum rooms; and the question of what method would be used to connect things hasn't been answered. I'm inclined to think what it wants to be connected to is a property of a room, and it satisfies it by the shortest route possible... but that is tomorrow me's problem. This has been a fascinating two and a half hours, but it's 4.30am and any additional planning will have to wait for a fresher me. I find it easiest to develop ideas by talking to myself, but I also find it useful to have an audience  ;D


* a splinter group of dwarves that fear the underground, a goblin-elf love cult that worship magma and enslave dwarves to get to it... 'preference' can be a broad term here.

**I'm not quite prepared to consider the complexities of multilevel heavy aquifers at this point, but I imagine you'd end up with a lot of unhappy dwarves in wooden structures on the surface, or shacked up in the dirt.

*** In a truly integrated fortress generator this would require the fortress sending the food in increase their food stores, either by building more food industries, or increasing imports, which, depending on the length of time it goes on for, may affect the industries in their neighboring cities. When the war ends, the price of food could fall and a city collapses economically. 

↕ "Seek Cavern" should involve digging vertical shafts to a certain depth, increasing in number until some critical stage when all shafts are made deeper. This is repeated until a cave is found. Shaft density should increase with depth. This might be hard to write, depending how caves are generated. There should be some math that helps dig exploratory tunnels.

↕↕ At this point blood wine would have made an interesting addition.

↕↕↕ eg. an unsuccessful invation that does some damage could be interpreted as "need for security" increased by "violent encounter", which could lead to "wall", "trap" or "moat" for a military fort, but possibly "abandon area" for a small family that came to build a hut in the mountains.

¶ Not strictly a problem, but I think the best way to approach this is from a worldbuilding / roleplaying perspective.

Title: Automatic Fort Generation Part 2: A Fresher Me
Post by: teatime on June 24, 2020, 05:50:17 pm
Automatic Fort Generation
How is a Fortress Constructed?
Dwarves arrive at an area. They have a reason for going there that will determine the overall structure of the fortress/settlement, and is seen as a property of the embark.
During their time constructing the fortress, they have certain general needs that need to be fulfilled. These were taken to be:
Although this lists ordering is roughly true as a priorities list for all fortresses, it only holds for the first iteration of the fortress; once all the needs are satisfied the Reason-For-Going should primarily influence the future evolution of the fortress. Ideally the Reason should consist of a small number of attributes that can collectively describe a large number of scenarios. Catagorically I think these can be described as a collection of needs, each consisting of a statement relating to what there was too much of, and what there was too little of. The outcomes of such needs are simple to define in terms of material needs, like MORE LEATHER, but become more nuanced around something like MORE EXCITEMENT, or MORE SECURITY. The latter could mean moving to a safe area, or moving to a safer area and fortifying the everloving fuck out of it. The former could mean colonising a volcano, or moving somewhere otherwise inhospitable.

I imagine scenarios generated this way could look something like MORE WOOD 200, which would aim to set up a colony producing 200 wood a year. Multiple needs would require prioritisation; weighing each need against how fulfilled it is at every phase of fortress construction, coupled with priority gives a way to navigate fortress construction over time.

So - the Reason is a prioritised list of needs that shapes the phased construction of a fortress. There are catagories of types of things to build to fulfill needs, and using the priorities from the Reason coupled with the instantaneous needs of the dwarves (and means they already have to fulfill them) the next phase of fortress construction can be planned. As a fortress generator, we are blessed, for we do not actually need to do the work or wait for it to complete, but over time we would like to include available materials into the equation. It seems the most extreme, granular version of this is a program that plays dwarf fortress; but while that would definitely get the result we want it is a bit overkill.

The list of available Needs for the Reason should be modeled on the above list of.. er.. other needs? Local Needs. The Reason contains the Global Needs, which are modeled after and shape the Local Needs. The Global Needs can contain abstract concepts though, and these need to be translated to Local Needs changing over time*.

I have no interest in writing direct mappings, as these would need to be updated whenever I wanted to add a property. Instead, each phase of fortress construction can be modeled as having a certain capacity for work, and the prioritised Needs used to direct the effort. The current Global Needs and Local Needs combine to form a list of priorities for the phase. Changing the granularity of the time scale considered would affect the kinds of fortresses being generated, as this would affect the construction capacity available in that time frame. At this point I imagine something like a fortress having a construction capacity of say, 300 actions, or 50 actions per dwarf over the considered time period; this is treated as a form of currency which is to be spent improving the fortress. It might be decided to spend some capacity on increasing the forts ability to generate food. In most cases dwarves will tend to try and spend as little capacity as is needed to fulfill the need, while planning for the future. It doesn't make sense to build a food area that could only feed 30 dwarves if you know you're aiming for at least 200. Either room should be left from growth, or it should be "known" by the generator that fortress construction is sometimes a two step affair, with a tiny fort created initially to house everyone while building the big fort**.

How is a Room/Area Constructed?

So, at the moment, fortress construction looks like this:

Key problems that remain are figuring out how to interact these lists, and how to actually generate the rooms.

It feels like how these lists interact should be somehow dictated from the Global Needs.
The king ordering you to do something affects your decisions differently to you just wanting to do it on your own. The fact that your fort does not need to produce food because it expects it by caravan can only come from the Global Needs (as in a delivery of food, not a trade). Needing to prioritise a certain industry for export can be due to a local abundance, but the location of fortress could also have been chosen to exploit that, in which case the Global Need of "MORE MARBLE STATUES" could have dictated the location in an area with much marble, but also preferentially drives the fortress to have a marble industry that is larger that it might otherwise have been, earlier than other forts would. I can imagine the Reason not only a collection of Global Needs, but also containing certain flags that would constrain the development of the fortress somehow - some kind of limited selection of overarching themes to add flavour to the process.

As for actually generating the rooms... I think there is an exercise in graph theory waiting for me in the future to be able to plan it out properly, but in the general sense it will be generated from a hierarchy.
As an example, the fortress needs food. Currently, there are no facilities, and so the food priority is high. On this map, over the course of a year there is on average 100 meat available from hunting↕. There is no soil. There is water. There are 0.5 caravans a year from neighboring settlements. The need for Food requires some way to generate and store food. The Food Storage Area is a substructure of the Food Area↕↕. There are several factors influencing the size of the Food Storage Area; including the frequency of the food source, the number of dwarves in the fortress and the required stock to store. A military fortress might mandate a years worth of food be kept at all times, in case of a seige, where a peaceful villiage might just need stores to last the winter. The exact math for transforming "food generating capacity" and "storage needs" into a number of squares of stockpile feels like something that will be determined by fiddling around, but once that value is generated, it needs to be transformed into an actual area.

As a first effort, rectangles of a fixed ratio connected by straight corridors; at a later stage, a configureable architecture. The Reason and Global Needs can kind of arise naturally from the game at the moment - and caters for some specific contrived scenarios to be included - but the architecture should have a guiding hand in it. I forsee it as something like the world generator, exposing a lot of parameters to be tweaked and customised per civilisation, but (on some level) relying on fixed configurations as starting points for generating the complexity of a specific world. Things like:
These properties should be able to provide the flavour of how to build the fortress↕↕↕ once the decisions have been made as to what size each room should be.... but I get ahead of myself. We've only just decided how big the food area is going to be in this example. Depth first is fun but sometimes distracting and laborious way to explore a topic.

In our food area, we have now determined the size of stockpile that is needed. Based on the map we choose to initially hunt for food, but given there is water we can make a farm area somewhere, this will just require too many actions to be a first iteration of our forts food source... but nevertheless in the future, this farm will be a part of our food area.
We should thus look at the embarkation Reason to determine what the forts projected size is to get a rough estimate of the overall floor area a finished food area would need. There's going to be a lot of heuristics and tinkering here...or maybe just assigning a max size to each thing and summing them.. but based on the projected food needs of what the dwarves consider their "finished fortress", a number of blocks is chosen that will represent the area where food is made.
This Final Food Area will contain a Final Food Storage Area, of which we are making a small piece right now¶. We can thus say something like "In this phase, we saw we will need, in the final fortress, a food area of about 500 blocks. 200 blocks of this will be required for food storage. Of those 200 blocks, we need to construct 50 to fulfill our projected food storage needs until the next phase, which leaves 200 actions for subsequent projects this phase".

Likewise, areas can be partitioned into little pieces for farms, kitchens, stills and all the things you would expect to find in an area named the Food Area. There is still something to be said for how these areas connect externally, and internally.
This partially leans back to the architecture config idea, since some may have a preference for rooms connected by corridors, where others mights prefer large structures with internal walls... but overall, there needs to be a way to decide where things lay relative to each other and how the connect them, beyond the concerns of architecture. Functional concerns - the Mad Demon King didn't get to be the Mad Demon King by ordering his food production be placed on the magma level, and his fortress be built on the surface¶¶. All races are fundamentally lazy and won't do more than is needed to accomplish a task.. even Beautification requires excess capacity.

There are fundamental relationships between areas and industries. Food areas would want to be close to the food source. Dining areas need to be close to the food store or, if they are beyond a certain distance, have a local stockpile of food, drink and mugs. On some level, every room and area has other rooms and areas they want to be close to, and perhaps others they don't want to be close to (nobody likes walking past the corpse pit).
Placing a room near something it wants to be near makes that room happy, and a fortress full of happy rooms is a happy fortress. With some rooms that need to be central to everything, it may not be possible to make all other rooms happy; but there are degrees of internal conflict that a fortress can tolerate, provided it is trajecting in a direction to make the fortress as a whole happier. The happiness of a room is a function of the status of its relationship with all other rooms it has relationships with, and new constructions use the current and projected future happiness of all rooms in the forts to guide their placement.

This would lead to very predictable results in the absence of a world and geology to consider; as the current algorithm would tend to find the same optima each time. Even with the architecture changing path lengths, room shapes and sizes, and preferred verticality, it would still find fundamentally similar solutions. On the one hand, merely introducing a map will provide a lot, at least near the surface and around the caves, providing hard constraints on where you can build will squeeze and push the fort into different shapes.. but I feel there is another element needed.

As a fortress generator, we are doubly-blessed, for we can see the entire map at once. In the future, requiring the dwarves to dig exploratory tunnels to determine where they can build could add a lot of character to a fort, but for now having them know it as if the voice of God spoke to them, or they had a special Dwarven rock-sensing sense will suffice. The geology of a world isn't generated as a random individual squares of different materials¶¶¶, there are areas that consist of mostly the same material, and there are veins of ore. I know I like nestling my functional areas inside a certain type of stone, and will even preferentially lengthen a piece of corridor so I can cross the border into a new type of stone for homogeneity in the new area. Sometimes, I mine out a pocket of orthoclase for a big, almost elliptical room. This can maybe be encapsulated as a sense of aesthetics in the architecture config, or as a trait in the Reason - willingness to delay work for aesthetic purposes. Small villiage, sure. Outpost on the front lines, no.

Using the world geology will also help to make things look better, but this still doesn't solve the problem of the basic fort layout. On the one hand, I want to avoid hard coding my ideas of how a fort should look into this. I mean, sure, there is absolutely no way to get away from these fortresses bearing my mark, but I don't want to fundamentally limit what kinds of things can come out of this without reason... that being said, it feels like I might have to have some kind of set of basic values for different fortress connectivities that make sense to avoid every fortress (in the absence of a world) looking the same for a given number of dwarves with the same industry, etc. Randomisation feels like too blunt a tool, and a seed value for spicing up otherwise deterministic choices... well, maybe, but I feel there is a layer of abstraction I'm missing here that would be able to do what I want in a more controlled way. I suspect that reading up on graph theory, and actually coding it for that matter, would be most inspiring.

...for now, though, the above is a satisfactory model to generate a variety of fortresses. So, areas and rooms are generated by:
The last item on that list refers to any excess actions left over after optimally distributing the points among the prioritised Needs, and can be used on small beautification actions, or upgrading infrastructure - widening a corridor, smoothing a wall, looking if there is maybe a corridor that could be built to make all rooms happier at once without compromising fortress security, or violating the architecture config▲▲. There may also be value in doing half a thing with the left over points; nothing says "living fortress" like a half finished construction project.... and can you imagine how cool it would be if you wander onto the map and there's a stream of dwarves carrying stones to build something?


A Mental Test Run

Now that the tools and abstractions governing the generation process has been loosely defined it should be possible to see what kinds of scenarios we can generate using them. This generator can go outside the realm of things that can currently happen in Dwarf Fortress, but just to motivate its construction. Running through an actual scenario should help point out any cracks in the current system.

I can imagine a goblin fortress built on slave labour. The fortress was constructed to make weapons and armor for soldiers in other fortresses - this Reason for this fortress might look something like MORE ARMOR 100, MORE SWORDS 100, to bias their industry and indicate they need to generate exports. The embark information might indicate 100 goblins and 20 trolls. The style guide for this type of fortress might say that this type of socity typically has 5% upper class, 15% middle management (slavedrivers) and 80% slaves, and these groups do not mix when eating or sleeping. Furthermore, sleeping areas are separated by species. The slave cast sleeps in dormitories. There is a subsection on troll sleeping quarters to generate something appropriate for them. Trolls cannot be nobles.

As this group arrives in the new area, they first build shelter. The architecture config for this society highly prioritises shelter for the upperclass / nobles, and requires one set of quarters that is more lavish that all others. If the slave force is large enough, the main throne room is constructed first. Otherwise, a temporary house in the field must be built to house the nobles until a fortress interior exists. Priority is generally given to the comfort of the nobles. Secondarily, some way of acquiring food is needed. The Reason for this fort may include that this fort subsists on caravans of food stolen by raiding parties - I'm not sure what goblins and trolls eat, but the thought of them farming seems slightly silly... but at this point simultaneous priority is given to a massive smithing area and housing for the middle management. Later there will be housing for the slaves. Terrible, cramped housing, physically distant from the nobles... but close enough to protect them if something attacks.

The size of the smithing area is based on the amount of laborors present, and the desired exports of weapons and armor. This translates into a size of area, which consists of stockpiles, workshops, and paths. The workshops need wood and or magma, so if depending on whether those things exist on the map those 'industries' might spawn in a limited fashion....or on the other hand, goblins may be able to work metal by magic. It would certainly make planing this scenario easier. This generator, not a human like me, would have reaslied it was needed to spawn the logging and charcoal generation industry before the smiths one.

I'm speaking in terms of goblins and slaves here just to stretch my brain away from dwarves for a moment, but everything I'm saying should translate directly back to dwarves. This world now has a freestanding structure somewhere that was used to house nobles; some kind of structure to house the middle management, and it is now getting some kind of shitty dirt hole for the slaves, just connected to the surface. There must be a reason a colony was placed here for the purpose of making weapons and armor, I'm going to choose to believe because it is a densely forested area that has the wood required to stoke the furnaces. As part of the embark information it should be specified that this fotress intends to import weapons and armor that doesnt fit their forces, like dwarf/elf and human armor, and melt it down to create new weapons and armor for the vile forces of darkness. This simplifies things but not requiring me to dream up a goblin mine, and, for the moment, leaves me reasonably happy that the above abstractions can encapsulate everything from the vanilla ideas they were generated from to some outlandish scenarios of the future.

An even better test, however, would be to play dwarf fortress while pretending I am the generator. That's kinda what got me into this position in the first place, when I had to restart a fort because of some combination of gamebreaking bug and personal stupidity, and I found a young version of the above running in the back of my head.

Yet the best test would be to start writing this and encountering actual problems. I'm a big fan of building castles in the air (or perhaps more appropriately, a fortress in the sky), but as TS Elliot rightly said, "betwen the thought at the action, there falls the shadow". There are definitely still things that need to be planned, such as how to manage what could reasonably be imported vs what should be made locally (clothes, for example?). Whittling down all the fluff to a core idea that can be developed is it's own kind of feat, but a neccesary first step to what could easily try and become an automatic dwarf fortress player if I'm not careful.

teatime is taken by a fey mood!

teatime claims an IDE.

I must have enums!
I must have a hierarchical class structure!
I must have definitions for object interactions!

teatime has begun a myseterious construction.

teatime works furiously!

▲▲▲


* Integrating Local Needs over time gives Global Needs... the calculus of fortress construction? Maybe we can derive some way of interacting these things ::)

** An abandoned little fortress next-to-and-accidentally-linked-with the main fort would make for a neat little feature in adventure mode. 

*** This is an interesting optimisation problem, since sometimes it's better to do eg. all the food at once, and other times you're better off adding just a little capacity here and there. A military fort might need a little food generating capacity to keep it running when caravans can't get through, but would much rather have a chunk of wall constructed after the first phase. In this scenario we are not dreaming we are playing dwarf fortress, we are dreaming are are military dwarves setting up an advance outpost.

↕ I just discovered you can hunt things to extinction, so perhaps hunting should always be considered a transitionary food source.

↕↕ Note that a different incarnation of Food Storage Area is also a substructure of advanced Meeting Areas and Dining Areas.

↕↕↕ Which opens up GREAT possibilities for having fortresses being taken over and the new occupants expanding it using their sense of architecture....

¶ In advanced fortresses this area may undergo internal changes where the stockpiles are arranged better and specified on a more granular level.

¶¶ And yet, one might argue that is exactly how he became the Mad Demon King. Architecture config: "Hates citizens"; doesn't minimise path length for optimal industry.

¶¶¶ Side note, a civilisation having a geologist could enable them to make mining colonies that mine specific materials. Libraries teach people cool skills, it would be nice if they featured here somewhere - like a knowledge of hydraulics enabling certain advanced Dwarven Science to appear in its colonies.

▲ Ah, no, I think this is what was missing from my thoughts on connectivity. The initial plan might always be the same, because there are only so many way a small number of people will choose to live together, or set up a fixed size fort optimally. The food, dining and sleeping areas are linked in some way.... but as the fortress grows, as needs change, and requirements change, the planned areas and their locations may be insufficient, leading to new and interesting structures. No need to mess about with complex math to generate interesting structures, when events happening over time can do a lot of heavy lifting for you.

▲▲ Defining acceptable configurations of corridors numerically brings us back to graph theory.

▲▲▲ Alternatively, some years earlier:
teatime went stark raving mad!
teatime is running around babbling!
Title: Re: Automatic Fort Generation
Post by: Shonai_Dweller on June 25, 2020, 12:21:06 am
This is some definition of the word "lazy" that I wasn't previously aware of... :D
Title: Re: Automatic Fort Generation
Post by: teatime on June 25, 2020, 04:17:42 am
Hehe, the old definition applies. When you compare solving this once to doing it manually forever, it seems like almost nothing :P
Title: Re: Automatic Fort Generation
Post by: Salmeuk on June 25, 2020, 04:25:21 am
Wow, that's a very detailed and interesting writeup! My first thought is, how much would the generation account for local terrain? You might fall into the trap of making a consistent, self-sufficient program that makes the same fortress again and again, with minor variations in location and spacing. Consider the rather boring ease of which a fortress can survive from day 1 with nothing. Even if your program is playing for a broad set of global needs, there is potential for extreme repetition when shooting for an optimum layout. Which would be cool to see, but overall not as interesting a program as you seem to be proposing. Introducing a hard variability to certain design choices would help with this, but how might you approach this issue?
Title: Re: Automatic Fort Generation
Post by: teatime on June 25, 2020, 05:29:17 am
The terrain will definitely be taken into account - but in my experience of developing complex ideas, you have to find the smallest hard nugget of thing that will do what it says on the tin, and then grow it. The planning session here was to peer into the future and see where a "fortress generator" might go, so I can figure out where to start to get there, and have a guiding light to keep me on course. You mention one of the problems I envisioned midway through the second post, in the section titled 'How is a Room/Area Constructed?'

Quote
This would lead to very predictable results in the absence of a world and geology to consider; as the current algorithm would tend to find the same optima each time. Even with the architecture changing path lengths, room shapes and sizes, and preferred verticality, it would still find fundamentally similar solutions. On the one hand, merely introducing a map will provide a lot, at least near the surface and around the caves, providing hard constraints on where you can build will squeeze and push the fort into different shapes.. but I feel there is another element needed.

Which was later partially solved by:

Quote
▲ Ah, no, I think this is what was missing from my thoughts on connectivity. The initial plan might always be the same, because there are only so many way a small number of people will choose to live together, or set up a fixed size fort optimally. The food, dining and sleeping areas are linked in some way.... but as the fortress grows, as needs change, and requirements change, the planned areas and their locations may be insufficient, leading to new and interesting structures. No need to mess about with complex math to generate interesting structures, when events happening over time can do a lot of heavy lifting for you.

There are two posts here, the first one is a rough sketch of the problems involved in generating fortresses, but the second one was a more detailed analysis of what kind of model we would need to generate interesting fortresses. At the moment I'm convinced that between the following factors there will be sufficient variance:

That being said, I'm not discounting the possibility that I might either need to hardcode a few "basic" fortress layouts to seed the process with, or introduce some kind of parameter to randomise it slightly... although I'm not too keen on limiting it in that way. If it turns out to be a problem I'm prefer to find some kind of way to fix it in principle, instead of patching it. I'm modelling this process on my own train of thoughts while playing DF, so if I get stuck, I'll go play some DF ^___^

Title: Re: Automatic Fort Generation
Post by: Starver on June 25, 2020, 05:59:21 am
Partly a PingTW, having read this first late last night and glad I saw it come up on my radar.

As to sameness, a trivial avoidance would be that for every decision there's a run-on effect. At its simplest, having dug an entryway towards an initial chamber (in such a start), the next chamber, that isn't explicitly beyond it, can be dug off to the left, right, downward or (if terrain allows) upwards. A few more iterations later and the first choice starts to restrict (or encourage) the next choice, even with an unimaginatively unwavering drive towards the same optimality at every stage.

It needs a little work to allow this to grossly change the emergent ploymorphism (not always "a maze of twisty little passages, all alike (https://en.wikiquote.org/wiki/Colossal_Cave_Adventure)") from tbis bare-bones approach. The 'library' of choices would include dealing with complexes (and complexes of complexes) optionally spawning rooms as clustered lobes (cloverleaf), linear 'production lines', horseshoe loops out and back, a fraction of the rooms crammed into limited available space on one side (and/or level) of a through corridor, necessitating the rest across the other (with or without cut-across), or where industries merge and unmerge products (various thread-sources, to various cloth-use outputs) then shared and distinct middleman workshops can be 'lent and borrowed' during development with artefact discontinuities and funny dog-leg haulage routes arising along the way, fossilising into the final layout.

All the above described as a 'me-style' Dwarf fortress, underground, when of course this project is intended to cover far more initial design philosophies, across all races, surface/aboveground/cavern-centric as well going into the mix, if the capability and prompensity is available. At the very least.


PPE: A bit ninjaed, but I still want to PTW.
Title: Re: Automatic Fort Generation
Post by: teatime on June 25, 2020, 07:30:59 am
Groovy, Starver, thanks - that helps. The more varied the raw materials I use to construct this generator, the richer the output will be; provided I am effective and managing and merging ideas.

At the moment in my head, for the minimum AutoFort (it has a name now), I'm going to be working with assigning an area to each aspect of the fortress, eg. shelter, security, etc.; and that area is the area of the complex, which is then subdivided into functional areas. The architecture config should be able to specify something about how this society likes structuring things, and I think that might contain information on the internal structure of a complex, and preferred layouts; if possible I want to consign all the "creative" decisions to config, and have that be something you can interact with to explore different generated forts (I would love a realtime output showing the generated fort, and mutating the inputs...).

Your post makes me think of the granularity of these controls; some of them will be 0 - 100 sliders, some would be selected from an enum, and that ties back with what Salmeuk said about having the same kinds of layout. Depending on how general or specific I set up those enums, results may range from obviously predictable to finegrained and varied. If there is a selection like "large complex with internal walls"/ "rooms off a hall" and "small rooms off a big room", each with subparameters to control the nature of the generation... that would be good. Abstracting the right things is key to this.

I've been imagining this very top-down, having all of the fortress generation happen instantaneously at each phase, but having it happen more naturally, like digging a tunnel, then making a decision about where to place a room, etc opens up interesting possibilities, and would generate different kinds of forts, given you can control and specify this model differently. Architecture config might involve a tunneling strategy, exploration strategy, etc. Neat! In the best world, both methods of fort creation slot into a greater abstraction that can wield both.
Title: Re: Automatic Fort Generation
Post by: teatime on June 25, 2020, 07:33:04 am
Yeah, that makes sense. Some things I plan independent of the terrain, and try find somewhere to make it happen; other things I have a need, and try squeeze that need in somewhere.
Title: Re: Automatic Fort Generation
Post by: mightymushroom on June 25, 2020, 11:35:48 am
You might also try asking in (or moving this thread to) the modding subforum; it's a little easier to attract technical discussions there.

I happen to have run across a similar-sounding previous effort:
https://github.com/jjyg/df-ai (https://github.com/jjyg/df-ai)
is a repository for a script that would allow Dwarf Fortress to "play itself" using DFHack commands. It's several years out of date, before my time, so I don't know how "good" it was. But it's worth a look for anyone interested in the problem.
Title: Re: Automatic Fort Generation
Post by: teatime on June 25, 2020, 11:48:12 am
mightymushroom, move it as in I have the power to take a thread from one subforum and relocate it to another, or just remake a thread there to discuss it?
I started it here because it was just man shouting at cloud at first, but it's still interesting and I can forsee this thread becoming dev-diarylike, so a move to the modding forum sounds like a good idea.

Edit: Thanks for the link, it's definitely worth checking out. I hope to solve the problem in a vacuum at first, but when the time comes to touch the actual dwarf fortress that will be most useful. 
Title: Re: Automatic Fort Generation
Post by: teatime on June 27, 2020, 05:40:02 pm
301: Moved Permanently
http://www.bay12forums.com/smf/index.php?topic=176774.0 (http://www.bay12forums.com/smf/index.php?topic=176774.0)
Title: Re: Automatic Fort Generation
Post by: Starver on June 27, 2020, 06:21:50 pm
...and, if you've "moved" the thread, you can probably lock this to ReadOnly too, to save confusion.

(I could hunt down the odd rare example of myself having started a thread to have a look at what it is you should be looking for, but I can't currently think of an example to aim for. Maybe later.)