DOOMQL: Как Лукас Фогель Переписал DOOM на Чистом SQL — Шокирующий Эксперимент!

DOOMQL: Когда SQL становится полем битвы для пиксельных Думов

В мире, где DOOM запускают на самых разных экзотических устройствах - от калькуляторов до тестов на беременность - появление новой версии шутера неизменно привлекает интерес. Однако проект DOOMQL, представленный сооснователем CedarDB Лукасом Фогелем, выделяется не столько самой игрой, сколько фундаментальным подходом к её реализации: полностью на SQL. Эта разработка поднимает вопросы о границах применения реляционных баз данных и их неожиданной эффективности в задачах, традиционно относящихся к игровому движку.

Проект DOOMQL, запущенный в сентябре 2025 года, стал результатом месячного декретного отпуска у Фогеля, давая ему шанс для глубокого экспериментального программирования. Вдохновением послужил DuckDB-Doom Патрика Трейнера, который также использовал SQL-логику, но полагался на JavaScript для рендеринга и обработки ввода. Фогель поставил цель довести идею до логического конца, отказавшись от JavaScript и создав многопользовательский шутер, где вся игровая логика, состояние и даже отрисовка осуществляются исключительно средствами SQL.

Архитектура хаоса в реляционных таблицах

Центральная идея DOOMQL заключается в представлении всего игрового мира как набора SQL-таблиц. Это включает в себя:

• Конфигурация игры: такие параметры, как player_move_speed, player_turn_speed, ammo_max и ammo_refill_interval_seconds, сохраняются в таблице config.
• Карта: таблица map представляет игровое пространство, где каждая ячейка (x, y) имеет свой тип tile (например, # для стены).
• Игроки и мобы: их позиции, направления, очки здоровья (hp), боезапас (ammo) и счёт (score) контролируются таблицами players и mobs.
• Ввод: действия игроков ('w', 'a', 's', 'd', 'x' для стрельбы) записываются в таблицах inputs.

Игровой цикл, работающий с частотой около 30 тиков в секунду, является небольшим shell-скриптом, который повторно вызывает SQL-файл - gameloop.sql. Этот файл содержит транзакции, обрабатывающие все игровые события: движение снарядов, коллизии, урон игрокам, начисление очков и возрождение.

-- gameloop.sql (ключевые фрагменты)
BEGIN TRANSACTION;

-- Продвигаем пули вперёд
UPDATE mobs
SET x = x + cos(dir) * 0.5, y = y + sin(dir) * 0.5
WHERE kind = 'bullet';

-- ...обработка попаданий, урона, очков...

-- Перерождаем игроков, чей уровень здоровья составил 0 или меньше
UPDATE mobs m
SET x = r.x, y = r.y, dir = 0
FROM players p
CROSS JOIN (...) AS r
WHERE m.id = p.id
  AND p.hp <= 0;

COMMIT;

Замечательно, что выполнение каждого такого цикла занимает примерно 1 мс на машине Фогеля, что, по его словам, позволяет потенциально увеличить тактовую частоту.

Рендеринг через VIEW: 3D-проекция в ASCII

Одним из наиболее запоминающихся аспектов DOOMQL является полностью SQL-ориентированный поток рендеринга. В отличие от традиционных графических библиотек, визуализация достигается набором SQL-представлений (VIEW), которые эмулируют процесс рейкастинга:

1. Трассировка лучей: рекурсивные запросы в представлении visible_tiles выясняют, какие зоны карты доступны игроку, а также их дистанцию.
2. Проекция стен и спрайтов: используя полученные расстояния и углы, SQL-запросы рассчитывают высоту стен и позицию мобов, проецируя их в 3-мерное пространство.
3. Детализация: выбранный уровень детализации спрайтов зависит от глубины.
4. Кадровый буфер: до финального буфера кадра, где строка собирается функцией string_agg, образуя ASCII-образ мира.
5. HUD и миникарта: такие UI-элементы, как индикатор здоровья (HP), боезапас (AMMO) и миникарта, генерируются динамически через SQL-запросы и строковое форматирование.

Фогель описывает это как "стек SQL-представлений, реализующих рейкастинг и проекцию спрайтов".

Производительность и мультиплейер

DOOMQL обеспечивает постоянные 30 FPS при разрешении 128×64 пикселей в одиночном режиме. Это существенно оттягивает 8 FPS при 32×16 пикселях, предлагаемых DuckDB-Doom, что, по словам Фогеля, является свидетельством эффективности используемой базы данных CedarDB и оптимизации запросов. Мультиплеерная часть реализуется за счёт того, что база данных по своей природе предназначена для синхронизации общего состояния между клиентами:

• Клиентский скрипт на Python (примерно 150 строк) передаёт команды ввода в таблицу inputs.
• Он также запрашивает своё уникальное 3D-изображение через SQL-запрос SELECT full_row FROM screen WHERE player_id = <your_id> ORDER BY y.

Такой метод позволяет мгновенно синхронизировать состояние игры для всех участников, при этом каждый клиент получает своё отдельное, согласованное представление мира благодаря транзакционной изоляции БД. Возможность «читерить», меняя напрямую записи в таблице players (UPDATE players SET hp = 100000 WHERE player_id = <your_id>), лишь подчёркивает открытость архитектуры.

Вызов для сообщества и перспективы развития

Фогель соглашается, что «делать это было... плохой идеей?» с точки зрения поддержки кода, который становится «ужасно трудно отлаживать». Тем не менее, он отмечает, насколько естественно получалось описывать состояние и логику игры на SQL, и полагает, что, возможно, случайно придумал паттерн «entity-component-system».

Проект DOOMQL доступен на GitHub под лицензией MIT, что позволяет любому желающему изучить и модифировать код. Фогель также планирует добавить в игру улучшения, такие как:

• ИИ-противники;
• система добычи предметов (лута);
• новые виды оружия;
• улучшенный клиент.

Он также бросает вызов другим энтузиастам: «Если найдёте [другую базу данных, которая сможет с ней [CedarDB] потягаться] - дайте знать!». DOOMQL не просто иллюстрирует необычное использование SQL, а служит ярким примером того, как базовые компьютерные идеи могут быть переосмыслены и реализованы в самых неожиданных условиях, расширяя границы возможного в разработке ПО. Это исследование явно демонстрирует, что даже простейшие инструменты могут стать фундаментом для создания сложных интерактивных систем, если подойти к задаче с достаточной изобретательностью.