Planea antes de construir
Descompón un proyecto real en piezas antes de escribir una línea de código
⏱ Estim. ~7 min
01 · Leer
El mayor error de los principiantes al empezar un proyecto nuevo: abren la terminal y se ponen a escribir código de inmediato.
Los profesionales hacen lo opuesto. Primero planean, aunque el plan sea tosco y luego cambie. Planear significa pensar en qué estás construyendo antes de pedirle a Claude que lo construya.
Esto importa todavía más cuando trabajas con IA. Un plan claro produce un código de Claude Code mucho mejor. «Constrúyeme un juego» te da algo genérico. «Construye un servidor que maneje salas de juego, empareje a jugadores en espera y valide movimientos» te da exactamente lo que querías.
Puntos clave
- Planea antes de codear — incluso un plan tosco ayuda
- Un plan claro produce mejor código generado por IA
- Divide el proyecto en capas: servidor, cliente, comunicación
- Vas a construir un juego de tic-tac-toe multijugador en tiempo real con emparejamiento en línea
02 · Leer
Esto es lo que vamos a construir: un juego de tic-tac-toe multijugador en tiempo real. Dos desconocidos visitan la misma URL, los emparejamos y juegan en vivo. Cuando un jugador hace un movimiento, aparece al instante en la pantalla del otro.
El juego terminado tiene tres capas: Servidor — la autoridad. Maneja el tablero, aplica las reglas, empareja a los jugadores y detecta la victoria. El servidor siempre tiene razón. Los jugadores no pueden hacer trampa porque el servidor valida cada movimiento.
Cliente — la interfaz. La página HTML que ven los jugadores en el navegador. Muestra el tablero, captura los clics y refleja las actualizaciones del servidor.
Comunicación — el puente. Los eventos WebSocket que fluyen entre cliente y servidor. Cuando un jugador hace clic en una casilla, el cliente envía un evento 'make-move'. Cuando el servidor lo valida, envía 'move-made' a ambos jugadores.
Puntos clave
- El servidor maneja todo el estado del juego — nunca confíes en el cliente
- El cliente muestra la UI y captura las acciones del usuario
- Los eventos WebSocket son la capa de comunicación entre ambos
- El servidor valida cada movimiento — evita trampas
03 · Paso a paso
Recorre las tres capas de cualquier app en tiempo real y qué hace cada una en nuestro tic-tac-toe.
1. Servidor: el árbitro
Maneja el tablero (cuadrícula 3x3), lleva el turno, valida movimientos (¿la casilla está vacía? ¿es tu turno?), detecta victorias y empates, y empareja a los jugadores en espera dentro de salas de juego.
2. Cliente: la pantalla
Muestra el tablero 3x3 como casillas clicables. Muestra mensajes de estado ('Esperando rival...', 'Tu turno', '¡Ganaste!'). Cuando el jugador hace clic, envía un evento. Cuando el servidor envía un cambio, actualiza el tablero.
3. Comunicación: los eventos
El contrato entre cliente y servidor. El jugador toca 'Find Game' — el cliente emite 'find-game'. El servidor empareja a dos jugadores — emite 'game-start' a ambos. El jugador toca una casilla — el cliente emite 'make-move'. El servidor valida — emite 'move-made' a ambos. El juego termina — el servidor emite 'game-over'.
4. Matchmaking: el lobby
Una cola de espera en el servidor. Cuando tocas 'Find Game', entras a la cola. Cuando un segundo jugador se une, el servidor los empareja en una sala, asigna X y O al azar e inicia el juego.
5. Manejo de desconexión: limpieza elegante
Si un jugador cierra el navegador durante el juego, el servidor detecta la desconexión y avisa al rival. Si la desconexión es en la cola, el servidor lo saca de ahí. Sin juegos zombis ni jugadores atascados.
04 · Ejemplo de código
Este es el flujo de eventos entre dos jugadores y el servidor. Estúdialo — es el plano de lo que vamos a implementar en las próximas 7 lecciones.
Flujo de eventos: del emparejamiento al fin del juego
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) |
Fíjate que toda acción pasa por el servidor. El jugador A nunca le habla directamente al jugador B. El servidor recibe los movimientos, los valida y transmite el resultado a ambos jugadores. Esta es la arquitectura estándar de cualquier juego multijugador.
05 · Lista de verificación
Antes de codear, confirma que entiendes el plan. Marca cada concepto cuando te sientas cómodo con él.
- El servidor guarda todo el estado del juego — tablero, turno actual, quién es X y quién es O
- El cliente solo envía eventos (como 'make-move') y muestra lo que el servidor le indica
- El matchmaking empareja a dos jugadores en espera dentro de una sala de juego
- Cada movimiento lo valida el servidor antes de mostrarse a los jugadores
- Si un jugador se desconecta, el servidor limpia y avisa al rival
06 · Quiz
¿Por qué el servidor debería validar los movimientos en lugar de confiar en el cliente?
- La validación en el servidor es más rápida que en el cliente
- El cliente no tiene acceso al estado del juego
- Los jugadores pueden modificar el código del cliente para hacer trampa — el servidor es la única autoridad confiable
- WebSocket requiere validación del lado del servidor
Otras lecciones de este capítulo
⚠ La experiencia interactiva completa necesita JavaScript. Actívalo y vuelve a cargar la página.
※ Este es un proyecto educativo independiente — no es un producto oficial de Anthropic. Claude™ es una marca registrada de Anthropic, PBC.