This table shows the number of combined Google hits for "X for Y developers" and "X for Y programmers", with a selection of Xs and Ys (e.g., the first rows shows the hits for "BASIC for BASIC developers", "BASIC for C++ developers", etc.):

It looks like we're missing a good "Cobol for BASIC programmers" book: I'll start typing right away!

Note that the matrix is highly asymmetric: apparently, Perl programmers are more interested to switch to Python than vice versa. We can turn the entries of the matrix into weights in a directed graph, that can be loosely interpreted as the relative number of people that would like to switch from a programming language to another. Below you can see the graphs for six of the languages (the size of the arrows correspond to one of 6 bins of equal size on a logarithmic scale; no arrow means zero results):

In case you were wondering: yes, there really is a successful "Java for Cobol programmers" book!

Update 1 Apr 2012: Added values for Fortran to the table.

In my opinion, an important but neglected goal of ALife should be that of identifying a minimal set of conditions that is able to sustain this stronger kind of open-ended evolution.

What would it take for an artificial system to display "real" open-ended evolution? It is possible that there may be multiple answer to this question, but co-evolution of agents seems to be a good candidate. A minimal example might involve populations of agents trying to predict each other's output. The output of a population should be tied to the process of predicting the response of the others. To initiate a runaway evolution process, predicting a simple output should require a simple algorithm, which however would produce a slightly more complex output by the laws of the artificial world. In such a scenario, the fitness function is given by the combination of prediction algorithms in the population, and each evolutionary step changes it in a way that requires increasingly complex behaviors.

It's that time of the year again... the word spreads, I download it, and my nights fly by. It's time for the new Google AI Challenge: http://aichallenge.org/ ! This time we will be writing multi-agent systems, as we program cyber-ant-colonies fighting against each other for bread crumbs.

The colored dots are ants of different colonies. The black dots are obstacles. The barely visible brown-ish dots are food.

A screenshot of the game

Writing javascript is quite intuitive for a Python developer, even though I'm sure that there are many idioms and tricks that I did not know about (and the code I wrote is the stream-of-thought kind).  I'm somewhat disappointed as I thought javascript would be more standard across browsers, but there remain important differences, for example in the way Firefox and IE handle ranges in textarea.

I haven't tried the game on Safari or Opera, please let me know if it works!

I have been looking for a list of this kind of games, but could find very little information, often outdated. This is my own, annotated list; let me know if I missed something, and I'll make amend. I included only decently active projects:

Games for bots:

1. Robocode (Java, .NET): AI bots control tanks equipped with cannon and radar on an square arena. A game with a long tradition, descending from the classic AI games RobotWar (1981) and crobots (1985). This is a very active project, with tournaments organized regularly all over the world. The strategical possibilities are quite limited, though.
2. Tron challenge (any language): This is the first AI competition organized by the University of Waterloo Computer Science Club and sponsored by Google. The AIs control the "snakes" in a variant of the popular game Snake (or Nibbles, of QBasic fame) on a number of boards with symmetric walls. Although the competition is closed, the code is open source and perfectly usable. A nice game, but there seems to be one dominating strategy: using minimax. Entries in the competition differ in their cleverness in coming up with various approximations to prune down the huge tree of possible moves, and in handling the endgame.
3. Planet Wars challenge (any language): Second AI competition, again organized by the University of Waterloo CS Club. The inspiration is the galactic conquer game Galcon. Bots controls fleets of spaceships to control planets for resources. Unlike the first competition, the optimal strategy is far from obvious, and the game offers a lot of space for experimenting with different approaches. Not as visually fun as other games, though.
4. PacMan capture the flag (Python): The CS department at Berkeley offers a very popular Artificial Intelligence course that requires students to code up classical AI algorithms to control agents in a PacMan-like environment. The course concludes with a tournament in which PacMan agents compete to eat each other's dots. The game is extremely fun as I wrote about in previous posts. The code is available online (although somewhat messy). Unfortunately (but understandably, since the game is used in a course), the authors don't want the code of developed agents to leak online.
5. Grid-Soccer (Mono, .NET): This is a multi-agent soccer-like game played on a grid board. I haven't tried this one yet... According to the authors, it was originally conceived as a testbed for multi-agent reinforcement learning algorithms.

Scriptable games (games that expose an interface for external clients):

1. Starcraft Brood War (any language): This is your one chance at writing AI bots for a commercial game! Starcraft has been hacked to allow to control any aspect of the game through a user-written client (building construction, units movement, the full monty). Since 2010 there have been a few AI competitions open to the public (two of them still accepting entries!). Here's a video from last year's AIIDE tournament:

2. XBlast (potentially any): A free version of Bomberman. The game has not been used to develop AI agents... yet. It is built with a server-client architecture and it's begging to get bots running on it.

Example of an evolved car.

GAs tie the ability to solve a problem to the likelihood of reproduction of a set of parameters: first, one creates a population of possible solutions to a problem, evaluates the solutions, and then forms a new generation by allowing the most successful ones to pass their parameters to the next generation, after small mutations and parameters swapping.

My general feeling about GAs is that in most cases other optimization algorithms will give similar or better results with less evaluations of the fitness function (which is typically the bottleneck). In Chapter 30.2 of his classic book on information theory, David McKay gives a very interesting interpretation of GAs as a Monte Carlo sampling in the space of parameters, and discusses the relation with efficient sampling methods, of which we have a better formal understanding.

The prediction algorithm seems to be a simple Bayesian estimator like the one I implemented for the Karate A.I. game. The interesting twist is that in "Veteran mode" the AI will make use its interaction with previous users to define a prior over possible move sequences. It surely works against me...

The faculty line-up includes developers of well-known scientific libraries for Python (e.g., Francesc Alted of PyTables fame). The program covers advanced topics in numerical programming (advanced NumPy, Cython, parallel applications, data serialization, ...) and modern techniques for writing robust, efficient code (agile programming, test driven development, version control, optimization techniques, ...). Most of all, the school is a great opportunity to meet like-minded people and have fun writing Python code together! Participation is free of charge, and you can apply online.

You can see a few picture from previous summer schools on our Facebook group.

Summer school participants in Berlin, working hard on their PacMan agents.

For  the traditional faculty-vs-students tournament at the G-Node scientific programming summer school this year, I wrote a PacMan team made by a simple attacker, and a more sophisticated defender that tries to intercept and devour enemy agents.

Both agents plan their movements using a shortest-path algorithm on a weighted graph: before the start of the game, the maze is transformed in a graph, where nodes are the maze tiles, and edges connect adjacent tiles. Weights along the edges are adjusted according to the estimated position of the agents:

• Weights on edges close to an enemy ghost are increased (starting value is proportional to the probability of the enemy being there, and falls off exponentially with distance)
• Weights on edges close to an enemy PacMan are decreased
• Weights on edges close to a friendly agent are increased

An agent navigating on such a maze will tend to avoid ghosts, chase PacMen, and cover parts of the maze far from other friendly agents. My attacker does little else than updating the weights of the graph at every turn, and move toward the closest food dot.

On the other hand, defending is quite difficult in this game, so I needed a more sophisticated strategy. While the enemy is still a ghost in its own part of the maze, the defender moves toward the closest enemy agent (its estimated position, that is). When the enemy is a PacMan in the friendly half, the chase is on! Since ghosts and PacMen move at the same speed, it would be pointless to just follow it around, one needs to catch them from the front... Once more, the solution was to modify the weights of the maze graph, making weights behind the enemy (i.e., opposite to its direction of motion) very high, and lowering the edges in front of it.

The combination of estimator and the weighted graph strategy can be quite entertaining:

Sometimes the defender only needs to guard the border to scare the opponent shitless:

Another useful thing to keep in mind for the future: it is better to base strategies on soft constraints (weighted graphs, probabilities). Setting hard, deterministic rules tends to get you stuck in loops. Soft constraints and some randomness give you more flexibility when you need it but are otherwise just as good.

The game contains a deck of cards with symbols varying across 4 dimensions: color, number, shape, and texture. For each dimension, there are 3 possible features (e.g., there are 3 possible textures: full, empty, striped). A valid set is formed by three cards that have on each dimension either the same feature, or three different features. So for example in the image below, the first three cards are a valid set, as they are different on all features across all dimensions; the second three cards also form a valid set, because they share the same features for color and number, and are different in shape and texture; the cards on the bottom are not a set, because two cards have the "full" texture, while one is striped.

Example of valid (top) and invalid (bottom) sets.

In a Set game, 12 cards are put on the table, and the players have to find a valid set. The quickest among them collects the set and replaces the removed cards with new ones. If the players agree that there is no set on the table, 3 more cards are added. Once the deck is empty, the player who collected the most sets wins! Simple but fun...

I decided to write a solver for the game that finds all possible sets given a set of cards, with the goal of collecting statistics over thousands of games. The solver should thus be as efficient as I can manage to write it.

I'm going to represent each cards as a four-dimensional vector (color, shape, texture, number), each element containing either 0, 1, or 2 (representing the 3 possible values for each dimension). A function that checks if three cards form a valid set would thus look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import numpy

import itertools



def same(x):

    """Returns True if all elements are the same."""

    return numpy.all(x == x[0])



def different(x):

    """Returns True if all elements are different."""

    return len(numpy.unique(x)) == len(x)



def is_set(cards, indices):

    """Checks that the cards indexed by 'indices' form a valid set."""

    ndims = cards.shape[0]



    subset = cards[:, indices]

    for dim in range(ndims):

        # cards must be all the same or all different for all dimensions

        if not same(subset[dim, :]) and not different(subset[dim, :]):

            return False

    return True

1
2
3
4
5
def find_sets(cards):

    """Brute-force Sets solver."""

    return [indices

            for indices in itertools.combinations(range(cards.shape[1]), 3)

            if is_set(cards, indices)]

The brute force approach is very inefficient, but it is also very useful to test more efficient solutions (just check that they give the same response as the brute force one).

The second solver improves on the first one with a simple observation. Once you have two cards, there is only one possible card that completes the set: for each dimension, if the two cards have the same feature, the missing one will also have to have the same feature; if the features are different, the missing card will have to have the missing feature.

Given two cards, there is only one possible card that forms a valid set.

A possible strategy is thus to consider all possible pairs of cards, derive the one completing the set, and check if it is present on the table. This solution is much more efficient, as there are 220 possible triplets out of 12 cards, but only 66 pairs. It runs about 6 times faster:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
def find_sets2(cards):

    ndims, ncards = cards.shape

    all_features = set([0, 1, 2])



    # solutions contain the indices of the cards forming sets

    solutions = []

    # iterate over all pairs

    for idx1, idx2 in itertools.combinations(range(ncards - 1), 2):

        c1, c2 = cards[:, idx1], cards[:, idx2]



        # compute card that would complete the set

        missing = numpy.empty((ndims,), dtype='i')

        for d in range(ndims):

            if c1[d] == c2[d]:

                # same feature on this dimension ->; missing card also has same

                missing[d] = c1[d]

            else:

                # different features -> find third missing feature

                missing[d] = list(all_features - set([c1[d], c2[d]]))[0]



        # look for missing card in the cards array

        where_idx = numpy.flatnonzero(numpy.all(cards[:, idx2 + 1:].T == missing,

                                                axis=1))

        # append to solutions if found

        if len(where_idx) > 0:

            solutions.append((idx1, idx2, where_idx[0] + idx2 + 1))



    return solutions

The trained eye will see at this point that the problem can be re-written as a dynamic programming one. We can start looking at the first dimension, and form groups of cards with the same feature. We know by the reasoning above that valid sets will either contain cards in the same group, or contain one card from each group. First we consider the former case, and recursively apply the same procedure to all the remaining dimensions for cards within each group. Second, we consider all triplets of cards that have one card per group and verify if it's a set:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
def find_sets3(cards, indices=None):

    nd, n = cards.shape

    c0 = cards[0, :]

    if indices is None:

        indices = numpy.arange(n)



    groups = [(c0 == f).nonzero()[0] for f in range(nfeatures)]



    # equals

    solequal = []

    for g in groups:

        if len(g) < 3: continue

        solequal += find_sets3(cards[1:nd, g], indices[g])

    # different

    soldiff = [(indices[i0], indices[i1], indices[i2])

               for i0 in groups[0] for i1 in groups[1] for i2 in groups[2]

               if is_set(cards, (i0, i1, i2))]

    return solequal + soldiff

It turns out that, although it is a very efficient strategy to use while playing with cards, find_sets3 is slower than find_set2, probably because the overhead of calling the function recursively outweighs the efficiency for such a small number of cards.

Let's have a look at some statistics, then. While playing it can be quite frustrating to stare at the cards without being able to find any set. The instructions that ship with the official game say that such a situation should occur only once every 33 turns, but it certainly doesn't feel that way. Is that really so?

First, I drew at random 12 cards from a complete deck of cards, and used the solver to compute the number of valid sets present on the table. I repeated this 10000 times, and ended up with this distribution for the number of set in a random draw:

Probability of finding a given number of sets in 12 cards drawn at random.

As the instructions say, about 3% of the time (1 in 33) there is no set in the cards. However, this is misleading, as during a game the cards are not independently drawn each turn: the players remove one set from the cards on the table, and replace it with new cards. I thus simulated complete games, where at every turn I removed one of the set present on the table at random. The code to simulate a game look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
def random_deck():

    # initialize cards deck

    cards = numpy.array([card for card in itertools.product(range(nfeatures),

                                                            repeat=ndims)]).T

    n = cards.shape[1]

    # shuffle

    return cards[:, numpy.random.permutation(n)]



ncards = 12



def onegame():

    nsolutions = []

    deck = random_deck()

    pos = ncards

    cards = deck[:, :pos]

    while True:

        # find all sets

        sets = find_sets2(cards)

        nsets = len(sets)

        if nsets > 0:

            # choose a random set

            chosen = sets[numpy.random.randint(len(sets))]

            # remove cards from chosen set

            idx = [i for i in range(cards.shape[1]) if i not in chosen]

            cards = cards[:, idx]

            # add new cards

            if cards.shape[1] < 12:

                nadd = 12 - cards.shape[1]

                cards = numpy.concatenate((cards, deck[:, pos:pos + nadd]), axis=1)

                pos += nadd

        else:

            if pos >= deck.shape[1]:

                break # game is over

            # add additional cards

            cards = numpy.concatenate((cards, deck[:, pos:pos + 3]), axis=1)

            pos += 3

        nsolutions.append(nsets)

    return nsolutions

The distribution of the number of sets on the table at any point in time looks quite different now (after simulating 1000 5000 random games):

Probability of there being a given number of sets on the table at any point in a Set game.

As you see, the probability of there being no set on the table tripled and became about 1 in 10!  Now that's a relief, it is not that weird not to be able to find a set... or is it? The distribution also tells us that about half of the times there are 3 sets or more on the table! Now that one, I didn't expect... (43 percent of the times, to be precise.)

The code and other material is available on the git repository at http://github.com/pberkes/masterbaboon/tree/master/projects/setgame/ .

Update 09/21/10: I updated the histogram of number of sets during a game with more games, so that the result is more accurate. The probability of not having a set at any point is even higher than reported before.

Cards and game © 1988, 1991 Cannei, LLC.  All rights reserved.  SET® is registered trademark of Cannei, LLC.  Used with permission from Set Enterprises, Inc.