

Google AI Challenge: Winner post-mortem and source code - codexon
http://a1k0n.net/blah/archives/2010/03/index.html

======
WilliamLP
The interesting subtext of this competition is that to an extremely good
approximation, everyone who was interested enough to write a competitive entry
used C/C++, even though the organizers went to great lengths to support as
many languages as possible (e.g. Haskell, Scheme, etc.) This is with a small
self-contained problem where performance wasn't a main difference between
entries, and fast prototyping and experimentation could be _extremely_
valuable.

What I take from it is being more convinced that the claims of dramatically
increased productivity from other languages, in practical terms, are at best
extremely overblown. If this isn't a practical problem where a Haskell or
Scheme programmer could be competitive using advantages of those languages, it
really makes me question what is.

~~~
a1k0n
You know, I didn't even once mention the language I used. Realtime constraints
and searching speed were the driving factor here; you have to return a move in
under one second. I didn't want to risk GC pauses, and I'm not good enough
with Haskell to guarantee I'm writing fast code. Otherwise I probably would
have used something else, but I don't consider it all that important. Really,
there wasn't anything too complicated data-structure-wise to do. In fact it
does next to no dynamic allocation. I wanted to use destructive updates for
speed when doing a backtracking search on a map. The hard part was just
implementing various recursive algorithms, and C++ didn't really get in the
way of doing it except that it would have been nice to have multiple return
values.

I did have some problems throughout the contest with my choice of C++ -- in
fact without Valgrind, my entry may never have run correctly. (Turns out one
of my algorithms was "escaping" off the border of the map and scribbling in
RAM) But hey, I've been dealing with problems like that for more years than I
care to count right now.

~~~
DannoHung
> I did have some problems throughout the contest with my choice of C++ -- in
> fact without Valgrind, my entry may never have run correctly. (Turns out one
> of my algorithms was "escaping" off the border of the map and scribbling in
> RAM) But hey, I've been dealing with problems like that for more years than
> I care to count right now.

:D

[http://blog.danielwellman.com/2008/10/real-life-tron-on-
an-a...](http://blog.danielwellman.com/2008/10/real-life-tron-on-an-apple-
iigs.html)

------
janzer
Here is a brief overview and the source code from my 5th place entry.
<http://janzert.com/tron/>

------
NathanKP
Now I understand why my bot did so badly (190 out of 800). My iterative
deepening algorithm never worked quite right because I didn't have the Voronoi
heuristic implemented properly.

This was a great walkthrough, and the contest, even though I was nowhere near
winning, was a nice learning experience for me.

------
ErrantX
Great PM. It's always interesting how much thought goes into challenges like
this.

Favourite line:

 _I don't have a good formal reason for this, it just seemed intuitively
right_

------
Blasa
Did you do any sort of memoization of the minmax evaluation?

For example the expected value of moving up and left should be the same as the
the expected value of moving left then up?

That would cut down the search space some. Of course it adds memory overheads.

You could also memoize the voronoi heuristic if that takes a long time to
compute.

~~~
a1k0n
> Did you do any sort of memoization of the minmax evaluation?

None. Considered it, but didn't really think it was worthwhile. I was mostly
focused on having a good evaluation. I know a lot of my competitors did that,
though, but without changing the evaluator it is, as I said, self-deluded.

> For example the expected value of moving up and left should be the same as
> the the expected value of moving left then up?

That isn't true; that ends up with the wall from the middle move in a
different spot.

At any rate, there was a lot I could have done to improve the search
speed/depth but I didn't have time, so instead I worked on a better evaluator.

It was pretty interesting -- I would frequently see stronger moves (as best I
could tell, after analyzing a losing game) found at shallower levels of search
depth discarded in favor of weaker moves at deeper levels. Presumably it
assumed the opponent would maximize its Voronoi territory at a time when it
was actually a bad thing to do.

~~~
Blasa
> That isn't true; that ends up with the wall from the middle move in a
> different spot.

Oops yes you are right. They would only be of the same value if the map was
symmetrical on the diagonal line going between the first position and the last
one.

I wonder it they should be similar (at least in situations where you don't
touch walls).

------
swah
Guys, shouldn't we be talking about 11th position? Lisp! Remember?

------
afterz
Very interesting article! I would like to know how much time was spent on
developing the bot.

~~~
a1k0n
So would I, but I'm afraid to find out.

Most of the development was done after putting my son to bed and before
collapsing of exhaustion at 3am.

