Flatiron Field Day — A Modern Hackathon
A single day, interactive, programming challenge
Flatiron Field Day, created by Flatiron School Staff, is a web application designed to challenge our students with an all day programming event. The application is directly inspired by the Reddit engineering team’s /r/place. If you aren’t familiar with that project, it’s worth your time to take a look! Before digging into how we built the application, let’s describe the event itself.
The premise of Field Day was to provide the participants with an online interactive coding experience. To participate, teams of four students each would need to utilize their web programming abilities and collaborate to compete against other teams. All of this was to take place on a giant ‘board’ consisting of 500x500 tiles, accessible through any browser.
Every team could write to any tile on the board via an API. The rules were simple: throughout the course of the day, make sure your team’s square remained its starting color as long as possible. Because anyone could change the color of any pixel on the board, this meant groups were trying to both keep their squares the correct colors while ‘painting’ opposing team squares.
We scored the event based on the total time tiles within any given team’s color block were not the starting color.
For example: if team A’s color block had 1 tile set to the wrong color for 200 milliseconds, they would have those 200 milliseconds added to their time (the lower a group’s time at the end of the event, the better).
As you can see in the time lapse of the latter half of the day, participants rapidly evolved their interaction with the board. While the day started out with straight lines and rectangles (primarily designed to protect team squares), participant programs quickly grew in sophistication, including:
- Converting images to pixmaps (multi-colored bitmaps) and painting them pixel by pixel
- Drawing sine curves to the screen (courtesy of the data science students)
- A ‘snake’ simulator, which trawled the board for apples
- A program which, on mouse move events in the browser, painted nearby tiles
In addition to the board client, we provided a way for groups to see their relative activity, with writes per group on the Y axis.
Towards the end of the day, we tallied up all of the points. After which, the server was left running so participants could simply have fun without worrying about defending their color blocks.
The team was blown away by what participants were able to do in such a short period of time — they took an open ended idea and showed us new tricks. We were also excited that the competition aspect of the game was quickly overshadowed by creative interactions. We found that the ‘protect your color block’ premise provided a good entry point for groups to become familiar with the API, after which they were better prepared to flex their creative skills.
How we built Flatiron Field Day
As this was the second time we ran the event, we had a good idea of how we wanted to implement the various applications that made up Field Day. We had one central consideration when designing Field Day: reduce participant barrier to entry.
Our application was made up of:
- A server to host the state of the board (a matrix of 500x500 hex values) and update it via http requests
- A client (see ‘Nexus’ below) the participants downloaded which maintained a local copy of the board and abstracted http interaction with the server
- Two browser clients for viewing the board and game statistics
- Three ‘language specific’ clients which made it easy for students of different backgrounds to interface with the server
Browser Clients
We provided browser clients for visual interaction with the board and game statistics. The board came out looking and working great thanks to our front end devs, featuring smooth movement, zooming, and real time updates. When being dragged with the mouse, the board would provide a fun tilt effect with acceleration.
The board made use of HTML5’s canvas element, and unpacked a binary stream via the Fetch API directly into image data that the canvas could display. Similarly for updates, we painted single pixels within the displayed image data to corresponding hex values.
Nexus
As we had participants with varying levels of web programming experience, we wanted to make sure the potential pains associated with rate limiting and asynchronous request/response was mitigated. This is where the Nexus came in. It acted as a buffer between the requests the participants’ scripts were making and the server.
All of our language specific user clients interacted with the Nexus, which ran on the users’ computers and was responsible for ferrying messages to the server. This allowed us to abstract some of the frustration of server-side rate limiting away from the participants by silently building a queue of actions to be stored in the Nexus. In doing so, students could build up a backlog of tiles to be set that would be steadily sent off as requests to the server. Without this queue, messages sent quicker than the rate limit (5 requests per second) would be rejected by the server.
Another major function of the Nexus was to store a local state of the board (which was kept up-to-date via a web-socket connection to the server). This took away the burden on us (as the developers) to write board updating logic in three different languages for the user-clients. This also kept the code in the language specific user clients minimal, enabling them to quickly familiarize themselves within the environment they were programming.
User Clients
All of our participants had experience in Ruby, Python, and/or Javascript, which led us to providing simple clients in each language. Each client had wrapper methods provided for the following:
- Get the state of the board (500x500 color values)
- Set a tile with an x and y coordinate, as well as a hex string (i.e. ‘#FF0000’)
- Get a tile’s color value
- Get the queue of actions waiting to be sent to the server
- Clear the queue of actions
This enabled participants to hit the ground running instead of worrying about their language of choice’s specific HTTP protocol. By using the Nexus, we also didn’t have to worry about implementing the queue functionality OR the unpacking of binary image data into a matrix in every language. Instead, we wrote the code once in the Nexus, and had each language specific client make use of it.
Server
The server was responsible for handling participant requests (i.e. set-tile, get-board, etc.), maintaining the state of the game as a whole (the board, group/game statistics, etc.), and the web-socket clients. The application ran on an NGINX/Redis/Node/Express stack. We wanted to avoid bulky frameworks and Redis was plenty persistent for our single day needs.
All HTTP requests were rate limited on the server (which was a failsafe for when students inevitably got around the Nexus’ first line of defense), and they all had to be signed by a group or be kicked back. In addition to handling HTTP requests, the server kept all web-socket clients up to date with the state of the board by emitting tile changes.
In order to reduce the payload size of the board, we used JavaScript’s ArrayBuffer object to maintain the state of the board in memory. This enabled us to send the board directly to clients as it was stored in memory on the server by streaming a binary buffer, which HTML5 canvas was already optimized to display on the client side! We were able to update and retrieve tile data from the binary by using JavaScript’s built-in typed arrays. As ArrayBuffers are the underlying data which JS typed arrays provide a ‘view’ into, we slapped a convenient UInt32Array view on the ArrayBuffer binary.
Every element of the Int32 view represented a single pixel, where each byte of the 32 bits was a single color channel:
- bits 0–8: alpha channel
- bits 9-16: blue channel
- bits 17–24: green channel
- bits 25–32: red channel
Again, this was very convenient for us as we had already decided on the standard of passing around 6 character hex color strings for our tile data. Once we had a desired tile color in hand, all we had to do was add an alpha channel (fully opaque colors), reverse the color RGB character pairs, and parse the string to an int:
// takes a 6 digit hex string, i.e. 'ff2200'...
// and returns a valid Int32 binary!function hex6CharToInt32(hexStr) {
const hex8Char = hexStr + 'FF'
const reversedWithAlpha = reverse8CharHexStr(hex8Char)
return parseInt(reversedWithAlpha, 16)
}
With that in hand, we used an x and y coordinate to determine the index, (e.g. idx = ROW_LENGTH * y + x) , and wrote the data directly in.
We were very happy with the result: we didn’t have any problems transmitting the board; serialization from the participants’ perception of tile values (6 character hex strings) to what worked on our back end was minimal; and the board’s memory footprint was tiny.
In Conclusion…
While the application as a whole was not terribly large, we didn’t hesitate to break it out into many smaller self-contained apps. This played a major role in Field Day’s success by allowing small teams (sometimes just a single person) to own a portion of the application without bottlenecking development on other parts.
All-in-all, the small and focused nature of our day-long programming challenge made for an excellent project. We had a blast both developing and implementing Flatiron Field Day and would love to continue iterating on it.
P.S. Want to work on a mission-driven team that loves hackathons and Salty Glitches? We’re hiring!
To learn more about Flatiron School, visit the website, follow us on Facebook and Twitter, and visit us at upcoming events near you.
Flatiron School is a proud member of the WeWork family. Check out our sister technology blogs WeWork Technology and Making Meetup.
