I've never seen the source code, but if you play the game a lot, you can get a feel for how the code must be structured under the hood. In many ways, DF is an example of what programmers tend to try to avoid. Instead of isolating functionality so that it doesn't affect something else in the game, the code is structured so that when you alter one tiny thing in one place, it has an effect on the other side of the code base. Quite frequently when people ask Tarn how something is supposed to work, he doesn't know. It's probably one big mess of code that relies on a lot of mutable global state.

What I've found really interesting, though, is that apart from the numerous bugs (and even more numerous regressions) the fact that it's all connected is charming. It's actually not hard to overlook the obvious craziness of the code interactions and add your own thematic explanation.

To take DF's most famous bug as an example: when the tavern update happened, cats were often found vomitting and/or dead. What happened was that when dwarfs are interrupted when they are drinking, it was decided to make them spill their drink on the ground. There is a system for tracking "contaminants" (for example, blood, mud, deadly dust, etc). Whenever something walks through a tile with something like that in it, it gets spread to tiles that the creature walks over. Every creature also has many body parts, so if they walk through something on the ground, that thing is marked as being on their body part. So when the dwarfs spill their beer, the cats can walk through it and it get's marked as being on their paws. A long time ago, there was a combat element added that allowed lizards to lick their eyes in the case that they got contaminants in their eyes. This allows them to regain vision at the cost of ingesting the contaminant (which could poison them). At the same time, because Tarn really likes cats, he decided that cats should occasionally groom themselves by licking contaminants off their body parts. There is also a system where creatures metabolise contaminants -- it's based on creature size. The bigger the creature, the more beer/poison/deadly dust it can drink/be exposed to before it dies, for example. So the cats were walking through the beer, getting it on their paws, licking it off and ingesting it. This was not planned behaviour, but just the result of a lot of different interconnected systems that were built up over several years. However, there was a bug. When contaminants were marked as being on a body part, it didn't indicate how much. It just defaulted to 1 unit (known as a "urist" -- all measurements are made in "urists" and the actual meaning depends on the kind of measurement). For liquid volume, I think a urist is about 1 pint. This was a placeholder (which is common in DF) until Tarn would get around to deciding how much contaminants to attach to things. The problem was that when the cats were licking their paws, they were drinking a pint per lick -- which quickly made them vomit, pass out and then die.

The interactions in the code are pretty clear -- it's just a bunch of semi-related processes working on global state. A bug, or placeholder in one process can potentially affect every other process. However, from the perspective of the game, this bad practice becomes magical. It's "OMG! Cats are vomiting because they are licking off beer that they picked up while walking through beer on the floor of the tavern that was spilled by dwarfs running off to a battle. This game is incredible".

This example has made me really think about the value of allowing a little chaos in the development of games. If you control every aspect of development so that everything is deterministic, it really helps in keeping the bugs down. However, it's probably not going to have the same kind of emergent behaviour. I don't think I would go to the same extreme that Tarn does (there are way too many placeholders and bugs in the game for my liking), but having his example has been really illuminating for me.