or how we held #icfpc2015

It was all about Cthulhu and hexagons. https://twitter.com/TT_Kilew/status/631208499410771968


This year we were prepared for this competition. At least, we called it “prepared”. We almost decided what language we would use this year, prepared the project base structure with Scala, Java and Kotlin support. As we were preparing, there were 6 of us who had decided to take part in the competition this year. Since each teammate had a preferred language, we decided to write this year’s solution in Scala, so everyone (or definitely at least one of us) took a look at an interactive Scala Tutorial and had some fun there.

The Team on Day One

This should have happened :) On Day One only two of us were able to start on time :) Plus, there was another guy, who joined us just before the contest. And then, as soon as we got the task, which was about something like hexagonal Tetris with some additional fun interesting stuff, we started to implement our awesome solution in Scala.

@vixentael and @TT_Kilew are reading spec. 5 min after start. https://twitter.com/Stanfy_UA/status/629629745630695424

Switching Language

Maybe it wasn’t a good idea, but at least, we tried. During three last years we were programming in Java, and this year we decided to break this tradition. After four hours of struggling with Scala, we capitulated. Even after some tutorials, we weren’t able to do a real-world task correctly. If only we’d had three months instead of three days!

Early beginning. We are in 2nd place solving map #0 and have submitted just some manual solution

How Javascript Infiltrated

A few hours after the contest started…

Working Hard

Javascript isn’t a hard language, so pretty much everyone was able to write some constructions and we added Mocha tests to our solutions. In previous years we were actively using TDD to create core parts of our solutions, and it helped a lot. This year we decided to use tests too. From the start, you think that this is a waste of time, but spending some time on tests on the first day will help you a lot on the third day when you start to optimize things.

Bananas are good when coding hard

Linear Congruential Generator in JavaScript

At the moment I started to implement LCG in Javascript, we already had two working solutions — one in Scala and the other in Objective-C. So from that point,it’s really easy to implement another one in JavaScript, right?


Our idea was pretty simple: we needed a visualizer to see the map and understand what was going on, an “estimator” to select targets for each unit, and an algorithm to move to those targets. Sounds simple. Heh.

Optimized version on A* algo for large maps. We called it ‘drunk algo’ :)

Infinity Loops

Our program was pretty straightforward.

Magic phrases

The solution was a sequence of commands (move left, right, down-left, down-right, rotate clockwise, rotate counterclockwise), that was written as letters. The tricky thing was that one command can be encoded as any one of six symbols (f.e. move to left/east could be encoded as ‘b’ or as ‘c’ or even as ‘e’). So the real result was a looooong line of symbols like ‘alalalalbgdhaldpa’.

Small output of our algo on a large map. https://twitter.com/TT_Kilew/status/630763853492715520

HAL 9000

— Don’t know how to write a cool algorithm that solves your problem?

We aren’t good at those things.

Well, suddenly it appeared that hexagon geometry is quite tricky, but we found an awesome site http://www.redblobgames.com/grids/hexagons/ that solved our confusion about rotating hexagons. However, even after looking at nice charts on that site, we still spent some time on debugging the simple behaviour of our hexagons.


Hello from LoserWill. We took 122nd place out of over 300 teams. Bad-bad-bad result. Still, there was a lot of adrenaline, a lot of updates in the last hour, and a lot of fun. :)

Watch how our repo was changing during contest (3rd party libs are not included)


  • The Team. Handling things in a dynamic team is always complicated. It was hard for many of us to allocate half of Friday (the contest started at 3 PM in our timezone), the whole weekend and half of Monday. That’s why team members were constantly coming and going during the contest.
  • Tests. You should write tests when you implement specification. It’s way better to use tests than debugging.
  • Decide which language to choose before starting the contest. It’s probably easier to share some thoughts between two independent teams, than to try to force everyone to work with some new language.
  • In case you decide to work as one team, give people who will participate at least 80% of the time to decide which language to use.
  • Learn some algorithms and when to use them, and try to implement them from time to time (it will help you!). Because of a lack of knowledge of those, we were inventing our ideas instead of using some good, well-known solutions.
  • It was a good thing to try new technologies and new tools. We’ve tried WebStorm on our solution, and since we’re already using AppCode and Intellij IDEA on our projects, we were able to switch fast to WebStorm.
  • We’ve used Trello to share tasks among project members and it’s a good thing, but we didn’t use Trello as one source of truth — this is a bad thing.


Our team: @Kilew, @vixentael, Fix, @Alex Voronov, @Lampapos, Silver. Moral support: @bexcite, @vandalko.


You can read our previous year’s report.

We are a native iOS/Android apps development studio in SF, with focus on custom Android firmware and chatbots, exceptional UX and UI. https://stanfy.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store