Das ultimative Datenbank-Flex
Falls du jemals in eine Datenbank geschaut und gedacht hast: 'Hier fehlen irgendwie Dämonen', dann ist heute dein Glückstag. Ein Entwickler namens Lukas Vogel hat Doom offiziell in eine SQL-Datenbank gebracht – das Projekt heißt passend SQLDoom. Auch wenn Vogel selbst zugibt, dass ein Shooter in einer Datenbank 'offensichtlich eine schlechte Idee' ist, sind die Ergebnisse highkey beeindruckend.
Wie die Magie passiert
Versteh mich nicht falsch – das ist nicht nur pures SQL, das hier die Arbeit macht. Das System nutzt einen kleinen Python-Client für Input, Output und das Timing des Games. Die Hauptarbeit passiert aber hinter den Kulissen in CedarDB. Mit etwa 1.300 Zeilen SQL-Queries und 89 Common Table Expressions hat Vogel es geschafft, die Spielgeometrie zu tracken und 35 Bitmap-Frames pro Sekunde in Farbe rauszuhauen.
Das ist ein massives Glow-up gegenüber seinem früheren Versuch DoomQL, der noch in der Ära von simplen, graustufigen ASCII-Grafiken feststeckte. SQLDoom erreicht tatsächlich eine 640×480 Auflösung, die legit aussieht wie das Original-Game. Indem Vogel die klassischen WAD-Dateien von Doom in Vertices und Sektoren zerlegt hat, konnte er SQL-Statements wie 'ORDER BY' nutzen, um das Rendering zu wuppen – das ist ehrlich gesagt ein Galaxy-Brain-Move.
Warum das wichtig ist
Ok, aber warum sollte dich das interessieren? Abgesehen von der absoluten Dreistigkeit des Projekts ist es technisch ein absoluter W. Vogel merkt an, dass die Nutzung einer Datenbank für den Game-State einen stabilen 'Referenz-Snapshot' von allem liefert, was passiert. Das bedeutet: Keine jankigen Physik-Bugs oder Diskussionen darüber, ob deine Rakete wirklich getroffen hat. Es ist eine extrem solide Methode für Multiplayer-Synchronisation. Wenn du abenteuerlustig bist und dir diese chaotische Schönheit mal ansehen willst: Der Code ist auf GitHub, oder du checkst die Demo. Aber wunder dich nicht, wenn dein Laptop anfängt zu schnaufen.
