
Разработчикът Lukas Vogel публикува на 22 септември 2026 г. проекта SQLDoom — пълноценна реимплементация на Doom, която живее изцяло в релационна база данни. Логиката на играта е около 5900 реда SQL, рендерът добавя още около 1300 реда, разпределени в 89 CTE (common table expressions), а схемата съдържа около 110 таблици и над 100 функции. Кодът е качен в GitHub хранилището cedardb/sqldoom под GPL v2 или по-нова версия.
Проектът върви върху CedarDB — компилираща, съвместима с PostgreSQL система за управление на бази данни. Подробното техническо описание на самия Vogel обяснява, че извън базата остава само малък Python клиент: той чете клавиатурата, държи такта и показва готовия кадър на екрана. Цялото останало — геометрия, физика, изкуствен интелект на враговете и всеки един пиксел — се изчислява от SQL заявки.
Рендер, който не е raycasting
Най-интересната част е графиката. Vogel не ползва евтиния трик с raycasting, а обхожда BSP дървото на оригиналния Doom — същата структура от 1993 г., която подрежда стените отпред назад. Обхождането е реализирано с рекурсивни CTE, изрязването на visplanes — с window функции, а подредбата по дълбочина — чрез сортиране на пакетирани bigint стойности.
Резултатът е картина с текстурирани стени под произволни ъгли, различни височини на подове и тавани, спрайтове и анимации — тоест истинската геометрия на Doom, а не плосък лабиринт от правоъгълни коридори.
Снимка: cedardb/sqldoom (GitHub)
За сравнение: рендерът на оригиналния Doom на C е около 3300 реда. SQL версията се справя с 1300 — просто защото декларативният език описва какво да се получи, а не как да се обходят пикселите един по един.
35 такта и до 60 кадъра в секунда
Кадровият буфер е оригиналните 320×200 пиксела, или 64 000 пиксела на кадър. Игровият цикъл тиктака фиксирано 35 пъти в секунда — точно като при Doom от 1993 г. — докато рендерът може да върви самостоятелно и да изкарва до 60 FPS на лаптоп с AMD Ryzen 7 7840U.
Разбивката на един типичен кадър по данни на автора:
visplanes (подове и тавани) ~3,0 ms
depth resolve (дълбочина) ~8,2 ms
рендер на стените ~1,7 ms
Зареждането на WAD файла в базата отнема около 18 секунди. Нужни са CedarDB Community Edition, Python с psycopg2 и pygame, както и IWAD — безплатният shareware doom1.wad работи:
python3 wad_loader.py doom1.wad \
--dsn "postgresql://postgres:secret@localhost:5432/postgres"
Deathmatch за четирима, пазен от транзакции
SQLDoom поддържа мрежова игра за до 4 играчи в deathmatch. Тук базата данни изведнъж се оказва на място: атомарните транзакции гарантират, че всички клиенти виждат едно и също състояние на света, а правата на играчите са разделени с SECURITY DEFINER, за да не може никой да чете или променя чуждите данни. Общият такт от 35 Hz се налага от Python скрипт в ролята на съдия. CedarDB е вдигнала и два демо сървъра — в ЕС и в САЩ — макар The Register да отбелязва, че при техния тест производителността им е била леко мудна.
От DoomQL до SQLDoom
Проектът, забелязан и от Tom’s Hardware, е продължение на DoomQL от 2025 г. — първи опит със raycasting, за който коментар в Hacker News язвително отбелязва, че резултатът е по-скоро Wolfenstein, отколкото Doom. Любопитното е, че по-сложният подход се оказва и по-бърз: по думите на Vogel производителността на BSP варианта е по-добра от тази на доста по-оскъдния му предшественик.
Оръжията са и hitscan, и снаряди с радиус на поражение, враговете имат машини на състоянията и проверка за пряка видимост, има физика, предмети за вземане, тайни помещения, анимирани спрайтове и звук, вплетен в игровия цикъл. SQLDoom не споделя нито ред код с оригинала, но според автора усещането е същото.
Защо това има значение
Освен като поредна точка в безкрайната традиция „ще върви ли Doom на това“ — редом с проекти като преправения драйвер, който пуска TITAN Xp под Windows XP — SQLDoom е и доста практична демонстрация. Компилиращите бази данни превръщат SQL в машинен код, а не го интерпретират ред по ред, и точно това прави 64 000 пиксела на кадър възможни 60 пъти в секунда.
Проектът е и напомняне колко далеч е отишла изразителността на SQL: рекурсивни заявки, window функции и потребителски функции стигат, за да опишете цял игрален двигател. Докато големите студиа преосмислят двигателите си за AI епохата, един човек показва, че и декларативна заявка може да бъде графичен конвейер. Кодът е свободен — ако имате лаптоп и WAD файл, можете да го пробвате още днес.
Харесва ви? Отбележете ни и ще ни виждате по-нагоре в Google.
Предпочитан източник в Google