Bay 12 Games Forum

It might be very possible with the use of cages, but eh feels cheaty.

There's a little description under the screen in the spoiler on how it's done, in case someone wants to try on their own terms without spoiling the fun of discovery.

In case someone wants to read more, I covered my science on huge forts in this topic http://www.bay12forums.com/smf/index.php?topic=181498.0 and I used the conclusions of it heavily in the challenge.

It's not really a functional fort, their needs are covered by various debug tools:
- debug_noberserk
- debug_nodrink
- debug_noeat
- debug_nomoods
- debug_nosleep

I think their names are self-explainatory.

But hey, the challenge was to get as many dorfs with any hackery possible, not to create a fully functional fort. For a fully functional fort I think the limit would be 2-3k, but I'm still testing that.

Result of my attempt - 4987 dorfs at 10fps:


That's the max amount of dorfs I was able to get. To add more someone would need to figure out how to increase the population limit past 5000 - it might not be possible (most probably a limit set in code, according to very knowledgeable people). And I have little to no intention to look for a way to increase it - I'm already at 10 fps after all.

DFHack was used only to speed up the setup process and to surpass the embark size limit. All dorfs are fully functional and have their eyes intact (I tried though, it did not change fps at all). In case I decide to set my PC on fire I very well might send them all at once to raid some goblins.

Bit surprised it was actually possible to get that far.

Spoiler: NOT A PROMISED FEATURE JUST A PIPE DREAM DO NOT HOLD ME TO THIS (click to show/hide)

My dream of an "FPS manager script" for DF could become far more extreme now that I have source access, come to think, turn on the "experimental FPS maximizer" that automatically detects what the slowest parts of the code are and moves things around for you, with the caveat that certain bugs are likely to be ignored, or whatever. And obviously every parameter that could be changed by this would be in the settings somewhere.

Like, what I've got in mind is "below the minimum FPS? First speed up actions and world ticks to match desired FPS, and if that's not sufficient smoothly turn down the Z-level LoS short-circuit, then turn off temperature, then turn down X/Y short-circuiting to a minimum of 10, then..." sort of thing. PID it, why not.

Sounds very cool if by short-circuit you mean the los skip. But if its really just one variable I'd reduce it to, lets say, 10 and do a test first. We might be hyping over it and who know, maybe it won't change all that much because reasons.

And regarding the impact of pathing through a completely dug-out z-level, well fps gets considerably lower when I dig out everything, but nothing too crazy. Still much better than 1x1.

Putnam clarified in this thread that:  The bounding box for skipping the calculation is a cube, and that the early-out is for greater-than 26.  So dwarfs on level N can consider dwarfs on level N+26 for further evaluation, but not on level N+27.

With 26 empty z-levels between they have at least 27 levels difference, something like 1st area z-level 0, 2st area z-level 28. And there are certainly more than 26 levels apart between 1st and 3rd and 4th area.

Inspired by the famous revelation from Putnam regarding the pathing impact, since 2 months I've been doing series of experiments on impact of different embark/population configurations on FPS.

I. The setup

1. Most of my experiments are made with a population of 1000 dwarves, to make the tests as consistent as possible, and to focus even more on just units impact on fps.

2. Most worlds are generated as small or medium regions with default settings, as I found them the most consistent.

3. Most of testing is made on 16x1 embarks (a so called noodle-embark), because its the only embark size which has the ability to handle 1000 dwarves. More on that later.

4. Most of my test designs are open. A wholy dug checkerboarded single z-levels. Something like:

XOX
OXO
XOX

X - dig
O - wall

5. To spread the dwarves evenly throughout areas, I create perperdicular stripes of meeting halls, separated by around one screen length (not because its the most efficient, but because its the easiest and fastest to setup multiple times). Roughly looks like this:

MXOXOXOMXOXOXOXOXMOXOXOXOXMXOXOXOMXOXOXOXOXMOXOXOXOXM
MOXOXOXMOXOXOXOXOMXOXOXOXOMOXOXOXMOXOXOXOXOMXOXOXOXOM
MXOXOXOMXOXOXOXOXMOXOXOXOXMXOXOXOMXOXOXOXOXMOXOXOXOXM

X - dig
O - wall
M - meeting hall

6. All of my tests are made without zooming, as it's proven to affect performance. So 2x zoom out from max zoom.

7. My recent test embarks are only on deserts without any vegetation, to avoid trees/herbs interfering with the results

8. All testing worlds have all 3 caverns enabled.

9. Most of the testing made on v50.07.

Relevant info about my PC:
- i7-12700k at stock clock
- 32gb of 6000mhz, cl34 ram

II. To make my science as much uninterfered with various variables, I use considerable amount of cheating, which include:

1. Debug tools in df.global structure:
- debug_noberserk
- debug_nodrink
- debug_noeat
- debug_nomoods
- debug_nosleep
- debug_fastmining

2. "fastdwarf 1 1" DFHack command to quickly dig the huge areas required for experimenting, changed to "fastdwarf 0 0" after setup is done.

3. "migrants-now" DFHack command to quickly pool huge amounts of dwarves in a matter of days, to count out any world changes impacting the fps

Thanks to all the cheats, absolutely 0 produced items interfering with the results.

III. The results

100% certain as of now, proven through countless different embarks now:

1. The feature of skipping interactions between dwarves if they are 26 or more tiles apart is by far the most impactful on performance. Its the mechanism that allows to have 1000 dwarves in a single embark with reasonable fps (at one point even 65 fps after culling all migrated animals!)

2. The most performance efficient embark for my testing conditions is 16x1 (and probably 1x16, but I haven't tested that one). It exploits the 26 tile skipping mechanism the most while still having relatively small amount of land to calculate/path around. With 1000 dwarves and their migrated animals on 16x1 embark i get around ~50 fps.

Not 100% certain, tested but not across every possible scenario:

1. I found checkerboarding of big areas beneficial for the fps, but for counterintuitive reasons. With the same setup as in point I.5. above, but with just digging out an entire z-level I get 35 fps, compared to ~50 with checkerboarding. Why? I thought because checkerboarding limits LoS - nope.
Turns out checkerboarding just makes the dwarves more spread on y-dimension, so more chances for dwarves to escape the 26 tile calculation area. Bonus is less spreading of mist/miasma/dust.

2. 4x4 embark gives considerably lower fps compared to 16x1, despite having the same amount of land - see the 26 tile spread rule. 16x2 embark is a bit slower than 16x1 - I've got ~45 fps, probably because of more land/pathing to calculate. But I've done only one 16x2 test.

3. 26 tile skipping doesn't work on z-dimension. On my recent test day I made 4 areas as in point I.5. separated by 26 z-levels, and spread 1000 dorfs on those areas resulting in roughly 250 dorfs on each of them, then removed stairs connecting them. FPS results are absolutely the same as with single 16x1 z-level.

4. 1x1 embark is terrible for fps with a lot of dwarves. I made 2 versions of 1x1 fort. One with stairs connecting 16 different, checkerboarded z-levels, second one with ramps going left-right, to spread the dwarves evenly on each of 16 z-levels. Result? At 1000 dorfs 17 fps with stairs, 18 fps with ramps, despite having 16 areas of 48x48, so roughly the same as with single 16x1 z-level, and the advantage of potentially more LoS-breaks, as there were floors between each z-level.
Fun fact - 16x1 simple checkerboard z-level handles 2100 dorfs at 16 fps. Yep, 1x1 forts are pretty bad.

5. Both small and medium region embarks start with roughly the same fps. Small region suffers no changes to fps after 10 years of world development post-embark. Medium world fps gets cut in half in about 3 years, and stays like this - but i only tested 10 years, and on limited amount of worlds, so it might be heavily dependent on RNG.

6. Increased RAM frequency helps significantly with handling big amounts of dorfs in a small area, and falls in importance with more optimal fort designs (would need a lot more testing though).


As a bonus - a save with 1000 dorfs to test your PC capabilities. Enabling debug mode advised (for advanced users, description in the link), but should run for a bit before dorfs kill eachother. I get 52-54 fps on it. Also it gives a good view on my testing methodology.
https://dffd.bay12games.com/file.php?id=16524