Title is self-explanatory, really. I know you can edit them afterwards, but I'm curious as to how they get rolled in the first place.

Okay, so because I'm insane, I spent last night hitting "No" 167 times to get ~1000 individual stats. These ranged from 9 to 18 (I have gotten an 8 once in the past, but only once, and I didn't want to sit around and do this forever). I manually entered them into Excel, plotted them as a histogram, and then went to sleep.

Then I spent this morning coming up with as many different rolling styles as I could think of and checking whether the histograms were similar. I tried standard roll types, I tried exotic roll types, I tried crazy roll types, anything I could think of to give you a random number between 8 and 18: 3d6, 4d6b3, 5d6b3, 2d9, 3d9b2, 2d6+6, 4d4+2, etc. etc. etc.

It took a while, but I finally found one that matched. And it's a strange one that you can't even use standard dice notation for:
* 12 coin flips that give you a 0 or 1
* Take the best 10
* Add 8.
This fairly reliably gives very similar plots to the original dataset: a peak at 14; roughly equal numbers of 13s and 15s, 16s and 12s, 17s and 11s, and 18s and 10s, with a possible slight bias towards the higher number in each pair; the occasional 9; and the exceedingly rare 8 (1/4096 chance of losing all 12 coin flips).

It is possible that the game uses 13 coin flips instead of 12; this also often gives a similar histogram to the one I received from the in-game stats. But it also often gives you a peak at 15, and I think it's slightly more probable that the game's developers would choose 12 rather than 13.

Does anyone know if this is accurate?

I don't know, but one could check it with a debugger (use a heavy debug build of DOSBox, or emulate a different version with an emulator that has a debugger); find where a specific stat is stored (shouldn't be hard), put a breakpoint there, and see if you can figure out what the code is doing.

Of course, to do this you will need to have some knowledge of the assembly language used by the specific CPU (x86 for the DOS version, but non-DOS versions are built for different CPUs for obvious reasons), and be at least somewhat familiar with a debugger, but this could, with some time and effort, be done.

Note that, for the algorithm you suggest, the game would have to store the flips somewhere in memory.

By the way, here's a slightly different algorithm that gives the same result, but would, I think, be easier to code:
* Game flips 12 coins, and adds the number of heads. (Alternatively, game rolls 12d2 - 12; that works the same way but has an added subtraction.)
* Game caps the result at 10.
* Then, the game adds 8.

Alternatively, one could just say that each stat is 12d2 - 4, but capped at 18; this is the algorithm in standard dice notation.

(By the way, some games of its era, like some Wizardry games, actually *did* use non-standard die types; I have seen games that would actually use d7 for the damage of certain weapons.)

I realized, a couple of hours after my post, that I had been silly; what I wrote was equivalent to 12d2b10-2. But I couldn't get to a computer until now.

Your capping suggestion is a good one. 12d2-4 capped at 18, or 12 coin flips capped at 10+8, both work well and are easier to code.

I can't find anywhere else that this has been investigated, however. I could do another thousand rolls to try and lock down whether it's 12 or 13...

Out of curiosity, have you checked whether 4d4 + 4 (what the Dark Sun setting uses), but capped at 18, fits the data?

(And, of course, the only way to know for certain is to look at the game code in a debugger.)

I hadn't tried that, no. Looking it up now, it's not a good fit - the curve is flatter, producing far more 8s, 9s, 10s, 17s, and 18s and far fewer 12s, 13s, and 14s. I'm not a programmer, unfortunately. I'm a dilettante with just enough knowledge of statistics and Excel to get myself in trouble :)

I did end up adding another 1500 rolls to my dataset, mostly because you get bored out of your mind waiting for the kids to fall asleep. I'm now certain it's *not* 13d2b10-2. But 12d2b10-2 doesn't seem to be a perfect fit either. It produces 18s slightly less often and 8s slightly more often than the game does.