DOOMSat

Pantalla de carga inicial
Diagrama del funcionamiento del sistema
Pantallazo de la jugabilidad
Pantallazo de la jugabilidad

Inspiration

DOOMSat nace a partir de una pregunta aparentemente absurda pero técnicamente muy seria, planteada en el Hackudc2026: ¿es posible ejecutar un videojuego interactivo en un satélite real, con las limitaciones extremas de un enlace espacial?

Inspirados de igual manera por problemas reales de ingeniería aeroespacial —downlinks extremadamente limitados, latencias no despreciables y pérdida de paquetes— decidimos abordar el problema desde un ángulo distinto: convertir DOOM en una carga útil experimental, usando el juego como banco de pruebas para técnicas de compresión, transmisión y tolerancia a fallos propias de sistemas espaciales.

El objetivo no era solo “hacer funcionar DOOM”, sino demostrar que, con un diseño cuidadoso, es posible transmitir información visual interactiva a través de un enlace ridículamente estrecho, como los que se encuentran en microsatélites académicos.

What it does

DOOMSat ejecuta el motor de DOOM en una plataforma AArch64 compatible con entornos space-grade, y permite jugarlo desde tierra en tiempo casi real.

Para ello:

El servidor (satélite) captura los frames del motor de DOOM, los reduce, cuantiza y comprime agresivamente, y los envía a tierra a través de un downlink UDP. El cliente en tierra recibe los frames, los reconstruye y los renderiza, enviando los controles del jugador por un uplink TCP fiable. El sistema está diseñado para funcionar bajo condiciones realistas de órbita baja (LEO), aceptando pérdidas de paquetes, latencia y ancho de banda muy limitado, sin que el juego deje de ser jugable.

Más allá del juego, DOOMSat demuestra un enfoque generalizable para:

transmisión de vídeo científico, teleoperación, visualización remota, y experimentación con enlaces espaciales degradados.

How we built it

Internamente, DOOMSat aplica un pipeline optimizado para minimizar cada bit transmitido:

Para ello se comunican tres entidades: Servidor (C): captura frame del motor, preprocesa, comprime y envía. Cliente (Java): recibe datagramas, descomprime y renderiza; envía controles. Proxy (Bash): Para reproducir condiciones satelitales, el proxy actúa como intermediario: limita ancho de banda, añade latencia, introduce pérdida..

Reducción de resolución del frame original. Cuantización por píxel: 2 bits de intensidad (luma). 6 bits de color (crominancia simplificada). Compresión sin pérdidas con zlib sobre el buffer cuantizado. Envío por UDP, priorizando frescura del frame frente a fiabilidad. Controles por TCP, garantizando orden y entrega. El resultado típico es un frame de aproximadamente 4 KB, lo que permite alcanzar del orden de 15–16 FPS bajo un downlink de ~500 kbps, una cifra realista para microsatélites académicos.

Challenges we ran into

El principal reto del proyecto fue pensar como ingenieros espaciales, no como desarrolladores de software convencional.

Algunos de los desafíos más relevantes fueron:

Downlink extremadamente limitado, que obligó a exprimir cada bit del frame.
Elección de protocolos: pérdida aceptable en vídeo (UDP), fiabilidad obligatoria en controles (TCP).
Latencia y jitter, manteniendo jugabilidad incluso con frames perdidos.
Arquitectura heterogénea: servidor en C (AArch64) y cliente en Java.
Cross-compiling y emulación mediante QEMU para validar ejecución ARM. Además, fue necesario definir suposiciones realistas de misión (RTT, pérdida, ancho de banda) y construir un proxy/emulador de enlace para pruebas controladas.

Accomplishments that we're proud of

Estamos especialmente orgullosos de haber logrado:
Un sistema jugable bajo restricciones espaciales severas.
Un pipeline de vídeo simple pero muy eficiente (~4 KB por frame).
Una arquitectura clara y extensible.
Un proyecto técnicamente honesto, basado en supuestos plausibles para LEO. DOOMSat demuestra cómo un problema lúdico puede convertirse en una demostración seria de ingeniería de sistemas.

What we learned

El desarrollo de DOOMSat nos permitió aprender sobre:

Transmisión de datos en enlaces degradados.
Compresión, cuantización y trade-offs calidad/ancho de banda.
Programación de bajo nivel en C y comunicación por sockets.
Cross-compiling y emulación de arquitecturas no convencionales.
Diseño de sistemas tolerantes a fallos. También reforzamos habilidades transversales como planificación, priorización de requisitos y toma de decisiones técnicas bajo restricciones duras.

What's next for DOOMSat

Aunque el sistema es funcional, existen múltiples líneas claras de mejora:

Segmentación de frames a nivel de aplicación para evitar fragmentación IP.
Keyframes periódicos para mejorar la recuperación tras pérdidas.
Compresión diferencial parcial (por ejemplo, HUD vs escena).
Aceleración por FPGA del empaquetado 2+6 bits y/o preprocesado.
Inserción de telemetría embebida en el stream.
Parametrización dinámica del enlace desde la propia aplicación. DOOMSat se concibe como una plataforma experimental abierta, no como un producto cerrado.