La tecnología avanza cuando las ideas aparentemente imposibles se vuelven posibles. Un desarrollo reciente demuestra que una base de datos puede albergar no solo almacenamiento, sino también la lógica de juego y la renderización. Este artículo examina el proyecto SQLDoom, un puerto de Doom que funciona íntegramente dentro de una base de datos SQL, gestionando tanto la mecánica del juego como la salida visual mediante consultas.
El proyecto, creado por el desarrollador Lukas Vogel, almacena la geometría de los niveles y el estado del juego en tablas de CedarDB, mientras un script ligero en Python se encarga del temporizador, la entrada y la salida de pantalla. El resultado es una experiencia de 640×480 en color completo, que renderiza 35 fotogramas por segundo, utilizando aproximadamente 1,300 líneas de SQL distribuidas en 89 bloques de consultas.
Un intento anterior quedó corto respecto a Doom real
Anteriormente, la iniciativa DoomQL, lanzada el año pasado, confiaba en raycasting con caracteres de texto en escala de grises. Eso hacía que la experiencia se asemejara más a Wolfenstein 3D que a Doom. La ausencia de la traversa de la BSP (Binary Space Partitioning) en DoomQL motivó a Vogel a desarrollar una segunda versión más fiel a Doom.
Para SQLDoom, el objetivo fue que tanto el renderizado como el ciclo del juego operaran íntegramente a través de SQL, con salidas limitadas a tablas de color exacto o bitmaps. “Renderizar Doom en una base de datos es obviamente una mala idea”, comentó Vogel en una entrada de blog sobre el proyecto. Construir la nueva versión implicó reconstruir partes clave del proceso de renderizado de Doom utilizando operaciones de base de datos en lugar de código de motor de juego convencional.
La gestión de la geometría del nivel fue relativamente directa gracias a una clave de orden calculada al cargar cada mapa, que permite una cláusula ORDER BY para determinar qué secciones de paredes deben dibujarse. Las superficies de suelos y techos representaron un reto mayor. El motor original usa visplanes y cambios de estado, conceptos que no se traducen de forma directa a un renderizado por SQL columna por columna. Vogel reemplazó ese sistema con un enfoque descrito como “bastante hacky”, recorriendo una secuencia de paneles ordenados para rellenar dichas superficies.
Figuras de velocidad y pruebas de servidor: resultados mixtos
Vogel reporta aproximadamente 60 fotogramas por segundo en un portátil con un chip Ryzen 7 7840U, aunque escenas más ocupadas pueden caer a 35 fps. Señala que la sobrecarga de las tablas fue significativa, pero el puerto superó a su intento más sencillo, DoomQL, del año anterior. “Lo concebí como una demostración técnica, pero se siente como el Doom real, aunque no comparta una sola línea de código con ninguna otra porta de Doom”, afirmó Vogel.
El puerto también soporta deathmatch, con servidores públicos en Europa y EE. UU. abiertos para partidas multijugador. Los críticos que probaron las demos en línea describieron rendimientos lentos, y una publicación sugirió que fueron los servidores, más que el puerto, los responsables. Vogel defiende que una base de datos mantiene un único registro estable del estado del juego, evitando actualizaciones parcialmente aplicadas, errores de física o disputas sobre si el cohete golpeó o no.
The Register destacó que este trabajo también funciona como escaparate de CedarDB, un sistema de bases de datos que compila consultas complejas en código máquina. Quienes quieran probarlo pueden ejecutar el código de GitHub localmente con CedarDB y los datos originales de Doom, o unirse a una partida gratuita hospedada en línea. Para más información, consulte The Register.
En resumen, SQLDoom no solo amplía el concepto de qué puede hacer una base de datos, sino que también invita a reflexionar sobre la versatilidad de las consultas SQL para más allá de la simple gestión de datos, abriendo una conversación sobre la intersección entre bases de datos y simulación interactiva.
from Latest from TechRadar https://ift.tt/BteGwCV
via IFTTT IA
