Team Name is a Day 2 Feature

I’ve been looking forward to the Crestron Masters 2018 Hackathon for quite a while, so I was caught off-guard when it was announced that it was a team competition. My first thought was that it might be bearable in teams of 2, but then Chris Tatton clarified that teams must consist of exactly 5 people. I despaired of getting 4 other people organized by the deadline, and I honestly wasn’t expecting it to be all that fun. I thought about skipping the hackathon since it wasn’t going to be a solo competition like I had expected.

Fortunately Facebook came to the rescue, and it was relatively easy to identify four other interested individuals and get us signed up. Not a bad bargain in exchange for all of our personal information in perpetuity. We had completed challenge #1: getting a bunch of solitary programmers to self-organize. Andrew Wirshborn, Nathan Hesson, Matt Rasmussen, Casey Roe and myself formed “Team Name is a Day 2 Feature” (name courtesy of Andrew).

Our task was relatively straightforward: implement one half of a Battleship game, allowing the user to place ships, fire missiles, and show the game status onscreen. The rules of the challenge were truly diabolical, though: this would be a programmer’s relay race, with each person taking 7 minutes at the keyboard in turn, and the other 4 players sequestered at the back of the room.

We had three minutes to read the challenge, which was barely enough to wrap our heads around it, then I went straight into my first 7-minute shift. I wasted half of it trying to download the provided graphics, only to discover that they were not a complete user interface as I had thought, but some optional graphical elements that we didn’t wind up using. I think the only part of my first seven minutes to survive was the “Start New Game” button on the panel (although it didn’t do anything yet). My head was spinning, I didn’t have a plan, and I was convinced the challenge was impossible.

Part of my problem was that I had trouble initially wrapping my head around the big picture. I was stuck on the “client/server” idea, trying to figure out whether the game state was held on the server, or if we were responsible for tracking the game state. My mistake was not thinking about the game of Battleship in more detail — it’s more like a peer-to-peer scenario, since each player only knows their local state. The protocol is symmetrical for a reason since both sides issue fire commands and parse miss/hit/sunk responses.

After my first 7 minutes of terror were over, I wasted some time at the back of the room despairing of completing the challenge. Toine stopped by to pester us about not having anything written down yet, and eventually we realized the wisdom of his comments and started sketching things out. That way we could refer to the user interface and parts of the program while four of us weren’t at the computer. This time was remarkably productive, although I think we could have used it even more efficiently.

We did very minimal planning for who would work on what— everybody played to their own strengths as far as the user interface design, signal naming and connections, SIMPL+ module definition, and gameplay logic. One of the problems identified early on was the coordinate system. The signals coming back from the panel were numbered 1–100 in column-major order (from using a vertical list with columns). Internally we were using [x][y] notation, but the protocol mandated A1 notation, where A is the row. We sketched out some mappings to make sure we all agreed on the preferred notation internally [x][y], but my big mistake was in not working out and testing code for mapping in both directions on paper. As it turned out we wasted at least 5–10 minutes in solving this issue by trial-and-error at the computer instead.

Some early design decisions paid off handsomely — no graphics, each square would have text indicating what was in it (nothing, hit, miss, ship #). Each of the five ships would have an ID, stored in the board array. Our board state array just needed those values, and we could compute everything else on the fly (like how much of ship #3 was remaining)

As we completed our 3rd rotation, Chris decided to accelerate the process to make sure one of the teams completed the challenge in the allotted time, so we switched to all-hands-on-deck with me at the keyboard. While I did the bulk of the gameplay code, it was invaluable to have multiple sets of eyes, not only on the code, but on the behavior of our program. Several times I got myself twisted up over something I thought I had seen, only to be corrected by somebody reminding me that I hadn’t recompiled yet, or that I had clicked too fast (this was a legitimate bug — we did not enforce turn order!)

It absolutely came down to the wire — Chris announced 10 minutes remaining when we had yet to see a hit/miss recorded properly on the remote player’s board. I’m not sure we had even seen a hit recorded on the local player’s board since we hadn’t played more than 2–3 shots into a game yet. All of our parsing code looked correct, and the debug trace was correct — but we had forgotten to actually draw the remote player’s board. At the last minute we added code that would draw the hits/misses, then yelled SHIP IT.

Since we were the only team out of 8 who thought we were even close, we got to demo our program for everybody else, while a Crestron engineer drove (thanks Pranav for not clicking too fast!) Since nobody else was willing to demo theirs, and Chris was determined to find a winner, I was pretty sure we already had the win locked down. There was a peaceful kind of inevitability in realizing that we couldn’t make any further changes to the code at that point. That didn’t stop us from getting stupid excited when Pranav actually sunk an enemy ship for the first time — not just his first time, but the first time we had seen that code working! Not surprisingly there was a small bug there — we didn’t actually mark the square where the enemy ship was sunk — but it was still playable.

Since we hadn’t even gotten to that point in our testing, of course we had not tested the “end of game” logic either, so we were ecstatic to see that it worked perfectly. And even better, our human player Pranav beat the evil WarGames AI (that was not a requirement of the challenge, fortunately)

Congratulations again to Chris and Toine on coming up with a truly unique form of torture. I’m grateful to all the team members who signed up for this wild ride and didn’t give up when it looked impossible (or at least unpleasant).