Winning a Hackathon with a multiplayer game

code

Joining HackEd Beta

Last year for my 20th birthday, I decided to participate in HackEd Beta 2019. This hackathon is open-ended and serves as a preamble to Edmonton's HackEd competition. It is open to students of the University of Alberta. I had at this point participated in several hackathons, and decided to join this one with a team of my university friends.

Finding an Idea

The hackathon began at 12 am, and there were a few hours of socializing and figuring out details related to what project to do. We did not come to the competition with an idea of what to make, but we decided to make a ".io" inspired multiplayer game after some deliberation. Inspired by Super Smash Bros Brawl (a personal favorite of mine), we decided to make a platformer brawl-style game with goomba-stomping as an attack mechanism.

Choosing the tech stack and designing the architecture

Once we chose an idea to build, we had to do some research on a tech stack that would allow us to build it. We decided to make a web-based game because this would simplify the multiplayer connectivity aspects of the game greatly, and implicitly make it easier to distribute and let people access it. For the front end of the game, we made a simple HTML website with phaser.js embedded in it for the game logic, rendering, and physics. Phaser.js is a javascript game library that takes care of rendering, physics interactions, and many other things. It is pretty customizable, even allowing for different kinds of physics simulations. Once we made this decision, we faced the challenge of figuring out how to design the backend service that would enable multiplayer gameplay. Sticking with the theme of hackathons, which tends to be quick and dirty, we decided to make a dead-simple node.js backend using express and socket.io to declare a number of events the server would handle such as players joining, players being killed, disconnecting, and changing their position. To simplify implementation and make sure that everyone from the front-end team and back-end team was on the same page, we created a UML diagram to outline the interface we would be using for client-server communications.

This diagram is very simple, but helped my team avoid difficult merge conflicts, as much of the development on the front end and back end was occurring in parallel.

Going for midnight Birthday Drinks

Work on the project was moving along very well, we had a working game with players and physics with platforming. When playing locally, stomp-killing worked well. Because this hackathon was being hosted at Startup Edmonton, which has a bar below, and because it was my birthday, we decided to go for some midnight birthday drinks to help get our minds unstuck from a difficult problem we were facing. This xkcd comic perfectly illustrates what we were going for:

Launch (And 6 am hackathon hell)

Getting back to the coding, we ran into some big problems when we combined our front end and our back end. There were discrepancies that were creating some mind-boggling errors in the chrome dev tools console. Probably due to a lack of experience in making javascript web apps, we had some difficulties in debugging it. I would also partially blame the lack of hard typing in the javascript ecosystem as well (hello typescript!). This dragged on for a number of hours stretching into the night. Eventually, we decided to rewrite the interface logic on both the backend and frontend, and this resolved the issue. We finally achieved this by 6 in the morning. Our game, while visually rough, was working! Here you can see the single table setup of our hackathon:

Sleep (At Last!)

With the game working by 5 am, I finally got to curl up on a foam pad underneath the hacking table and get some sleep in preparation for the presentation the next (current) day. My friends decided that the game was too bland, and needed a soundtrack, which lead them to bus home to get a bass guitar. They then recorded a sick bass solo as the theme music for the game. I woke up in the morning at 10 am, only 2 hours before the presentation, and joined my team in preparing a slideshow presentation with a live demo to the panel of judges.

Presentation and 1st Place!

We presented our game, and the judges were impressed! We landed 1st place, which was quite exciting given the difficulties we faced in getting the game working throughout the night.

What could have been done differently

Looking back on it now, more than a year later, I feel that a great improvement for debugging and speed of writing code would have been to use typescript on both the front end and the back end, with a shared folder to keep types in. This would have guaranteed to some extent that the information that we were sending over the sockets broadcasting event information would have been received exactly as expected.

Because we hosted our server on a digital ocean droplet with 50$ of free credits, after a few months we ran out of credits, and our server was disabled. We also got our domain name, squabble.xyz for free during the competition, and due to no interest in paying for the domain fee, we lost this as well.

I have some ambitions to find a free node.js server hosting environment for free, and hosting the front end to squabble on this website at some point.