ICFP contest 2017 postmortem for uguu.org
Contest site:
https://icfpcontest2017.github.io/
Final submitted tarball:
https://drive.google.com/open?id=0B7XdTJOhKlR9UGx2YUZicGZ1cm8
I took what I considered to be the least risky approach, which was to compute all distances once at setup time, select a random mine, then greedily expand from currently reachable sites. It works fine when there is only a single mine on the map since the heuristics are tuned to increase distance (for quadratic increase in scores). If there are multiple mines, it will try to connect to a different mine (doubling score if successful), but this depends mostly on luck since all previous random steps must have built sufficient turf for this work. This approach pretty much guarantees nonzero scores, which had been my modest goal every year, but it isn't very competitive. I won most games against "eager punter" (not a particularly high bar) but lost almost every game against "YAGI". The only competitive feature I have implemented was to grab a random river if there is nothing better to do, because there is no reason to waste one turn and let someone else take that river.
I didn't implement all of the contest spec because I was particularly risk-averse this year. Having spent a significant amount of time debugging IO issues, I just wanted something to work at all. So I took the risk on assuming that things will be fine in offline mode and tried to minimize all other risks. This meant not implementing the "futures" or "splurges" extensions, since I wasn't confident that I could get that working in time without breaking something. I did implement the "options" extension because that was easy, but I don't think I tuned the weights correctly so it probably doesn't trigger very often. I also didn't implement any timeouts handling -- this was entirely an oversight but since my solution generally runs fast (<100ms per turn), I should not see timeouts if there is no networking. I hope.
For the amount of time I actually spent: it was only ~31 hours this year, about 7 hours of which was just getting the IO bits working. For comparison, it was ~44 hours in 2015 and ~40 hours in 2016. I was able to save time on not implementing various tools and infrastructures, which had been always been a burden for single person teams. There are diminishing returns in spending more time with these contests, and I feel like I got the right balance this year. I got much more sleep this year, and even spent a few hours taking pictures, so I was fairly pleased.
Networking was pretty much the only sore point for this year, which was later mitigated by judges' lamduct tool. The barrier to entry for this year was otherwise relatively low for this year, there are few intricacies to consider no obscure concepts to ponder over. A more baroque spec could make a more interesting contest (the VM for 2006 was totally worth it), but I am glad it was relatively straightforward this year. I was also happy about how the judges made efforts to level the playing field for people who might not have access to supercomputers by requiring submission of executables. A side effect of which is that this year's contest slightly favors languages with low runtime overheads such as C++, which fits my bias perfectly.
This has been a good contest, thanks to all judges and participants for making it fun!
Previous (2017-07-25): "Eromanga Sensei" volume 9 by Fushimi Tsukasa
Next (2017-08-07): "Joseito" by Dazai Osamu