Plan before you build
Break a real project into pieces before writing a single line of code
⏱ Est. ~7 min
01 · Read
The biggest mistake beginners make on a new project: they open a terminal and start writing code immediately.
Professionals do the opposite. They plan first — even if the plan is rough and changes later. Planning means thinking about what you're building before you ask Claude to build it.
This is even more important when working with AI. A clear plan produces excellent Claude Code output. "Build me a game" gets you something generic. "Build a server that manages game rooms, matches waiting players, and validates moves" gets you exactly what you want.
Key points
- Plan before you code — even a rough plan helps
- A clear plan produces better AI-generated code
- Break the project into layers: server, client, communication
- You're going to build a realtime multiplayer tic-tac-toe game with online matchmaking
02 · Read
Here's what we're building: a realtime multiplayer tic-tac-toe game. Two strangers visit the same URL, get matched up, and play a game in realtime. One player makes a move, and it appears instantly on the other player's screen.
A finished game has three layers: Server — the authority. It manages the board, enforces the rules, matches players, and detects wins. The server is always right. Players can't cheat because the server validates every move.
Client — the interface. The HTML page the player sees in the browser. It displays the board, captures clicks, and shows server updates.
Communication — the bridge. The WebSocket events flowing between client and server. When a player clicks a cell, the client sends a 'make-move' event. When the server validates it, it sends 'move-made' to both players.
Key points
- Server owns all game state — never trust the client
- Client displays the UI and captures user actions
- WebSocket events are the communication layer between them
- Server validates every move — prevents cheating
03 · Step-through
Walk through the three layers of any realtime app, and what each does in our tic-tac-toe game.
1. Server: the referee
Manages the board (a 3x3 grid), tracks whose turn it is, validates moves (is the cell empty? is it your turn?), detects wins and draws, and matches waiting players into game rooms.
2. Client: the screen
Displays the 3x3 game board as clickable cells. Shows status messages ('Waiting for opponent...', 'Your turn', 'You win!'). Sends events when the player clicks. Updates the board when the server sends changes.
3. Communication: the events
The contract between client and server. Player clicks 'Find Game' — client emits 'find-game'. Server matches two players — emits 'game-start' to both. Player clicks a cell — client emits 'make-move'. Server validates — emits 'move-made' to both. Game ends — server emits 'game-over'.
4. Matchmaking: the lobby
A waiting queue on the server. You click 'Find Game' and you join the queue. When a second player joins, the server pairs you both into a room, randomly assigns X and O, and starts the game.
5. Disconnect handling: graceful cleanup
When a player closes their browser mid-game, the server detects the disconnect and notifies the opponent. If they disconnect while in the queue, the server removes them. No zombie games, no stuck players.
04 · Code example
This is the event flow between two players and the server. Study it — this is the blueprint we're going to implement over the next 7 lessons.
Event flow: matchmaking to game over
Player A Server Player B
| | |
|--- find-game ---->| |
|<--- waiting ------| |
| |<--- find-game -----|
|<-- game-start ----|--- game-start ---->|
| (you are X) | (you are O) |
| | |
|--- make-move ---->| | (A clicks cell 4)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| |<--- make-move -----| (B clicks cell 0)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| ...more moves... |
| | |
|<-- game-over -----|--- game-over ----->| (X wins!)
| (you won!) | (you lost) |
Notice that every action goes through the server. Player A never talks directly to Player B. The server receives moves, validates them, and broadcasts results to both players. This is the standard architecture for any multiplayer game.
05 · Checklist
Make sure you understand the plan before you code. Check each one when you're comfortable with the concept.
- Server holds all game state — the board, whose turn it is, who's X and O
- Client just sends events (like 'make-move') and displays what the server tells it
- Matchmaking pairs two waiting players into a game room
- Every move is validated by the server before being shown to players
- When a player disconnects, the server cleans up and notifies the opponent
06 · Quiz
Why should the server validate moves rather than trusting the client?
- Server validation is faster than client validation
- The client doesn't have access to the game state
- Players can modify client code to cheat — the server is the only trustworthy authority
- WebSocket requires server-side validation
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.