Doom hat gerade den ultimativen SQL-Flex hingelegt

Doom hat ein neues Zuhause gefunden: eine Datenbank. SQLDoom, ein Projekt von Lukas Vogel bei CedarDB, ist nicht einfach nur ein Spiel, das Highscores in einer Datenbank speichert, oder eine visuelle Nachahmung. Es ist eine vollständige Neuimplementierung des originalen Doom von 1993, bei der die Kern-Spiellogik und das Grafik-Rendering vollständig in SQL ausgeführt werden.

Diese Architektur ist elegant entkoppelt. Die Spiellogik und die Rendering-Engine laufen als SQL-Abfragen, während Python als leichtgewichtige Brücke fungiert. Die Rolle von Python beschränkt sich darauf, Tastatureingaben zu erfassen, das Timing der Spielschleife zu verwalten und den resultierenden Framebuffer anzuzeigen. Jeder Frame, den Sie sehen, ist das Ergebnis einer einzigen, massiven SQL-Abfrage.

Das Ausmaß dieses Unterfangens ist beeindruckend. Die Auflösung des Spiels von 320x200, was insgesamt 64.000 Pixeln entspricht, wird vom Renderer berechnet, der etwa 1.300 Zeilen SQL in rund 89 Common Table Expressions (CTEs) umfasst. Die Spiellogik fügt weitere 5.900 Zeilen SQL hinzu. Diese gesamte SQL-Codebasis ist bemerkenswert kürzer als die etwa 9.000 Zeilen C-Spiellogik des originalen Doom.

Jeder in SQLDoom gerenderte Frame stammt aus einer einzigen, komplexen Datenbankabfrage. Diese Abfrage berechnet die Farbe für jedes der 64.000 Pixel (320 × 200 Auflösung) auf dem Bildschirm und gibt das Bild als rohe Bitmap-Daten zurück, wobei eine Zeile jedes Pixel repräsentiert. Allein die Rendering-Abfrage umfasst etwa 1.300 Zeilen SQL und nutzt rund 89 Common Table Expressions (CTEs).

Relationale Operationen unterscheiden sich grundlegend von traditionellem prozeduralem Code. Anstatt expliziter Schleifen, die durch Spielobjekte iterieren, nutzt SQLDoom mengenbasierte Operationen, um Entitäten kollektiv zu verarbeiten. Dies ermöglicht es beispielsweise, mit einer einzigen UPDATE-Anweisung den Status aller Monster gleichzeitig zu ändern – ein krasser Gegensatz zu den zahlreichen for- oder while-Schleifen der ursprünglichen C-Implementierung.

Die Leistungsmetriken sind für ein datenbanknatives Spiel beeindruckend. Die Kern-Spiellogik hält sich an Dooms ursprüngliche 35 Tics pro Sekunde, was ein authentisches Spieltempo gewährleistet. Der Renderer kann jedoch auf moderner Hardware bis zu 60 Bilder pro Sekunde (FPS) erreichen, indem er Kamerapositionen zwischen diesen Spiel-Ticks interpoliert, was ein flüssigeres visuelles Erlebnis bietet als das Original von 1993. Lukas Vogel bei CedarDB hat die überraschende Leistungsfähigkeit von SQL als Game-Engine effektiv demonstriert.

Das Rendern von Doom in einer Datenbank stellt einen faszinierenden Kompromiss dar. Die ursprüngliche Engine von 1993, entwickelt von John Carmack, sparte meisterhaft CPU-Zyklen mit Binary Space Partitioning (BSP)-Bäumen, um die Sichtbarkeit zu bestimmen. SQLDoom hingegen berechnet Tiefe und Okklusion für seine 64.000 Pixel pro Frame per Brute-Force. Dies macht die Sichtbarkeitsberechnung zum langsamsten Teil der SQL-Rendering-Pipeline.

Dieser Brute-Force-Ansatz ist nur dank der Architektur von CedarDB praktikabel. Die Query-Engine kompiliert SQL-Abfragen direkt in LLVM IR und dann in nativen Maschinencode, wodurch komplexe analytische Workloads mit beeindruckender Geschwindigkeit ausgeführt werden können – bis zu 60 Bilder pro Sekunde auf einem Laptop. Diese Kompilierung ist entscheidend für die Verarbeitung der 1.300 Zeilen SQL in einer einzigen Rendering-Abfrage, wie im Blogbeitrag des Projekts beschrieben: We Ported the Original Doom to SQL - CedarDB.

Die Spielwelt selbst verwandelt sich in strukturierte Daten. Dooms ikonische WAD-Assets, die alles von der Kartengeometrie bis zu Texturen definieren, finden als relationale Tabellen ein neues Zuhause. Dazu gehören:

• Maps
• Sectors
• Linedefs
• Textures

Sogar einzelne Objekte wie die Schrotflinte werden zu Zeilen in einer Tabelle, was eine direkte SQL-Manipulation zur Änderung der Spielmechanik ermöglicht, wie etwa das Aktualisieren einer Waffe, sodass sie mit einem einfachen UPDATE-Befehl 500 Projektile abfeuert. Dies macht die gesamte Spielwelt durch Standard-Datenbankoperationen abfragbar und modifizierbar.

Ungewöhnliches Design führt auch zu überraschenden Ergebnissen. Da Waffen und Spielerwerte als Tabellendaten gespeichert sind, kann ein einzelnes SQL-Update die Projektilanzahl einer Schrotflinte oder die Basisgesundheit eines Spielers verändern. Dies demonstriert die dynamischen Fähigkeiten der Datenbank, obwohl ein laufendes Match eine solche direkte Manipulation einschränken würde.

Multiplayer-Funktionalität ergibt sich natürlich aus Datenbanktransaktionen. Jeder Spiel-Tick wird als isolierte Transaktion verarbeitet, wodurch sichergestellt wird, dass alle Spieler eine konsistente, synchronisierte Ansicht der Spielwelt abfragen. Eingeschränkte Funktionen verhindern, dass Clients geschützte Werte wie ihre eigene Gesundheit direkt ändern, um die Integrität des Spiels zu wahren.

SQLDoom geht über eine bloße Neuheit hinaus und dient als rigoroser Test für Datenbank-Abfrage-Engines als Rechenplattformen. Dieses Projekt baut auf Lukas Vogels früherem ASCII-Raycasting-Prototyp, DOOMQL, auf und verschiebt die Grenzen dessen, was relationale Datenbanken erreichen können. SQLDoom lädt uns dazu ein, neu zu überdenken, wie andere komplexe Spielmechaniken als reine Daten und Abfragen dargestellt und ausgeführt werden könnten.

Was ist SQLDoom?

SQLDoom ist ein Projekt von Lukas Vogel bei CedarDB, das die Spiellogik und Grafik-Rendering von Doom in SQL neu implementiert.

Läuft SQLDoom vollständig in SQL?

Die Spiellogik und der Renderer laufen in SQL. Python übernimmt die Tastatureingaben, das Timing und die Anzeige des gerenderten Frames.

Wie viele Pixel rendert SQLDoom pro Frame?

Es berechnet 64.000 Pixel pro Frame, was der Auflösung von 320-mal-200 von Doom entspricht.

Wie handhabt SQLDoom den Multiplayer?

Spiel-Ticks laufen als Datenbanktransaktionen ab, was den Spielern eine synchronisierte Ansicht des geteilten Spielzustands bietet.