Orijinal Doom'u SQL'e Taşıdık: Bir Veritabanı İçinde 35 FPS Oyun Motoru
Kaynak: Hacker News
İçindekiler 6 başlık
Özet (TL;DR)#
1993 yapımı efsanevi orijinal Doom oyununun mantığını ve render motorunu tamamen SQL'e taşıyarak doğrudan bir veritabanı içerisinde çalıştırdık. Oyun döngüsü orijinal standardı olan 35 FPS hızında çalışırken; SQL tabanlı render motoru, 320x200 çözünürlüğündeki tam kare arabelleğini (frame buffer) dizüstü bilgisayarda 60 Hz'e kadar üretebiliyor. Bu mimaride Python yalnızca zamanlamayı yönetiyor, klavye girdilerini okuyor ve veritabanından dönen bitmap görselini ekrana basıyor. Üstelik çok oyunculu (multiplayer) modu da veritabanı üzerinden eksiksiz çalışıyor.
DOOMQL'den Gerçek Doom'a#
Geçtiğimiz yıl yayımladığımız DOOMQL projesi, 30 FPS hızında ASCII formatında çıktı üretiyordu. Ancak o proje ışın izleme (raycasting) tekniği kullandığından Doom'dan çok Wolfenstein 3D'ye benziyordu. Gerçek Doom ise dokuları, serbest duvar açılarını ve değişken zemin yüksekliklerini ucuz bir derinlik sıralamasıyla ekrana taşımak için BSP (Binary Space Partitioning) ağaçlarını kullanır. Bu yeni çalışmayla gerçek Doom mimarisi doğrudan SQL sorgularıyla hayat buldu.
Kurallar#
Geliştirme sürecinde projenin hedeflerini korumak adına beş temel kural belirlendi:
- Kural 1 - Gerçek Doom Gibi Görünmeli: Görsel sadakat orijinal oyuna tam olarak uymalı, retro deneyimi eksiksiz yansıtmalıdır.
- Kural 2 - Gerçek Doom Hissiyatı Vermeli: Orijinal oyunun sunduğu saf eğlence ve akıcı mekanikler korunmalıdır.
- Kural 3 - Render Tamamen SQL Tabanlı Olmalı: Sorgulardan elde edilen tek geçerli çıktı; her pikselin RGB değerlerini saklayan bir tablo veya bitmap olmalıdır.
- Kural 4 - Oyun Döngüsü Tamamen SQL Tabanlı Olmalı: Veritabanı içinde kullanıcı tanımlı fonksiyonların (UDF) kullanımına izin verilir.
- Kural 5 - İstemci Sadece Temel Görevleri Üstlenmeli: Başka bir dilde (Python/pygame) yazılan istemci yalnızca girdileri ayrıştırmalı, oyun adımlarını (game tic) tetiklemeli ve gelen bitmap'i ekrana çizmelidir.
Mimari#
Sistem iki bağımsız kanaldan meydana gelir:
- SQL Oyun Mantığı (Game Logic): Oyun durum tablolarını (game state tables) güncelleyen ve 35 Hz sabit frekansta tetiklenen mantık döngüsü.
- SQL Render Motoru (Renderer): Veritabanındaki oyun durumu tablolarının saf bir fonksiyonu (pure function) olarak çalışan ve istemci talep ettikçe (mümkün olan en yüksek hızda) yeni kare üreten sorgu katmanı.
Oyun Verilerini Yükleme#
Doom'un .wad dosya formatı doğası gereği ilişkisel veritabanı yapısına oldukça uygundur: İki köşe noktası (VERTEXES), iki kenara (SIDEDEF) sahip bir çizgiyle (LINEDEF) birleşir; kenarlar ise içinde nesnelerin (THINGS) yer aldığı sektörleri (SECTOR) çevreler. Yaklaşık 1000 satırlık Python koduyla tüm WAD dosyası tablolara aktarılmış ve Doom 1 verilerinin içe aktarımı yalnızca 18 saniye sürmüştür.
Yazılım Geliştirme Açısından Pratik Çıkarımlar#
- İlişkisel Modelleme: WAD formatının tablolara doğrudan eşlenmesi, karmaşık durum (state) yapılarının ilişkisel veri tabanlarıyla ne kadar doğal temsil edilebileceğini gösterir.
- Durum ve Görünüm Ayrımı (CQRS): Oyun tetiğinin 35 Hz ile durumu güncellemesi, render sorgusunun ise bağımsız birer salt-okunur fonksiyon gibi çalışması modern veri mimarileri için harika bir ayrım örneğidir.
- Veritabanının Hesaplama Gücü: Modern SQL motorları ve UDF'ler, veritabanlarını salt depolama aracı olmaktan çıkarıp yoğun hesaplama gerektiren motorlara dönüştürebilir.
Kaynak ve atıf
Bu yazı, Hacker News üzerinde yayımlanan içerikten yararlanılarak Edumints tarafından yapay zekâ desteğiyle Türkçe hazırlandı. Ayrıntılar ve yazarların kendi anlatımı için orijinaline bakabilirsin:
- cedardb.com/blog/sqldoom