Existen varias formas de juego multiplayer, desde el Link cable
que utilizaba la GameBoy
, las consolas con varios puertos para mandos, las consolas con capacidades de red en LAN
y finalmente las consolas con acceso a Internet
. En este artÃculo exploraremos las distintas posibilidades multijugador que presenta ArkOS
en la R36S.
El artÃculo se compone de varias secciones:
- Compatibilidad NetPlay
- NetPlay: Misma LAN
- NetPlay: Distinta LAN
- NetPlay: Distinta LAN, Relay server
- NetPlay: Distinta LAN, custom Relay server
- NetPlay: Partida privada
- NetPlay: Adhoc mode
- NetPlay: Spectator mode
- Game Share
- Ports/Consolas LAN
- Sistemas >= 32 bits
- PSX
- Nintendo64
- DreamCast
- Pruebas
- Debug
Compatibilidad NetPlay:
NetPlay
es el sistema multijugador de RetroArch
que nos permitiará emular el tener dos mandos conectados a la consola pero por Internet.
Cuando utilizamos NetPlay
es importante tener en cuenta algunos requisitos y limitaciones del sistema:
- La conexión de red debe ser estable, asà que debemos evitar descargar contenido de
Torrents
, videos deYouTube
o similar. - No permite
Save states
. NetPlay
solo está disponible para ciertas combinaciones deEmulador/Core
, en la documentación deArkOS
podemos ver los emuladores y cores soportados. Luego tendremos que averiguar si dichoEmulador/Core
tiene capacidades de netplaying.- Los sistemas entre consolas deben coincidir en cuanto a versiones de
ArkOS
,RetroArch
,RetroArch core
,ROM version
y en caso de utilizar un emulador fuera deRetroArch
, la versión de dicho emulador.
En mi caso me voy a centrar en Genesis/MegaDrive, NES, SNES y CPS3
, para la emulación de dichos sistemas tenemos las siguientes opciones:
-
- RetroArch: genesis_plus_gx , genesis_plus_gx_wide , picodrive
- Mednafen
-
NES :
-
SNES :
- RetroArch: snes9x , snes9x2010 , snes9x2002 , snes9x2005
- Mednafen
-
CPS3 :
- RetroArch: fbneo , fbalpha2012 , fbalpha2016, fbalpha2018
Las consolas 3D como N64, Dreamcast, PS1, etc
, están descartadas mediante NetPlay
ya que utilizarán su propio sistema en caso de disponer de él.
ArkOS version:
Start -> Distro Version
R36S | R36H |
---|---|
RetroArch version:
Retroarch -> retroarch -> Information -> System Information -> RetroArch Version
Retroarch -> retroarch32 -> Information -> System Information -> RetroArch Version
R36S | R36H |
---|---|
RetroArch core:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Information -> Core Information -> Core Version
R36S | R36H |
---|---|
Si no fuese la misma versión, procederÃamos a la actualización de RetroArch
en las dos consolas:
Retroarch -> retroarch -> Online Updater -> Update Installed Cores
Retroarch -> retroarch32 -> Online Updater -> Update Installed Cores
R36S | R36H |
---|---|
ROM version:
Cuando se inicia un partida NetPlay
, el jugador que va a unirse puede ver la versión de la ROM
, pero no he sido capaz de averiguar la versión local, solo podemos saber si es la misma versión uniéndonos a la partida sin que dé error:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Netplay -> Refresh Netplay Host/LAN List
Nos desplazamos a la partida y presionamos SELECT
Configuración previa:
Un aspecto importante es el username
ya que este se utilizará para presentar las partidas disponibles:
Retroarch -> retroarch -> Settings -> User -> Username
Retroarch -> retroarch -> Configuration File -> Save Current Configuration
Retroarch -> retroarch32 -> Settings -> User -> Username
Retroarch -> retroarch32 -> Configuration File -> Save Current Configuration
R36S | R36H |
---|---|
NetPlay: Misma LAN
Si ambos jugadores están en la misma red local se conectan directamente(mayor rendimiento), podemos comprobar esto accediendo por SSH
previamente habiendo
habilitado los servicios de la consola
y arrancando un tcpdump
:
tcpdump -ni wlan0 port 55435
00:14:52.195324 IP 192.168.69.206.52630 > 192.168.69.208.55435: Flags [S], seq 3310496430, win 29200, options [mss 1460,sackOK,TS val 225288 ecr 0,nop,wscale 7], length 0
El proceso de conexión es el siguiente:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Refresh Netplay LAN List
NetPlay: Distinta LAN
En caso de no estar en la misma LAN, RetroArch
intentará abrir el puerto mediante UPnP IGD
, en caso de no conseguirlo siempre podremos hacerlo nosotros mismos manualmente accediendo a la interfaz de configuración del router.
Podemos comprobar esto accediendo por SSH
previamente habiendo
habilitado los servicios de la consola
y arrancando un tcpdump
:
tcpdump -ni wlan0 port 55435
00:49:30.275473 IP 79.117.65.106.41566 > 192.168.69.208.55435: Flags [P.], seq 536:556, ack 8595, win 1424, options [nop,nop,TS val 744804 ecr 743766], length 20
El proceso de conexión es el siguiente:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Refresh Netplay Host List
Una manera sencilla de comprobar si el puerto ha sido abierto ya sea por UPnP IGD
o manualmente es mediante
esta web
donde debemos cambiar el puerto al 55435
.
NetPlay: Distinta LAN, relay server
Si incluso después de haber intentado redirigir el puerto mediante UPnP IGD
o manualmente tenemos problemas, podemos utilizar un servidor intermedio en Internet
que reenvÃe el tráfico y actúe a modo de puente entre los dos jugadores. Una conexión remota mediante servidor Relay
se verÃa de este modo en tcpdump
:
tcpdump -ni wlan0 port 55435
01:05:54.009817 IP 34.140.160.20.55435 > 192.168.69.208.42310: Flags [P.], seq 161:181, ack 7299, win 1002, options [nop,nop,TS val 3474243896 ecr 989709], length 20
El proceso de conexión es el siguiente, ahora veremos que en la partida aparece la palabra (Relay)
:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Network -> Use Relay Server
Player1: Netplay -> Network -> Relay Server Location: Western Europe
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Refresh Netplay Host List
NetPlay: Distinta LAN, custom relay server
Si tenemos problemas de latencia en los Relay
servers públicos, podemos montar nuestro
propio servidor
, este debe ser instalado en un servidor en Internet
, si lo montamos en nuestra red LAN
no funcionará si alguno de los dos jugadores se encuentran en esta misma red.
Creamos el usuario con el que correrá el servicio:
adduser relay
Clonamos el repositorio del proyecto:
su -l relay
git clone https://github.com/libretro/netplay-tunnel-server.git
Instalamos la unidad de SystemD:
su -l
cp /home/relay/netplay-tunnel-server/retroarch_tunnel_server.service /etc/systemd/system/retroarch_tunnel_server.service
chmod 664 /etc/systemd/system/retroarch_tunnel_server.service
systemctl daemon-reload
Comprobamos manualmente que el software corra sin problemas:
python3 -OO /home/relay/netplay-tunnel-server/retroarch_tunnel_server.py
[*] Tunnel server listening on: ::|55435
[*] Tunnel server listening on: 0.0.0.0|55435
Arrancamos el servicio:
systemctl enable retroarch_tunnel_server.service
systemctl start retroarch_tunnel_server.service
Comprobamos que esté el socket a la escucha:
netstat -nputa | grep 55435
tcp 0 0 0.0.0.0:55435 0.0.0.0:* LISTEN 4055287/python3
tcp6 0 0 :::55435 :::* LISTEN 4055287/python3
NOTA: Si procede filtraremos el acceso al puerto mediante iptables
.
El proceso de conexión será exactamente igual a cuando utilizábamos un Relay
público pero con la diferencia de que tendremos que indicar que vamos a utilizar nuestro propio server y la IP
de este.
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Network -> Use Relay Server
Player1: Netplay -> Network -> Relay Server Location: Custom
Player1: Netplay -> Network -> Custom Relay Server Address: IP
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Refresh Netplay Host List
NetPlay: Partida privada
Cuando hosteamos una partida podemos ver que aparece en
esta web
:
Para que la partida no quede expuesta en Internet
de forma pública tenemos dos opciones, protegerla mediante password o no anunciar la partida.
Proteger por password:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Network -> Server Password: PASSWORD
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Refresh Netplay Host List
Eliminar el password de la partida ha resultado ser imposible, la única manera ha sido accediendo por
SSH
y editando el fichero ~/.config/retroarch/retroarch.cfg
:
vi ~/.config/retroarch/retroarch.cfg
netplay_password = ""
No anunciar la partida:
Si no anunciamos y los jugadores se encuentran en distintas redes, tendremos que pasarle la
IP WAN
o en mi caso el nombre de dominio que resuelve a dicha IP WAN
, al otro jugador para que pueda conectar.
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Network -> Publicly Announce Netplay:: No
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Connect to Netplay Host: WAN_IP/DNS
NOTA: Si la partida es local, seguiremos viéndola en Netplay -> Refresh Netplay LAN List
, incluso con el anuncio deshabilitado.
AdHoc/GameShare pitfalls:
Existe la posibilidad de crear partidas
Adhoc
en las que no requieren de un AP
para conectar los jugadores ya que una de las consolas montará un AP
al que conectarán las demás, este mismo mecanismo es el que se utiliza también en el modo
GameShare
.
Este sistema tiene un requisito importante y es que el chip Wifi
debe poder configurarse en modo AP
, en caso contrario fallará. En mi caso tengo la R36S
con un dongle USB
con el chip
Realtek RTL8188
y la R36H
con el
MediaTek MT7601UN
.
El chip Realtek RTL8188
es capaz de configurarse en modo AP
mientras que el MediaTek MT7601UN
no.
NetPlay: Adhoc mode
Mediante el sistema Adhoc
de ArkOS
podremos montar un AP
en la propia consola para que el resto de jugadores se conecten, eliminando de este modo la necesidad de un Router/AP
externo, todo esto de forma automática. El único factor a tener en cuenta es que el chip Wifi
debe poder configurarse en modo AP
.
El procedimiento es el siguiente:
Player1: La consola que actuará a modo de AP arranca el juego
Player1: Justo cuando le damos a la A para arrancar el juego mantenemos presionado el botón X
Player1: 1 - Host an adhoc Netplay Session
Player2: Entramos en el mismo juego que el Player1
Player2: Justo cuando le damos a la A para arrancar el juego mantenemos presionado el botón X
Player2: 2 - Connect to an adhoc Netplay Session
Podemos ver en el video como funciona este modo y el AP
que ha montado la consola.
AdHoc mode | AdHoc AP |
---|---|
![]() |
NetPlay: Spectator mode
El modo Spectator
de ArkOS
permite a jugadores unirse a partidas en modo RO
, es decir quien se una a la partida, solo podrá ver un streaming sin poder actúar sobre ella. Este funciona en cualquier configuración de las anteriores, pero según sea modo Modos normales
/AdHoc
se habilitará de una forma u otra.
Modos normales:
El proceso de conexión es el siguiente:
Arrancamos el juego
Presionamos: SELECT + X(RetroArch) / SELECT + START + R1 + L1(RetroArch32)
Presionamos: B
Player1: Netplay -> Host -> Start Netplay Host
Player2: Netplay -> Network -> Netplay Spectator Mode: Yes
Player2: Netplay -> Refresh Netplay LAN List
En el primer video se puede ver como incluso seleccionando el modo multijugador, Player2
solo es espectador, no es capaz de mover el personaje.
Spectator mode: Multi | Spectator mode: Single |
---|---|
AdHoc:
Como ocurrÃa en el modo AdHoc
, el chip Wifi
debe poder configurarse en modo AP
.
El procedimiento es el siguiente:
Player1: La consola que actuará a modo de AP arranca el juego
Player1: Justo cuando le damos a la A para arrancar el juego mantenemos presionado el botón X
Player1: 1 - Host an adhoc Netplay Session
Player2: Entramos a RetroArch
Player2: Justo cuando le damos a la A para arrancar el juego mantenemos presionado el botón X
Player2: 3 - Spectate an adhoc Netplay Session
Pero parece que nunca encuentra la partida a pesar de haberse creado el AP
.
Spectator mode: Adhoc | Spectator AP |
---|---|
![]() |
Tanto en Modos normales
como en AdHoc
es posible asignar un password de acceso al modo Spectator
, si lo configuramos, este tendrá el mismo problema que el password de las partidas normales, no será posible borrarlo una vez habilitado. Tendremos que acceder por
SSH
y editar el fichero ~/.config/retroarch/retroarch.cfg
:
vi ~/.config/retroarch/retroarch.cfg
netplay_spectate_password = ""
Game Share:
El
Game Share
de ArkOS
nos permite compartir un juego con nuestros compañero de juego, para ello montará una partida AdHoc
.
Las únicas restricciones de este sistema son que el jugador debe estar en el mismo emplazamiento fÃsico que nosotros para poder conectar con el AP
que monta, que el juego sea de un solo fichero, es decir que no sea multi-disco y que el chip Wifi
pueda configurarse en modo AP
.
El procedimiento es el siguiente:
Player1: La consola que actuará a modo de AP arranca el juego
Player1: Justo cuando le damos a la A para arrancar el juego mantenemos presionado el botón X
Player1: 4 - Game Share Mode
Player1: 1 - Share current game with Client
Player2: Entramos a RetroArch
Player2: Justo cuando le damos a la A para arrancar mantenemos presionado el botón X
Player2: 4 - Game Share Mode
Player2: 2 - Share game from Host
Aunque yo no he conseguido que funcione de ninguna manera, siempre dá error y el cliente se queda colgado. En cambio el AP
podemos verlos sin problemas desde el móvil.
GameShare mode | GameShare AP |
---|---|
![]() |
Ports/Consolas LAN:
Todos los juegos de PC
portados mediante
Ports
con capacidades de juego LAN
y las consolas que también soporten el multigaming en LAN
deberÃan de funcionar bajo la R36s
, pero la R36S
no tiene potencia suficiente para correr las consolas de esas generaciones, asà que nos centraremos en los Ports
.
Podemos ver una lista de juegos de PC
con soporte multiplayer en LAN
en
este enlace.
Half-life
es un buen ejemplo que además está disponible mediante Ports
, su instalación está detallada en
este artÃculo anterior.
En el video podemos ver como se juega en LAN
:
Se intentó utilizar software como ZeroTier
o Hamachi
para tunelizar el tráfico LAN
a través de Internet, se habilitó el tráfico MultiCast/BroadCast
y se pushearon rutas pero todo fué en vano.
Sistemas >= 32 bits:
Como ya hemos comentado NetPlay
solo está disponible bajo ciertas combinaciones de Emulador/Core
, en la documentación de ArkOS
podemos ver los
emuladores y cores soportados.
Luego tendremos que averiguar si dicho Emulador/Core
tiene capacidades de netplaying.
ArkOS
nos permite ejecutar juegos de distintas formas, una de ellas es a través de RetroArch
y el Core
correspondiente y la otra es mediante un emulador StandAlone
, además algunos emuladores pueden estar disponibles tanto como Core
de RetroArch
como en formato StandAlone
.
En el caso de Nintendo64
además del Core/Emulador
también encontraremos distintos Video plugins
, estos no afectan al NetPlay
pero es necesario comentarlo para que quede claro cada una de las opciones disponibles mostradas por ArkOS/EmulationStation.
Cabe destacar que la mayorÃa de emuladores funcionan mas rápido en modo StandAlone
pero son mas dificiles de configurar ya que cada uno funciona con su sistema, interfaz o ficheros de configuración.
PSX:
Soporte NetPlay
en PSX
:
Emulator | Core | NetPlay | RetroArch Shortcut |
---|---|---|---|
RetroArch32 | pcsx_rearmed | No | SELECT + START + R1 + L1 |
RetroArch | duckstation | No | SELECT + X |
RetroArch | swanstation | Unknown | SELECT + X |
DuckStation | NULL |
No | NULL (SELECT + START: Exit) |
Existe na versión de DuckStation
modificada con soporte para NetPlay
, pero la
implementación de HeatXD
está estrechamente ligada a la interfaz gráfica Qt
, es decir, es parte de la GUI
. No está integrada en el backend del emulador ni en el modo nogui.
También existe este
frontend para DuckStation
pero está en fase Alpha
y tiene el mismo problema que la versión modificada de DuckStation
, requiere de un servidor gráfico arrancado.
Nintendo64:
Soporte NetPlay
en Nintendo64
:
Emulator | Core | NetPlay | Video plugins | RetroArch Shortcut |
---|---|---|---|---|
RetroArch32 | parallel_n64 | No | Glide64 , Gln64, Rice , Angrylion | SELECT + START + R1 + L1 |
RetroArch | parallel_n64 | No | Glide64 , Gln64, Rice | SELECT + X |
RetroArch | mupen64plus_next (GLES3) | No | Glide64 | SELECT + X |
RetroArch | mupen64plus (GLES2) | No | Glide64 | SELECT + X |
Mupen64plus/Rice | NULL |
No | Rice | NULL (SELECT + START: Exit) |
Mupen64plus/Glide64mk2 | NULL |
No | Glide64mk2 | NULL (SELECT + START: Exit) |
Mupen64plus/GlideN64 | NULL |
No | GlideN64 | NULL (SELECT + START: Exit) |
Si decidimos cambiar el Video plugin
, recordad que hay que guardar los cambios y reiniciar el juego para que aplique:
Core Options -> Manage Core Options: Save Game Options
Según como ejecutemos el juego bajo RetroArch
la opción de configuración cambiará:
RetroArch32: parallel_n64 -> GFX Plugin
RetroArch: parallel_n64 -> GFX Plugin
RetroArch: mupen64plus_next -> RDP Plugin
RetroArch: mupen64plus -> RDP Plugin
NOTA: Cuando ejecutamos Mupen64plus
en modo StandAlone
, siempre ejecutamos Mupen64plus
pero se le pasa como argumento --gfx
un módulo distinto.
Ha habido intentos de NetPlay
en Parallel
pero nunca se consiguió que fuese un sistema determinista, finalmente descartando la idea. En cuanto a Mupen
podemos ver que se puede compilar con la
opción NETPLAY
, pero parece ser un modo básico en pañales que no gestiona lobbys
, conexiones, ni nada de nada.
Si que hay una
versión en Android
que parece funcionar, pero seguramente se haya escrito toda la parte de código de NetPlay
que falta.
DreamCast:
Soporte NetPlay
en DreamCast
:
Emulator | Core | NetPlay | RetroArch/RetroRun/Flycast Shortcut |
---|---|---|---|
RetroArch32 | flycast32_rumble | Yes* | SELECT + START + R1 + L1 |
RetroArch32 | flycast_xtreme | Yes* | SELECT + START + R1 + L1 |
RetroArch32 | reicast_xtreme | Yes* | SELECT + START + R1 + L1 |
RetroArch | flycast_rumble | Yes* | SELECT + X |
RetroArch | flycast | Yes* | SELECT + X |
RetroRun32 | flycast32_rumble | Yes* | SELECT + X |
RetroRun32 | flycast_xtreme | Yes* | SELECT + X |
RetroRun32 | reicast_xtreme | Yes* | SELECT + X |
RetroRun | flycast_rumble | Yes* | SELECT + X |
RetroRun | flycast | Yes* | SELECT + X |
FlyCast | NULL |
No | SELECT + START + R1 + L1/SELECT + START/SELECT + X |
DreamCast soportaba dos modos multijugador:
- Multiplayer: Dos mandos conectados a la consola.
- Internet game: Se marcaba un número de teléfono mediante modem para acceder a
Internet.
RetroArch
es capaz de montar partidas online, pero no mediante el sistema NetPlay
, si no mediante configuración modem del juego. El sistema es batante inestable debido a que los servidores funcionan muy mal(con nuestro servidor propio mostrado mas abajo, no ocurre), la cuestión es que yo solo he conseguido maljugar un par de veces, haciendo la experiencia insoportable.
En este video podéis ver el comportamiento habitual, rara vez conecta y si llegase a hacerlo serÃa injugable, con lageos y desconexiones:
NOTA: Los parámetros de conexión son los por defecto a excepción del nombre y el prefijo que creo que solo debe cumplir que sean dos dÃgitos. La selección de la partida he mirado que las dos consolas tuvieran una velocidad de conexión aceptable y me he asegurado de entrar en la misma partida en las dos consolas.
A partir de la versión de Flycast >= v2.5
incorpora
DCNet
que funciona mucho mejor y soporta
mas de 30 tÃtulos
, por desgracia la versión que trae ArkOS
es del 16/03/2025
mientras que DCNet
fué incluÃda el 7/05/2025
.
También es posible montar nuestro propio servidor, pero cada juego requiere del suyo propio, en mi caso voy a montarlo para Quake3.
Añadimos el usuario con el que correrá el proceso, le asignamos un password y cambiamos la shell a bash
para que sea mas cómodo:
useradd -m gameserver
passwd gameserver
chsh gameserver
Bajamos el servidor:
cd /home/gameserver
wget dc.loc-os.com/quake3dc-server.tar.xz
tar xvf quake3dc-server.tar.xz
cd quake3dc
chmod 700 q3ded
Instalamos las dependencias:
cat dependencias.txt
apt install lib32z1-dev screen
Editamos la configuración, según el tipo de partidas que queramos servir, editaremos un fichero u otro:
vi baseq3/ffa.cfg
set sv_hostname "AlfaExploit Server"
set g_motd "Welcome to AlfaExploit-DC Server"
Indicamos la IP
a la que debe bindearse:
vi ffa_server.sh
net_ip="192.168.69.4"
Cambiamos el propietario y el grupo del directorio:
chown -R gameserver:gameserver /home/gameserver/quake3dc
Según el tipo de partidas que queramos servir, ejecutaremos un script de arranque u otro:
su -l gameserver
cd quake3dc
chmod 700 ffa_server.sh
./ffa_server.sh
Trying to start Dedicated Quake III Arena Server/n/n
Date : date '+%m.%d.%y' /n
Basepath : /home/gameserver/ /n
IP : 192.168.69.4 /n
Port : 27960 /n
###################################### /n
To Attach the screen use $ screen -list/n
$ screen -r PID.q3a-ffa/n/n
To detach press ctrl + a + d/n
or for qwertz strg + a + d
Podemos ver la sesión de Screen
donde se ha lanzado el servidor:
screen -ls
There is a screen on:
1416429.quake3dc (29/06/25 18:03:45) (Detached)
1 Socket in /run/screen/S-gameserver.
Si nos attacheamos podremos ver el arranque del servidor:
screen -x
------ Server Initialization ------
Server: dc_map02
Loading dll file qagame.
Failed to load dll, looking for qvm.
Loading vm file vm/qagame.qvm.
VM file qagame compiled to 1500845 bytes of code
------- Game Initialization -------
gamename: baseq3
gamedate: Mar 14 2000
Warning: cvar "dedicated" given initial values: "1" and "0"
------------------------------------------------------------
InitGame: \.Admin\N/A\g_needpass\0\gamename\baseq3\gamestartup\06-29-2025 18:34:00 \bot_minplayers\2\sv_allowDownload\0\sv_privateClients\0\mapname\dc_map02\protocol\43\sv_keywords\dreamcast\version\Q3 1.16n linux-i386 Mar 14 2000\capturelimit\10\g_maxGameClients\4\sv_floodProtect\1\sv_maxRate\3000\sv_hostname\AlfaExploit Server\timelimit\30\fraglimit\0\dmflags\0\g_gametype\0\sv_maxclients\4
Warmup:
0 teams with 0 entities
12 items registered
-----------------------------------
-----------------------------------
***** Finished Parsing \maprotation\ffa.cfg *****
***** Finished parsing ffa.cfg *****
Hitch warning: 632 msec frame time
Resolving master3.idsoftware.com:27950
master3.idsoftware.com:27950 resolved to 192.246.40.56:27950
Sending heartbeat to master3.idsoftware.com:27950
Resolving dc.dreamcast-talk.com:27950
dc.dreamcast-talk.com:27950 resolved to 100.10.54.70:27950
Sending heartbeat to dc.dreamcast-talk.com:27950
Resolving master.ioquake3.org:27950
master.ioquake3.org:27950 resolved to 192.241.238.177:27950
Sending heartbeat to master.ioquake3.org:27950
Resolving dpmaster.deathmask.net:27950
dpmaster.deathmask.net:27950 resolved to 107.161.23.68:27950
Sending heartbeat to dpmaster.deathmask.net:27950
Resolving master.onlineconsoles.com:27950
master.onlineconsoles.com:27950 resolved to 167.114.173.38:27950
Sending heartbeat to master.onlineconsoles.com:27950
Ctrl+a+d
Comprobamos que se haya bindeado:
netstat -nputa|grep 27960
udp 0 0 192.168.69.4:27960 0.0.0.0:* 1443553/q3ded
Redirigimos el puerto: 27960/UDP
en el router en caso de haberlo montado en nuestra casa y al rato deberÃamos de ver nuestro server en la web:
https://dc.dreamcast-talk.com/q3/q3masterlist.html
Si la consola conecta desde la misma red donde está el servidor puede ocasionar problemas debido al hairpinning , en tal caso o conectamos las consolas por otra red o montamos el servidor en algún hosting.
Si las dos consolas salen por la misma conexión a Internet
también puede ser problemático, en tal caso podemos hacer tethering-Wifi mediante el teléfono móvil para una de ellas.
En mi caso con el servidor en local y las dos consolas compartiendo salida hacia Internet
no he tenido problemas.
Como podemos ver en el siguiente video, el resultado es infinitamente mejor que con los servidores públicos, sigue funcionando mal, pero al menos ahora llega a conectar:
Una alternativa serÃa utilizar
Flycast Dojo
pero no está soportado nativamente por ArkOS
y seguramente dependa de un servidor gráfico para funcionar, asà que queda descartado en la R36S.
También existe este
frontend para Flycast
pero está en fase Alpha
y requiere de un servidor gráfico arrancado.
Pruebas:
En las explicaciones anteriores sobre el uso de NetPlay
solo se ha utilizado Contra/NES
a modo de ejemplo, en estos videos veremos varios juegos de distintas plataformas funcionando con NetPlay
.
Genesis | NES |
---|---|
SNES | CPS3 |
---|---|
Debug:
RetroArch
:
Si tenemos problemas conectando con las partidas, podemos comprobar que se hayan publicado en la web
lobby.libretro.com
También podemos comprobar la redirección del puerto 55435
en el router.
E incluso podemos acceder por
SSH
a las consolas y analizar el tráfico mediante tcpdump
:
tcpdump -ni wlan0 port 55435
Una caracterÃstica bastante interesante cuando estamos realizando pruebas es habilitar los detalles de NetPlay
:
Settings -> User interface -> On-screen notifications -> Notification visibility:
Display netplay ping
Extra netplay notifications
Si entramos a una partida AdHoc
pero hemos seleccionado un juego distinto al de la consola que actúa a modo de AP
, veremos algo parecido a esto:
Si la conexión AdHoc
experimenta muchos problemas puede que el AP
se haya montado en un canal Wifi
saturado, podemos acceder al asistente que detecta que canal está mas vacÃo y deja dicho canal en la configuración del AP
para su posterior uso:
Eliminar el password de una partida NetPlay
resulta imposible, para ello debemos acceder por
SSH
y editar el fichero ~/.config/retroarch/retroarch.cfg
:
vi ~/.config/retroarch/retroarch.cfg
netplay_password = ""
Con el password de modo espectador ocurre lo mismo:
netplay_spectate_password = ""
DreamCast
:
Si nuestro servidor de DreamCast
propio dá problemas, podemos attachearnos a la sesión de Screen
para ver posibles errores:
screen -ls
screen -x
Si la consola conecta desde la misma red donde está el servidor puede ocasionar problemas debido al hairpinning , en tal caso o conectamos las consolas por otra red o montamos el servidor en algún hosting.
Si las dos consolas salen por la misma conexión a Internet
también puede ser problemático, en tal caso podemos hacer tethering-Wifi mediante el teléfono móvil para una de ellas.