Jemand hat Doom in eine SQL-Datenbank gesteckt – und es funktioniert tatsächlich.

Jemand hat Doom in eine SQL-Datenbank integriert und es funktioniert tatsächlich. Lukas Vogel, der Entwickler hinter dem Projekt, nennt das Ergebnis SQLDoom und es rendert Full-Color-Frames mit 35 Frames pro Sekunde – und das ausschließlich mithilfe von SQL-Abfragen. Die Einrichtung ist absurd wörtlich: die Spielgeometrie, der Zustand und die Rendering-Logik leben in Tabellen, wobei etwa 1.300 Zeilen SQL-Abfragen über 89 Common Table Expressions die schwere Arbeit erledigen.

Das Projekt ist eine direkte Fortsetzung von Vogels frühem DoomQL, das versuchte, „einen Mehrspieler-Doom-ähnlichen Shooter vollständig in SQL zu erstellen.“ Dieses Experiment produzierte Raycasting-basierte, Graustufen-ASCII-Grafiken, die eher den einfachen 90-Grad-Winkel-Karten von Wolfenstein 3D ähnelten als dem tatsächlichen Aussehen von Doom. SQLDoom erzeugt im Gegensatz dazu Full-Color-Frames mit 640×480 Pixeln, die dem Output des Originalspiels durchaus ähneln könnten.

Wie SQLDoom funktioniert

Das System ist nicht rein SQL. Ein kleiner Python-Client kümmert sich um Ein- und Ausgabe, steuert das Timing des Spiels und zeigt jeden Frame auf dem Bildschirm an. Dahinter verfolgen eine Reihe von CedarDB-Tabellen die Spielgeometrie und den Spielzustand. Die SQL-Abfragen selbst erledigen das Rendering und generieren 35 Bitmap-Framebuffers pro Sekunde.

Der Konvertierungsprozess sei relativ einfach gewesen, schreibt Vogel, aufgrund der Art und Weise, wie Doom Level in Vertices, Linien, Sektoren und so weiter aufteilt. Selbst Doom’s berühmte Binary-Space-Partition-Bäume können in SQL zerlegt werden, indem man für jedes Objekt einen sort_key verwendet, der bei der Ladung für jede Position vorab berechnet wird. Mit diesem Wert in Ihrer Tabelle bestimmt eine einfache „ORDER BY“-Anweisung, welche Teile der Wände angezeigt und welche ignoriert werden müssen, was die Leistung erheblich verbessert.

Der Python-Client ist auf die Handhabung von Ein-/Ausgabe und Anzeige beschränkt. Alles andere – die Geometrie, der Zustand und die Rendering-Logik – lebt in der Datenbank. Die Abfragen sind die Engine, und der Python-Client ist lediglich der Treiber.

Von DoomQL zu SQLDoom

Der Vergleich der beiden Projekte ist aufschlussreich. DoomQL war der Versuch, die gesamte Spielengine in SQL neu aufzubauen, einschließlich Mehrspielerunterstützung. Das Ergebnis war ein funktionierendes Proof-of-Concept, das jedoch hässlich war. SQLDoom verfolgt einen anderen Ansatz: Es verwendet SQL für Rendering und Zustandsprotokollierung, stützt sich aber in allem anderen auf Python.

Die Tabelle zeigt die Entwicklung deutlich. DoomQL war ein Machbarkeitsbeleg, der funktionierte, aber hässlich war. SQLDoom ist ein Machbarkeitsbeleg, der gut aussieht.

Warum SQL das richtige Werkzeug ist )

Die entscheidende Erkenntnis ist, dass Doom’s Geometrie bereits wie eine Datenbank strukturiert ist. Level werden aus Eckpunkten, Linien und Sektoren aufgebaut. Die binärensraum-Partitionbäume können in einen Sortierschlüssel übersetzt werden, den SQL’s „ORDER BY“-Funktion effizient nutzen kann.

Das bedeutet, dass die Datenbank die schwere Arbeit erledigt. Jeder Frame wird durch Abfragen der Geometrietabellen generiert, die sichtbaren Elemente sortiert und das Ergebnis gerendert. Der Python-Client übernimmt die Ein- und Ausgabe sowie die Anzeige, aber das eigentliche Rendern wird von SQL durchgeführt.

Die SQL-Abfragen sind nicht nur eine Neuerung. Sie sind die Rendering-Engine. Der Python-Client ist die Benutzeroberfläche. Die Datenbank ist das Spiel.

Was die Zahlen bedeuten )

Die Zahlen erzählen die Geschichte. Etwa 1.300 SQL-Zeilen über 89 gemeinsame Tabellen Ausdrücke steuern die gesamte Rendering-Pipeline. Das ist viel Code, aber auch eine bemerkenswerte Leistung. Die Zahl von 35 Bildern pro Sekunde ist bemerkenswert, da sie aus SQL-Abfragen allein stammt.

Das Projekt erreicht etwas wirklich Neues: einen vollständig funktionsfähigen Doom-Renderer, der vollständig in SQL lebt. Der Python-Client kümmert sich um die Ränder, aber das Herzstück des Renderings ist reines SQL.

Die praktischen Grenzen )

SQLDoom ist eine Demonstration, aber sie zeigt, was möglich ist. Sie benötigt ein Datenbank-Backend, eine Python-Umgebung und die Bereitschaft, stundenlang rohes SQL zu betrachten. Der ASCII-Vorgänger zeigte, dass das Konzept möglich ist. SQLDoom zeigt, dass es schön sein kann.

Das Projekt ist auch eine Erinnerung daran, dass die Werkzeuge, die wir verwenden, nicht in Stein gemeißelt sind. Spiele werden aus Daten aufgebaut, und Daten können abgefragt werden. Die Kluft zwischen einem Spiel und einer Datenbank ist kleiner als sie scheint.

Warum das wichtig ist )

Das Projekt ist eine technische Kuriosität, hat aber auch praktischen Wert. Es zeigt, wie bestehende Spielassets für neue Plattformen wiederverwendet werden können. Eine WAD-Datei enthält Leveldaten, und SQLDoom demonstriert, dass diese Daten auf ein Datenbankschema abgebildet werden können.

Die Performance-Zahlen sind zwar nach heutigen Maßstäben bescheiden, aber das Projekt erreicht etwas wirklich Neues: Einen voll funktionsfähigen Doom-Renderer, der vollständig in SQL läuft. Der Python-Client kümmert sich um die Ränder, aber das Herzstück des Renderings ist reines SQL.

Das Urteil )

SQLDoom ist ein cleverer Hack, und es funktioniert. Vogels Projekt nimmt ein Spiel, das für Geschwindigkeit entwickelt wurde, und baut es als eine buchstäbliche Datenbankabfrage neu, und das Ergebnis hält zusammen. Die Performance ist stabil, und die zugrunde liegende Technologie ist wirklich ungewöhnlich.

Das Projekt ist eine Erinnerung daran, dass Kreativität in der Software oft aus unerwarteten Richtungen kommt. Vogel hat SQL an den Punkt gebracht, an dem sich das Spiel aus Abfragen rendert.

Das Ergebnis ist ein funktionierender Doom-Renderer, der auf SQL läuft, und das ist an sich schon Grund zur Freude.

Quellenangabe: “Jemand hat Doom in einer SQL-Datenbank,” Ars Technica.