Para quien le interese, existen varios esquemas de networking para juegos, y unas cuantas decisiones que tomar:
- P2P o Servidor/Cliente: P2P implica que todos los jugadores envían y reciben los inputs del resto de jugadores, y la simulación se produce en todas las máquinas. Servidor/cliente se traduce en una máquina que realiza toda la simulación, y uno o más clientes que envían los datos de los inputs y reciben actualizaciones del estado de la partida.
** P2P: Todos los jugadores son iguales. No es recomendable para juegos en los que parte de la información ha de estar oculta, ya que todos los jugadores deben tener toda la info para realizar la simulación. Es un infierno evitar las desincronizaciones. Si un jugador se retrasa, toda la partida sufre.
** Serv./Cliente: Una sola simulación, por lo que las desincronizaciones se producen a nivel local (un par serv./cliente), y siempre se resuelven a favor del servidor (el servidor manda). Hackear el servidor es hackear la partida completa. De igual modo, si el servidor cae, no hay partida.
- (Solo serv./cliente) Servidor externo o no: ¿hay un servidor que controla la partida y no participa en el juego?
** Serv. externo: El servidor puede tener una conexión mucho mejor que los usuarios, por lo que soporta más jugadores. La mala conexión de un jugador no afecta de manera global a la partida. Cuesta dinero. Si el/los servidor/es se cae/n, nadie puede jugar.
** No serv. externo: Más barato. Permite mods. El jugador que hace de servidor suele tener ventaja al recibir las actualizaciones más rápido, aunque el efecto se puede reducir midiendo el RTT y forzando al servidor a esperar en los envíos al cliente local. Adicionalmente, el jugador/servidor puede utilizar un programa externo para analizar los paquetes y utilizar información que de normal estaría oculta (p.e. wallhacks) de manera totalmente transparente al resto de jugadores, como en el caso del p2p. Si el servidor se desconecta, mala suerte.
- Cliente predictivo o no: Un modelo mixto donde el cliente realiza parte de la simulación. Lo introdujo Carmack en QuakeWorld y se gasta en todos los FPS, MOBA e imagino que en los RTS modernos, así como en
GGPO.
** Cliente predictivo: Enmascara el lag realizando una simulación de la evolución del mundo sin esperar a las actualizaciones del servidor. Cuando el servidor responde, la simulación se compara con el estado real y se corrigen las diferencias. Es bastante más complicado de programar, ya que es necesario guardarse los estados confirmados por el servidor y los simulados, y corregir la simulación de forma lo más transparente que se pueda de cara al usuario. Lo más importante es que, de cara al usuario, el control se vuelve mucho más fluido, ya que los inputs del jugador se ejecutan al instante de manera local y ya se encargará el servidor de corregirlos más tarde. Utilizar con moderación, ya que si los saltos correctivos se vuelven muy evidentes la frustración del jugador es mucho mayor que si la partida "va lenta".
** Cliente no predictivo: Las acciones no se procesan hasta que no sean validadas por el servidor (con frecuencia, el cliente ni siquiera dispone de la lógica para procesarlas). El cliente se detiene si no recibe actualizaciones del servidor. No utilizar a no ser que sea necesario.
Por poner ejemplos,
lol usa serv/cliente con cliente predictivo, servidor externo (y contestando a @Joshi, no se envían los inputs de los otros jugadores, sino el estado del juego). Otros juegos como
L4D permite que uno de los jugadores haga de servidor, o bien utilizar un servidor externo. Por la pinta,
SSB4 gasta P2P sin predicción, como la mayoría de juegos de lucha, por lo que un ping
bajo y
estable de
todos los jugadores es vital.
TL;DR: a comprar el adaptador ethernet.
PD: Por cierto, como apunta @Uranus, el ping no depende de la velocidad contratada. Tener una velocidad superior no garantiza que las partidas vayan a ir mejor :S
