For those interested in writing your own automata, here is a quick guide to the syntax:
An automaton is composed of rules. Each rule is designated by a new line. Double slash (//) or pound (#) designate a commented line.
Each rule looks something like BLACK->WHITE: 1 = 2
BLACK is the type of cell that the rule applies to, WHITE is the type of cell that it will become. After the colon is a statement that must resolve to a single value, or “noun”.
Nouns can be strings, numbers, true/false, JSON arrays, “neighbors”, or any of the cardinal directions (lower-case). The noun “neighbors” is a special noun which is a JSON array with values equal to the types of the surrounding tiles (in eight directions). The special nouns “west”, “north”, “south” and “east” are equal to the type in that direction, or “NULL” if at the edge.
Nouns can be acted upon by the following “verbs”:

• =, >, < — Basic comparison operators. They behave like their counterparts in javascript (except for =, which is comparison, not assignment). — example: “1 > 2 = false” (returns true)
• or, and — Low-priority logic operators. These behave like || and && in most languages. Low-priority means they are evaluated after other verbs. — example: “true and false or true” (returns true)
• not — Inverts the boolean value to the right. If the value to the right is non-boolean, it is cast to a boolean just like ! in javascript. — example: “not true” (returns false)
• contains, isIn — Check if a value is contained in an array. The two verbs are identical except in the order of their parameters (“value isIn array”, or “array contains value”). — example: “[1,2,3] contains 0″ (returns false)
• count — Changes the noun on the right from an array to an integer. — example: “count [0,1,2]” (returns 3)
• ofType — Filters an array on the left to only contain the value on the right. — example: “[0,0,0,1,2,3] ofType 0″ (returns [0,0,0])
• echo — Makes a popup containing the value on the right. Does not change the data. This verb isn’t very useful, and can flood your browser with popups if you aren’t careful.

Verbs are evaluated from left-to-right, but you can use parentheses to change the order of operations. More examples can be found by loading the prebuilt automata.

I know the interface is a bit hard to use, but if you make anything (even if it’s pretty trivial) please leave a comment! You can export boards as well, so feel free to share interesting formations in Conway’s Game of Life, Wireworld, or others.

On a related note, this talk by Wolfram is not to be missed:

Most of the class was thinking of making an obscenely huge strategy game akin to Risk meets Monopoly, which just so happens to be the sort of design which I despise. Having spent many long years learning the hard way to design as small as possible, I helped my team brainstorm a small, grid-based, strategy game based on resource management and simple unit-movement. My hope was that the project would be basic enough that it could be running with an initial rule-set within the week and that the remainder of the term could be devoted to polishing the interface/graphics and working on the rules. (I was only vaguely aware of it at the time, but this sort of thinking would expand into rapid-prototyping, playtest-heavy, and iterative design philosophies in my own work.)

We decided on a zombie theme, with the twist that the zombies were actually corporate pawns, and the necromancers were CEOs. It’s kinda vanilla, but it was a 1-hour design within a group of relative strangers. We presented our designs for the class and they decided to work on Risk-Monopoly. That weekend, in about 8 hours*, I built a working alpha for the game:

EDIT: If the images aren’t working, you may need to view this post by itself.

Rules:
The player on the left (pink/green) goes first. And then blue player takes a turn, and so on.
To move an army, drag them to an adjacent square. (They move like kings in chess.)
Armies are composed of undead: zombies, lawyers, or both.

Each space is commercial, residential or corporate (Starbucks, house or building). At the beginning of each turn, you get cash to buy lawyers with and new interns to turn into zombies. The goal of the game it to capture your opponent’s skyscraper. The income is as follows:
Corporate Space: +$5,000 & +5 interns / turn
Commercial Space +$2,000 / turn
Residential Space +2 interns / turn

Each turn you get one action (upper-right), in addition to moving each unit. Select a board space then chose:
PROMOTE: Turn all interns into zombies at the selected space.
HIRE: Hire lawyers for $5,000 each at the selected space.
DEVELOP: Selected commercial or residential space now produces 2N+2, where N = current production. (Units are single interns or thousands of dollars.) Each space can only be developed twice.

If you move into a space that has an enemy army, you deal damage to them, killing a number of units. If you defeat all units in a space, you capture it. An army with both lawyers and zombies loses its zombies first. Lawyers deal roughly 5x
more damage to zombies (I forget the actual multiplier).

It’s really a very boring game, but the idea is that it’s playable and (mostly) bug free. Additional rules and features can easily be added onto the skeleton in an attempt to make it more engaging. At the end of the week you’ll have a game, though, and you’ll have a good impression of roughly how fun it is. This last part is vital, I think, to good game design.
Rapid-prototyping lets me play a game with very little time investment. This lets me determine whether it is worth making.

* This amount of time is actually quite excessive for such a simple game. At the time I wasn’t using Slick, and I didn’t have much experience with applets.

Disclaimer: I do not own any of the graphics used in the game, but I feel that they are used fairly. Unlike most of my work, this game is not open source, and I ask that you do not redistribute it without permission. Its sole intent is to showcase what I did one weekend, and maybe talk a little about game-programming.