PDA

View Full Version : Monte Carlo Level Simulation


fizzix
November 2, 2010, 14:57
I've been poking around a lot in generate.c and simultaneously thinking about how to implement a monte carlo level simulation.


There are two options to simulation, one is to generate a level as it exists, and then go through manually removing the monsters and logging the treasure. The second simulation winds up being a change of how the level generation is done, this would involve a complete rewrite of generate.c

The advantage of killing all monsters on the level manually is that changes in generate.c will not effect the simulation. The main advantage to rewrite level generation is that the simulation can be done faster, and it's easier to log some specific items.

I'm leaning towards the manually killing monsters approach, with one change to generate.c, new floor designations PIT_FLOOR and NEST_FLOOR, so I can properly log monsters and treasure in these areas. If it turns out this approach is too slow, I'll look at the rewriting generate.c approach.

The main idea will be to go through each square. If you hit a treasure, record it and log it. If you hit a monster, record what treasure it would drop if you were to kill it, log it and the treasure, and remove it from the level.

The big question is what to record. I'm looking at something like this in average value per level:

total monsters
OoD monsters: in vaults: in pits/nests:
total unique monsters: in vaults:
At or OoD unique monsters: in vaults:

Gold:
from monsters
from ground (non vaults)
from vaults
from veins

Items (weapons and armor)
Total:
From ground: in vaults:
From monsters: in vaults: in pits/nests:
From uniques: in vaults:

(repeat for excellent, superb, endgame quality, artifacts, and artifacts with min levels near or above current depth.)

consumables: (i need some input here, what should I log...)

I'm thinking of putting all totals into longs (can I use floats?) and dividing by the sim number after it's done. Longs should be large enough for everything but money, and I can get around that by dividing by 10 or 100 or something.

thoughts/suggestions?

RogerN
November 2, 2010, 16:31
It's an interesting an idea - I would love to see the results, and I'm sure others would also.

How would you use the results, though? Very few players actually kill every monster or loot every item on the floor, so I'm not sure how relevant this data would be to balance. Given that players may explore only 20 to 30% of a level, and consciously choose to avoid certain types of monsters, you wouldn't be getting a clear picture of a given player's experience.

I suppose it might provide information that's useful for balancing ironman-style games.

Oh - I think it's very important to calculate the standard deviations as well as average treasure values. That can give you a better clue regarding player frustration w/rt loot shortage vs. loot surplus on different playthroughs.

d_m
November 2, 2010, 16:32
I think myshkin has implemented something like this (and is finishing it up before pushing it into trunk). I won't say more because I'm not totally clear on the details, but I really look forward to using it to profile level creation and item generation.

Derakon
November 2, 2010, 16:47
I'm sure the data will be useful even if players only interact with 30% of the dungeon.

The way I'd do this would be to add a debug-mode command that would forcibly restart dungeon generation after it finishes (as when it has to restart e.g. due to having too many monsters in the dungeon) for the specified number of times. This would involve a fairly simple addition to generate.c's main loop (the "while (error) {cave_gen(); create level feeling; check for error conditions;}" bit).

As for actually examining the quality of the level, see if you can co-opt display_itemlist() and display_monlist().

takkaria
November 2, 2010, 17:08
Note that wiz-stats.c in V already does some monte carlo experimentation already and I used it to change monster drops and objects found on the floor.

fizzix
November 2, 2010, 19:06
I think myshkin has implemented something like this (and is finishing it up before pushing it into trunk). I won't say more because I'm not totally clear on the details, but I really look forward to using it to profile level creation and item generation.

should i interpret this as 'wait a bit before starting on this project?

Note that wiz-stats.c in V already does some monte carlo experimentation already and I used it to change monster drops and objects found on the floor.

cool, i'll check it out, and see how expandable it is.

Magnate
November 2, 2010, 20:39
should i interpret this as 'wait a bit before starting on this project?There are a few denizens of #angband-dev who don't post on oook, and it would be good to optimise the use of people's time. I'm still a bit sad that PyAngband went ahead and developed a new text file syntax, when someone already did that ... but now we have github, these links should be easier to make.

So by all means crack on with it if you're dead keen - but if you have other stuff to do as well, you might find that what myshkin pushes to github does most of what you wanted.

That said, it's impossible to guess when it will appear. Soon, I hope.

myshkin
November 2, 2010, 20:43
should i interpret this as 'wait a bit before starting on this project?


Yes, I'm hoping to have something on github in the next day or two. (There's one main bug to fix.) My approach is a combination of wiz-stats.c and elly's main-test.c, and uses your second option. (It does not open chests, but it does kill all monsters.) The gist is

* Initialize the game
* Dump to file any necessary data from a_info and perhaps m_info
* For each DL 1-99:
* Generate the level
* Dump to file all of the monsters generated
* Kill all the monsters
* Dump to file all of the objects generated, including origin depth and source

I will also supply a sample (extensible) perl script to run this test N times and take various statistics on the output. The combination of the changes and the perl script should be easily portable to older versions of V (and probably variants as well). My primary goal is to measure how randart and standart distribution (how many, source of drops, etc.) have changed over time, but I'll also take requests for other measurements. Magnate asked for number and average number of levels OOD for OOD artifacts. I'll have something for speed rings, at least max pval. All of the data from fizzix's first post will be available in the raw dumps, except that there's no code to differentiate pits and nests from regular rooms.

fizzix
November 2, 2010, 21:16
I will also supply a sample (extensible) perl script to run this test N times and take various statistics on the output. The combination of the changes and the perl script should be easily portable to older versions of V (and probably variants as well). My primary goal is to measure how randart and standart distribution (how many, source of drops, etc.) have changed over time, but I'll also take requests for other measurements. Magnate asked for number and average number of levels OOD for OOD artifacts. I'll have something for speed rings, at least max pval. All of the data from fizzix's first post will be available in the raw dumps, except that there's no code to differentiate pits and nests from regular rooms.

Cool. After you get it online, I'll look into adding differentiation from pits/nests. I think these are necessary as I get a very large amount of consumables and artifacts from pits.

myshkin
November 2, 2010, 22:15
Cool. After you get it online, I'll look into adding differentiation from pits/nests. I think these are necessary as I get a very large amount of consumables and artifacts from pits.

The tricky thing is that the cave_info array has a flag for vaults (CAVE_ICKY), but not for actual room type. I didn't want to mess with this data structure to avoid any portability headaches, but it shouldn't be too hard to record room type somewhere.

fizzix
November 2, 2010, 22:29
The tricky thing is that the cave_info array has a flag for vaults (CAVE_ICKY), but not for actual room type. I didn't want to mess with this data structure to avoid any portability headaches, but it shouldn't be too hard to record room type somewhere.

I agree, the easiest way to do that is to modify the structure. This would not affect gameplay in any way but would greatly help diagnosis, so it might be easy to get into V.

If you don't modify it, it gets harder. There is a 'crowded' flag that dictates whether a pit or nest exists somewhere on the level. Finding it on the level might be possible if a bit difficult.

Sirridan
November 3, 2010, 13:33
There are a few denizens of #angband-dev who don't post on oook, and it would be good to optimise the use of people's time. I'm still a bit sad that PyAngband went ahead and developed a new text file syntax, when someone already did that ... but now we have github, these links should be easier to make.

Can you link me the new style syntax? I'm using what I have now as a stop-gap, I find it a big pain in the tochas to write, but it works for now. (Plus no parser to write since it's just basically python code).

fizzix
December 10, 2010, 04:15
I got a preliminary monte carlo version up. So far all it does is scan the floor and count the gold, artifacts and ego_items. Outputs go to stats.log in the user file. It is activated by the debug command "_"

I'll add more functionality with time.

(outputs from standart and randart sims are attached, I used 1000 simulations on each level)

Estie
December 10, 2010, 12:08
Not sure if it matters for the purpose, but I assume deeper level artifacts dont take into account the possibility that a given artifact might have been found before and thus be unavailable ?

fizzix
December 10, 2010, 14:58
Not sure if it matters for the purpose, but I assume deeper level artifacts dont take into account the possibility that a given artifact might have been found before and thus be unavailable ?

It definitely does matter, but rather than worry about handling that the plan is to add more granularity into the artifact printout. This is more of a proof of principle than anything else. A test to see how fast the sim runs, and whether I am capable of coding up the full thing. Looks like it's fast enough for sure, and I might be ok on the second as well. (I feel like I really suck at coding in C...)

Here's the path I'll take, probably later today or tonight:
First, I'll separate special artifacts from artifact equipment. Special artifacts have a different generation path, and are more likely to suffer from the 'not found before' effect

Then, I'll separate other artifacts into aritfacts that are 25 levels above depth and shallower. Artifacts that are between 25 levels above and 1 level below. And artifacts that are deeper than 1 level below.

I could also add granularity between weapons and armor, but I'm not sure this is needed.

After that, I have to get drops from monsters, but this is a slightly more difficult problem.

camlost
December 10, 2010, 16:42
It definitely does matter, but rather than worry about handling that the plan is to add more granularity into the artifact printout. This is more of a proof of principle than anything else. A test to see how fast the sim runs, and whether I am capable of coding up the full thing. Looks like it's fast enough for sure, and I might be ok on the second as well. (I feel like I really suck at coding in C...)

Here's the path I'll take, probably later today or tonight:
First, I'll separate special artifacts from artifact equipment. Special artifacts have a different generation path, and are more likely to suffer from the 'not found before' effect

Then, I'll separate other artifacts into aritfacts that are 25 levels above depth and shallower. Artifacts that are between 25 levels above and 1 level below. And artifacts that are deeper than 1 level below.

I could also add granularity between weapons and armor, but I'm not sure this is needed.

After that, I have to get drops from monsters, but this is a slightly more difficult problem.

I assume that you're doing this as a wizard command, so why not just call mon_take_hit with a lot of damage through the monster list a few times before you do your calcs?

fizzix
December 10, 2010, 17:05
I assume that you're doing this as a wizard command, so why not just call mon_take_hit with a lot of damage through the monster list a few times before you do your calcs?

I want to distinguish where the items come from. Specifically, I want to know if they come from monsters, uniques or the ground. So I need something a little more advanced than that.

Derakon
December 10, 2010, 17:45
Don't items remember their provenance, though? I.e. if I kill Maggot and get a magic dagger from him, when I 'I'nspect the item it should say "Dropped by Farmer Maggot at dungeon level 0" or words to that effect.

Or is that just one of those features that was added in every variant but not Vanilla yet?

Timo Pietilä
December 10, 2010, 18:06
Don't items remember their provenance, though? I.e. if I kill Maggot and get a magic dagger from him, when I 'I'nspect the item it should say "Dropped by Farmer Maggot at dungeon level 0" or words to that effect.

Or is that just one of those features that was added in every variant but not Vanilla yet?

That feature is in vanilla. Don't remember which version added that, but it is rather recent addition. Something like 3.1.0 or so.

fizzix
December 10, 2010, 18:08
Don't items remember their provenance, though? I.e. if I kill Maggot and get a magic dagger from him, when I 'I'nspect the item it should say "Dropped by Farmer Maggot at dungeon level 0" or words to that effect.

Or is that just one of those features that was added in every variant but not Vanilla yet?

it's in vanilla. but extracting that information seems harder than what i'm planning to do. Since that only gets written if the monster is visible when it dies, so I'd have to figure out how to override that. Then I'd have to back out that Farmer Maggot was a unique. Forget about figuring out if the monster that dropped it was generated in a vault.

I think it's easier to get info on the monster, calculate its drop and then generate those items locally (don't even allocate them) and log them. There's some code to do this that I came across, and I may poach that.

Derakon
December 10, 2010, 18:22
Detect entire level (thus forcing all monsters to be visible).
Hit monster.
Add modification to provenance information to include if monster was standing in a vault square when killed.

If provenance information is stored as a string, you can run a script afterwards to reverse-lookup monster names against the uniques list (assuming you care about the distinction between unique drops and normal drops). If it's stored as symbolic information (i.e. monster #54 at dlvl 20) then you can look up the monster info by its index and check if it's unique that way.

camlost
December 10, 2010, 18:55
Well, I figured that you'd just do a pass of object counting on the ground, delete the objects there, then kill each monster and do it again. I guess there's no reason you couldn't filter out uniques on the first monster pass and hit them on a later pass instead.

PowerDiver
December 10, 2010, 19:08
I'm thinking of putting all totals into longs (can I use floats?)

There's nothing wrong with using floating point, but always use doubles instead of floats.

Derakon
December 10, 2010, 19:18
2^64 gets you about eighteen quintillion, so I don't think floating point is really necessary compared to unsigned long. Even signed long is nine quintillion. Just how many times were you planning to run this simulation? A very conservative guess would still have a single character finding less than a hundred thousand items in their lifetime, which would let you run the simulation trillions of times before running out of room.

(NB this is using the American "short scale", million = 10^6, billion = 10^9, etc)

Magnate
December 10, 2010, 19:22
Don't items remember their provenance, though? I.e. if I kill Maggot and get a magic dagger from him, when I 'I'nspect the item it should say "Dropped by Farmer Maggot at dungeon level 0" or words to that effect.

Or is that just one of those features that was added in every variant but not Vanilla yet?It's in V, the ORIGIN_FOO codes.

fizzix - what's behind your choice of -25/>+1 levels for artifacts? The latter in particular makes little sense: +1 level OOD is roughly the same likelihood as +2 and a whole lot different from +0. I'd suggest:

More than 25 levels shallower

25 to 1 level shallower

At depth

1 to 10 levels deeper

More than 10 levels deeper

... if you don't fancy that much granularity, combine the 2nd/3rd and the 4th/5th

PowerDiver
December 10, 2010, 20:22
2^64 gets you about eighteen quintillion, so I don't think floating point is really necessary compared to unsigned long

It has nothing to do with necessary. Longs have more bits of precision than doubles, if you are worrying about necessary. It's just simpler, particularly if you do division and do not want to worry about casting to avoid truncation. If you are going to be calculating standard deviations etc it is downright bizaare to avoid floating point.

It's not the 1970s. There's nothing wrong with using floating point.

RogerN
December 10, 2010, 21:18
There's nothing wrong with using floating point, but always use doubles instead of floats.

Seconded. This is especially important when working primarily with addition and subtraction (ie adding up lots of numbers from a monte carlo simulation). If you're only using multiplication and division then you can frequently get away with less precision.

At single precision you've only got 23 bits of mantissa to work with, which doesn't get you very far.

fizzix
December 11, 2010, 18:17
I took camlost's suggestion of killing the monsters and picking up their items. It seems to work and the numbers are adding up properly. Some amount (1-2 at deeper levels) of items get killed because of insufficient drop room. This probably occurs more often with monsters in vaults. Either way, I've decided not to worry about these lost items even though you possibly lose some good items.

(another possibility is to remove all the traps in each level. I think I'll do that. Cataloguing traps is dumb anyway)

Time to sim still looks reasonable on my computer, but it might be rough on slower computers.

I'll try to have a semi-complete version up on git later today or tomorrow.

fizzix
December 12, 2010, 17:29
Finished up potion generation. And cleaned up the output a bit so it's more readable. 1000 sims doing 20 levels (20k total levels) takes less than 2 minutes on my laptop, and it's unlikely to get much slower. No swag gets deleted on drops anymore.

Going to finish up consumables, and then do work on the egos, hopefully be done by the end of the day. (Ego and gold counts are mislabeled currently)

buzzkill
December 12, 2010, 17:46
That's cool but hard to read. The text cleanup will be nice. A quick glance, confirms what I've always thought. A vast majority of artifacts are dropped by everyday-in-depth-monsters, not uniques, not vaults.

Derakon
December 12, 2010, 18:26
Which is to be expected, frankly; the main bonus that uniques have to their drops is that they bypass the roll to see if the item is good (i.e. they can't drop average or cursed gear), which happens more or less automatically by 1000' or so anyway. Otherwise, they're vastly outnumbered by the normal monsters.

fizzix
December 12, 2010, 20:14
That's cool but hard to read. The text cleanup will be nice. A quick glance, confirms what I've always thought. A vast majority of artifacts are dropped by everyday-in-depth-monsters, not uniques, not vaults.

the monster total includes unique drops as well. However, the unique total *may* be inflated since each time a level is generated, no uniques have been killed yet. Something that's not true in an actual game. I have no way of getting around this.

Magnate
December 12, 2010, 20:52
the monster total includes unique drops as well. However, the unique total *may* be inflated since each time a level is generated, no uniques have been killed yet. Something that's not true in an actual game. I have no way of getting around this.Instead of generating individual levels, why not generate a whole dungeon, levels 1-100? Then if a unique is killed at level 23, it can't be generated again later.

Without wishing to oversimplify things, is it much more than a 1-100 loop over the individual level generation?

Estie
December 12, 2010, 21:39
Instead of generating individual levels, why not generate a whole dungeon, levels 1-100? Then if a unique is killed at level 23, it can't be generated again later.

Without wishing to oversimplify things, is it much more than a 1-100 loop over the individual level generation?

And while youre at it, if an artifact has been dropped at level 23, it can't be generated again later. :D

fizzix
December 13, 2010, 01:29
I'll think about how to do a 1-100 simulation result. In the meantime, I have a fairly completed version up on git. I ran a 5000 iterations per level sim (takes about 5 minutes) for a standarts case, and the results are included here.

Everything is in expected value/level.

My sim found the one ring 0.92% of the time at dlevel 100 and at no shallower levels.

fizzix
December 13, 2010, 17:33
Hmm, it seems a messed up the gold, and forgot to include prayer/spell books. I guess there's still some more work to be done.

@magnate: I thought about your cycling through the levels, an I think I can implement it with some (relatively) minor changes. There are two possibilities:

1: change all the data storage elements to arrays (there are a lot of them)
2: Open and rewrite the log file. (is this slow? requires some code that I'm not sure how to do...yet)

Both also need stuff to keep artifacts lost and uniques dead (easy) and a reset of all the artifacts to available when we go back to dlevel 1 (probably easy?)

I'm leaning towards approach 2...but with either approach I don't think I'll get to it this week... (I will try to fix the gold problem and add spell books though.)

edit: fixed gold and added books during lunch break. Included a new randart sim.

Magnate
December 13, 2010, 21:34
Hmm, it seems a messed up the gold, and forgot to include prayer/spell books. I guess there's still some more work to be done.

@magnate: I thought about your cycling through the levels, an I think I can implement it with some (relatively) minor changes. There are two possibilities:

1: change all the data storage elements to arrays (there are a lot of them)
2: Open and rewrite the log file. (is this slow? requires some code that I'm not sure how to do...yet)

Both also need stuff to keep artifacts lost and uniques dead (easy) and a reset of all the artifacts to available when we go back to dlevel 1 (probably easy?)

I'm leaning towards approach 2...but with either approach I don't think I'll get to it this week... (I will try to fix the gold problem and add spell books though.)

edit: fixed gold and added books during lunch break. Included a new randart sim.Cool. I would seriously recommend #1 over #2 - 100-element arrays are easy to deal with and far quicker than opening and closing files. Yes, artifact tracking is easy: use a_ptr->created, and just cycle through the artifacts setting it back to 0 between each sim.

fizzix
December 15, 2010, 05:33
Cool. I would seriously recommend #1 over #2 - 100-element arrays are easy to deal with and far quicker than opening and closing files. Yes, artifact tracking is easy: use a_ptr->created, and just cycle through the artifacts setting it back to 0 between each sim.

Finished.

Unfortunately, the output file now has 100 levels instead of one and I cannot attach it here because of size constraints.

I'll write some basic post-processing routines soon. Probably tomorrow, too tired tonight... I actually planned to *play* some angband...that sure didn't happen.

fizzix
December 15, 2010, 20:37
btw 1000 iterations without randart regenning takes 4 minutes and 45 seconds on my laptop.

fizzix
December 15, 2010, 22:10
added an option to regen randarts after each sim. I truly didn't trust Magnate that it was going to be as slow as it is. Damn.

50 iterations took 15 s without randart regen and 285 seconds with randart regen. That's almost 20 times longer!

Also fixed a couple bugs and pushed to git. Probably won't be doing any serious work on this for a while. Although I don't consider tracking new items to be serious work. That can be done in about 2-3 minutes.

fizzix
December 16, 2010, 03:09
Similar to what I posted in the stat-swap thread. Here are the same results for various other resists. (assuming standart set) I can generate this fairly easily for any other res/ability/effect anyone might be curious about.

fizzix
December 16, 2010, 03:27
More stats:

For a standart game, clearing each level once yields a total artifact count of approximately 70.

For randarts, the amount seems to be around 60 or 61. So it looks like standarts are about 16% more common than randarts.

ewert
December 16, 2010, 08:38
I think that is well within range of being caused by standarts being a spread out artifact type list (most base types have an artifact, increasing chances), and randarts can have "blanks" in base types.

PowerDiver
December 16, 2010, 09:34
I think that is well within range of being caused by standarts being a spread out artifact type list (most base types have an artifact, increasing chances), and randarts can have "blanks" in base types.

That's a second order effect. I doubt it is noticeable. The way to think of it is to assume you pick the base, and then ask for the probability that after you create one artifact, if you tried again the very next try would produce the other one. Even if there are 20 more such pairs in randarts vs standarts, unless the chances to produce the randarts are over 1/20 on a single try [which seems excessive] that still comes to less than 1 a game on average.

You guys complaining about too many randarts before the last change may have forgotten how many standarts are typically produced.

fizzix
December 16, 2010, 15:13
I think that is well within range of being caused by standarts being a spread out artifact type list (most base types have an artifact, increasing chances), and randarts can have "blanks" in base types.

I'm not sure the reasoning, or whether it needs "fixing". It is what it is though. The counts seem pretty steady, I'm guessing a standard deviation of less than 5. I may work on actually calculating a std dev later, both for the artifact counts, and for the first level that objects occur on.

Probably won't get to this today though. Sorry d_m.

ewert
December 16, 2010, 19:42
That's a second order effect. I doubt it is noticeable. The way to think of it is to assume you pick the base, and then ask for the probability that after you create one artifact, if you tried again the very next try would produce the other one. Even if there are 20 more such pairs in randarts vs standarts, unless the chances to produce the randarts are over 1/20 on a single try [which seems excessive] that still comes to less than 1 a game on average.

You guys complaining about too many randarts before the last change may have forgotten how many standarts are typically produced.
Okay talking probabilities and statistics in a foreign language gets hard, but I think we are talking slightly different here.

If we have 20 base types, of which all have 1 artifact, and game creates x number of each base type (approximately), then compare to 20 base types of which 10 have two artifacts ... I think need to check up on the artifact creation code, if it is like I recall: "item good, check for artifact chance, pass, check to see if available artifact, check to pass artifact creation roll", then there would definitely be a noticeable difference in the 10x2 case versus 20x1. Since the x2 creates no extra chance for artifact creation until an artifact of that base type has been created, but the "blank" base types halve artifact creation chance from the get-go ...

Depends on code, that is what I am saying. If the code is like I recall, then a quickie thought process about the probabilities gives me a result of "yes it could make a noticeable difference".

PowerDiver
December 16, 2010, 20:46
What I wrote was pretty accurate. Another thing you are missing is the number of standart daggers and gauntlets. The most important term is the number of pairs of artifacts with the same base item, which is quadratic in artifacts per base item. It would not be shocking to me if the effect is in the direction opposite to what you are expecting.

Estie
December 16, 2010, 20:52
...
You guys complaining about too many randarts before the last change may have forgotten how many standarts are typically produced.

That is very likely, given that my last standart game was back in...well, some version before 1.3.x

My "complaint" was based purely on what I felt while playing to be too much. Too many items turning out to be artifacts diminishes the special feeling (hah!), too few and the game becomes a grindy drag. I am aware that this is highly subjective.

If equivalence of standart and randart game is wanted, then, assuming the property algorithm is balanced, fizzix´s numbers must be brought to match. Any conjectures about item types affecting generation chance are moot: the guy who finds 60 artifacts is worse off than the one who finds 70. Noticably so.

fizzix
December 16, 2010, 22:02
If equivalence of standart and randart game is wanted.

This is a big if. Consider the following possibilities.

1. randarts are considered a challenge option at birth. You have an unknown set of artifacts, and you are slightly less likely to find them.

2. to equalize difficulties, randarts need to be slightly more common than standarts. Because randarts are unbalanced, you may need more of them to come up with a suitable endgame kit.

3. to equalize difficulties, randarts need to be less common. This is because you are more likely to find a very powerful randart in the early-middle game than in a standart game. (again due to the lack of balance.)

I have no opinions anymore on which of the three is accurate, true, or should be aimed for.

Derakon
December 16, 2010, 22:42
I think it's reasonable to want to get a similar number of randarts as standarts in a given game. However, it's also reasonable to want a challenge game where artifacts as a whole are less common, though not eliminated outright. Basically, a slider that ranges from 0 (no artifacts) to 5 (standard distribution) to 10 (artifacts are very common).

ewert
December 16, 2010, 22:54
What I wrote was pretty accurate. Another thing you are missing is the number of standart daggers and gauntlets. The most important term is the number of pairs of artifacts with the same base item, which is quadratic in artifacts per base item. It would not be shocking to me if the effect is in the direction opposite to what you are expecting.
God I can talk medical English, but math English is ... gah. =P

I'll grant you the daggers, but still isn't there like atleast one artifact of almost each base type in standarts? I guess the first issue would be to define the spread of artifacts in standart vs. the probabilities of # of "blanks" in random sets. The artifact number is low enough that it won't get balanced well enough compared to the manually assigned standart set, as far as I would hazard a guess. Meaning I'd haphazard a guess that randart sets have much more blank "base" spots on average.

Anyways, a more even spread of artifacts per base items would result in an average higher total amount of artifacts found in a collection of enough samples of "gamesims", I can't really see how on earth one could get to the opposite resolution in any math based view of the issue ... Granted, haven't done high math in a dozen years or so really. :P But still.

PS. Is the sim removing a found artifact from further "finds"? I think I read earlier in the thread something about that not being done yet in the sim at that point.

PowerDiver
December 16, 2010, 23:16
I think you are missing something basic. Suppose you have two artifacts and two base types. Say each base type is 50% and each artifact has rarity 10%. Then if both artifacts are in the same slot, you have a 50% chance to choose that slot, then whatever chance to decide to try for an artifact [depending on DROP_GOOD etc], then a 19% chance to generate an artifact [.1 + .1 - .1*.1 since each possible matching artifact type is checked until one matches]. If one artifact of each base type, whatever chance for artifact, then a 10% chance. So you are comparing proportionally 9.5% to 10.0% until one is created. After one is created, the time to generate the second artifact would be the same in either scenario.

fizzix
December 17, 2010, 02:46
PS. Is the sim removing a found artifact from further "finds"? I think I read earlier in the thread something about that not being done yet in the sim at that point.

Yes, it does this now. There are currently two supported modes, that I've termed Diving and Clearing. Diving mode starts each level assuming no artifacts are found and no uniques are killed. This was the first sim I made, and is what you are referring to. Clearing mode assumes the player clears every level, killing all uniques and picking up all items. (yet no monsters are spawned or summoned) Killed uniques stay dead, and found artifacts are removed from the set. The player clears all 100 levels, then the artifacts are 'uncreated' and the uniques are 'revived' and the sim starts again at level 0. The artifact totals are provided from Clearing sims.

Diving mode is accurate for levels < 50 for a fairly adept player that will kill few uniques and discover few artifacts. After level 50, it more often does stupid things like create the phial several times per level, so is less trustworthy in this region. Clearing mode should be fairly accurate for newer players who progress slower for lack of knowledge, and play styles that spend more time on levels.

Of course, if anyone has more suggestions over features to add, I'll be glad to put them in. The next thing I will do is get standard deviations on the number of artifacts you find, and the levels that you are first likely to find certain items.

ewert
December 17, 2010, 08:02
I think you are missing something basic. Suppose you have two artifacts and two base types. Say each base type is 50% and each artifact has rarity 10%. Then if both artifacts are in the same slot, you have a 50% chance to choose that slot, then whatever chance to decide to try for an artifact [depending on DROP_GOOD etc], then a 19% chance to generate an artifact [.1 + .1 - .1*.1 since each possible matching artifact type is checked until one matches]. If one artifact of each base type, whatever chance for artifact, then a 10% chance. So you are comparing proportionally 9.5% to 10.0% until one is created. After one is created, the time to generate the second artifact would be the same in either scenario.
Will have to check the creation code, since I am working on the assumption (yeayea ;)) that it is not a cumulative or multiplive chance to go from base to artifact based on how many artifacts are in that base, but just _a_ chance to go from base to _an_ artifact.

Thus no matter how many artifacts of the base item exist, there is no extra chance increases to start the artifact creation process. Thus double/triple/multiple "slotted" artifacts reduce the overall artifact creation rate compared to an even spread.

Of course if multiple base item artifacts increase the chance to go from non-artifact to artifact-testing, then it is a near-moot point. As I said in one of the earlier posts, we ARE talking of slightly different things. :) Need to check the code itself for this.

ewert
December 17, 2010, 08:08
I think you could add a "farming" option, that clears dlvl 98 for x times, where x could be set somewhere. I know I like to farm some at the end. Would give some info on that too, so the rare items can be balanced (like the superrare rods etc., so people could realistically get them if patient in the deep end).

fizzix
December 17, 2010, 16:14
I think you could add a "farming" option, that clears dlvl 98 for x times, where x could be set somewhere. I know I like to farm some at the end. Would give some info on that too, so the rare items can be balanced (like the superrare rods etc., so people could realistically get them if patient in the deep end).

Endgame consumables and ego items do not vary to any significant quantity based on how many ego items/uniques are left. So if you want to know what your endgame consumables are like on dlevel 99, I can already give you that info with reasonable accuracy.

you have roughly an 18% chance of finding a rod of speed/healing. And a 8.6% chance if you limit yourself to non-monster drop, non-vaulted items.

You will on average find 0.81 !life or !*healing* but ~2/3 of those are from monster drops. Similarly, you will find on average 5.1 stat gain potions (not including !Chr, !Aug counts as 5 potions) about 70% of which come from monsters and 15% are found in vaults.

ewert
December 17, 2010, 19:58
Endgame consumables and ego items do not vary to any significant quantity based on how many ego items/uniques are left. So if you want to know what your endgame consumables are like on dlevel 99, I can already give you that info with reasonable accuracy.

you have roughly an 18% chance of finding a rod of speed/healing. And a 8.6% chance if you limit yourself to non-monster drop, non-vaulted items.

You will on average find 0.81 !life or !*healing* but ~2/3 of those are from monster drops. Similarly, you will find on average 5.1 stat gain potions (not including !Chr, !Aug counts as 5 potions) about 70% of which come from monsters and 15% are found in vaults.
Thats a 0-99 clear though? I'd be more interested in the chances of high end stuff from clearing a dlvl98. Since I can't see how one could have an 18% chance to find rod of speed/healing in a single level clear ... I'd be swimming in those with most of my chars with such chances. =P

d_m
December 17, 2010, 20:16
Thats a 0-99 clear though? I'd be more interested in the chances of high end stuff from clearing a dlvl98. Since I can't see how one could have an 18% chance to find rod of speed/healing in a single level clear ... I'd be swimming in those with most of my chars with such chances. =P

I think it assumes you kill all monsters generated. Do you completely clear dungeon level 98 a lot? ;) (without banishment, *destruction*, etc)

fizzix
December 17, 2010, 20:55
Thats a 0-99 clear though? I'd be more interested in the chances of high end stuff from clearing a dlvl98. Since I can't see how one could have an 18% chance to find rod of speed/healing in a single level clear ... I'd be swimming in those with most of my chars with such chances. =P

no, the stats I cited were *only* for dlevel 99.

fizzix
December 17, 2010, 20:57
Here are some results with the mean and standard deviation for the first level you are likely to find equipment with specific resists (assuming standarts) along with the mean and standard dev for artifact total counts.

randarts to come. After discussion with Magnate, there are some errors with how I'm been generating randarts.

Magnate
December 17, 2010, 21:34
I think it's reasonable to want to get a similar number of randarts as standarts in a given game. However, it's also reasonable to want a challenge game where artifacts as a whole are less common, though not eliminated outright. Basically, a slider that ranges from 0 (no artifacts) to 5 (standard distribution) to 10 (artifacts are very common).I think people may be underestimating the difficulty of tuning any kind of drops to that sort of granularity. Personally I am stunned that fizzix's figures show randart drop numbers to be within 15% of standarts. I suspect that before the last change the error was in the region of 50% (the other way), and before that probably also somewhere between 25-50%. That's a swing of roughly 100% with each change.

I do plan on using the stats to improve balance in various areas, but I'm not going to lose any sleep over whether a statistically average randart game produces ten more or ten fewer artifacts than a standart game. There are way too many more important things to think about (like what the artifacts are actually like, and whether egos and consumables are dropping in roughly the correct relative amounts etc.).

Derakon
December 17, 2010, 22:29
I wasn't suggesting worrying about the tuning of randarts vs. standarts; just adding detail to the "should I generate an artifact" check that makes it harder/easier depending on a user-defined value. I agree that randarts and standarts are likely to have different overall rarities, but as long as they're in the same ballpark I wouldn't worry overmuch.

Magnate
December 17, 2010, 22:52
I wasn't suggesting worrying about the tuning of randarts vs. standarts; just adding detail to the "should I generate an artifact" check that makes it harder/easier depending on a user-defined value. I agree that randarts and standarts are likely to have different overall rarities, but as long as they're in the same ballpark I wouldn't worry overmuch.My sense is that if takk were to introduce a "difficulty" rating, it wouldn't be related to artifact generation (there is already a binary no_artifacts option). I think it would be more likely along the lines of higher monster hp and/or slower xp gain.

ewert
December 17, 2010, 23:11
I think it assumes you kill all monsters generated. Do you completely clear dungeon level 98 a lot? ;) (without banishment, *destruction*, etc)
Well no, but hitting pits and vaults accounts for a big part of the level ... and I sometimes do erm, dozens of 98ish dlvl pits/vaults. =P

fizzix
December 23, 2010, 02:56
Haven't gotten randarts to work properly yet. But in the meantime here are statistics on magic books. Magic books and prayer books have exactly the same allocation probabilities so you can use one as a proxy for the other.

Here are the mean and standard dev for the first level you find each of the magic books by level clearing each level once:


mb1 mean: 9.650000 std-dev: 5.396990
mb2 mean: 15.990000 std-dev: 6.144095
mb3 mean: 25.660000 std-dev: 6.392527
mb4 mean: 34.460000 std-dev: 5.261977
mb5 mean: 41.490000 std-dev: 8.368387
mb6 mean: 48.950000 std-dev: 9.957284
mb7 mean: 54.400000 std-dev: 9.866104
mb8 mean: 60.550000 std-dev: 10.674619
mb9 mean: 71.200000 std-dev: 13.203030


one of the things borne out in the sims is that dungeon books become too common (IMO) deep and town books are not common enough early.

PowerDiver
December 23, 2010, 03:23
Here are the mean and standard dev for the first level you find each of the magic books by level clearing each level once:

For the purpose of discussing selling vs non-selling, I'd be interested in the number of dungeon spellbooks produced. I don't know if I'd even want to look at all of the data level by level, so per game would be good enough to start.

fizzix
December 23, 2010, 03:37
For the purpose of discussing selling vs non-selling, I'd be interested in the number of dungeon spellbooks produced. I don't know if I'd even want to look at all of the data level by level, so per game would be good enough to start.

This is trivially easy to do, gimme a sec.

edit: here they are. Std devs would take me a tad longer to write, but I could do it if you want.

mb5: 33.600000
mb6: 29.685000
mb7: 25.750000
mb8: 19.075000
mb9: 10.200000

ewert
December 23, 2010, 08:30
This is trivially easy to do, gimme a sec.

edit: here they are. Std devs would take me a tad longer to write, but I could do it if you want.

mb5: 33.600000
mb6: 29.685000
mb7: 25.750000
mb8: 19.075000
mb9: 10.200000
Comparing to my recent Duhmage with unlimited home, with all uniques killed, a little bit but not much of dlvl 98 pit/vault hunting, I ended up in home roughly 1/2 - 1/3 of those amounts due to autopickup and compulsive "run over items" reflexes. Just a FYI, I think it gives a little bit of informative value, that a full clear of each lvl is maybe around 50% more stuff atleast than for example my "icings first" playstyle.

Good to know atleast for me personally, so I know how much I miss out. :)

PowerDiver
December 23, 2010, 10:18
This is trivially easy to do, gimme a sec.

edit: here they are. Std devs would take me a tad longer to write, but I could do it if you want.

mb5: 33.600000
mb6: 29.685000
mb7: 25.750000
mb8: 19.075000
mb9: 10.200000

Thanks. For a mage, those get picked up without thought and don't even cost a slot. If we assume a max of 25K at the store, that's roughly 320K + 560K + 1250K is over 2M. I don't see any point in worrying about late game effects of a gold multiplier when there is that much free money floating about.