Un archivo .hbr2 no es un video del partido. Es el registro de lo que hicieron los jugadores, tick a tick, y el juego lo vuelve a simular cada vez que lo abres. Esta guía recorre el formato de punta a punta: qué hay en cada parte del archivo, qué información trae y cuál no, y por qué eso define cómo funcionan el reproductor de HaxBall y el analizador de Spike.
No es un video: es una lista de acciones
La física de HaxBall es determinista: si partes del mismo estado de la sala y aplicas las mismas acciones en los mismos ticks, llegas siempre al mismo resultado, hasta el último decimal. La grabación aprovecha eso. En lugar de guardar dónde estaba cada jugador en cada momento, guarda una foto de la sala al empezar a grabar y, después, cada cosa que alguien hizo y en qué tick la hizo: apretar o soltar una tecla, escribir en el chat, cambiar a alguien de equipo, pausar.
El juego avanza a 60 ticks por segundo, y mientras la pelota está en juego el reloj del partido suma 1/60 de segundo en cada uno. Por eso en esta guía se habla de ticks y no de segundos: son la unidad de tiempo del archivo.
La cabecera: 12 bytes
Los primeros 12 bytes no están comprimidos. Son tres enteros sin signo de 32 bits, escritos con el byte más significativo primero (big-endian):
| Bytes | Contenido | Ejemplo |
|---|---|---|
| 0 a 3 | La firma: los caracteres HBR2 (leídos como número, 1212305970) | HBR2 |
| 4 a 7 | La versión del formato | 3 |
| 8 a 11 | La duración de la grabación, en ticks | 271070 (75 min 18 s) |
Que la duración esté en la cabecera permite saber cuánto dura una grabación sin descomprimir nada. El analizador la usa para dos cosas: rechazar al instante las grabaciones de más de seis horas y calcular la barra de progreso mientras simula. Si los cuatro primeros bytes no dicen HBR2, no hay nada que hacer: el analizador responde que el archivo no es una replay de HaxBall antes de intentar leer el resto.
El cuerpo comprimido
Todo lo que sigue a la cabecera es un único bloque comprimido con DEFLATE sin envoltura (ni zlib ni gzip, el flujo comprimido tal cual). Una vez descomprimido tiene tres partes, una detrás de otra:
[cantidad de goles: 2 bytes] [por cada gol: ticks desde el anterior + arco] [estado de la sala al empezar a grabar] [acciones hasta el final: ticks desde la anterior + jugador + tipo + datos]
El índice de goles
Empieza con la cantidad de goles y, por cada uno, cuántos ticks pasaron desde el anterior y un byte con el equipo del arco en el que entró la pelota. El reproductor de HaxBall usa esta lista para dibujar las marcas de gol sobre la barra de tiempo sin tener que simular nada. En las tres grabaciones de ejemplo que aparecen más abajo, el índice tiene 17, 4 y 15 entradas: exactamente los goles de cada una.
La foto inicial de la sala
Después viene el estado completo de la sala en el momento en que empezó la grabación: nombre de la sala, límites de goles y de tiempo, si los equipos están bloqueados, el estadio entero, la lista de jugadores con sus datos, las camisetas de los dos equipos y, si había un partido en juego, el estado de ese partido. Gracias a esta foto una grabación puede empezar a mitad de un partido y verse bien desde el primer tick.
La lista de acciones
El resto del archivo son acciones hasta el final. Cada una lleva cuántos ticks pasaron desde la anterior, el número del jugador que la hizo (2 bytes), un byte con el tipo de acción y los datos propios de ese tipo. Los ticks se escriben como un entero de longitud variable: 7 bits por byte, con el bit alto indicando si sigue otro byte. Un salto de menos de 128 ticks ocupa un solo byte, y el máximo son 5 bytes.
Qué acciones quedan grabadas
HaxBall define 24 tipos de acción. Estas son las que más pesan en una grabación normal:
- Teclas. Cada vez que un jugador aprieta o suelta una tecla, se guarda el estado completo de sus teclas como un número de 32 bits. Mientras las teclas no cambian no se guarda nada: mantener apretada la flecha derecha diez segundos ocupa lo mismo que un toque corto.
- Chat. El texto de cada mensaje, de hasta 140 caracteres.
- Pings. Cada unos 180 ticks (tres segundos) el host manda una lista con el ping de todos los jugadores. Si esa acción viniera de otro jugador, el juego la ignora. Con estos datos el analizador muestra el ping de cada uno a lo largo del partido.
- Movimientos de la sala. Entradas y salidas, cambios de equipo, inicio y fin del partido, pausas, cambios de estadio y de ajustes.
Dentro de ese número de 32 bits, cada tecla es un bit:
| Valor | Tecla |
|---|---|
| 1 | Arriba |
| 2 | Abajo |
| 4 | Izquierda |
| 8 | Derecha |
| 16 | Patear |
Arriba y derecha a la vez valen 9. En diagonal, el juego normaliza la dirección para que moverse en diagonal no sea más rápido que en línea recta. Y la patada solo se arma cuando el bit 16 pasa de apagado a encendido, por eso dejar la tecla apretada no patea una y otra vez.
Por qué hay que simular el partido
Como el archivo no tiene posiciones, para saber dónde estaba la pelota en el minuto 30 hay que partir de la foto inicial y aplicar, tick por tick, todas las acciones de esos 30 minutos con la física de HaxBall: 108.000 ticks de simulación.
El reproductor de HaxBall lo hace en vivo mientras miras. Avanzar es fácil; retroceder, no. El formato no tiene puntos intermedios desde donde retomar, así que para volver atrás el reproductor reinicia la grabación desde el principio y la adelanta a diez segundos de partido por cada cuadro que dibuja hasta llegar al momento pedido. En una grabación larga se nota la espera.
El analizador de Spike resuelve eso de otra forma. Al abrir el archivo simula la grabación completa una sola vez, en un Web Worker (un hilo aparte del navegador, para que la página no se congele), con una copia del motor de HaxBall. En cada tick guarda el marcador, el reloj, la fase del partido, la posición y la velocidad de la pelota y la posición de cada jugador. Con todo eso en memoria, saltar a cualquier momento es inmediato y las estadísticas salen de posiciones exactas, no de estimaciones. En una computadora de escritorio, la grabación de 75 minutos de la tabla de más abajo se simula en alrededor de un segundo. Qué se calcula después con esos datos está explicado en las estadísticas del analizador.
Qué trae una grabación y qué no
Todo lo que el juego necesita para reconstruir la sala está adentro:
- El nombre de la sala, los límites de goles y de tiempo, el bloqueo de equipos y el límite de patadas (la protección de HaxBall contra el spam de patadas).
- El estadio completo. Aunque su autor lo haya marcado como no descargable, la grabación lo trae entero, y por eso el analizador puede ofrecer el archivo .hbs del mapa.
- Las camisetas de los dos equipos: colores, ángulo de las franjas y color del texto.
- De cada jugador: nombre, país (la bandera), avatar, si es admin y en qué equipo está.
- El chat completo y los pings.
Y esto es lo que no está:
- Ni la IP ni el identificador de cuenta de los jugadores, ni la contraseña de la sala. Compartir una replay no expone esos datos.
- La fecha. HaxBall la pone en el nombre del archivo al guardarlo (
HBReplay-2026-08-28-22h14m.hbr2) y el analizador la toma de ahí. Si el nombre ya no la tiene, solo queda la fecha de modificación del archivo. - Asistencias, posesión, tiros o atajadas. Son cálculos que cada herramienta hace a partir de la simulación, con sus propias reglas, y por eso dos programas pueden dar números algo distintos para el mismo partido.
Cuánto pesa y qué límites tiene
Tres grabaciones reales, todas con la versión 3 del formato:
| Duración | Goles | Archivo | Descomprimido |
|---|---|---|---|
| 75 min | 17 | 470 KB | 1,78 MB |
| 36 min | 4 | 377 KB | 2,92 MB |
| 31 min | 15 | 151 KB | 652 KB |
El tamaño no sigue a la duración ni a los goles: la segunda grabación dura la mitad que la primera y descomprimida ocupa más. Lo que cuenta es cuántas acciones se registraron (cuántos jugadores pasaron, cuánto se movieron, cuánto escribieron) y cuánto se comprimen. Aun así, las tres pesan menos de medio mega.
Estos son los límites de las herramientas de Spike:
- Analizador web: archivos de hasta 20 MB, 64 MB una vez descomprimidos y 6 horas de grabación.
- Guardar una replay en tu perfil: hasta 10 MB por archivo.
- El comando
/analyzedel bot en Discord: hasta 8 MB (ver Partidos y replays en la documentación).
Versiones y archivos dañados
El segundo número de la cabecera es la versión del formato. El cliente actual de HaxBall graba y reproduce la versión 3. Si abres una replay de otra versión desde el botón Replays del juego, aparece el aviso «Incompatible replay version» con la opción «Open player», que abre haxball.com/replay?v= seguido de la versión del archivo: un reproductor para ese formato.
El analizador de Spike solo lee la versión 3. Si el archivo es de otra, lo dice junto con el número de versión que encontró.
Un archivo cortado es otro problema. Todo el cuerpo es un único bloque comprimido y cada acción depende de las anteriores, así que una descarga interrumpida o una copia incompleta no se puede leer: el analizador no intenta rescatar una parte y muestra «No se pudo leer la replay» con el detalle «La replay está dañada o incompleta». La solución es volver a conseguir el archivo completo. Para no llegar a eso, revisa cómo grabar y guardar replays sin perderlas.