Saltar al contenido
[ Suscribirse ]
[ Guía ]

Cómo llevar a internet el multijugador local de juegos retro con netplay

El netplay no le añade internet a cualquier juego retro. Sí puede sincronizar el multijugador local de un solo sistema, si ambos lados llegan con la misma base.

Redacción ItzLambo

Publicado 15/08/2026, 10:13 · 6 min de lectura

Compartir en WhatsApp Compartir en Facebook Compartir en Bluesky Compartir en X
Barra comparativa de opciones para alojar netplay, de reenvío manual de puertos a relay server.
Imagen: ItzLambo

Esta guía resuelve un caso concreto: dos personas a distancia que quieren compartir el multijugador local de un juego retro en un mismo sistema emulado. Netplay no convierte cualquier juego viejo en uno con funciones de red; RetroArch lo define como la sincronización por internet de instancias para emular el multiplayer local clásico de un solo sistema. Esa diferencia importa antes de mover un solo ajuste.

La condición no es comprar hardware ni asumir que toda plataforma entra. Es hacer que ambas instancias ejecuten exactamente la misma base y elegir una ruta de conexión que sí esté disponible. Si el objetivo es entender qué hace un núcleo, conviene empezar por la explicación de Libretro y los núcleos; aquí el trabajo empieza cuando ya se tiene el emulador y el contenido.

1. Delimita el juego y prepara dos configuraciones idénticas

Primero, confirma que lo que se busca es multijugador local de un solo sistema. La FAQ de RetroArch marca ese alcance y separa de él el cable link y los modos de red propios. También advierte que su modelo actual no es apto para PSX, Nintendo 64, Dreamcast, GameCube, Wii o 3DS. No es un detalle de compatibilidad menor: si el juego depende de una de esas rutas, esta receta no promete resolverlo.

Después, ambos jugadores deben tener la misma versión de RetroArch, la misma versión del core y el mismo contenido exacto. La documentación técnica explica por qué: el netplay presupone un core determinista, controles de gamepad o sticks analógicos y core y contenido idénticos en ambos extremos. No basta con que los dos hayan elegido el mismo título de memoria; el requisito publicado es más estricto.

  1. Acuerden quién será anfitrión y cuál contenido van a cargar.
  2. Comprueben en ambos lados la versión de RetroArch y la del core.
  3. Verifiquen que el contenido sea exactamente el mismo antes de abrir la sala.

Esta es la parte que evita el error más común: intentar arreglar una sesión inestable cambiando controles, cuando la condición inicial ya no coincide. La sincronización espera entradas retrasadas de la red y vuelve atrás para reproducirlas de nuevo con un estado consistente; por eso las diferencias de base no son un asunto cosmético.

2. Hospeda primero y elige la ruta de conexión con menos fricción

El anfitrión configura la red desde el menú de netplay, elige Start Hosting, carga el contenido y espera a que entren los demás. RetroArch indica que el host necesita aceptar conexiones entrantes por TCP 55435. Puede intentar abrir ese camino mediante UPnP; también existe el reenvío manual en el equipo de red.

Hay una alternativa pensada justo para no quedarse atorado ahí. La guía de inicio dice que, si el router no soporta UPnP, no se pueden redirigir puertos o simplemente hay duda sobre cómo hacerlo, se habilite Use Relay Server. Esa opción enruta ambos lados por uno de los proxies públicos. No hay base para prometer que UPnP dejó el dispositivo accesible desde internet: la propia documentación sólo dice que RetroArch lo intenta.

  1. El anfitrión inicia el hosting y carga el contenido acordado.
  2. Si la conexión directa no es una opción clara, activa el relay server antes de esperar al otro jugador.
  3. Deja que la otra persona entre a la sala; no cambien de core o contenido durante este proceso.

La comparación útil no es entre una opción “profesional” y otra “para principiantes”. Es entre la cantidad de configuración que exige cada ruta. El reenvío manual requiere crear una regla; UPnP es un intento automático; el relay existe para los casos en que abrir puertos no se puede o no se sabe hacer.

3. Entra a la sala y reparte los controles

Quien se conecta abre el menú de netplay, usa Refresh y selecciona la sala. Con contenido coincidente que ya esté escaneado o aparezca en el historial, RetroArch puede conectar de inmediato. Si no, indica cargar manualmente el core y el contenido e intenta la conexión. Si la sala exige contraseña, la pedirá: no es un paso que deba improvisarse a mitad de la partida.

Con la asignación automática, el anfitrión queda en el control 1 y el cliente en el 2. Para repartir más mandos existe Request Device, una opción avanzada que la documentación pone como ejemplo para cuatro jugadores desde dos instancias o para que quien se conecta solicite el control 1. Úsala sólo cuando la distribución automática no corresponda al juego; no es necesaria para una partida básica de dos personas.

  1. Actualiza la lista de salas en la instancia cliente y elige la del anfitrión.
  2. Si no conecta de inmediato, carga manualmente el core y el contenido que ya verificaron.
  3. Comprueba qué control ocupa cada lado antes de iniciar la partida.

Los estados guardados también merecen una frontera clara. Un save state no es lo mismo que guardar dentro del juego; en netplay de Mednafen, por ejemplo, se usan estados al conectar y cuando un jugador carga uno. Su documentación advierte que el ancho de banda es crítico, sobre todo con sistemas más nuevos y estados grandes. Es otro modelo técnico, basado en un servidor independiente, así que no conviene mezclar sus instrucciones con las de RetroArch.

4. Qué no hacer cuando la sesión no sale

No asumas que “retro” significa compatible. RetroArch excluye varias plataformas de su modelo actual y dice que no es emulación general de cable link; sólo anota excepciones concretas para Game Boy/Game Boy Color con los cores TGB-Dual y SameBoy. Tampoco confundas el multijugador local con un modo de red original: son categorías distintas desde el punto de partida.

  • No mezcles versiones de RetroArch, core o contenido. La coincidencia exacta es un requisito explícito.
  • No des por hecho que UPnP funcionó sólo porque RetroArch lo intentó; la documentación no confirma accesibilidad externa.
  • No empieces por Request Device si una asignación automática de host en control 1 y cliente en control 2 ya resuelve la partida.
  • No copies una guía de Mednafen como si fuera un ajuste de RetroArch. Mednafen documenta servidor independiente y uso de estados guardados al conectar.

La regla práctica queda más corta que la promesa del título: netplay sirve para reproducir por internet un multijugador local clásico dentro de sus condiciones, no para borrar las diferencias entre consolas, cable link y juego en red. Tener claro ese límite ahorra tiempo y hace que la partida que sí corresponde al modelo empiece con la misma pantalla, el mismo core y los controles donde deben estar. Para la diferencia entre formatos de contenido, queda como complemento esta guía sobre ROM e ISO.

[ Fuentes ]

  1. RetroArch Netplay FAQ · Libretro Docs
  2. Getting Started with Netplay · Libretro Docs
  3. Netplay Multiple Controllers · Libretro Docs
  4. RetroArch Netplay · Libretro Docs
  5. Netplay · Mednafen · 2024-03-19
El semanal

Lo que importó de verdad

Un correo por semana con las 5 noticias que mueven la industria y el mejor video vertical. Nada de refritos de notas de prensa.

Doble opt-in · Sin spam · Sin pop-ups en todo el sitio

[ Síguenos donde leas ]

Sin algoritmo que decida por ti: el correo y el RSS llegan enteros. En las redes publicamos los cortes.

En redes