In questo articolo Indice dei contenuti 2 sezioni
Far girare Doom dentro un database SQL sembrava una di quelle idee nate per scherzo, e invece qualcuno ci è riuscito davvero. Il leggendario sparatutto di id Software, da sempre terreno fertile per esperimenti informatici fuori dagli schemi, stavolta finisce in un ambiente pensato per tutt’altro. Una parte sostanziale della logica di gioco viene infatti trasformata in interrogazioni al database.
Il progetto si chiama SQLDoom ed è firmato da Lukas Vogel. Per conservare la geometria dei livelli e lo stato della partita si appoggia a CedarDB, mentre un piccolo client Python si limita a gestire input, temporizzazione e visualizzazione. La stranezza dell’operazione salta subito all’occhio, ma c’è dell’altro. L’esperimento mostra come un database relazionale possa occuparsi anche di compiti che di solito spettano a un motore di gioco.
Come funziona SQLDoom tra tabelle e query
Il cuore del sistema è fatto di circa 1.300 righe di SQL distribuite in 89 Common Table Expressions, che gestiscono la logica e producono i fotogrammi. Il database custodisce mappe e stato del gioco, il client esterno pensa all’interazione con il giocatore e all’uscita video. Il rendering genera immagini bitmap a colori con una risoluzione di 640×480 pixel.
Portare i livelli originali dentro un modello relazionale è stato più semplice grazie alla struttura stessa di Doom, che organizza gli ambienti attraverso vertici, linee e settori. Anche gli alberi Binary Space Partition trovano posto nelle tabelle. Vogel usa una chiave di ordinamento precalcolata per decidere quali elementi della scena vanno mostrati e quali esclusi, così una semplice operazione ORDER BY diventa lo strumento con cui applicare la selezione durante la composizione dell’immagine.
I veri grattacapi arrivano con pavimenti e soffitti. Il metodo originale basato sui visplane non si sposa bene con il modello scelto per SQLDoom, che ripiega quindi su un sistema alternativo fondato sull’iterazione di pannelli ordinati. Lo stesso autore lo definisce poco elegante, però basta a completare la pipeline grafica.
Prestazioni e il nodo del multiplayer
Sul fronte delle prestazioni i numeri sono più che dignitosi. Vogel riferisce di aver raggiunto circa 60 fotogrammi al secondo su un portatile con Ryzen 7, con cali fino a 35 nelle situazioni più impegnative. Il dato va letto per quello che è, ovvero il risultato di un esperimento in cui ogni componente del gioco deve passare attraverso operazioni su strutture SQL. Un sovraccarico che un’architettura videoludica tradizionale eviterebbe senza pensarci due volte.
L’aspetto più curioso però emerge quando si ragiona sul multiplayer. Un database mantiene una fotografia coerente dello stato della partita e offre meccanismi nativi per la concorrenza e la gestione degli accessi. Secondo Vogel questa impostazione può ridurre i problemi legati ad aggiornamenti applicati solo in parte e alle divergenze nello stato della simulazione, questioni piuttosto delicate quando più giocatori condividono lo stesso mondo.
Nessuno pretende che SQLDoom diventi un’alternativa concreta ai motori grafici. Il progetto nasce come dimostrazione di ciò che un modello dati può fare se usato in modo radicalmente diverso, mettendo in discussione la classica separazione tra database, logica applicativa e rendering. Chi volesse provarlo può eseguire il codice in locale insieme a CedarDB e a un file WAD di Doom, oppure affidarsi alla demo disponibile online.
Fonte: TecnoAndroid
