We continue to tell how our laser quest with the destruction of the server was arranged. Start in previous .
In total, the backend of the game had 6 architectural units, which we will analyze in this article:
- Backend of game entities that were responsible for game mechanisms
- Backend and platform data exchange bus on VPS
- Translator from backend requests (game elements) to arduino and hardware on the site
- Arduino, which was responsible for controlling the relays, received commands from the translator and did the actual work
- Actual devices: fan, garlands, floor lamps, etc.
- Frontend - the site of the Falcon itself, from which players controlled devices
Let's go through each of them.
Backend of game entities
The backend was implemented as a spring boot application: it had several rest controllers, a websocket endpoint, and services with game logic.
There were only three controllers:
- Megatron. Through GET requests, the current page of Megatron was given: before and after turning on the power. Through the POST request, the laser fired.
- Mapping tilde pages to be rendered by page name. The tilde exports pages not with original titles, but with internal IDs and matching information.
- Captcha controller to serve pseudo-high server loading captcha.
Websocket endpoint was used to control gadgets: lamps, garland and letters. It was chosen to synchronously display to all players the current status of the device: whether it is on or off, active or not, what color of the letter is currently lit on the wall. In order to slightly complicate the task of turning on the laser, we threw authorization on the garland and the laser with the same login and password admin/admin.
Players could test it by turning on the garland and repeat the same with the laser.
We chose such a trivial login-password pair in order not to torment the players with unnecessary selection.
To make the task a little more interesting, the object IDs from mongodb were used as device IDs in the room.
ObjectId contains a timestamp: two random values, one of which is taken based on the device ID, and the second based on the pid process that generates it and the counter value. I wanted to make identifiers generated at regular intervals and with different pid processes, but with a common counter, so that the selection of the laser device identifier would be more interesting. However, in the end, everyone started with identifiers that differ only in the value of the counter. Perhaps this made the step too simple and did not require analysis of the structure of objectIds.
Translator from backend requests
, who dealt with timers and translated from game abstractions into a physical model. For example, "turn on the floor lamp" β "turn on relay N2".
The script connected to the RabbitMQ queue and passed requests from the queue to Arduino. It also implemented the logic of parallel switching on the light: together with some devices, the light turned on on them, for example, when the power was first applied to Megatron, it was illuminated by stage light. Lighting design for cinematography of the entire scene is a separate story about the great work of our co-producer of the project and production designer Ilya Serov, and we will tell about it in a separate post.
The translator was also responsible for the logic of starting the shredder on a timer and transmitting the image to the TV: the shredder start timer, the screaming capybara, the commercial at the end of the game.
How the Megatron Token Generation Logic Was Arranged
test shot
Every 25 seconds a new token was generated that could be used to turn on the laser for 10 seconds at 10/255 power. Link to .
Then the laser cooled down for 1 minute - during this time it was unavailable and did not accept new requests for a shot.
This power was not enough to burn through the rope, but any player could shoot from Megatron and see the laser beam in action.
The MD5 hashing algorithm was used to generate the token. And the scheme turned out MD5 from MD5 + counter + secret for a combat token and no secret for a test token.
MD5 is a reference to a commercial project done by Pavel, our backender. Just a couple of years ago, this project was using MD5, and when he told the project architect that it was an outdated encryption algorithm, they started using MD5 from MD5. Since we decided to do the most noob project, he remembered everything and decided to make a small reference.
combat shot
Megatron's combat mode is 100% laser power of 3 watts. This is enough for 2 minutes to burn the rope that held the weight to break the aquarium and flood the server with water.
We left a few hints on the projectβs github: namely, the token generation code, by which it was possible to understand that the test and combat tokens are generated based on the same counter indicator. In the case of a combat token, in addition to the counter value, a salt is also used, which is almost completely left in the change history of this gist, with the exception of the last two characters.
Knowing this data, it was possible to iterate over the last 2 characters of the salt and actually find out that numbers from Lost converted to 16-ary system were used for it.
Next, the players had to catch the value of the counter (by analyzing the test token) and generate a combat token using the next value of the counter and the salt selected in the last step.
The counter simply incremented with each test shot and every 25 seconds. We did not write about this anywhere, it should have been a small in-game surprise.
Service for interacting with captcha
In the game world, this was the same captcha that had to be loaded in order to turn on the fan and open the flipchart with a hint. Next to the camera was a laptop with load monitoring.
calculated what to display in the monitoring as the current load: temperature and CPU Fan. The metrics were transferred to the timebase database and rendered with graphana.
If in the last 5 seconds there were more than 50 requests to display captcha, then the load grew by a fix + a random number of steps. The calculation was that 100% load could be obtained in two minutes.
Indeed, there was more logic in the service than was displayed in the final game: we placed the monitor in such a way that only the rotation of the CPU Fan was visible.
At the beginning of the quest, they wanted to leave Grafana available from the Sokol website. But it also contained springboot metrics according to the backend application report, which we did not have time to clean up, so we decided to close access to it. And rightly so - even at the beginning of the quest, some players guessed that the application was written on the springboot framework and even dug up the name of some services.
Hosting and data bus
A tool for transferring information from the backend to the site, the VPS server on which RabbitMQ was launched.
Backend and data bus kept on . Its power was comparable to the computer that you saw on the screen: a 2-core VPS with two gigabytes of RAM. The tariff was taken for resources, since the peak load was planned for only a few days - this is what our clients do, who plan to load VPS for a short time. Then it turned out that the load is higher than we expected, and a fixed tariff would be more profitable. If you will make a quest, choose the tariffs of the line .
To protect the server from DDoSa, we used Cloudflare.
It is worth saying that VPS withstood everything with honor.
Arduino, which was responsible for controlling the relays, received commands from the translator and did the actual work
This is more the topic of the next article about the hardware part of the project: the backend simply sent requests to turn on a specific relay. It so happened that the backend knew almost all the entities and requests from it looked like βturn on this entityβ. We did this for early testing of the site (we havenβt collected all the Arduinos and relays yet), in the end we left everything like that.
Frontend
We quickly created the site on tilde, it took one working day and saved us 30 thousand of the budget.
Initially, we thought of just exporting the site and throwing in the logic we lacked, but ran into the terms of use, which forbade us to do so.
We weren't ready to violate the license, so there were two options: do it yourself, or contact Tilda directly, talk about the project, and ask for permission to change the code.
We chose the second option and they not only met us halfway, but even gave us a year of a free business account, for which we are very grateful to them. It was very embarrassing to show them the design of the Sokol website.
As a result, we screwed the js logic to the frontend for sending requests to elementary devices, slightly changed the styles of the on and off buttons for game elements.
Site design
History of searches, which is worth a separate chapter.
We wanted to create not just an old-fashioned site, but an absolutely sickening one that violates all the basic design rules. At the same time, it was important to maintain credibility: it had to not break the LOR of history, demonstrate the pretentiousness of the author, and the players would have to believe that such a site could exist and even bring customers. And brought! While the game was going on, we were asked twice to create websites.
At first, I did the design myself, trying to put in more gifs and shiny elements. But my designer husband with 10 years of experience looked over his shoulder and dismissed it as βtoo good.β To break design rules, you need to know them.
There are several combinations of colors that cause a persistent feeling of disgust: green and red of the same richness, gray and pink, blue plus brown. As a result, we settled on a combination of red and green as the basic colors, added GIFs with a cat and selected 3-4 photos of Sokolov himself from the photo stock. I had only a few requirements: a middle-aged man, in an ill-fitting suit a couple of sizes too big, and in a βprofessional studio photo shootβ pose. For the test, they showed it to friends and asked βhow are you?β.
In the process of developing the design, my husband had to lie down every half an hour, he began to fly. Pasha tried to open the developer console to most of the screen while he was finishing the frontend - taking care of his eyes.
Actual Devices
Fans and lights were mounted through solid-state relays so that they did not immediately turn on at full power - so that the power increase occurred in parallel with monitoring.
But we will talk about this in the next post, about the hardware part of the game and the actual development of the site.
Stay tuned!
Other articles about the quest with the destruction of the server
Source: habr.com