Skip to content
alzy.kr
Devlog

The day I deleted the sky from the game board

There used to be a sky over the TAMNA board. Three translucent clouds drifted from left to right, two gulls crossed on a diagonal with their wings beating, and clicking the lighthouse sent its light around once. I had even left a comment in the CSS saying the opacity was low enough that it would not get in the way of play. In the end I deleted all of it. That day the change removed a little over a hundred and thirty lines from two files and added two. The work itself was small; what stayed with me was the rule I took away from it. Here is what I put in, what I saw, and what I kept.

Written: 2026-06-14

I wanted the board to feel alive

There were three pieces to it. Three clouds, each with its own height, size and speed, taking thirty-four, forty-six and forty seconds to cross once. Their opacity stayed between 0.16 and 0.2, and they faded out at both edges so that no cloud would hang awkwardly in an empty corner of the board. Two gulls, at twenty-six and thirty seconds, with the travel on a parent animation and the wing beat on a child animation, so the wings moved while the bird moved. And a lighthouse you could click, whose light swept a full turn over 1.4 seconds and then faded away.

The sky sat at the very end of the SVG, so it painted after the tiles and looked like it was passing over the island. To keep it from stealing clicks I made the whole layer ignore pointer events, and every animation stopped for players who ask their system for reduced motion. The game is set on an island ringed by sea, so I wanted the air above the board to move a little. That was the entire reason, and nothing about the implementation was broken.

Looking at it changed my mind

The check was simple: capture the board while it moved, across several frames, and lay them side by side. What that showed me was that the gull did not read as a bird. At that size and that faintness, a line crossing the screen reads as a smudge, or as a ghost the display left behind. The moment a player stops to wonder whether something is stuck on their screen, the effect has already failed.

The clouds had the same problem. Over open water they were fine, but the instant one reached the tiles it became noise sitting on top of the resource art and the numbers people have to read. The lighthouse beam was the plainest failure of the three. The board is drawn from directly above, while the beam lit it from the side. The two viewpoints did not agree, so every rotation made the mismatch more obvious. Code doing exactly what I told it to do is not the same thing as the screen looking right, and it was the captures that showed me the difference.

What I removed, and what I kept

Out went three animation definitions — the drifting cloud, the gull with its wing beat, and the lighthouse beam — along with the sky layer inside the board itself. The component also lost a piece of state it had been holding for no reason other than restarting that one rotation. Across the two files it came to a hundred and thirty-one deletions against two additions, which is close to a plain return to what was there before.

Some things stayed. The lighthouse standing still, the basalt reef at its feet, and the ring of waves around the sea. None of them move, and what does move sits outside the tiles. Something that holds still can be looked at when you feel like looking at it. As long as it does not pull the eye on its own schedule, it is free to add a sense of place. The question I ended up asking was not whether a detail was pretty, but whether it got in the way of reading the board.

Where the motion went instead

I do not think motion is the problem in itself, which is why I moved it rather than throwing it away. The harubang stone statue, the clouds, the sun and moon, the sailing boat — the living picture now lives on the sign-in screen. The sun and moon there are not decoration: their position follows the actual time of day and refreshes every minute, so signing in at night gives you a night sky.

The same motion works there because there is nothing on that screen to read. No pieces to count, no next square to find. The movement is allowed to be the content. The board is the opposite: which number is on which tile, whose road that is, where you are allowed to build — almost every pixel exists in order to be read. The same cloud means one thing in one place and the reverse in the other.

The rule I kept

First, the only things allowed to move on the board are things that carry information. Whose turn it is, what just changed, where you can click — if a motion says none of that, I now treat it as noise.

Second, I do not decide until I have looked at it myself, across several frames. The person who wrote "this will not get in the way" in a comment was me, and that judgement was wrong. What I believe I built is not evidence of what ends up on the screen.

Third, deleting is worth it. A change that removes a hundred and thirty-one lines and adds two can be a better day than one that ships a feature. Since then, whenever I want to add something to the board, I capture it, lay the frames out, and decide after that.

TAMNA