Doom gira dentro un database SQL: ecco come è stato possibile

Doom continua a essere terreno fertile per esperimenti informatici fuori dagli schemi.

L’ultimo caso porta il leggendario sparatutto di id Software dentro un database SQL, trasformando una parte sostanziale della logica di gioco in interrogazioni al database.

Il progetto, chiamato SQLDoom, è stato realizzato da Lukas Vogel e sfrutta CedarDB per conservare geometria e stato della partita, mentre un piccolo client Python gestisce input, temporizzazione e visualizzazione.

Il risultato è interessante non soltanto per la stranezza dell’esperimento, ma perché mostra come un database relazionale possa essere utilizzato anche per compiti normalmente affidati a un motore di gioco.

Come funziona Doom dentro SQL

Il cuore di SQLDoom comprende circa 1.300 righe di SQL distribuite in 89 Common Table Expressions, utilizzate per gestire la logica e produrre i fotogrammi. Il database conserva la geometria dei livelli e lo stato della partita, mentre il client esterno si occupa dell’interazione con il giocatore e dell’output video. Il rendering genera immagini bitmap a colori con risoluzione 640×480 pixel.

La conversione dei livelli originali nel modello relazionale è stata agevolata dalla struttura stessa di Doom, che organizza gli ambienti attraverso vertici, linee e settori. Anche gli alberi Binary Space Partition possono essere rappresentati nelle tabelle. Vogel utilizza una chiave di ordinamento precalcolata per stabilire quali elementi della scena debbano essere mostrati o esclusi. Un’operazione ORDER BY permette quindi di applicare il processo di selezione durante il rendering.

La parte più complessa riguarda pavimenti e soffitti. Il metodo originale basato sui visplane non si adatta direttamente al modello scelto per SQLDoom, che ricorre quindi a un sistema alternativo fondato sull’iterazione di pannelli ordinati. È una soluzione definita dallo stesso autore come poco elegante, ma sufficiente a completare la pipeline grafica.

Perché usare un database per un videogioco

Sul piano prestazionale, Vogel riferisce di aver ottenuto circa 60 fotogrammi al secondo su un portatile dotato di Ryzen 7, con cali a 35 fotogrammi nelle situazioni più impegnative. Il dato va letto nel contesto dell’esperimento: ogni componente del gioco deve passare attraverso operazioni su strutture SQL, introducendo un sovraccarico che un’architettura videoludica tradizionale eviterebbe.

L’aspetto più curioso emerge però pensando al multiplayer. Un database mantiene una fotografia coerente dello stato della partita e offre meccanismi nativi per concorrenza e gestione degli accessi. Secondo Vogel, questa impostazione può ridurre problemi legati ad aggiornamenti applicati solo parzialmente e a divergenze nello stato della simulazione, questioni particolarmente delicate quando più giocatori interagiscono con lo stesso mondo.

Il progetto non nasce quindi come alternativa pratica ai motori grafici, ma come dimostrazione delle possibilità offerte da un modello dati usato in modo radicalmente diverso. Il codice può essere eseguito localmente insieme a CedarDB e a un file WAD di Doom, mentre è disponibile anche una demo online. L’interesse di SQLDoom sta soprattutto nel mostrare che la separazione tradizionale tra database, logica applicativa e rendering può essere messa in discussione quando l’obiettivo è esplorare nuovi approcci tecnici.