← Lab notebook

I Wanted to Make a Game. First, I Had to Learn Its Language.

7 min read

Three questions every game has to answer, the six words I had to learn, and what my first AI-built version got wrong.

My first tic-tac-toe had one bug that wasn't in the code. I clicked a square, and an X and an O landed on the board at the same instant. I couldn't tell which one was mine.

The first version of the game after one click: an X in the top-left corner and the computer's O in the centre, both placed at once, with the board already visible before any start screen.
Version one, August 18: one click, two marks. No start screen and no pause, so nothing told me which mark was mine.

The rules were right: tests ran every possible sequence of my moves against the computer, 569 games, and it never lost. But the game wasn't talking to me. It had no start, no clear turn, and no moment that said "you won, go again." I didn't have words for any of that yet, so I learned them. I started calling them "game grammar." That's my shorthand, not a formal standard.

Just want to play? Play tic-tac-toe. You don't need to read this first.

How do you start making a simple game?

Here's the order I use now. Copy it into your notes before you open an editor.

  1. Describe the goal and how a round ends.
  2. Sketch the start, play, result and replay moments.
  3. Build the smallest playable rules and controls, including what can't happen: once a round is over, every empty square locks.
  4. Show turns and results, then add effects that communicate real changes.
  5. Watch someone play it and fix what gets in their way.

My first version skipped step 2. The rest of this post is why that mattered.

Six words that made it click

Each term below comes with what it means in my tic-tac-toe.

  • Game loop: show the situation, take input, work out what happened, show the new situation. MDN's anatomy of a video game describes it in engineering terms. Tic-tac-toe: you pick a square, the game checks for a winner, the board redraws.
  • State: everything the game needs to remember right now. Tic-tac-toe: nine cells, whose turn it is, and the session score.
  • Scene: a distinct moment with its own job. Tic-tac-toe: title, playing, result. The result appears under the finished board, and Play again sends you straight back to playing.
  • HUD (heads-up display): the always-visible information layer. Tic-tac-toe: the status line ("X to move.") and the score.
  • Feedback: the game's direct answer to an action. Tic-tac-toe: the square fills and the turn message changes.
  • Juice: extra response on top of feedback, like motion, sound, particles or shake. Tic-tac-toe: almost none on purpose: the win line, and a quick pop-in for the newest mark.

Rule 1: A game tells you what happens next

Version one had no path through it. The board sat there on page load, and a finished game just stopped. The next day's rebuild added the path: title → playing → result → replay.

A diagram of the tic-tac-toe journey from title to play, result, and another round.
The whole journey, sketched before any single screen.
The current game's opening screen: a mode choice between playing the computer or two players, and a Start game button, with no board shown yet.
The rebuild starts with a choice instead of a board, so you know what kind of round you're in before it begins.

Rule 2: The screen answers questions before you ask them

At any moment, the screen should answer three questions. Whose turn is it? Where can I play? Who won?

In my version, a status line names the turn, the marks keep the history, and a line runs through the three winning marks.

A tic-tac-toe screen annotated with turn, available moves, mode, score, and replay controls.
Each piece of screen information answers the player's next question.

Some games draw the HUD as an overlay, like a score counter. Others build it into the world, like a sign by the road. The 2009 Chalmers thesis Beyond the HUD by Erik Fagerholt and Magnus Lorentzon gave me the vocabulary for that choice. It studies shooters, not board games.

"Where can I play?" has to work without a mouse too. Each cell is a real button, following the W3C button pattern. Tab moves a visible focus ring, and Space or Enter plays the square. Played squares drop out of the tab order.

A two-player game in progress with X in the top-left and top-middle, O in the two left-middle cells, and a thick blue focus ring on the empty top-right cell.
Keyboard players get the same answer to "where can I play?": a focus ring on the next open square.

Rule 3: Every action gets an answer

Feedback comes first. Place a mark, and the square changes. Complete a row, and the game names the winner and draws the line.

The first rebuild's result screen: a card reading 'X wins — the top row.' with Play again and Back to start buttons sits over the board, covering and dimming the green line through the three X marks.
The first rebuild's result scene named the winner and offered the next step, but the card sat over the winning line and dimmed it. I only noticed while taking this screenshot.

Juice is the layer on top. The "Juice it or lose it" demonstration adds it step by step to a plain Breakout-style game, and its companion repository lets you inspect each technique.

A layered diagram placing movement, sound, particles, and shake above essential game information.
A legible response first; effects only where they add meaning.

My version stays quiet on purpose: no sound, particles or shake. Starting there made me ask what each effect would tell the player.

How AI built it, and where it got stuck

AI coding agents wrote the rules engine, the page and the tests, working from a design spec I gave them. A separate AI QA pass checked the result and played it in a browser. I kept an evidence log of every command and failure.

  • It followed my spec too well. The spec said the computer's reply "lands in the same tick as the human move" and ruled out an artificial delay or a spinner. The agents built exactly that. The QA pass later noted that the instant reply made it hard to tell your move from the computer's. That's the bug from the top of this post, and my spec caused it.
  • Its first tests failed. Eight of 17 engine tests failed on the first run because of how the test runner unpacked the winning-line data. The agent fixed the test setup, and all 17 passed.
  • A second agent caught what the first missed. The builder added a font link that failed the type check. The separate QA pass blocked the release until it was fixed.

The lesson for me: the AI built my grammar mistakes as faithfully as my good ideas. It couldn't tell me the game felt confusing until something played it.

Update: I fixed both problems

Writing this post exposed two problems, so I fixed them before publishing.

  • The computer now takes a visible turn. After your move, the status line says "Computer's turn — O is choosing…" for under half a second, and the board locks. Then the O appears with an outline, so you can see which mark is new. That reverses my own spec's no-delay rule.
  • The result card moved below the board, so the winning line stays fully visible.
The fixed game right after the player's first move: an X in the top-left corner, an empty board otherwise, and the status line reading 'Computer's turn — O is choosing…'.
One click, one mark. The computer's turn now gets its own moment on screen.
The fixed result screen: a green line through three X marks on the top row, fully visible, with the 'X wins — the top row.' card and its Play again and Back to start buttons placed below the board.
The winning line now stays in full view, and the next step sits right under it.

What I haven't tested yet

An AI QA pass has played this game. A person hasn't, and that's a different test. The next step is a simple, uncoached session of the kind the Nielsen Norman Group describes: three people, three tasks each (pick a mode, finish a round, start another), and a note wherever they hesitate. Until then, the design is a hypothesis.

It's a starting order for small projects. Real-time movement or a longer story will change the questions. That's what my platformer research digs into.

You can help: play a round, then send me the first moment you weren't sure what to do. A DM or a comment on @ai.maker.lab on Instagram reaches me.

AI coding agents built the game, and AI and automation helped produce this article. I own AI Maker Lab and take responsibility for the final wording and source checks.

Sources

Keep reading