Open krulz.games and a ship is already flying. Nothing asked whether you wanted to play, because a start button is a question, and the honest answer to a question nobody asked is usually no. Removing the button removes the decision: by the time you have worked out that this is a game, you are holding the controls.
That is a one-sentence idea with a surprisingly long tail. Here is what it actually forced.
1. THE TEXT HAD TO GO SOMEWHERE ELSE
If the first screen is the game, the first screen has no prose in it. For a while that meant the strongest URL on the domain — the homepage, the one everything links to — carried a title, a description and three menu links. About ten words of indexable text, on the page most likely to be ranked.
The fix is boring and it is the right one. The play area is exactly one viewport tall, and a prose section sits directly beneath it. A visitor who came to play never scrolls and never meets the writing. A crawler, which has no viewport and no patience, reads all of it immediately. Nobody is being tricked: it is the same markup for both, just below the fold rather than in it.
This is worth stating as a general rule. An interface-heavy homepage is not an excuse for a contentless one. Put the words under the interface instead of leaving them out.
2. THE LAYERS ARE ABSOLUTE, NOT FIXED
The first screen is four stacked layers: a pixel grid behind the page, a play canvas, a separate canvas for the ship, and a grid in front used only when a run ends and the result has to cross over everything.
The instinct is to pin those to the window with
position: fixed. That is wrong here, and the reason only
shows up once you scroll. The play canvas scrolls with the document,
because it is in the document. Anything pinned to the window does not.
Scroll a hundred pixels and the frame has separated from the thing it
was framing.
So the layers are positioned inside the first screen rather than the browser window, and the whole screen moves as one piece. The routine that sizes the outer grid measures in first-screen coordinates rather than window coordinates, which in practice means it accounts for how far the page has scrolled instead of pretending it has not.
3. THE SHIP RUNS ON A DIFFERENT GRID
Everything in the game is drawn in game pixels, then scaled up by a whole number. The ship is the exception: it has its own canvas that runs in screen pixels.
It looks identical — same size, same colours. What changes is resolution. On the game grid the ship can only sit at whole game pixels, so at a scale of three it jumps three screen pixels at a time. Given its own canvas, its edge lands on a screen pixel instead, and it moves in thirds of a game pixel. The difference between those two is the difference between a cursor-following ship that glides and one that stutters, and it is invisible in a screenshot.
The general form of this: pick the grid per element, not per project. The one thing tracking a continuous input deserves the finer one.
4. THE WORDMARK IS A REAL LINK
The logo is drawn into a canvas, and the temptation is to attach a click handler and call it done. That breaks middle-click, ctrl-click, “open in new tab”, the status bar preview and every other affordance a real anchor gives you for nothing.
It is an anchor with a canvas inside, plus the studio name in a visually hidden span so the link has anchor text. On the homepage it points at the homepage, which means clicking it reloads the page — and reloading the page starts a new run. The one place where a link to yourself is not a bug.
5. THE TAB TITLE IS PART OF THE GAME
During a run the browser tab shows the result. That is a nice touch and it had a bug hiding in it: after the first run ended, the tab stayed on the game’s string forever. Whoever came back to that tab an hour later found a label that was not the name of the page.
At rest the tab is now the document’s own title again. If you are
going to write to document.title, you have to own the way
back.
The titles themselves are sentences and not shouting. Seven capitals in a row invites a search engine to rewrite your result for you, and the moment it does, you no longer control what people read before they click.
6. WHAT IT COSTS THE VISITOR
A page that runs a game on load spends CPU on someone who came for an email address. That is a real cost and it does not go away by being clever about it.
What it gets is restraint elsewhere. Sound is off until it is asked for; there is no autoplaying audio on arrival. There is a pause control in the same row as the menu, not buried. The page loads no third-party code, so the only thing spending your battery is the thing you can see. And every link out of the first screen is an ordinary link, so leaving is never harder than arriving.
Would I do it on a client’s site? No. It works here because the product is games, and the homepage is the shortest possible argument that the person behind it can make one. On a site selling insurance it would be a party trick with a battery cost.