How this works

This explains the whole thing in plain language. You do not need to read it to make a game — Claude handles all of it. It is here for when you want to know what is actually going on.

The shape of it

There is one website. It lists your games and lets people play them. Each game is a folder. Adding a folder adds a game to the site; there is no list to update and nothing to register.

apps/web/games/connect-four/     one game, one folder
  game.config.ts                 its card in the arcade
  logic.ts                       the rules
  logic.test.ts                  the rules, proven
  Game.tsx                       what you see
  components/                    the pieces of what you see

Everything else in the repository is the framework: the parts every game gets for free. The arcade page, the header, the phone handling, the sounds, the multiplayer plumbing. You should almost never need to touch it, and Claude will ask before it does.

Rules and looks

Every game is split in two, and the split matters more than it sounds.

logic.ts is the rules. Whose turn it is, what moves are allowed, who wins. It is written as plain functions with no interface attached, which means it can be tested — a computer can play through a thousand situations and check the rules hold. It also means the same rules can run on the server, which is what stops anyone cheating.

Game.tsx and components/ are the looks. The board, the colours, the animations, the feel.

This is also why you can have two Claude windows open at once: one on the rules, one on the looks. They never touch the same file.

What the tests are for

The tests are not homework. They are how you find out the rules work without playing a hundred games by hand.

A good test reads like a sentence about your game: "you cannot play in a full column", "four in a row wins", "the board fills up and it is a draw". If you read the test names and recognise your game, the tests are doing their job.

When you change a rule later, the tests tell you immediately if you broke something you had forgotten about. That is the whole point.

Multiplayer

When two people play, the game is not running in either of their browsers. It runs on the server.

Someone taps a column. Their browser asks the server "can I do this?" The server looks up the game, runs your applyMove from logic.ts, decides, and saves the new board. Everyone watching gets the new board instantly.

Three things follow from that:

• Nobody can cheat, because nobody's browser gets to decide anything.
• You can refresh mid-game and pick up exactly where you were.
• The rules exist in one place. There is no second copy to keep in step.

The cost is about a sixth of a second per move. Fine for board games, cards and party games. Not fine for something twitchy — say so if you want to make one and we will build the fast path.

Draft and live

Every game has a status. draft means it is playable by anyone with the direct link, but does not appear on the front page. live means it is on the front page.

That is how you share a half-finished game with a friend for a playtest without it being on the front page of your studio. /ship flips it when you are ready.

Supabase and Vercel

Supabase is the database. It remembers players, scores, and live game rooms. It is free at this size. If nobody visits for a week it may pause itself — unpausing is one click in its dashboard.

Everyone who opens the site quietly becomes a player, with a name like "Wise Ibex" and an emoji. No sign-up, no password, no email. Your friends open a link and they are playing. They can change the name if they want.

Vercel is what puts the site on the internet. When you ship, it takes the code and makes it live at daligames.xyz, usually in under a minute.

When something looks wrong

Say pnpm doctor, or just tell Claude something is wrong and it will run it.

It checks everything that can break quietly: whether the database is awake, whether the keys are where they should be, whether the live site can actually reach the database, whether anything got left unprotected, and whether git is set up so your changes actually publish. Each thing it finds comes with the one action that fixes it.

It is worth running when something feels off and you cannot say why. Most of the alarming-looking failures are one of about eight boring causes.

When something goes wrong on the live site

Say /fix-the-website. Claude works down the likely causes in order and knows where to look.

The one thing worth knowing yourself: open Vercel, go to Deployments, find the last one that worked, and press Instant Rollback. The site goes back to how it was in a few seconds. Then fix the problem calmly, with nothing broken while you work.

One that catches everyone: the free database goes to sleep after about a week with no visitors, and everything fails at once. It looks catastrophic. It is one button in the Supabase dashboard marked Restore.

Two windows at once

You can run two Claude Code windows on this folder. Tell each one what it owns — "you take the rules", "you take the look". They write down which files they are working on in .daligames/claims.md and stay out of each other's way.

That works because both of them follow the convention, not because anything enforces it. So do not put two windows on the same file, and it will be fine.