How Browser Games Actually Work

Understanding this changes how you prompt Claude for games

Most people open Claude Code and type "build me a snake game" and get something that mostly works but has weird bugs they cannot describe or fix. That happens because they cannot see the structure underneath.

This lesson gives you that structure in plain English. No code. Just the mental model that lets you describe games accurately and fix them when they break.

The Game Loop

Every browser game runs on a loop. A function that calls itself 60 times per second, forever, until the game ends.

Each time the loop runs it does three things in order. It reads input to check what the player is pressing or clicking right now. It updates state to move things forward by one frame, which includes moving the character, checking collisions, updating the score, and advancing any timers. Then it draws by clearing the screen and redrawing everything in its new position.

This is called the game loop. It runs using a browser function called requestAnimationFrame which asks the browser to call your function before the next screen repaint, resulting in smooth 60fps motion.

When you tell Claude "the snake should move one grid square every 150ms" you are describing how often the update step moves the snake within that loop. Claude knows what that means and implements it correctly.

State

State is everything the game currently knows about itself.

In a Snake game, the state includes the current position of every segment of the snake's body, the direction the snake is moving, the position of the food, the current score, and whether the game is running, paused, or over.

In a Memory Match game, the state includes which cards are face up, which cards have been matched, how many attempts the player has made, and whether a flip is currently animating.

Every time something happens in a game the state changes. The game loop reads the current state and draws it to the screen.

When you describe your game to Claude you are describing the state and the rules that change it. You do not need to use the word "state." Just describe what the game remembers and what causes it to change.

Input

Input is how the player controls the game.

For keyboard games, Claude listens for keydown events and updates the state accordingly. Arrow key pressed means update the direction in state. Space bar pressed means toggle pause in state.

For mouse and click games, Claude listens for click and mousemove events and maps them to game actions.

For mobile and touch games, Claude listens for touchstart and touchmove events. This is a separate system from keyboard events which is why you need to explicitly ask for mobile controls if you want them.

When prompting Claude, always specify the control scheme. "Arrow keys to move" or "WASD controls" or "click to jump" or "swipe to change direction on mobile." All of these map to different event listeners and Claude needs to know which ones to add.

Collision Detection

Collision detection is how a game knows when two things have touched each other.

There are two types used in the games in this course.

Grid-based collision is used in Snake and Wordle-style games. Everything exists on a grid with integer coordinates. The snake head is at position row 5 column 3. The food is at row 5 column 3. They match, so a collision happened. This is simple and precise.

Bounding box collision is used in Brick Breaker and Pong. Every object has a rectangle defined by its X position, Y position, width, and height. If two rectangles overlap then a collision occurred. Claude calculates this automatically when you describe what should happen on collision.

When describing a game to Claude, say what should happen when things collide. "When the ball hits a brick, the brick disappears and the ball reverses its vertical direction." Claude knows how to implement the collision check from that description.

Canvas vs DOM

This is the single most important technical choice in a browser game.

DOM-based games build the game using standard HTML elements like divs, and use CSS to position and style them, and JavaScript to update their positions and appearance. Good for: card games, word games, grid games, and quiz games. Easier for Claude to build and easier to style to match your brand.

Canvas-based games draw everything onto a single HTML canvas element using pixel-level commands. Good for: arcade games with moving objects, physics, particle effects, and smooth animation. Harder to style but essential for real-time action games.

You do not choose which one to use in code. You describe the game and Claude picks the right approach. But understanding the difference helps you know what to expect and what kinds of visual customisation are possible.

DOM games are easier to style with your brand colours and fonts because they use regular CSS. Canvas games need specific instructions about colours and fonts because Claude draws them programmatically in JavaScript.

What This Means for Your Prompts

When you describe a game to Claude, describe four things.

What exists in the game and what properties each thing has. What the player can do and what controls they use. What happens when things interact covering win, lose, score, and sound. What gets shown on screen at each moment covering menus, gameplay, pause, and game over.

These four descriptions map directly to state, input, collision detection, and the draw step of the game loop. Claude converts them into working code.

The next lesson puts this into practice with the master game build prompt.