In order to prevent this thing filling up my blog and driving away people who perhaps don't care, I'm contemplating setting up a new site of some sort to host it.
Anyway. This problem wasn't very imaginative; I hadn't thought of anything seriously fun by the deadline and rather than let it drag on, put something up to give me at least 4 weeks to think of a new one and pass-the buck. Apologies, then, to anyone who thought it was rather similar to Link 6. I'll try to do better next time. A few people claimed to have found bugs, but it seems they were just misinterpreting the message that was returned on death -- it highlighted jumps, but not the points where they drove their buggy straight into holes.
I let people have a minute to solve the problems, so that automation was utterly unnecessary.
Anyway, 10 people solved the problem, which was to provide essentially an AI for a simple version of the Linux moon-buggy game by Jochen Voss (the real version has LASERS and slightly different physics).
Fice and faux were tied for first place starting, both taking just 1 second to get the page. It seems fice had the better luck in actually solving it, though. His entry was a C# application, as usual, with some funky indenting. Winning submission, after 19 minutes 45 seconds.
It's fully automated. It precomputes which spots can be jumped or driven to, passes them as an array and then recursively evaluated all paths, culling as soon as the buggy explodes. I'm not sure why driving forward is "beating", but it certainly beat the problem, so.
It doesn't help that his code is replicated everywhere, and I don't even know how it detects holes. Eww. Anyway, it's a recursive solution similar to fice's, but doesn't do any precomputation.
Taking an hour and 5 minutes, Faux came in next with a verbose Java solution.
Like fice's, it's fully automated. It contains much copy/paste code, in common with Connor's -- but at least I can read this one! Other than the copious amounts of debugging it presumably produces, there's not much more to say about this one.
Monk got the first page within about 30 seconds, and submitted just over 2 hours afterwards. He wrote a Python solution which uses rather depressingly normal code. It does however produce a tonne of debugging output.
One notable feature is that the ASCII used for the car in the output is a customisable parameter to the solver.
Not content with normality, Jessica made a solution in TCL (63 mins solving time; run as
./buggy.tcl '<landscape'), and then followed up with three C solutions, all tweaks on the previous.
The code is neat and is not very copy-paste at all. Also, I can read it, which I don't remember being the case for TCL before.
Michelle submitted next, with a C solution, which was apparently annoying to write in vim. Heresy!
The code is a basic tree search, which is nicely geometrical. It's manually run, and does no caching. It does contain the phrase "HURR DURR DURR HURR HURR FAIL", however.
Uncertain how long it took him to solve it; my logger claims 33 seconds but I find that unlikely, though he did use Haskell, so it's within reason. Having been reading a Haskell tutorial of late, I can read some of his code!
Colin's code doesn't use enough monads, and I think is longer than my Python solver. I feel he has room to grow as a Haskell coder. It's a non-automated recursive solution which pre-caches valid moves.
Fyorl submitted on Codd, so I don't have an accurate time-to-solution, but he solved after Colin, which is what counts. His PHP code is a fully-automated recursive solution with no caching.
Interestingly, he appears to be describing the problem explicitly as a graph exploration, though unlike Faux's problem before it, the exploration is rather more like a tree. Still, it's nice to see the geometry written out explicitly.
Ryan submitted a Haskell solution just after 25 minutes from first fetch, thus being defeated by Colin in the Haskell subgame by a factor of about 50. His solution is similarly lacking in monads, however. I wonder how these people expect to obtain the respect of their peers?
The code implements a non-automated recursive solution without caching.
Coming in last and also least, since his time between first fetch and solution was only 16 mins 15 secs, Moltenfire rounds off my submissions list with a solution in Java.
His solution is recursive with no caching, and no automation. He opts to reformat the problem string into integers, presumably to increase the memory consumption of his app slightly (or because the symbols are ordered by badness afterwards).
Fice has won, and should be setting up a new problem soon. Expect more info on his blog. Moltenfire and Ryan should be quicker at starting. Haskell users need less readable code. Jessica needs to specify whether new solutions overwrite old ones.
My code is of course also available!