O(n²) scaling is brutal. If n=100, then that is 100×100=10,000 mood checks. When n=101, that grows to 101² = 10201. 102² is 10404. You see how fast it is growing¹? Every person you add causes far more mood checks than the last person you added. There is nothing that computer science can do to reduce this growth. The whole study of computer science is the study of the limits of computing, and these are the limits. No amount of brain sweat can reduce the the rate at which the problem scales.
Of course we could redefine the problem; make each mood check simpler, for example. We could simply leave some of the current factors out of the calculation, so that the calculations are cheaper to do. For example we could make the mood check ignore consanguinity. A dwarf’s reaction would depend only on whether they saw a friend or not, but not on whether they saw a cousin or a sister. That will allow us to scale to higher population counts, but we still face the fact that there will be _some_ population limit.
Or we could reduce n somehow. For example, we could arbitrarily decide that some of the population doesn’t participate in line of sight checks. Maybe livestock are never checked at all, so the 50 cats don’t make n bigger. But then your cats won’t run away from zombie invaders, because they don’t check line of sight to see what is around them. Is that acceptable? Maybe, maybe not. Maybe it’s disappointing to to the game designer but they go ahead with the change because the players will still have fun.
The third thing to do is to optimize the mood checks so that they use the processor more efficiently. This is hard but doable, and can be done without changing the problem. And in fact it has already been done, to one extent or another. But modern processors are actually pretty hard to optimize for, and all the low–hanging fruit has been picked. For example, I have a 16–core CPU, and until a few years ago the game could only use one of those cores to run the line of sight checks on. The other 15 would be idle. That obviously leaves a lot of performance on the table. Now that the game uses all 16 cores equally you’ll find that n has gone up quite a lot. But it didn’t go from 100 to 1600, it went from 100 to about 400. 100²=10,000 line of sight mood checks, and 400²=160,000 mood checks. But once spread over 16 cores that’s still 10,000 per core! So now it can do the line of sight mood checks for a population of 400 in the same time as it could do them for a population of 100, only a 4× improvement. And if your CPU only has 8 cores then the new limit for you is really a population of about 283, etc.
But there is still more processing power in our CPUs that is going untapped by DF, and language models are actually really good at making use of that power. A modern CPU can run SIMD, or Single Instruction Multiple Data, instructions that can operate on many values at once. It can multiply two numbers together, or it can multiply a vector of 4, 8, 16, or even 32 numbers together all at once. And multiplying the vectors takes the same amount of time as multiplying two ordinary numbers! All a language model is doing is repeated matrix multiplication, which boils down to multiplying lots of individual numbers together. An LLM is _only_ doing vector instructions on 32 half–width floats at a time, over and over again, but DF doesn’t have that luxury. Most of what DF does just cannot be done using vector math in any useful fashion. The graphics could be (sprite compositing), but DF sends all of the graphics over to the GPU instead. So LLMs are not an apples–to–apples comparison for Dwarf Fortress.