I picked the game for this contest with the thought that it would be simple and straight forward. Was I ever wrong! The contest was due to start Jan. 1, but a sudden unexpected vacation took me to Vegas through Jan. 2. With jet lag and such, I wasn't really up to sorting the entries it for a day or two after. I had most of my competition runner created, though I hadn't debugged it. By that point, there were 18 entries that had to be compiled into exes for C++/C# or .class files for Java. That can take a surprising amount of time when all done by hand. The C++ and C# entries were mostly Visual Studio projects, so with one exception, a single keypress popped out an exe. The Java entries, on the other hand, were a little bit problematic. Most compiled with a simple javac command, but two were built with POM, a Maven project for building, which caused a little delay. And one entry used package names, causing further delay. In Java, if you use package names, you have to sort out the classpath to compile. I just commented out the package name line and it compiled OK. Please make my life easy and have your Java entry built from the command line with a single javac command! The Java also became problematic for my contest software to run. I'd written a contest runner application in C#/Winform that manages all the entries and manages a game. It writes the input file into each bot's location, waits for it to run, then reads the program’s move.txt file to find out which card was played. It also does logging -- vital with a contest like this. Originally I'd had all the entrants’ bots in one location. I assigned each bot a number so that, in theory, there’d be no clashes. The problems with that, though, was that some of the Java entries generated several .class files and there were at least two Card.class files generated. In the end, it worked better to isolate each entry with all of its files in its own folder. Running standalone exes from compiled C++/C# was no problem. Running Java from a C# program can be done but it took me a week of my evenings along with suggestions from some entrants (thanks to everyone who replied) to make it work and do a bit of refactoring. Finally, the contest is runnable. Unfortunately, some entries proved to be uncooperative and refuse to play nice, or do anything at all, for that matter. Others run but seem to have a mind of their own. Here’s an example: Player 3 Bot=3 6H 4C 6C KD 2D KS H C7 D7 S7 Player 3 Bot=3 skips move In the example above, the 6C is playable (and the only option), yet Bot 3 didn't play it. That's a bug. Before running each bot, my program looks at the four card stacks and checks that there's at least one playable card for the bot to choose. If there isn't one, it doesn't run it. In this case, 7H, 6C, 8C, 6D, 8D, 6S or 8S would be valid to play. As the player had 6C, the program ran the bot.

Where the Competition Stands

And that’s the current state of the contest: Most bots are playing OK, but a few are a bit buggy and some crash. I’ve emailed the writers of faulty bots and provided the input file. I’ve also allowed bots to output a log file and I'll email those back to the owners after each week's run. Because of the delay in starting, I will run the contest through to the end of February. It's still open to anyone who wants to join in.