"Doom in einer Datenbank zu rendern, ist offensichtlich eine schlechte Idee", schreibt Lukas Vogel. Er hat es trotzdem getan.
SQLDoom, gebaut vom CedarDB-Mitgründer, spielt das originale Doom: Ein kleiner Python-Client übernimmt Eingaben, Timing und das Ausgeben fertiger Frames. Dahinter halten CedarDB-Tabellen Geometrie und Spielzustand, und rund 1.300 Zeilen SQL – verteilt auf 89 Common Table Expressions – implementieren die Spiellogik und erzeugen 35 Bitmap-Framebuffer pro Sekunde. Das Ergebnis sind farbige 640×480-Bilder, die aus dem Original von 1993 stammen könnten – nicht das Graustufen-ASCII-Raycasting von Vogels früherem DoomQL-Experiment.
Eine relationale Datenbank ist gar kein so schlechter Ort für Dooms Daten. Die WAD-Dateien waren ohnehin in Vertices, Linien und Sektoren zerlegt, das Laden von Levels ist also vor allem eine Tabellenfrage. Sogar die BSP-Bäume übersetzen sich: Ein pro Position vorberechneter sort_key lässt ein schlichtes "ORDER BY" entscheiden, welche Wandstücke in jedem Frame gezeichnet werden. Böden und Decken waren der unangenehme Teil – gelöst mit einer, wie Vogel sagt, "ziemlich hackigen" geordneten Panel-Iteration statt der Visplanes des Originals.
Die Leistung ist besser, als die Idee verdient: rund 60 Bilder pro Sekunde auf einem Ryzen-7-Laptop, in vollen Szenen 35. Und die Datenbank hat ein unerwartetes Argument für Mehrspieler – ein konsistenter Schnappschuss der Welt bedeutet keine halb angewandten Updates, keine Physikfehler und keinen Streit darüber, ob die Rakete wirklich getroffen hat.
Der Code liegt auf GitHub, lokal braucht man eine CedarDB-Kopie und eine Doom-WAD; dazu gibt es ein gehostetes Demo-Match. Ars Technica berichtete diese Woche über das Projekt. Es ist der jüngste Eintrag in der langen Tradition, Doom auf Hardware und Software laufen zu lassen, die dafür nie gedacht war.
