The game, shown on the left, is named “Dead End” and is written in Python. In it, the player controls a cat that needs to reach the exit (which, as I notice now, is not depicted in the picture, but it’s supposed to be an area in the top of the screen) to win. The opponents are a pack of dogs, which attempt to capture the cat, at which point the game ends. This, of course, is just a prototype intended to demonstrate how the game would work if it were really played, it is not intended to be fully robust or playable, but the aim is to make it “good enough” so that one can test it out with some real users at the end as a final dataset.

The game needs to exist both as a playable game and a simulation in the ADATE system, preferrably without having to rewrite any code. This would require a game “core” written in Standard ML, which is then called from the python code that handles the graphics and input system for the playable game. This would, ideally, make the game logic completely consistent between game and simulation, as anything related to how the characters move and behave is controlled by the shared Standard ML code. To me, this seems like the best way to go, unless it turns out that the game logic is sufficiently simple that writing the code to interface between python and Standard ML would actually end up being more work than maintaining two copies.

For the next week, my focus is going to be finishing up the game completely in Python, and start work on translating the core to Standard ML for the simulation.

This first blog post is not going to be a work log for my project, but rather an introduction to the project (as it is currently formulated, which may change) that I am working on and the tech that is used. I intend to create my work log posts on Wednesdays, to coincide with my GTD review, so the first work log post is going to be next Wednesday.

Introduction

The tentative title of my thesis is "Evolving entertaining game adversaries using ADATE" which probably tells you very little. In more descriptive terms the aim of the thesis to use artificial evolution to create the artificial intelligence for a game's opponents, with the aim of creating a more entertaining game. This will be accomplished using a system for doing such artificial evolution named ADATE created by one of my supervisors, Dr. J. Roland Olsson.

The hypothesis I'm working from is that variation in game adversaries would create a more entertaining game than if all the adversaries behaved in a similar way, and that using artificial evolution makes it easy to create diverse AI for opponents that fulfill the criteria set for them, in this case entertainment value.

The game

At this point you might wonder which game I will be using. Sadly this part is perhaps not as fancy as others, I won't be making new opponent behaviors for a game like Skyrim or anything of that complexity. The game I will be using will be a very simple "predator-prey" game akin to Pacman or other games where the aim is basically to avoid a small amount of enemies that are chasing you and fulfill a goal.

I don't have any more specific details about the game I will be using, but this is the focus of my current work, and will most likely be the topic of next week's work log, where I will cover how to integrate the game into ADATE, and other such fancy things.

Artificial evolution and ADATE

Of course, most people will not know what this mysterious ADATE system is or what artificial evolution is all about, so I'm going to take some time to describe. I'm going to treat artificial evolution in the context of the ADATE system, which might gloss over certain parts of the more general description, but these are easily looked up if one is more interested.

First off, ADATE's name is actually a decently good description of what it actually does. The name stands for Automatic Design of Algorithms Through Evolution, which is exactly what it does. More specifically, it uses artificial evolution to automatically create program code in the language SML (more specifically, a subset of this named ADATE-ML), based on some input data and a function which is used to rate the performance of the evolved algorithms.

General description of artificial evolution

Artificial evolution is a technique that takes what we know about the process of biological evolution and applies it to programming. In this process, the "species" are pieces of program code, data or any other artificial thing, often termed individuals, and "genes" are usually small pieces of each individual that are considered to be the smallest division, in program code this could be a single instruction, in a picture this could be a pixel, etc.

This population of individuals are run through a "cycle of life" where the individuals are reproduced to create new individuals which are slightly different from their parent(s), through genetic recombination, mutation or other techniques which are inspired by biological reproduction. The new individuals are then ranked according to what is called a fitness function, which is a function that takes the individual and anything else it needs (such as input to the system), and gives it a rating.

After enough reproduction, the population is trimmed to a certain size by removing the worst performing individuals, and the process starts over, and is run over and over until the system is stopped, either because good enough individuals have been created, a time limit has been exceeded, or any other reason, really.

How ADATE works

ADATE takes this process and specializes it. As mentioned before, the individuals are pieces of SML code, and the genes are individual instructions of this code. In ADATE new individuals are created only through a form of mutation, there is no genetic recombination. The mutation process works as such: the parent individual has one or more alterations applied to it, picked from a predefined set of possible alterations. (things such as changing one variable/value to another random one, adding a new function call, adding an if-else, and so on)

ADATE starts this process from a specification which defines a set of input values, a fitness function that rates the performance of individuals over the input values, a function that serves as the starting point for creating the individuals (often just an empty function for maximum randomness), and various pieces of support code that the individuals and fitness function might need.

Other than all of this, ADATE's cycle of is very similar, it uses some more specialized ways of managing its population, and decides when to stop creating new individuals based on the time expired and how "complex" the individuals were, but these are all minor details which aren't worth going into here.

The APIs I had to update were in ruby code, and they looked as follows:

b.key "a"
b.key "Enter"
b.key_up "Ctrl"
b.key_down "Ctrl"

b.keys.send "a"
b.keys.send :Enter
b.keys.up :Ctrl
b.keys.down :Ctrl

So not only do you need to change three different function calls, but you also need to change any special keys to Ruby symbols, and this doesn't even take into account that Ruby supports two different ways of calling functions (both with and without parentheses), and the code base used both, with varying spacing. In the end you should be left with more consistent code, that doesn't throw a gazillion deprecation warning. :)

What is an intern to do? You hatch a master plan, of course! One including a single regexp matching all the cases, and use python's ability to replace with the result from a function call to make everything magically happening. So, without further ado, here's my code:

import os
import os.path
import re
import sys
import tempfile

tmp = tempfile.NamedTemporaryFile(delete=False)
f = open(sys.argv[1])
print tmp.name, os.path.abspath(f.name)
called = False

def key_upgrade(key):
    if len(key) == 1:
        return '"%s"' % key
    else:
        return ':%s' % key.capitalize()

def replacement(match):
    global called
    called = True
    func = match.group(1)
    if func:
        func = func[1:]
    else:
        func = 'send'

    key = key_upgrade(match.group(2))

    trail = ''
    if match.group(3):
        trail = match.group(3).replace(')', '')

    return '.keys.%s %s%s' % (func, key, trail)

for line in f:
    tmp.write(re.sub(r'\.key(_down|_up|)[ (]\s*["\'](.+?)["\'](\s*[ )]?\s*[}#]?)?',
                    replacement, line, 0))

tmp.close()
f.close();

#Minor security thing
if called:
    os.rename(tmp.name, os.path.abspath(f.name))
else:
    os.unlink(tmp.name)

As you can see, it uses a simple (probably too simple for "real" code, so be warned) file handling routine that creates a new temporary file, rips through the code file line by line, running the regexp against it, and writing the result to the temporary file.

The regexp substitution calls the function replacement whenever it matches, sending in a match object containing either two or three groups (depending on if the last group of the regexp matches). This is then used to do the necessary manipulation on the key names, generate the right function call, and do some munging on the trailing parts of the call.

The last group ((\s*[ )]?\s*[}#]?)?) is probably the most bewildering. It's used to filter out closing parentheses in calls that use them, even if they are followed by a comment or a brace, in a way that retains spacing. Purely aesthetic, but it leaves things looking neat and consistent, which was a design goal.

When all the lines have been processed, it does some magic to put the new and improved file into place. It'll check if any replacements have been done. If none, just delete the temporary file, otherwise you rename the temporary file to the same name as the old one to replace it, this should avoid a few of the problems inherent in doing this sort of thing, and be reasonably fast, without thrashing the old file if anyone is trying to run it while we're working.

After running this, I was left with a pretty massive diff, which I actually went through and controlled every single change in to make absolutely sure my quickly hacked up code didn't break anything. This was made pretty easy by the use of git's interactive commit functionality (git commit --interactive), which may just be one of my favourite git features.

In summary, it was a very effective way to make my work more fun, and probably more efficient. Of course, since it's a quick hack, there are flaws in the code (it doesn't handle multiline calls, for example), but as noted it worked perfectly fine on the codebase I had, and I made sure to control the result (!!!), so everything went better than expected. :D