Third month of web debugging the board game in the browser. What takes so much time / Habr

Meanwhile, I come across posts on social media about how people are building games over the weekend with AI: 3D, multiplayer, published, and you can play them. We have the same tools, and I don't understand why they have weekends, while I have months.

We are still two people plus models in the project. The developer colleague maintains the engine and the network, while I handle everything visible on the screen and the game rules. The code is written by the models: I use Opus, and the colleague uses Opus and Astra. I can read the code, but I can't understand it, so the analysis will start from what I see on the screen for three months straight, like a day in the life of a groundhog.

Without the device, the article can't be complete: how the board communicates with the host or where everyone gets the same table image, you can't see from the screen. In such places, I'll insert quotes from colleagues or from the model description; I won't try to retell it myself.

Card movements

I choose a card from my hand, it lifts up and shows a preview. I take it with the mouse and place it on the table, and the fan closes behind it. When I release it, the card lands in the center, and the same card is laid out in the same place for the opponents. One second of the game, and I've long stopped seeing the card, only the seams between movements.

I wanted it like at the table

I've played a lot with my board game, and I wanted the browser to give the same feeling as holding cards at the table. I decided this early on, and from the first movements in the play area: the map on the screen flows from place to place along with the rotation and scale, without teleporting, so that the animations on the screen clearly show what is happening. The target arrow and the map with a pulsating path I saw in big PC card games. And no linear animations, they look unnatural.

Not everything from the table was worth bringing to the screen. I didn't animate the shuffling of the deck, it would only slow down the game. And lengthy game moments at the table got a quick playthrough on the screen.

What had to be invented for the browser

I didn't find a ready library that would move cards in the browser as they do on the table. I laid out the cards with layout, and all the paths were planned in advance: from where, to where, along which curve, through which intermediate states, and what the neighboring cards do during this time. For this purpose, an animation dictionary was created: dozens of modules from which each movement on the table is assembled.

Some things immediately stood out: card flipping, target arrow. But what you don't think about when playing at a physical table had to be worked out. A played card stands at a random angle so that the plays don't look like the same animation. For the discard, I worked out the view as a pile. A separate story is the entry of a card into the fan. At first, the card was inserted straight and then teleported behind the neighboring card that covers it. Then a curve appeared: the card comes from the side, over the fan, and dives under it at the top of the curve. The last card has its own exception: there's nothing for it to dive under, and the curve becomes straight.

Dealing with opponents was simpler. The opponent on the screen is a block, their cards are hidden, and it's meaningless to see the hidden fan. The card that goes to them flies into this block and disappears: it was taken from the table, and who took it is visible from the block.

It wasn't possible to consider everything in advance

Scenes moved onto the board using the same modules, and the first games showed how much the playfield didn't know about the table. In the playfield, the scene ended with the card landing. On the board, each place where a card lands requires its own state, which the game tracks and shows to everyone the same way.

Center of the table. I release the card, choose the card for which I pay, and on the opponents' screens nothing happens: as if I do nothing. At the same time, everything on my screen looked normal. It turned out that the table didn't know that the card was already in the center, and it was counting it in the deck: when I played a pair, the laid-out card teleported back into the deck and then came out to the center again. The same issue happened with the host, its "play the card" notification came to a card that was already in place. This was resolved by a fix in the engine: it now tracks cards laid out in the center so that the game maintains the table state and shows the same thing to everyone. I rarely dive into the engine, and this was one of those cases.

Turn state panel. It worked until the game started encountering situations that the panel didn't know about, and these states had to be added manually.

Discard pile. Cards in the discard pile changed their order or orientation, and the discard pile was reassembled through teleporting layers and positions.

DDoS via AI card. I attack DDoS on the AI release in the opponent's release zone, and the card gets discarded, although according to the rules, the AI card shouldn't be discarded and should return to the event deck. By the game's logic, the card was added to the event deck, while also lying in the discard pile. The table didn't count cards and didn't catch such duplicates, leading to more checks.

And a lot of other things.

Where did the third month come from

The project is divided into three parts based on its commit history. In June, I was working on the style and playfield: cards, hand, table, and animation dictionary. A colleague was setting up the monorepo, network, and lobby on the same days. In July and early August, the engine and table appeared, and on August 10th, the first playable game session took place, still without animations. From mid-August, the table started receiving animations from the playfield scene by scene: dealing, playing, drawing, arrow, pair, release, and defense. From this point on, the animations, logic, and their integration were being debugged to make everything fit seamlessly.

Screen check

I debug on the table: the same table and engine, only the game state is built from a preset, and one scene can be played as much as needed. I play a card, see what's wrong, describe the models, she fixes it, and I check again. I described what I saw to her for a long time. Then realized that interface animations can be written to the log: sent the log, and the model saw the same frames as I did with my eyes, and under long logs, it made its own analyzer that names problematic areas.