Burn the Tickets: a story about a web game for the dev conference
Hi ✌
My name is Sergey, and I’m a designer, frontend developer, and marketing technology team lead at ManyChat.
ManyChat is a platform for automating business communications in messaging apps (Instagram, Facebook, WhatsApp, iMessage) that helps businesses grow by building meaningful communication with their customers. It is used by over 1 million companies around the world, from a New Jersey bakery to the Philippine Department of Education.
My team Mart (marketing, technologies, art) is responsible for building ManyChat’s brand image for a global audience before they register on the platform. The team is made up of a designer, two frontend developers, and me. With the help of a clear and catchy design, we communicate the value of our product to users. Also, we launch different web projects to increase engagement.
Today, I’m going to tell you about a side project we worked on. We created a web game about burning tickets to promote the ManyChat HR brand and used it as an entertaining interlude between talks at the dev conference. This game helped us to transmit the values of the agile development methodologies we use at the company in a playful way.
Context and Task
ManyChat participated in a dev conference as a general partner a year ago. Several people from the company were speakers there, at the booth we told people about the company, held a quiz, asked developers to fix bugs blindly (their colleagues gave the instructions to guide them), and raffled off prizes. It was around the time when COVID restrictions were beginning to ease, but many people still preferred to participate in conferences online, so our team had to come up with an online activity for the participants.
Limitations:
- Only two weeks left before the conference
- Resources: me, another frontend developer, and a part-time backend developer
We started thinking about the concept. The storyline must be connected with ManyChat or its culture and make sense for all developers. To get people more involved, we decided to run a competition between the participants with prizes for the winners, of course.
We decided to use a readymade gaming algorithm from an open source in order to meet the deadline, but we shifted the standard mechanics into an unusual context, linking them by some kind of metaphor. We approached the creative process from the mechanics’ perspective by looking at the available algorithms and thinking about a story they could represent.
Creative Ideas
1. Minesweeper
The field represents software, and the mine is a bug. The player needs to find the bugs without being blown up by them. If you get blown up, the application crashes and a stock video explosion fills the screen, just like in YouTube videos with descriptions like ‘Kernel Panic’ or ‘System Error.’
2. Remember and repeat
Pictures containing elements of web application architecture or the HTTP request processing pipeline are briefly displayed and must then be restored from memory by the player.
3. Kill dev words
You need to type out words from a workflow that drop onto the screen without missing anything while maintaining your work-life balance and avoiding typing any terms related to your personal life that appear. For example, you would need to type out words like ‘deadline,’ ‘technical debt,’ and ‘bubble sort,’ but leave out words like ‘coffee,’ ‘cat,’ and ‘garbage sorting.’
4. Doodle jump
An octopus jumps from one platform to another, overcoming obstacles to help a startup grow (our company logo is an octopus).
5. Match 3
The field is a backlog, and the elements represent different tasks. You need to line up 3+ tasks of the same type to get rid of them.
It took us around 2 days and precisely 2 meetings to come up with our shortlist and choose the idea. We met for a preliminary briefing with the DevRel (developer relations) team and discussed the context and the initial ideas. Then we split up, looked for algorithms and mechanics, tried to match them to different metaphors, and wrote everything down in a table. The same group met for a second time, ran through the ideas from the table with the help of a leader from the engineering community, and settled on the Match 3 mechanics. On the one hand, the metaphor isn’t too niche or technical and will be interesting to play for lots of people without serious skills. On the other hand, it’s already well developed in its current form, without too many unresolved issues (for example, the need to explain how to play and win), and it will be interesting to develop further.
The next steps were as follows: the DevRel team came up with the types of tasks and the ‘titles’ the players who complete the most tasks of a certain type get, we designed the layouts, got to grips with the algorithm, and built the web application.
Game Design
Players have a one-minute sprint to burn through as many backlog tickets as possible. You need to swap the positions of tickets to create a row of three or more of the same type. It made them burn, but, of course, three new tasks appeared in their place. You can play as many times as you like, trying to complete as many tasks as possible in the sprint.
Players’ top sprints will appear on a leaderboard. The leaderboard charts the results throughout the day of the conference, starting at 09:00 when the game is announced and ending at 19:00, and when all the talks are over, we announce the results. The top 5 players who complete the most tasks in their best sprint are declared the winners and receive LEGO sets. If a winner participates in person, their prize will be awarded at the afterparty. If they participate online, it will be sent by courier the following day.
Players don’t need to participate in the leaderboard. They can simply play for their own enjoyment, and the game will remain available for casual players even after the end of the conference.
At the end of each sprint, players will receive a ‘title’ based on the type of ticket they burned the most with a corresponding level:
- bugs — Fixer
- code review — Team Lead
- tech debt — Uncle Bob
- onboarding — Mentor
- testing — Minesweeper
- refactoring — Smell Keeper
For example, if a player has burned 150 tickets in a sprint and most of them are in the onboarding category, they will get the title of ‘Mentor 150 level’. This result can be shared on social networks, which means that other people who are not attending the conference will also be able to visit the site and play.
The design concept and key layouts were ready within a few hours. We checked the visual style and basic user flow with the team and immediately began development, gradually adding screens, states, and steps. New challenges awaited us in the development process, and there was only a week and a half left to overcome them.
Development
The client side is based on React and Next.js, as they are generally accepted in the team and everything is clear with the frontend side. There is a basic game algorithm that just needs to be adapted as well as a user flow, key layouts, and a resource. We know what to do and how to do it.
The situation with the backend is more complicated. There is no dedicated resource here, just a part-time PHP developer (we usually use Node.js within the team, but there were no resources available for it at the time). To enter the leaderboard, you need to register in the game so we know to who to give the prizes. We also need to be able to save players’ results to create the leaderboard. It would be a big advantage if we could create an anti-cheat functionality, as it would be quite easy for a developer to make a server request and send a fake high score from the game without actually playing it. We decided to turn a blind eye to this until the final moment and act as though there was a chance that nobody will try to cheat.
We came up with a fallback option in case we ran out of resources on the backend, and this was as follows: remote participants don’t feature in the leaderboard, and simply play to keep themselves entertained between presentations and share their results on social networks. Offline participants can take part in the competition at our booth, there will be a computer with a large screen where you can play a sprint game. Someone will write down the results in a notebook (or table), and the best results will be updated on a screen with the prizes awarded at the end of the day.
Of course, we also had the option of not creating a leaderboard at all.
But we still had a part-time backend resource, and we came up with several simplifications and creative workarounds so that we could implement all of our ideas. Another backend developer also volunteered to assist us in his spare time.
Workaround №1
Registration via a Telegram bot. This allowed us to save on client-server interaction, validation and error handling, and the associated UI: the bot provides everybody with a unique code that is used for authentication.
Workaround №2
To save on infrastructure, we deployed the backend API handlers directly on the testing machine of one of the developers, but we proxied requests through the API endpoints to Next.js so that the internal implementation wasn’t visible from the outside. There are not many participants, so we will be able to withstand the load and this will suffice for one day.
Workaround №3
Manual anti-cheat. As we already mentioned, we behaved as though everything would somehow be okay without any anti-cheat mechanism until the last moment, but this isn’t how things work. The basic functionality of the game was ready by the middle of the second week, and we posted it to the #backend_community channel in our in-house Slack. The team started to play and compete, and our teammate Ivan took a huge lead within 29 minutes.
We had of course realized that this would happen, but this was when it became impossible to ignore.
Our team didn’t have any expertise in online games and there wasn’t much time left, so we no longer had the option of bringing in full-time reserch. We considered the risks of implementing our own anti-cheat mechanism to be acceptable.
I’ll explain why anti-cheat is so complicated. We looked at the following options:
- You could encrypt the result of the game before sending it to the server, add salt to it and make it as incomprehensible as possible in the request. With this method, the encryption and salt are still only implemented on the client side and you only need to run a simple backtrace to find out exactly how it was encrypted. This means you can do your own encryption and send any fake result to the server the same way.
- You could send every turn of the game to the server instead of the final result, which is then calculated on the server side. The problem here is that it only takes a little perseverance to figure the process out and send fake ‘lucky’ moves to the server individually. The server will still calculate the fake total result and put it on the leaderboard.
- You could write a fully-fledged verification algorithm on the server that checks each move by taking into account the previous one, in order to check whether the move would be possible in the game conditions. To do this, you would need to write a fairly complex algorithm, check various corner cases, and test it properly. There is no time for this.
We, therefore, arrived at the following compromise:
- We log each turn
- We put some basic checks in place:
☞ Ensuring that moves are made no faster than is physically possible in terms of clicking on the cards
☞ Ensuring that the moves made match the end result
☞ Ensuring that the result doesn’t exceed the number of points that can be physically scored in one minute with the most favorable arrangement at the beginning, with a margin of error of an order of magnitude
☺ This method allows us to catch ‘entry-level cheaters’ - Next, we manually check the moves of players who are performing well in real time in order to catch the ‘high-level cheaters’. On the day of the conference, from 09:00 to 19:00 (while the competition is open), we follow the leaderboard and check everyone who enters the top five, analyzing their moves and results to see whether they could occur or if there are anomalies. Looking ahead, there were some suspicions, but these didn’t prevent the team from working on other tasks in parallel.
Conference day
We announced the game 15 minutes early and the first player registered at 08:45. One of the team’s representatives was present at the booth, and two more were on standby in our general online chat, ready to respond promptly.
We banned the first ‘high-level cheater’ at 13:33 — everyone else had already been filtered out by the entry-level anti-cheat mechanism. After a few more bans we added another general rule: limiting the number of possible moves in a single game. Most games have 35–55 moves, but some have thousands of moves. We set a limit with a margin of error of an order of magnitude and there were fewer manual checks.
Over the course of the day, we analyzed the games of everybody who topped the leaderboard and, in most cases, found no anomalies.
There was one guy who sat right next to the stand with his laptop and tried to hack the system. He didn’t succeed 😎
129 people were included in the leaderboard. The last one registered at 18:06. We identified 15 cheaters and banned them. There was one incident where somebody was banned in error:
He wrote to us in the chat, and we looked at his moves and found the game that had been flagged as suspicious: he had amassed 238 points by the first move. Looking more closely, we noticed that only the final 9 seconds of the game had been logged and there were no other anomalies. It appears that there was a network lag. We apologized and unbanned the player within 15 minutes. He continued to play and eventually took 3rd place.
In just 10 hours, the players in the leaderboard played 3,279 games, with an average of 25 games per person. The maximum number of games per participant was 211 (this represents three and a half hours of pure playing time, and this was the same person who placed third and who we banned by mistake. He got back to playing in no time).
The top score was 329, and the average was 166. The top five had the following results:
- 1st place: 339 score, 119 games
- 2nd place: 330 score, 131 games
- 3rd place: 326 score, 211 games
- 4th place: 314 score, 112 games
- 5th place: 306 score, 204 games
At 19:00 we froze the leaderboard, quickly built the list of winners, and announced the results. We awarded prizes to the participants who were there in person and contacted the remote participants to send their prizes.
People continued to play without participating in the ranking. Anton wrote the following one week later:
Conclusions
We developed a game to support our participation in a conference. We had limited resources and lots of cool ideas and we wanted to make the game quickly and successfully. Despite the limitations and problems in the process, we managed to implement all our plans and enjoy both the process and the result. We submitted the game to various competitions and rankings and received a number of mentions and awards, most significantly an honorable mention and mobile of the week from Awwwards.
Credits and Links
Anya Kryukova — stakeholder (DevReal team), copywriting
Andrey Marshantsev, Sergey Malyshev — backend
Vova Lukashov — frontend
Sergey Lisovsky — design, frontend
