Making interesting creatures is fun and testing them in the arena is more fun, but when it comes to worldbuilding, it's the entities that count. Unfortunately, there are surprisingly few comprehensive guides on the topic of civilizations science.
Have you ever made an entity that behaved in an unusual way? Have you discovered any tricks for making an entity behave in the way you wanted to, during worldgen or afterwards? Post your finds here.
There are four entity 'factions' that can be created in Dwarf Fortress, although Vanilla only uses three of them. These factions are determined by the presence or absence of the [BABYSNATCHER] or [ITEM_THIEF] tags, so the four factions can be called the Civilized (with neither tag), the Babysnatchers, the Item Thieves, and the Babysnatching Item Thieves. Members of the same faction will trade with you in fort mode, and members of all other factions may invade you. This is separate from civs at war, which is determined by having opposing ethics.
Some caveats: Creatures without the ability to communicate will always be hostile, even if they technically would be considered the same faction. They will also wage endless wars, since they lack the ability to form treaties. This includes creatures without CAN_SPEAK (or INTELLIGENT, which is functionally CAN_LEARN and CAN_SPEAK combined). Creatures with UTTERANCES cannot communicate with other civs, however if they have both UTTERANCES and CAN_SPEAK they will be able to communicate.
A civ can only have one DEFAULT_SITE_TYPE, which determines the kinds of sites they build. However, members of a civ who have the LIKES_SITE tag may leave their homes and settle in sites created by other civs - sometimes living alongside them peacefully, sometimes by taking them over. It is possible to make an entity that actually prefers sites other than their own default site type, which will cause them to try and leave as soon as they come within range of the preferred site type.
There are four entity tokens related to biomes: START_BIOME, EXCLUSIVE_START_BIOME, SETTLEMENT_BIOME, and BIOME_SUPPORT. The way these tags interact determines how a civ will spread out across the map and where they can settle.
EXCLUSIVE_START_BIOME determines the biome or biomes where the civ can start out. A civ can have more than one EXCLUSIVE_START_BIOME.
SETTLEMENT_BIOME determines where a civ can settle. As a civ spreads out, it will build sites in areas it controls, provided it also has a SETTLEMENT_BIOME tag matching that region. There is no technical difference between a civ's initial site and those it settles in later; vanilla dwarves will build hillocks for their settlements because CAVE_DETAILED always builds hillocks for non-mountain sites and mountain halls for mountain sites.
START_BIOME is kind of a misnomer due to it being a hold-over from an older system. It simply means that a civ can both start in a particular biome and build there, i.e., it means both EXCLUSIVE_START_BIOME and SETTLEMENT_BIOME for that particular biome.
BIOME_SUPPORT determines how the civ spreads out. When the world is first generated, a civ's initial settlement is placed in one of its valid starting biomes. The civ's "sphere of influence" (which can be viewed in Legends Mode) then spreads out from the starting point based on their BIOME_SUPPORT tags. Each BIOME_SUPPORT tag represents how 'easy' it is for the civ to travel over or control that particular type of area, which are averaged out against each other.
For example, if a civ has [BIOME_SUPPORT:ANY_FOREST:3] and [BIOME_SUPPORT:ANY_DESERT:1], that means the civ will spread through forests 3 times as fast as it spreads through deserts. If the numbers were replaced with 300 and 100, it would have the same effect. If a civ has no BIOME_SUPPORT tag for a particular biome, that biome will effectively act as a 'wall' for the civ's spread.
A civ's sphere of influence determines where it can build settlements, provided it is able to build in that area. It also determines what sites the civ will typically interact with, through war and trade, although it seems that some civs can interact with civs outside of their region of influence under certain circumstances.
MAX_STARTING_CIV_NUMBER, MAX_POP_NUMBER, and MAX_SITE_POP_NUMBER also affect how common a race will be, and how easily they will spread.
MAX_STARTING_CIV_NUMBER places a limit on the number of individual civs of that entity will be created. Note that, depending on how many races you have, and how many civs are allowed by worldgen parameters, this number may or may not have an actual effect. Worldgen creates civs by passing down the entity list, adding one civ of each type with each pass, until the maximum civ number for the world is reached.
MAX_POP_NUMBER places an approximate limit on the number of individuals per civ. The actual max population for a given entity is the MAX_POP_NUMBER multiplied by the number of civs that entity has.
MAX_SITE_POP_NUMBER places an approximate limit on the number of individuals that can live in a site. The closer a site is to reaching its limit, the more likely it is for a new site to be created.
If you make a race that tends to take over the map when you don't want it to, you can limit its spread by decreasing the MAX_POP_NUMBER, increasing the MAX_SITE_POP_NUMBER, or both. Likewise, you can encourage a civ to spread out by lowering the MAX_SITE_POP_NUMBER. However, this means that each individual site will be more vulnerable to invasions.
Note that this doesn't fully apply for civs with DEFAULT_SITE_TYPE:CAVE, as these civs will never build new sites, only settle in existing caves. If a civ has no nearby cave for migrants to move into, they will remain in place.
Some quirks:
Although a civ can potentially build a site anywhere within its sphere of influence, it is more likely to build relatively close to an existing site. So even if, for example, a civ's influence spreads all the way across an ocean (that it cannot build in), it will usually not start building on the other side unless the ocean at that point is relatively narrow, and the civ already has a city nearby.
If a civ has EXCLUSIVE_START_BIOME but no SETTLEMENT_BIOME matching that region, only the initial site will be placed. The civ may still be able to spread by expanding its sphere of influence into a region where it can build, although this is rare, since the existing city will not usually be close enough to the targeted biome.
If a civ has EXCLUSIVE_START_BIOME in a region where it has no BIOME_SUPPORT, the game will attempt to place the initial settlement directly on a boundary between one of its EXCLUSIVE_START_BIOMEs and one of the regions that it has BIOME_SUPPORT for. However, this seems to prevent the civ from spreading beyond its initial site. For example, if a civ has [EXCLUSIVE_START_BIOME:ANY_OCEAN][SETTLEMENT_BIOME:ANY_LAND][BIOME_SUPPORT:ANY_LAND:1], it will begin on a coast, but will never spread out beyond that point.
Members of a civ can migrate to or conquer any site within the sphere of influence, even if it is not within the civ's SETTLEMENT_BIOME list. SETTLEMENT_BIOME determines where a civ can build, not where its members can live. Whether they will do so or not is determined by the LIKES_SITE and TOLERATES_SITE tokens. If a civ conquers a site through war but does not like that particular kind of site, the site will simply be left as a ruin.
Speaking of oceans, it's worth mentioning that all biome types, including oceans, are functionally equal when determining spread and settlement, and will be regarded as such during worldgen. Logic will assert itself if you try to visit certain sites, though. (i.e. if you visit a subaquatic human city, everyone will drown as soon as you arrive.)
Nice thread, let's talk about pets and livestock.
During world gen, each civ fills 5 lists of creatures:
- Pets: Can be bought at embark, and are also brought by caravans and migration waves
- Mounts: Used by invaders, a mounted invader is pretty much two enemies in one tile.
- Pack: Used by caravans, they hold a limited amount of good on their back.
- Pull: Used by caravan to pull wagons, two of them are also spawned on embark.
- Minion: Creatures gathered into their own squads during invasions and are used in world gen battles.
In order to add creatures to this list, civs requires a white list made from preference tags. According to these tags, each civilization will spread over neighboring biomes, adding any non intelligent animal with a PET tag living in these places.
PULL, MOUNT, PACK creatures are explicitly added to their role as well as the pet list, TRAINABLE_WAR will also add trained versions in the minion list.
In example, camels are common pack animals living in desert biomes. An human civ spreading over a desert will consider camels as a pet and a pack animal.
Adding creatures
COMMON_DOMESTIC_PACK, PULL, PET, etc. Allow creatures with the PET and COMMON_DOMESTIC tags to be added. Those creatures must not be intelligent.
USE_CAVE_ANIMALS enables any creature with a subterranean level of 1 or 2 to be added. Because all biomes tend to have an underground area and those ignore good and evil levels of the surface, this makes it very easy to add such creatures to the civ. This is why goblins always have access to trolls.
USE_GOOD_ANIMALS or USE_EVIL_ANIMALS allows creatures with GOOD or EVIL tags to be added. Otherwise those will be forbidden even if they satisfy other conditions. Such creatures only spawn on good or evil biomes and there is no way to force a civ to go there. The best bet to add such creatures is to make them cave animals as well.
One special case for EVIL creatures: INTELLIGENT races with SLOW_LEARNER or only CAN_SPEAK (aka dumb creatures) are also added to pets and minions as they are enslaved. This is why goblins bring trolls for sieges.
USE_ANY_PET_RACE causes the civ to treat PET_EXOTIC as simply PET. This is why elves can trade exotic creatures but since they only use PACK and not PULL animals, they do not have wagons.
Special cases
SCOUT adds adventurers during world gen who will go in the wilds or the caverns. If they are successful, they will tame a PET_EXOTIC creature of the mentioned biomes and add it to the lists. This is used to create more variations between worlds and explain with humans often send squads of tigers at you.
USE_ANIMAL_PRODUCTS will add leather, sheared fur, blood and venom from creatures, pet or not, to the available resources.
Players can add PET_EXOTIC creatures to the civ lists in fort mode by capturing and taming them.
You can also use the ANIMAL tags to override any or all of these rules for a specific entity. To do this, you designate an animal definition using the
[ANIMAL] tag, then use [ANIMAL_TOKEN], [ANIMAL_CASTE_TOKEN], [ANIMAL_CLASS], and [ANIMAL_FORBIDDEN_CLASS] to tell the game which specific animals you are modifying the rules for. If not specified, the rules will apply to ALL creatures.
ANIMAL_NEVER_MOUNT, ANIMAL_ALWAYS_MOUNT, ANIMAL_NEVER_WAGON_PULLER, ANIMAL_ALWAYS_WAGON_PULLER, ANIMAL_NEVER_SIEGE, ANIMAL_ALWAYS_SIEGE, ANIMAL_NEVER_PET, ANIMAL_ALWAYS_PET, ANIMAL_NEVER_PACK_ANIMAL, ANIMAL_ALWAYS_PACK_ANIMAL will then override the normal rules for the animals/castes selected.
[ANIMAL_ALWAYS_PRESENT] will ensure that the animal is always available to that civ even if their territories do not overlap.
There are two basic kinds of nobles: civ-level and site-level. Positions with the [SITE] tag are site-level, those without it are civ-level. These types of nobles can be regarded as completely separate systems; with the lone exception of LAND_HOLDER related appointments (which have their own specific rules), civ-level nobles cannot appoint, succeed, or be replaced by site-level positions, and vice versa.
Outside of fort mode, the game will always attempt to assign nobles whenever possible (except for those with NUMBER:AS_NEEDED). So the rules for when nobles appear are controlled by the tags which limit them.
Nobles with [APPOINTED_BY:position] require a noble of the designated position.
Nobles with [REQUIRES_POPULATION] require the population to have a specific size.
Nobles with [REQUIRES_MARKET] will only appear in "large" sites (which may have different rules for different site types). This tag has no effect in fort mode.
Positions that have no requirements will automatically be assigned to a random civ member when a new site/civ is created.
A position that requires a certain population will not appear in fort mode unless it has [APPOINTED_BY] or [ELECTED], probably due to a bug. In worldgen, there is no functional difference between ELECTED and no appointment rule except that ELECTED nobles tend to have high social skills and/or skills related to the position, while non-elected ones are assigned randomly.
If a noble dies or advances to a new position via succession, the position will be granted to another unit based on the [SUCCESSION] tag. If they have an heir or the position exists, the unit will be assigned. If not, a new one will be appointed according to the usual rules.
It is possible to assign multiple levels of SUCCESSION:BY_POSITION, creating a line of positions where the death of one causes all those "below" them to advance.
[REPLACED_BY:position] means that once the replacing position is available, the current position will disappear. As mentioned, site-level and civ-level positions are completely separate; a site position cannot be replaced by a civ-level one or vice versa.
These rules are followed in worldgen. It is possible to cause civs and individual sites to change their behavior substantially when they reach a certain size by controlling nobles. For example, if a site can only appoint a position with [MILITARY_GOALS] after reaching a particular size, that site will not send armies on missions until the required size is reached.
Another interesting point is that a civ-level LAW_MAKING position is required for the civilization to have any kind of cohesion. Without it, sites will be constantly embroiled in territorial disputes and civil wars will be commonplace.
The way DF determines what positions will actually appear in your fortress is somewhat counter-intuitive and fairly limiting. This guide should help you understand what you can do to actually get your positions working properly.
There are five tokens governing which positions appear in your fortress - LAND_HOLDER, REQUIRES_POPULATION, APPOINTED_BY, ELECTED, and REPLACED_BY. The first two determine when your fortress is eligible for a new position, the next two determine how a new position for which your fortress is eligible can be added, and the fifth allows you to clear up obsolete positions. Unfortunately, they also interact in some strange ways that makes creating interesting position structures difficult.
When you start a new fortress, DF compiles a list of your initial positions. To do this, it looks at the requirements for each position - any position whose only requirement is less than seven dwarves (either because they have no requirement tokens, or because their only requirement tokens are [REQUIRES_POPULATION: =< 7] or [LAND_HOLDER:some trigger whose only requirement is some number of dwarves equal to or less than 7]). Most importantly, any position whose only requirement is a LAND_HOLDER requirement, regardless of what the trigger for that requirement is, will be added if another eligible starting position is REPLACED_BY it. A non-LAND_HOLDER position that is REPLACED_BY a LAND_HOLDER position will never appear. With this list compiled, the game culls all positions that are REPLACED_BY another eligible position, and then culls all positions that have the APPOINTED_BY token. You may not embark with any appointed positions. Any remaining positions are then filled by a dwarf chosen at random.
Positions do not automatically appear when you reach their requirements. For example, if you remove the ELECTED token from the Mayor, then the Mayor will never appear, even once you reach their required number of dwarves. For a position that does not appear at embark to appear in your fortress, it must be APPOINTED_BY another position or ELECTED.
Naturally, this is more complicated than it looks. APPOINTED_BY positions must be appointed by another position already in your fortress, or a civ-level position. Only LAND_HOLDER positions may be appointed by civ-level positions. LAND_HOLDER positions that are APPOINTED_BY civ-level positions are inherently tied to civ-level tokens with the ESTABLISH_COLONY_TRADE_AGREEMENTS responsibility. If a fortress meets the LAND_HOLDER_TRIGGER for a new LAND_HOLDER tier when a caravan leaves, then the next time the outpost liaison or equivalent arrives, they will offer to make you an official colony, which will allow you to select all positions for that LAND_HOLDER level. Each time they appear, the outpost liaison will only promote your fortress one tier up the LAND_HOLDER track. The biggest problem with this system is that you may set your LAND_HOLDER_TRIGGERS such that you are eligible for the first tier of LAND_HOLDER positions at embark. If you are eligible for the first tier of LAND_HOLDER positions at embark, then all first-tier positions will appear twice - once at embark, and again when the outpost liaison comes to appoint you to the first tier.
Every site can have its own army, and that army can potentially be sent out on missions. The civ itself can also have its own army, which is treated as a separate army. How armies are built depends on the noble positions.
Normally, nobles will be created based on their NUMBER; as long as a noble position can be appointed (either [ELECTED] or its [APPOINTED_BY] noble exists) that number of nobles will be created automatically. The exception to this is those with AS_NEEDED, which will never be created until an army is formed.
Missions are created by a noble with the [MILITARY_GOALS] position (defending a site from invasion is also considered a mission). When a mission is created, the noble will first decide how many troops it will send on that mission. This number is limited by the total population of the site.
These troops will be assigned to nobles with SQUAD tags. If there are not enough squads to handle all of the needed troops, nobles with the COMMANDER tag, who command positions with the [NUMBER:AS_NEEDED] tag, will start appointing subordinates. The "lowest ranked" noble that is still able to appoint new subordinates will have priority.
The [COMMANDER:position:ALL] tag states that a noble is the commander of the designated position. However, you can ALSO put a number here (this feature is not used in vanilla). For example, [COMMANDER:position:10]. This means that the commander can command a maximum of 10 nobles with the specified position. (ALL means they can appoint as many as they want.)
In vanilla DF, since the GENERAL has [COMMANDER:LIEUTENANT:ALL], and the LIEUTENANT has [COMMANDER:CAPTAIN:ALL], even though LIEUTENANT has [NUMBER:AS_NEEDED] there will almost never be more than one LIEUTENANT per civ: once there is one LIEUTENANT they can keep adding CAPTAINs until there are enough to manage the entire army, so no more LIEUTENANTs are needed. However, if, for instance, you limit the LIEUTENANT to only be able to command 10 CAPTAINs, if the mission requires an army larger than 100 soldiers the GENERAL will appoint a new LIEUTENANT.
This also means that if you limit the GENERAL to only be able to command 10 LIEUTENANTs, the civ's total army size will be limited to about 1000 soldiers. Using this, you can limit the size of a civ's army and make it weaker in war.
Site type specifics
Civs with [DEFAULT_SITE_TYPE:CAVE_DETAILED] will create different kinds of sites depending on where they settle. If they settle on a mountain, they will create 'Mountain Halls', elaborate underground structures. If they settle elsewhere, they will create 'Hillocks' instead, little hollowed-out mounds.
On both mountain and non-mountain biomes, sites with high population may create 'Fortresses', rectangular structures that are built above ground but are mostly underground. If the civ can build tunnels, they may also create tunnels that link fortresses together. Unfortunately, lag tends to be pretty bad around fortresses, so navigating them can be a chore even if you can deal with their maze-like structure.
Hillocks contain Civic Mounds, where the ruler of the site can usually be found. They will also produce 'Drinking Mounds', where you will find 'Drunks' hanging around. This happens regardless of the race's dependency on alcohol, and is presumably the mountain-civ equivalent of taverns. Drunks are basically unskilled peasants, but they will always be willing to accompany you on an adventure or join your insurrection, as long as you don't have too many companions already. Be warned that even if they claim to be joining your insurrection, attacking a ruler they like may cause them to turn on you.
Civs with [DEFAULT_SITE_TYPE:CITY] will create cities, towns, and hamlets, depending on the population of the site.
Hamlets are small areas with simple houses, although you will frequently find bags of food lying out in the open, free for the taking. Hamlets with ruling nobles will also have mead halls, where the rulers will live, and you will often find free equipment here as well.
Towns and cities are large areas, which may have structures such as markets, temples, keeps, catacombs, and sewers. Bands of criminals will often hide out in the catacombs.
Civs with [DEFAULT_SITE_TYPE:TREE_CITY] create forest retreats, regardless of whether they are actually in a forest or not. These sites consist of larger versions of regular trees. Some of these trees, 'shaping trees', may have free items seemingly 'growing' on top, although these items are actually just whatever items the civ is capable of producing. (If the civ produces only wooden items, like the elves, they will be made of wood, but if they produce metal or animal products, you'll find metal or bone items 'growing' out of the trees instead.)
One of these trees, the Home Tree, functions as the ruling building of the site. It will be bigger than the other trees. You may also find market trees which function basically like city marketplaces, except in the trees. The inhabitants of the site will live in the trees. If you have to ask permission before going to sleep in a tree, sleeping there will keep you safe from bogeymen.
One interesting effect of forest retreats is that some trees that do not normally produce branches may produce branches in a forest retreat. This can be seen with date palms and banana trees, for example. I haven't worked out the exact conditions that allow this to happen, but it is potentially of interest to those who want to make trees that produce items that can only be harvested by an adventurer who travels to a forest retreat.
Mushroom-type trees in forest retreats are...weird. They won't grow any higher than they normally grow, but they will grow some odd growths that stick out of their caps, and sometimes, at their base. They will also leave sky-colored 'unusable slopes' floating in the air in ring shapes. Evidently support for ultra-sized mushrooms isn't really in the game, but they don't cause crashes or anything like that.
Sites with [DEFAULT_SITE_TYPE:DARK_FORTRESS] have a number of interesting properties that makes them rather difficult to mod. Their civs begin around underworld spires, and are ruled by demons. They cannot have more than one civ-wide position with the [RESPONSIBILITY:LAW_MAKING] tag, and cannot have any nobles with the [CHAT_WORTHY] tag except for their primary law giver, or worldgen will crash.
There are two kinds of dark fortress sites; dark pits and the dark fortresses proper. Both types of sites have long furrows leading through them, which will make traveling through them difficult unless you can climb or jump. Both sites will also have towers, and most of the population will be concentrated on the roofs of these towers, presumably due to a bug.
Dark fortresses proper are large structures that are a lot of fun to navigate, unfortunately lag is often terrible around them, unless you happen to find an abandoned or mostly abandoned site. They have many levels, often with pits that lead all the way into the caverns. Captives of the civ will be kept in prisons. (If a non-fortress civ is a babysnatching race, you will find the captive children just standing around instead), and dark fortresses will have prisons whether they are snatchers or not.
As dark fortress sites are fairly large areas and you cannot view the map while in them, navigating them can be tricky. The compass (in the upper-left corner of the screen) is helpful for finding the main fortress.
Civs with [DEFAULT_SITE_TYPE:CAVE] will not create their own sites during worldgen, and will not appear on the civ list in fortress mode (unless you turn 'reveal caves' on in worldgen options). They will, however, settle in other sites and may go to war with other civs, provided they have the required tags. This allows you to create 'secret' civs that may show up as a surprise for a fort, or you may rarely find members of them hanging out on regular sites as an adventurer. On rare occasions, a cave civ may take over a nearby settlement and claim it for themselves.
Adventurers can come from cave civs, but you will not be able to see where they start out on the map when choosing your adventurer, unless 'reveal caves' is on.
Inhabited caves will generate full of traps. Because of this it is a good idea to give any cave-dwelling civilized creatures [TRAPAVOID], otherwise they may get caught in their own traps when you are exploring an inhabited cave in Adventure Mode.
While in world gen a civ with DEFAULT_SITE_TYPE:CAVE will not settle in any other caves than the one they are placed in at the start of world gen. After world gen they will go and "reclaim" other caves, but if the cave is on a different landmass (or in some other way inaccessible?) the group will just sit in place and go nowhere. This "reclaiming" of caves will often have the effect of emptying the original cave of most of its inhabitants.
Furthermore, in the event that there are no empty caves to "reclaim" the civ will instead send out one or more groups to "found" a new cave. This will create a large site that contains nothing at all, which on the adventure map resemble what dwarf sites used to look like before that last major update made them visitable again. And just like those unvisitable dwarf sites, there will be no way to find or in any way interact with those said to live there.
(allows you to upload an entity file and tweak their ethics while viewing how much each civ likes/hates each other, then download the result)
Info about sapient petsStuff about mining underworld disastersI will post more here later.
Author
Topic: The Civilization Cookbook (Read 23075 times)