I participated in ICFPC 2017 this year after a gap of two years. As in 2012 and 2015, the task this year seemed to be inspired by a game as well - specifically, Ticket To Ride, the board-game. You had to connect a few producer sites containing “lambda mines” to various other consumer sites interested in these “lambdas” along rivers connecting sites to one another (forming an undirected graph) by claiming one river per turn for a limited number of turns. You were pitted against one or more adversaries. It was quite fun, with some improvements over my performance at previous attempts at ICFPC, though not enough to make much of a dent.
Instead of continuing to be a masochist and writing the code in a low-level programming language like C or C++, I opted for a high-level programming language this time: Python. I also spent much less time writing a visualizer this year, postponing it as much as I reasonably could and even then writing just a bare-bones one using PySDL2 and SDL2_gfx. Both these decisions let me explore the task more than I usually get to do.
Unfortunately however, I ended up spending an inordinate amount of time getting the lambda-duct helper-program provided by the organizers to work on my system. Only the OCaml sources of this tool were available initially and getting its entire set of direct and indirect dependencies working in order to be able to compile it was, in hindsight, a lot of effort wasted that would have been better spent writing such a tool myself. (The need for every programming language to have its own package-manager and for every tool and library to have far too many dependencies are rants I reserve for some other time.)
Even when it was finally running, it did not work for me for quite some more
time due to what ultimately
turned out to be the use of non-blocking input by it for the captured
stdin of player programs. Combined with another half a day I had
to give up due to some personal commitments, this resulted in a total loss of
about one and a half days out of the three days we had for this contest. Ugh!
Once these hurdles were overcome though, it was quite a lot of fun banging up code to tackle the problem. The use of Python meant that I could ignore a lot of the messy details and just tackle the actual problem. My inner systems-programmer kept cringing from time to time at the egregious waste of resources the solution entailed, but it was surprisingly easy to shush him up. I had so much fun in fact, and so much that I still wanted to explore, but could not due to the lack of time, that I had to drag myself back to work on Tuesday and seemed to be having withdrawal symptoms.
I ended up with having completed (and submitted) only a very naive strategy before the contest ended. Even then, it was amusing to note that randomizing its behavior produced better scores than it did otherwise (possibly due to that blocking the opponent in its attempts to capture rivers).
The source-code for my attempt this year can be found on Bitbucket, on GitHub and on GitLab. You can find some other write-ups on /r/icfpcontest.