Por qué empezar por aquí#
Estos conceptos valen para cualquier tecnología (Netcode, Mirror, Photon...). Entenderlos primero te ahorra elegir mal la herramienta y pelearte con bugs que en realidad son malentendidos de diseño.
Convertir un juego single-player en online no es "activar una casilla": afecta a cómo se mueve todo, quién decide qué y cómo se guarda el estado. Piénsalo desde el principio. Empieza con un prototipo mínimo (dos cubos sincronizados) antes de tocar tu juego real.
Cliente-servidor#
El modelo dominante. Un servidor manda (tiene la "verdad" del juego) y varios clientes se conectan a él. Los clientes envían sus intenciones ("quiero moverme a la derecha") y el servidor decide qué pasa y lo comunica a todos.
- Host: un jugador hace de servidor y cliente a la vez. Es lo más común en juegos indie (no necesitas alquilar servidores).
- Servidor dedicado: una máquina aparte, solo servidor, sin jugador. Más justo y escalable, pero cuesta dinero mantenerlo.
En P2P todos hablan con todos sin un servidor central. Es barato pero difícil de hacer justo (¿quién tiene razón si dos discrepan?) y vulnerable a trampas. Por eso la mayoría de frameworks modernos usan cliente-servidor, aunque el "servidor" sea uno de los jugadores (host).
Autoridad: quién decide la verdad#
Autoridad = quién tiene la última palabra sobre el estado de algo (dónde está un jugador, cuánta vida tiene).
| Servidor-autoritario | Cliente-autoritario | |
|---|---|---|
| Quién decide | El servidor valida todo | Cada cliente decide lo suyo |
| Resistencia a trampas | Alta | Baja (fácil de manipular) |
| Complejidad | Mayor (hay que predecir y reconciliar) | Menor |
| Uso típico | Shooters competitivos, cualquier cosa con ranking | Juegos cooperativos casuales, prototipos |
La regla práctica: si importa que no hagan trampas, el servidor manda.
Sincronización: mantener a todos de acuerdo#
Que el estado (posiciones, vida, puntuación) sea el mismo en todas las máquinas. Se hace con dos herramientas complementarias:
- Variables sincronizadas (state sync): un valor que se replica solo a todos (la vida de un jugador). En Netcode es
NetworkVariable, en Mirror[SyncVar]. - RPC (Remote Procedure Call): llamar a un método que se ejecuta en otra máquina. Para acciones puntuales: "dispara", "reproduce este efecto".
Usa variables sincronizadas para estado continuo que debe estar siempre correcto (vida, posición). Usa RPC para eventos puntuales que ocurren una vez (un disparo, una explosión). Mandar cada evento por variable, o cada estado por RPC, es nadar a contracorriente.
El enemigo: la latencia#
Entre que un cliente pulsa una tecla y el servidor responde pasan milisegundos (el ping). Si el jugador tuviera que esperar esa ida y vuelta para verse mover, el control sería intragable. Dos técnicas lo resuelven:
- Predicción del lado cliente: el cliente mueve su personaje inmediatamente, sin esperar al servidor, asumiendo que el servidor estará de acuerdo.
- Reconciliación: cuando llega la respuesta del servidor, si discrepa de lo que el cliente predijo, se corrige (idealmente sin que se note).
- Interpolación: los personajes de otros jugadores se muestran suavizados entre las posiciones que va mandando el servidor, para que no se vean a saltos pese a que los datos llegan a intervalos.
El servidor no procesa el juego "continuamente", sino en pasos discretos llamados ticks (p. ej. 30 o 60 por segundo). En cada tick recoge las entradas de los clientes, avanza la simulación y envía el nuevo estado. Un tick rate más alto = más precisión y menos latencia percibida, pero más ancho de banda y CPU. Es un equilibrio central en el diseño de red.
Ancho de banda: manda menos#
Cada dato que sincronizas cuesta red. Buenas costumbres:
- No sincronices lo que se puede calcular en cada cliente.
- Manda a cada jugador solo lo que le importa (interest management: no le cuentes lo que pasa al otro lado del mapa).
- Comprime: no necesitas 32 bits de precisión para todo.
Errores frecuentes (de concepto)#
- Diseñar el juego en single-player y querer "añadir red" al final.
- Dar autoridad al cliente en un juego competitivo (puerta abierta a trampas).
- Sincronizar por RPC lo que debería ser una variable de estado, o al revés.
- No prever la latencia y esperar respuesta del servidor para mover al propio jugador (control con lag).
Ponte a prueba#
Resumen#
El multiplayer moderno es cliente-servidor (a menudo con un jugador de host). El servidor tiene la autoridad si te importan las trampas. Sincronizas con variables de estado (continuo) y RPC (eventos puntuales), y combates la latencia con predicción, reconciliación e interpolación. Piénsalo desde el principio. Con esto claro, elige herramienta: empieza por Netcode for GameObjects o mira la comparativa.