Game Bot

Tags: Chatbot, Rust, MongoDB

TL;DR

A lot of clubs at NUS like to run events with certain games like scavenger hunts, bingo games, quests, etc. However, a lot of that is managed manually and is generally a headache to deal with. I wanted to build a chatbot using Telegram that made the process easier and more enjoyable for participants.

My first live service app

When hosting events, things can't break for too long. Participants expect things to work more than your teammates do, so keeping your app functional and alive when your users haven't been trained on how to use it is not an easy challenge for a small side project.

The Tech Stack

The original tech stack was Rust with Teloxide (Telegram Bot framework). Teloxide was amazing to work with and really ergonomic for quick development, with the single caveat that basically every month they released breaking changes in the form of a new version, changes that I sometimes had to adopt since I also had to keep up with Telegram's API changes.

The Goals

I wanted to build a resilient and user-friendly chatbot which would help boost engagement in our event's activities and increase enjoyment by the participants. Features like broadcasting when a team completed a certain challenge, including pictures that participants sent in, and a quest-based ranking system were all planned for the prototype.

The Outcomes

What all participants see - a live feed of game events

This app was prototyped in the span of about two weeks. It was deployed successfully for use in an event, and engagement levels were higher than expected.

What all teams see - a visual summary of their completed quests

Additional features not originally planned included graphics for a bingo board and generation of a post-event report (in case event leaders want to give prizes for winners).

The Lessons

The first test was a success and the event went smoothly. The one complaint I have is that configuration of the games took way longer than ideal, and similarly to my other project Wheel, it wasn't very user friendly. This is a pattern in the apps that I've designed so far, where the frontend user experience is smooth and streamlined, but the backend setup is assumed to be only done by me. It's something that I need to fix if I want my apps to be used in the future.

The Conclusions

I learned a lot about deploying and maintaining a live app to be used by members of the public outside my own team - even though it was only for the short period of a single event, ensuring that the app ran smoothly was quite stressful. This is a lesson in the importance of good logging and tests, so that for future projects, I know when something is going wrong.