SQLDoom: il leggendario sparatutto gira dentro un database SQL a 60 fps

Lukas Vogel ha fatto quello che sembrava una battuta: ha messo il leggendario Doom dentro un database SQL e l'ha fatto funzionare a 60 fotogrammi al secondo. Non è uno scherzo di programmazione, non è una dimostrazione teorica. È un gioco che gira davvero, con 1.300 righe di SQL che gestiscono la logica, la geometria dei livelli, lo stato della partita e il rendering stesso. Il progetto si chiama SQLDoom e rappresenta una sfida radicale a come pensiamo ai videogiochi e ai database.

L'architettura è elegante nella sua stranezza. CedarDB conserva tutto — le mappe, lo stato del gioco, la posizione del giocatore, i nemici, tutto quello che serve per ricostruire il mondo di Doom istante dopo istante. Un piccolo client Python esterno si occupa solo di tre cose: leggere l'input dal giocatore, gestire il timing e mostrare sullo schermo quello che il database produce. Il cuore del sistema è fatto di 89 Common Table Expressions, strutture SQL che si costruiscono l'una sull'altra per trasformare i dati grezzi in fotogrammi bitmap a colori, risoluzione 640×480 pixel. È il contrario di come funziona un motore grafico tradizionale, dove il database è una cosa separata, lontana dal rendering. Qui il database è il motore.

Portare Doom dentro un modello relazionale non era impossibile, grazie alla struttura geometrica del gioco originale. Doom organizza i suoi livelli attraverso vertici, linee e settori — una rappresentazione che si adatta naturalmente alle tabelle. Gli alberi Binary Space Partition, la struttura che id Software usava per decidere cosa disegnare e cosa no, trovano posto nelle righe di una tabella. Vogel ha usato una chiave di ordinamento precalcolata per determinare quali elementi della scena vanno mostrati e quali esclusi, trasformando un semplice ORDER BY in uno strumento di selezione durante la composizione dell'immagine.

I veri problemi sono arrivati con pavimenti e soffitti. Il metodo originale di Doom, basato sui visplane, non si adatta bene a un modello relazionale. Vogel ha dovuto inventare un sistema alternativo fondato sull'iterazione di pannelli ordinati. Lo stesso autore ammette che non è elegante, ma funziona. Completa la pipeline grafica. A volte è così che vanno le cose quando si spinge un'idea fino al limite.

Sui numeri: 60 fotogrammi al secondo su un portatile con Ryzen 7. Nelle situazioni più impegnative scende a 35. Questi dati vanno letti per quello che sono — il risultato di un esperimento dove ogni componente del gioco passa attraverso operazioni su strutture SQL. È un sovraccarico che un'architettura videoludica tradizionale non si porterebbe dietro nemmeno per un istante. Eppure funziona.

L'aspetto più interessante emerge quando si pensa al multiplayer. Un database mantiene una fotografia coerente dello stato della partita. Ha meccanismi nativi per la concorrenza e la gestione degli accessi. Secondo Vogel, questa impostazione potrebbe ridurre i problemi che affliggono i giochi multiplayer — gli aggiornamenti applicati solo in parte, le divergenze nello stato della simulazione quando più giocatori condividono lo stesso mondo. È un vantaggio che nessun motore grafico tradizionale offre naturalmente.

Nessuno sostiene che SQLDoom diventerà un'alternativa ai motori grafici reali. Il progetto è una dimostrazione di ciò che un modello dati può fare quando viene usato in modo radicalmente diverso, quando si mette in discussione la separazione classica tra database, logica applicativa e rendering. Chi vuole provarlo può eseguire il codice in locale con CedarDB e un file WAD di Doom, oppure usare la demo disponibile online. È un esperimento che funziona, e questo è tutto quello che conta.