UCT Charts

Today’s topic is a little different: it’s as much an art project as it is engineering or science. Pretty graphs below, but first, an introduction.

UCT is messy by computational standards. It wends its way towards perfect play, but the answers you get depend on how long you waited before asking and how fast the hardware was running, not to mention a stream of pseudo-random numbers. An antivirus program running in the background, a network blip on another continent, bubbles in your CPU’s thermal paste – they can all affect what a general game player ends up returning as its move.

So what happens if we take some of that messiness away?

2016 Tiltyard Open format

It's time to reveal the types of matches at this year's Tiltyard Open tournament. A few things have changed from last year, so use this as your guide to what's ahead.

Alloy 0.10.0 graphical log streaming is live

You can now get some insight into what Alloy is thinking by watching a live graphical representation of its logs as it plays on Tiltyard.

I decided to do this primarily as a way to better understand my player and UCT. I had moved Alloy to run on a dedicated computer so it can run continuously, but this made it difficult to view information directly from the program. Streaming this publicly makes it easier to see regardless of where I am, and it also allows others to watch this information and gather their own insights about game AI.

By moving from a few lines of logging at a time to a full screen of graphical information, I can also afford to include a wider array of information useful for debugging or for understanding my player's weaknesses.

The GDL engine performance-testing framework

The Game Description Language is declarative, not imperative. It defines the rules of a game, but not the process by which a program should apply those rules to produce facts. This has led to a wide variety of implementations of GDL interpreters, or engines, that handle this computation, with a wide range in their speed and accuracy across games.

A paper presented at the GIGA'13 conference by Yngvi Björnsson and Stephan Schiffel compared the performance of six such engines on 12 games. (To access the paper, select "proceedings" on the conference website and scroll to page 55.) To follow up on this experiment, and to test my own creations, I decided to write an open-source framework for this type of performance testing.

2015 Tiltyard Open format

Here's a somewhat more in-depth explanation of the sets of matches that will be played in the 2015 Tiltyard Open. Hopefully this will help make sense of the overall tournament structure and how match results affect the final results.

We expect to use version 0.0.7 of the ggp-tournament library for scheduling the matches, so you can check out that library for details beyond the explanations here.

Bases and inputs

I don't know if there are any clear full descriptions of how base and input sentences work in GDL. (They were added to GDL since the last full specification was written.) So, here's a brief write-up of how they work.

The base and input keywords are used to specify the possible true sentences (i.e., components of the game state) and legal moves that could occur over the course of the game.

GDL perf framework preview

I've been working on and off on a performance-testing framework for interpreters of GDL games (i.e. rule engines). There's still more work to be done before it's sufficiently complete and well-documented for others to use, but here's a sneak peek of output. Suggestions are welcome on the Github issues page.