Project in Detail: The Kegatron

Submitted by Josh on
Kegatron Homepage The "Arkeg" is, as you might be able to suss out if you think long enough, a combination of a stand-up arcade game cabinet plus a "kegerator," another portmanteau describing a mini-fridge with a small keg of beer inside. This is, in fact, a real thing, and it's one that will set you back roughly four thousand dollars.
So, a few years back, during a hackathon at my company, a group of intrepid guys went about building one of their own to keep around the office. I won't claim credit for that at all, because I wasn't involved at first (mainly because I was working remotely at the time - I would have jumped all over the chance had I been local!). This machine was christened "Kegatron." Late on, I became involved in a subsequent hackathon as we did hardware and software upgrades, and that's where this blog post comes in.
For a while, we'd been running gaming tournaments using the games installed on the machine, but they were a decidedly low-tech affair. Our office administrator would send out an email announcing the dates and games involved, people would play them and write their scores on a giant whiteboard, and people would walk by to see where they stack up. Simultaneously, any time a keg was tapped, the person who tapped it would have to go find our admin and let her know; also, a whiteboard had to suffice to find out what we had on tap in the first place.
The solution was a microsite to be run alongside the Kegatron itself; follows is a design document illustrating the process.


Create a microsite to serve the purposes of the Kegatron and reduce the manual work involved with maintaining its features.
  1. Operate an intranet site for all features on existing architecture.
    • Site operable on dedicated Kegatron-adjacent hardware.
    • Site available to all users on internal network or VPN.
  2. Create a toolkit to add and maintain employee game tournaments.
    • Creation of tournaments for one or more games.
    • Addition of games to the meta-tournament records.
    • Real-time display of game and tournament leaderboards.
  3. Create a toolkit for player self-service for recording tournament scores.
    • Creation of user records.
    • Addition of user scores.
  4. Reflect the beer currently on tap.
    • Describe the beer.
    • Allow for a guesstimation of keg volume for visual display.
    • Create a feature to email the Kegatron admins when the keg is tapped.
  5. Show the employees who have contributed to the project.
  6. Represent the site in an appealing and responsive way.


Pac-Man High Score Screen Illustration of a Typical Arcade Cabinet Technology: Given the ubiquity of the features on any internal server on which we might throw the site, as well as my own familiarity with it, we elected to run this site via the LAMP (Linux, Apache, MySQL, PHP) stack. For the user-facing components, standard HTML5, CSS3, and jQuery run the show.
Design: Working with an internal graphic designer, I created a UI for the site that evokes a standard 1980's arcade cabinet, keeping the individual elements small but on-brand by using corporate colors and logos. The header looks like a cabinet marquee, and the container for the main content looks like the bezel in front the cabinet's monitor. The main content exists on the "monitor" itself, though the monitor in our case is a grey gradient rather than a black TV screen for easier readability in a variety of environments. The graphics making up the cabinet live as fixed content layered atop the content, giving the opportunity to give the design visual depth and making scrolling content appear as if it is really on a screen within the screen. The main navigation exists at the bottom of the bezel, where game instructions typically live.
Inside the content, most text is displayed as the Google Font "Press Start 2P," a bitmapped pixel font that is patterned after the fonts used in many classic arcade games like Pac-Man, Q*Bert, and Centipede to show scores and other text. Colors for standard text were defined as white and light, cool greys to contrast the darker background. For more attention-grabbing displays, such as tournament leaderboards, a rainbow of colors were defined using the colors in the original Pac-Man arcade top score board. Table headers become yellow, first place scores are shown in grey, second place in red, etc. For pages with more complex data structures, such as tournament pages with multiple leaderboards, I determined that despite departing from the overall 80's arcade theme, sub-data would be boxed in with solid black backgrounds to improve legibility.


This post ignores the general setup of the server - for one, that's not exactly exciting; for another, it was mostly done before starting; for a final reason, I didn't do much of that work myself! Suffice to say that we did set aside from space on an existing internal LAMP box and then configured everything as desired from there.  The database contained eight tables:
  • Meta-tournament data - tournament names, dates, internal IDs, etc.
  • Game data - Game name, game platform, and so on
  • User information for tournament players
  • Tournament-game data - a mapping table to map the first two together, creating tournaments made of one or more recognized games
  • Tournament-score data - a mapping table to map users' scores to tournament records for each game in a tournament
  • Score computation data - to map a user's rank in a given tournament game to an arbitrary score, used to create overall scores for tournaments with more than one game
  • A view to combine many of the above tables into a view-table to avoid overly complicated queries in the middleware
  • Keg data to describe the current on-tap brew
From this data, I produced a number of pages to present it to users.
  • The site homepage shows the current or most recent tournament, along with all games involved, the open and close dates for each game (as a tournament typically involved multiple games, each available for a week), and scoreboards for the current game and the overall tournament.
  • A tournament archive page gives a list of all prior tournaments for recordkeeping, listing the dates, games, and winner of each. These pages drill down to detailed results for each tournament that resemble the homepage, albeit with more complete data.
  • Score entry page so that users can add their own username records and record scores for games played.
  • A "Credits" page that resembles a more-detailed post-game credits roll for all the folks involved in Kegatron. This page has names and avatars for every person involved in each phase of the project, with incredibly tasteful grave markers replacing the avatars for anyone who has since left the company.
  • An "On Tap" page that shows a large visual indication of the beer on tap. The beer is shown in a mug like that from the classic arcade game "Tapper," with the color of the beer in the mug selected by the admin updating the page from a palette of ten options, from "dark" to "white," including "green" for anything we might drink over St. Patrick's Day. This page shows data about the beer, including its name, brewer, alcohol content, style, and the date tapped. The large visual mug also had the capability to have its volume adjusted by admin users to show roughly how close the keg was to being kicked.
  • A tap archive page, showing all the beers put into place and subsequently tapped. This page shows a smaller, full version of the mug in the correct color and the date the keg was kicked.
  • Admin pages to manage most of the above, including tournament setup and editing, user editing, game library additions, and the on-tap selection. Admin pages were protected by integrating the company's LDAP into a HTTP basicauth in Apache to limit access to a handful of users.


We sourced an unused touchscreen-capable all-in-one PC to set up near Kegatron to run the site 24/7, as well as giving users the option to access the site from their own work machines and VPN-connected personal devices. Users were naturally happy to be able to enter and chart their progress without having to crowd around the arcade cabinet, and the site ran a number of tournaments before the monthly tournament shut down for other reasons many months later. Note: As of 2017, this site is still in use to track the beer side of the Kegatron, which, let's be honest, was always going to be everyone's favorite feature.


Kegatron Tap Page All in all, this was a successful project for a few days' work. It looks good, people like it, and it's still in use. There are definitely some holes that would have been good to fill, but are now unlikely.  
  1. Using the honor system for reporting scores. There will always be some level of honor system in these tournaments, because players won't always have people with them when they play games, and there's no way for the games themselves to record the scores in a central location. However, the current site also allows people to submit scores for other people if they were so inclined. If, instead of allowing users to self-service adding their accounts and scores, we instead connected the user list to LDAP and required a basicauth password, people would be unable to submit scores for anyone other than themselves (assuming, of course, proper password security protocol at the user level).
  2. Front-loading all the games. Admins got tired of adding games for every tournament - it would have been better to take all of the games installed on the machine and loaded them in via MySQL before the project was released to make the site more usable. Data entry via CSV is much faster than via web interface.
  3. More pre-planning of the site's views. In a hackathon, this kind of time isn't usually available, but some design choices were made on the fly during development which very rarely results in work of the same quality as the original planned information.
  4. Better implementation for the "On Tap" feature. It's visually cute, and has some good ideas behind it, but with a bit more time and budget this could have been very cool. A couple of ideas:
    • Integrate the Untappd API for beers. Untappd is a social network for beer drinkers, about which I'll probably blog at some point, but it stores thousands of different breweries and brews so users can track and rate what they try. The API opens that data to other sites, meaning that I could have built an interface to let admins search and prepopulate everything about the beer when it's tapped, including the average rating values that Untappd stores. 
    • Attach the keg to the Internet of Things. There are tap flow meters that are capable of reporting out over wifi how full their kegs are (I mean, of course this exists. How could it not?). Integrating one of these would bypass a lot of the features of the current site, by allowing automatic updates of the mug on the On Tap page to show the level of remaining beer, and by also allowing the keg to report itself as kicked rather than requiring a human to do it. We had access to an old Raspberry Pi that could have done the job, but not enough budget within the hackathon to buy a meter, which at the time sat at around $100. 
  5. Open source the thing! I should get an anonymized version of it up to Bitbucket or GitHub at some point...