{ø} The Set of the Empty Set

I’m currently working on a discrete, finite probability library.  It’s progressing fairly well.  The only downside to the library, as I’m beginning to realize, is that most probabilities, even discrete ones, are not in a finite number of categories.

However, here’s some examples of what the library can do.

• All calculations are exact.
• You can model dice.  I wrote a dice function that rolls 2d6, 3d6, 1d4, 27d27, etc.  I also modeled a few systems I like (for instance Dungeons and Dragons’ 4-die ability roll).
• You can transform a function.  For instance, you can take a hero’s ability score in D&D, subtract 10, divide by 2, and round down to get the distribution of modifiers.
• You can combine distributions using a function.  For instance, given 2d6 and 3d4, you can find the distribution of 2d6+3d6.  More interestingly, you can find the distribution of those two combined using any function whatsoever (for instance, multiply and take the square root, to get the geometric mean).  If the function returns a distribution itself, this can let you do some tricky things like have distributions of distributions (which the library of course has a ‘compose’ function for if you didn’t want that).
• You can make a uniform distribution out of an arbitrary set of things, which is often a helpful starting point.  You can give the library a list of things and their probabilities, but since that’s how the library stores distributions, that’s a little boring for me.
• If the distribution is all numbers, you can get the mean, median, quartiles, a cumulative version of the distribution.
• You can make a random generator out of a distribution (for instance, given the d6 distribution, make a function that returns a random number 1-6 whenever called).
• You can plot numerical distributions (approximated by a polynomial, too.) and their cumulative versions along with boxplot stats.  This doesn’t return anything, it just dumps a bunch of pretty graphs and statistics.

This is my to-do list for the library:

• Standard distributions like the binomial distribution
• Standard deviation and variance
• Fix - the ‘window’ of the graph is determined by the points in the distribution.  It should also take into account the approximating polynomial, which can go off screen at present.
• Fix - the random number generators made my polynomials are almost certainly subject to rounding errors at present.  Change that.
• Add permutations, and the standard distributions of permutations
• The ultimate goal - a scheme macro, dist-random, which would do something like the following:

(dist (+ (dist-random 1 2 3) (dist-random 1 2 3)))

Which would return the distribution 2d3.  This would allow you to take a normal program that uses random generation, replace the random generators with dist-random, and wrap the whole thing in dist, and get back the distribution of outputs that program *would* have given is dist-random were actually a random number generator.  For instance, you could take a poker program that draws a hand of five cards and tells you what you got, and use this library to wrap it such that you just got a distribution of the hands in poker.  Remember too, that these are all exact probabilities.

If you have comments or suggestions, please contact me.  I’d especially like to hear anything you think I should add to the library.

After having deleted about 3000 comments over a few weeks, none from humans, I decided to add a CAPTCHA system to the blog.  For those unfamiliar with the name, these are systems wherein the system presents a word or two to the user as a distorted graphic, and the user types the word correctly.  They are designed to be solvable by users and not computers, but have the downside of being irritating to the user by slowing everything down, and sometimes so distorted that humans can’t easily solve them either.  For this blog, I decided on a system called reCAPTCHA, which uses actual scanned text from a central repository.  It has the neat benefit of simultaneously recognizing scanned text that scanners can’t read, i.e. for digitizing books, while providing insurance against spam.

On a happier note, the mysterious python project I mentioned earlier is close enough to finished that I’ll elaborate more now.  I have been working on a roguelike game.  Since it’s an unpopular genre, many readers may not have heard of it before.  In a roguelike, the player moves around an ascii character inside a tile-based map, fighting monsters and picking up treasure.  They’re essentially like old-style block-based RPG games set in a dungeon, except the whole thing’s overhead and in ASCII instead of fancy graphics.  For instance, a ‘$’ might represent a pile of gold, or an ‘r’ the ever-feared rat.

In my game, the player must delve into a dungeon, collect as much loot as possible, and leave–a typical goal.  It includes line-of-sight, twenty-something identical monsters of increasing power, a random dungeon generator, about eight unique items, a message system, color (provided with python’s curses), and three original game devices.  The only aspects of the game uncompleted are the highscore table, and game balancing issues.  (Right now it works as a program, but it’s not much fun to play.)  Documentation might be added at some point.  If you intend to play the game, I advise you skip the next paragraph where I spoil the hell out of it.  Or read it, depending on your play style.

The first element is a branching dungeon.  As the player descends, she travels through an inverted “tree” about six levels deep.  This isn’t completely random, to make other aspects of the game consistent between plays.  Each level of the dungeon has a random setup of nine rooms connected by corridors, all in a grid, as per the classic ‘Rogue’ which started the genre.  There are a guaranteed nine monsters and nine items per level, for consistency between sessions.  The second element is lava.  As the player explores the dungeon, she may discover that it is in fact a volcano about to erupt–and she had better get out of the way before it does!  This provides a built-in time limit, an interesting forced aspect to exploration, and the opportunity for me to have fun making the lava flow up and down branches in a fluidlike manner.  Lava flow rate, relative to the speed of the player, is one of the balance issues I am working on now.  Finally, the goals of the game are rather like a checklist.  First, getting out of the dungeon alive is a plus.  Second, getting more points by taking items and killing monsters than the lava consumes provides an interesting ultimate goal.  Third, there are special items in the dungeon the player can try to get before she leaves.  There is gem on each of the six levels of the dungeon.  Getting all six gives the player a reward.  Also, there is a magic scroll in a special level somewhere in the volcano.  This is especially difficult to bring to the surface.

In all, I tried to make a simple, but fun roguelike to play in half an hour to an hour.  I wanted it to be original enough to be interesting, but simple enough that I could write it and fairly casual players could discover everything about it.  Finally, I wanted to write a game I myself would find fun to play, which I believe I have.