Parte 7 — Multijugador y networking

⬅️ Volver al programa · 📚 Índice completo · ⏮️ Parte anterior

18 clases · rango 138–155 · Del socket al shooter en red: arquitecturas, MultiplayerAPI de Godot, RPCs, replicación de estado, predicción/reconciliación, rollback, servidores dedicados y seguridad

🧪 Laboratorio ejecutable: esta parte tiene un proyecto Godot real — labs/multijugador — con versión inicio/ (para completar) y solucion/ (referencia jugable), verificado en CI levantando un servidor y varios clientes de verdad.

Fuentes de referencia de esta parte:

• Joshua Glazer & Sanjay Madhav, Multiplayer Game Programming (Addison-Wesley).
• Glenn Fiedler, Gaffer On Games — artículos sobre networking.
• Valve — Source Multiplayer Networking y charlas de GDC sobre netcode.
• Documentación de networking de Godot 4 y Nakama.

🎯 ¿De qué trata esta parte?

El multijugador es uno de los retos más difíciles del desarrollo de juegos: internet añade latencia, pérdida de paquetes y tramposos, y hay que dar la ilusión de un mundo compartido en tiempo real pese a todo ello. Esta parte va de los fundamentos a un juego en red funcional, con Godot 4. Empezamos por la base: TCP vs UDP, latencia y jitter, y los modelos de arquitectura (P2P, cliente-servidor, servidor autoritativo) con sus ventajas e inconvenientes.

Luego construimos con las herramientas de alto nivel de Godot: MultiplayerAPI, RPCs, MultiplayerSpawner y MultiplayerSynchronizer, un chat/lobby paso a paso, y la replicación de estado para mover jugadores en red. Después llega lo difícil y lo que separa un juego amateur de uno pulido: predicción del cliente y reconciliación, interpolación/extrapolación, lag compensation y rollback netcode, servidor autoritativo con anti-cheat básico, serialización eficiente, matchmaking y NAT traversal, servidores dedicados headless, backends (Nakama, Steam) y seguridad. Cerramos con un capstone: un juego en red mínimo cliente-servidor.

🧩 Problemas que resuelve

• No saber elegir arquitectura (¿P2P o servidor autoritativo?) y pagarlo caro después.
• Movimiento en red "a saltos" por no interpolar ni predecir.
• Input que se siente lento porque todo espera al servidor (falta de predicción del cliente).
• Juegos fáciles de trampear por confiar en el cliente.
• No poder desplegar un servidor dedicado ni gestionar salas/matchmaking.
• Consumir demasiado ancho de banda por serializar mal el estado.

🎓 Resultados de aprendizaje

Al terminar la parte, el alumno podrá:

• Explicar TCP/UDP, latencia y los modelos de arquitectura de red de juegos.
• Usar la MultiplayerAPI de Godot: RPCs, spawner y synchronizer.
• Replicar estado y mover jugadores en red de forma fluida.
• Implementar predicción del cliente, reconciliación e interpolación de entidades.
• Aplicar lag compensation y entender el rollback netcode.
• Montar un servidor autoritativo con validación anti-cheat básica.
• Desplegar servidores dedicados y usar backends de matchmaking (Nakama/Steam).

🧱 Prerrequisitos

• Partes 0–3 (redes básicas de la Parte 0, determinismo y física fija de la Parte 3, escenas y movimiento).
• Soltura con señales, instanciado y máquinas de estado (Partes 1 y 5).
• Godot 4.x; para servidores dedicados, nociones básicas de terminal y despliegue.

📚 Las 18 clases

Has recorrido de los fundamentos al multijugador. Las siguientes partes del roadmap (game design, arte, plataformas, web, VR/AR, optimización, tooling y publicación) se construyen con este mismo formato.