Making a Hackathon Game
Last Friday I participated in the Kopius Hackaton 23. Where teams of 3 devs were tasked with making a game that Kopius as a company could use to showcase the new brand in nerdearla (one of the largest IT trade shows in LATAM). The thing about Hackatons is that there is a whole process to actually building something that fast. Here is a little bit of my process.
1. The Idea
First, We needed to figure out what to make. And because the logo is an asterisk, we decided to go with a drawing game. We did this for a few reasons
- It's highly interactive: People are actively playing with the logo and brand.
- Branding guidelines: it allows us to showcase the logo and brand in a very similar space to the usual ones and follow all branding guidelines
- Team: it meshed well with the team's skills.
- Requirements: The requirements stated that we needed to showcase the brand and have a pointing system.
2. Picking a stack
This part was easy, almost by default we were going to go with a web based JS experience. I did ask to use Typescript, as I find that having types in JS makes debugging so much easier. One decision we did make at this point was not using any FE library or framework. Because these are great for a webpage or maybe the game's menu interface. They are not great for a game's core functionality and would slow us down. In the end, we went with pure JS and HTML.
3. Core functionality
Now it was time to actually get building. The core of the game consists of an interactive web canvas. On this canvas we listen for click events, and store their X, Y positions. One thing we did have to take into account was calculating the distance to the last point to prevent a user who is holding their finger steady from creating thousands of points on top of one another. So in the end as the user drags their fingers or cursor, on every move event we calculate the distance to the last stored point and once is higher than a set minimum we store a new point. At the same time, we use the previous point and the new one to add a new line to the canvas, allowing the player to interact in real time.
4. Win Condition
Remember when I said we picked this kind of game because it met the requirements of allowing for a pointing system. Well now it was time to actually build the pointing system, and it was a little harder than expected. In the end because of time constrains we landed on waiting for the user to lift their finger. This keeps us from constantly calculating a score, and it also allows the user to see the win animation as their finger will be off the screen. The scoring is done by counting how many points fall within a set distance of the perfect place. This means that for every point the user makes. We take the Y coordinate, and calculate the mathematically perfect X coordinate where the logo should be, and if the user's X coordinate falls close enough they get a point. The user wins if they get 70 points, and there was no science to that number. We just got a bunch of people to play, and took note on how good their logo looks and the score they got, and decided on a threshold.
5. Cleanup.
After this, we Just needed to finish up the styling to meet brand guidelines and clean up the code.
Conclusion
We did end up winning! Because of some of the points listed above. The game is a good showcase of the brand and its fun. In the end, it was quite a fun experience to participate in a hackathon. In my case, the whole thing was great because I love working on product development, and in a hackathon the whole objective is the product and getting it to the presentation. If there are technical difficulties, the team has the choice to fix it with tech or by changing the final product and doing real-time feature prioritization, and that is a fantastic exercise for teams. It's also an amazing exercise on measuring difficulty. A lot of things we thought were going to be effortless took a lot longer, and some we had to drop.
Code
You can see the GitHub repo code here.
The Game
You can also try the game here!.
