Español
El netcode es la parte del software de un juego que permite que distintas máquinas participen en una misma partida. La palabra es una denominación amplia, no un único algoritmo: incluye enviar información, sincronizar simulaciones y decidir qué hacer cuando los mensajes llegan tarde o no coinciden.
También es fácil echarle la culpa. Un disparo fallado, un salto repentino de posición y una respuesta tardía a un botón pueden sentirse similares aunque tengan causas distintas. Entender las técnicas principales permite hacer un diagnóstico más útil que limitarse a declarar que el netcode de un juego es malo.
¿Quién decide qué ocurrió realmente?
En un juego donde el servidor tiene la autoridad, los clientes no tienen la última palabra sobre el resultado compartido. La descripción general de redes de Epic explica la existencia de un mundo del servidor que actúa como referencia junto a las versiones mostradas por los clientes conectados.
Un servidor dedicado no tiene un jugador local. Un servidor de escucha también aloja a un jugador en la máquina que actúa como servidor. Ambos son esquemas cliente-servidor; alojar una partida en el ordenador de un jugador no elimina automáticamente la autoridad del diseño.
Conviene separar esta cuestión de cómo viajan los mensajes. Peer-to-peer describe la comunicación entre participantes, no una garantía universal de que ningún anfitrión tenga autoridad o de que un juego no necesite emparejamiento, relés u otra infraestructura de apoyo.
Ticks, actualizaciones y fotogramas no son intercambiables
Un tick de simulación hace avanzar el estado del juego. Una actualización de red comunica información. Un fotograma renderizado produce una imagen. Pueden seguir ritmos diferentes. Los juegos sin conexión también hacen avanzar sus simulaciones por pasos; no se vuelven matemáticamente continuos porque no haya servidor.
A 60 ticks por segundo, el intervalo nominal es de unos 16,67 milisegundos. Ese cálculo no establece el tiempo total necesario para que tu acción llegue a la pantalla de otro jugador. El procesamiento, la transmisión, el almacenamiento en búfer y el renderizado pueden contribuir al retraso.
Una tasa de ticks más alta puede beneficiar a determinados diseños, pero la cifra anunciada por sí sola no certifica un mejor registro de impactos. También importa qué registra el juego, cómo marca los tiempos y qué valida.
La predicción hace que el movimiento local responda con rapidez
Esperar la respuesta de un servidor antes de mostrar cada movimiento haría que los controles parecieran lentos. En la explicación de Riot sobre el netcode de VALORANT, el cliente predice el resultado de las entradas locales mientras el servidor conserva la autoridad. Si sus simulaciones no coinciden, el servidor corrige al cliente.
Esa reconciliación puede hacerse visible como un salto o un efecto de retroceso brusco, conocido como rubber-banding. Es un mecanismo para recuperar la concordancia, pero las correcciones frecuentes pueden seguir indicando un problema. Una grabación de un salto, por sí sola, no revela si la causa fue pérdida de datos, un atasco de procesamiento o un defecto de la simulación.
La interpolación suaviza el movimiento remoto
Las actualizaciones no llegan necesariamente a intervalos regulares. La demostración de interpolación de instantáneas de Glenn Fiedler muestra cómo un receptor puede almacenar instantáneas en un búfer y dibujar posiciones entre estados conocidos. Se acepta algo de retraso a cambio de una presentación más fluida.
Por tanto, interpolación y extrapolación son distintas. La primera estima entre muestras disponibles; la segunda proyecta más allá del último estado conocido. Ninguna debería describirse simplemente como que el ordenador sabe dónde está un rival en este preciso momento.
El rollback corrige un pasado predicho
El rollback permite que un juego continúe antes de que lleguen todas las entradas remotas. Si una predicción resulta equivocada, el juego restaura un estado anterior y vuelve a simular hacia delante con las entradas corregidas. El proyecto GGPO es una implementación conocida de este enfoque.
Su guía para desarrolladores exige una simulación determinista, un estado que pueda guardarse y restaurarse y la capacidad de hacer avanzar la simulación sin renderizar cada paso intermedio. También documenta un límite de predicción: si la información que falta supera ese límite, el juego no debe seguir avanzando a ciegas.
El rollback no promete retraso cero ni una recuperación perfecta. GGPO admite un retraso deliberado de las entradas junto con la predicción, y las predicciones incorrectas pueden producir discontinuidades visibles. La implementación tiene que equilibrar la rapidez de respuesta, la extensión de la corrección y la respuesta visual del juego.
El rollback y los servidores pueden trabajar juntos
Es engañoso presentar el rollback y las redes cliente-servidor como opciones mutuamente excluyentes. En su explicación del diseño en línea de 2XKO, Riot describe el uso de ambos, con el servidor ejerciendo la autoridad sobre las entradas, el estado y el tiempo.
Ese artículo también describe un retraso intencionado de las entradas tanto en partidas sin conexión como en línea. El ejemplo importa porque desmonta dos simplificaciones comunes: rollback no tiene por qué significar peer-to-peer, y un juego con rollback no tiene por qué eliminar todos los fotogramas retrasados deliberadamente.
Por qué un impacto puede llegar después de alcanzar cobertura
Los jugadores ven información de momentos distintos. La explicación de Riot sobre VALORANT describe cómo se comprueba un disparo frente a un estado anterior del mundo correspondiente a lo que vio quien disparó. También insiste en limitar cuánto puede retroceder el servidor.
Esto ayuda a explicar por qué quien se defiende puede ver el daño después de haber llegado aparentemente a salvo. No demuestra que cada muerte de ese tipo fuera correcta ni que la compensación de latencia sea la única causa posible. Juzgar un incidente exige conocer las reglas del juego y contar con datos temporales, no solo con la imagen final de una pantalla.
Qué registrar cuando una partida se siente extraña
Empieza por los diagnósticos del propio juego. Anota el tiempo por fotograma, el ping indicado, los indicadores de pérdida de paquetes, la región del servidor y si el problema también ocurre sin conexión. El ping suele indicar una medición de ida y vuelta; no es automáticamente el tiempo de viaje en un solo sentido de cada mensaje de la partida.
Compara una conexión poco utilizada con otra que transporte mucho tráfico y, cuando sea práctico, haz una comparación con una red por cable. Un resultado alto de velocidad de descarga no demuestra por sí solo un retraso bajo, una entrega regular ni condiciones adecuadas durante toda una partida. Las necesidades de ancho de banda también dependen del diseño del juego.
Si la misma respuesta tardía aparece sin conexión, investiga también el recorrido local desde la entrada hasta la pantalla. Si un problema ocurre solo en una partida, conserva la hora y el identificador de partida disponible para elaborar un informe de error útil.
Un buen netcode gestiona las discrepancias dentro de unas limitaciones. No puede eliminar la distancia ni hacer que todos los dispositivos funcionen en el mismo instante, pero sus decisiones pueden reducir mucho el efecto de esas diferencias.
Traducción al español del artículo original en inglés del 2026-06-24. Traducido con ayuda de IA el 1 de noviembre de 2026; las referencias temporales siguen siendo las del original.
