Original Doom'un oyun mantığı ve render motoru tamamen SQL sorguları olarak çalışacak şekilde yeniden yazıldı

1993 yapımı orijinal Doom SQL'e taşındı; hem oyun mantığı hem de render motoru derlenmiş oyun kodu olarak değil, bir veritabanı içinde sorgular olarak çalışıyor. Projeyi anlatan CedarDB blog yazısına göre oyun döngüsü Doom'un doğal hızı olan saniyede 35 tic'te çalışıyor ve render motoru, yazarın dizüstü bilgisayarında (AMD Ryzen 7 7840U) 320x200 tam frame buffer'ı 60 Hz'e kadar üretiyor. Küçük bir Python istemcisi yalnızca zamanlamayı, klavye girdisini ve geri aldığı bitmap'i ekranda göstermeyi üstleniyor. Multiplayer deathmatch da çalışıyor.

22 Eylül 2026 tarihli ve SQLDoom adlı yazı Hacker News'in ana sayfasına kadar yükseldi. Yazar, ilk bölümün shareware sürümünü çalıştıran, her biri dört oyuncu slotlu canlı deathmatch sunucularını AB ve ABD'de barındırıyor. Tüm koltuklar dolduğunda ziyaretçiler bir kuyruğa düşüyor; kuyruk da doluysa yine de bağlanıp canlı oyun durumunu doğrudan SQL ile sorgulayabiliyorlar.

Bir ASCII prototipinin devamı

Geçen yıl aynı yazar, Doom'u andıran ASCII-art kareleri yaklaşık 30 FPS ile render eden DOOMQL projesini yayımladı. Yazının da kabul ettiği gibi, yorumcular bunun Doom'dan çok Wolfenstein 3D'ye yakın olduğunu doğru bir şekilde belirttiler; çünkü raycasting yaklaşımı kullanılmıştı. Gerçek Doom motoru BSP ağaçlarına dayanır ve bu ağaçlar doğru derinlik sıralamasını, dokuları, rastgele açılardaki duvarları ve değişken zemin yüksekliklerini karşılayabilecek kadar ucuz tutar. Yeni taşıma bu sadakat açığını kapatmak için yapıldı; yazar da işin başka bir babalık izni döneminde yapıldığını belirtiyor.

Kendi koyduğu kurallar

Taşıma, yazıda sıralanan bir dizi kısıtlamaya uyuyor. Gerçek Doom gibi görünmeli ve en az o kadar önemlisi, oynanışı da öyle hissettirmeli. Render tamamen SQL tabanlı olmalı; kabul edilebilir tek çıktı, her piksel için kesin RGB değerlerini içeren bir tablo veya bir bitmap kodlaması. Oyun döngüsü de saf SQL olmalı, ancak veritabanı içindeki kullanıcı tanımlı fonksiyonlara izin veriliyor. Başka bir dilde yazılmış bir istemciye izin var, ama yalnızca girdiyi ayrıştırmak, oyun tic'lerini sürmek ve ortaya çıkan bitmap'i göstermek için.

Nasıl bir araya geliyor

İstemci tarafında, kasıtlı olarak sade tutulmuş pygame tabanlı bir Python betiği saniyede 35 kez oyun tic'i tetikliyor, klavyeyi okuyor ve geri aldığı kareyi çiziyor. Gerisi — oyun mantığı, oyun durumu ve render motoru — veritabanının içinde yaşıyor. İki yol bilinçli olarak ayrı: mantık sabit 35 Hz'de ilerlerken render, oyun durumu tablolarının saf bir fonksiyonu; böylece istemci istediği sıklıkta ve hızda yeni bir kare isteyebiliyor.

Oyunun veri formatu da bu çabayı kolaylaştırdı. Doom'un WAD dosya formatı doğal olarak ilişkisel yapılara oturuyor: iki vertex kaydı bir linedef ile bağlanır, bir linedef iki sidedef taşır, sidedef'ler sektörleri sınırlar ve sektörler thing'leri içerir. Bir bütün WAD'ı veritabanına çevirmek yaklaşık 1.000 satır Python aldı ve Doom 1'in tamamını içe aktarmak yazarın dizüstünde yaklaşık 18 saniye sürüyor. Bir gösterim olarak yazı, E1M1'i bu tablolardan doğrudan kuşbakışı bir ASCII haritası olarak render eden tek bir sorguyu sergiliyor.

Neden önemli

Bu kısmen Doom'u olasılık dışı platformlarda çalıştırma geleneğinin en son halkası, ama aynı zamanda SQL'in ifade gücünün gerçek bir stres testi olarak da hizmet ediyor. Yazılım tabanlı render motorlu gerçek zamanlı bir oyun simülasyonu, tipik veritabanı iş yüklerinden ne kadar uzaksa bu kadar uzak; proje, ilişkisel sorguların ve kullanıcı tanımlı fonksiyonların bu yükü oyunun orijinal hızında taşıyabildiğini gösteriyor. Mimari ayrıca temiz bir ayrışmayı gözler önüne seriyor — oyun durumu sorgulanabilir tablolarda yaşıyor ve render o durumun saf bir fonksiyonu. Tasarımın en şık numarasını da bu mimari mümkün kılıyor: devam eden bir maç yalnızca veritabanındaki satırlar olduğundan, herkes onu sıradan SQL ile inceleyebiliyor; sunucu kuyruğunda sıkışan seyircilere de tam olarak bunu yapmaları öneriliyor.