Doom в SQL перестал быть шуткой из разряда «а слабо запустить на холодильнике»: разработчик Лукаш Фогель перенес логику и рендеринг классического шутера в базу данных. Проект SQLDoom использует около 1300 строк SQL-запросов, 89 common table expressions и генерирует до 35 полноценных bitmap-кадров в секунду в сложных сценах.
О проекте сообщает Ars Technica: небольшой Python-клиент в SQLDoom отвечает за ввод, вывод, тайминг и показ кадров на экране, а основная работа происходит в CedarDB. Таблицы хранят геометрию уровня и состояние игры, а SQL-запросы считают логику, выбирают видимые фрагменты сцены и собирают изображение. Да, это все еще не «чистый Doom только на SQL», но достаточно близко, чтобы у DBA дернулся глаз, а у разработчиков появилась новая тема для пятничного созвона.
Фогель прямо признает: рендерить Doom в базе данных — плохая идея. В этом и смысл. SQLDoom не претендует на практичный игровой движок, зато хорошо показывает, насколько далеко можно утащить декларативный язык запросов, если относиться к таблицам не как к месту для отчетов, а как к универсальной модели состояния. В результате база хранит вершины, линии, сектора, игровые объекты и данные, нужные для построения кадра.
Отдельно любопытно, что Doom оказался удобным кандидатом для такого эксперимента. Классические WAD-файлы уже разбивают уровни на структуры, которые неплохо ложатся в реляционную модель: вершины, линии, секторы и другие элементы карты. Даже binary space partitioning, на котором держится часть магии оригинального движка, можно представить через заранее рассчитанные ключи сортировки. После этого обычный ORDER BY помогает определить, какие стены надо рисовать, а какие можно отбросить.
Новая версия заметно ушла вперед по сравнению с прошлым экспериментом Фогеля DoomQL. Тот проект пытался собрать многопользовательский Doom-подобный шутер целиком на SQL, но визуально был ближе к серому ASCII-рейкастингу и простым прямоугольным лабиринтам в духе Wolfenstein 3D. SQLDoom уже выдает полноцветные кадры 640×480, которые внешне напоминают оригинальный Doom, а не терминальный фан-арт по мотивам ада.
Главная боль оказалась не в стенах, а в полах и потолках. Оригинальный Doom использовал для них свои приемы рендеринга, завязанные на послойную обработку и изменение состояния по ходу построения кадра. В SQLDoom такой подход плохо ложится на модель запросов, поэтому Фогелю пришлось использовать более грубую схему с проходом по упорядоченному списку панелей. Сам автор называет решение хакерским, и это тот случай, когда слово «хакерский» звучит не как маркетинг, а как честная инженерная самооценка.
Производительность получилась неожиданно приличной. На ноутбуке с Ryzen 7 SQLDoom, по словам автора, способен работать примерно на 60 fps, хотя в насыщенных сценах частота может проседать примерно до 35 fps. Для системы, где каждый кадр проходит через чтение и запись в таблицы, это не просто «оно запустилось», а вполне рабочая демонстрация того, что современные аналитические и in-memory-ориентированные базы могут делать странные вещи очень быстро.
Практической пользы у Doom в SQL немного, если понимать пользу как «завтра внедряем в прод». Но для разработчиков и архитекторов здесь есть нормальный инженерный урок. База данных — это не только CRUD-слой под приложением, а среда с транзакциями, согласованностью, конкурентным доступом и воспроизводимым состоянием. Фогель отдельно указывает, что для мультиплеерного сервера такая модель дает интересный бонус: меньше шансов получить частично примененные обновления или спор между клиентами о том, попала ли ракета в цель.
Для бизнеса вывод проще: никто не предлагает переносить игровые движки в SQL, но эксперименты вроде SQLDoom помогают по-новому смотреть на границы платформ. Разработчики годами спорят, где должна жить логика — в приложении, базе, очередях, edge-слое или вообще в браузере. Такие проекты не дают универсального ответа, зато напоминают: часть ограничений сидит не в инструментах, а в привычке использовать их только одним способом.
Doom в SQL продолжает старую традицию «запустить Doom где угодно», но на этот раз шутка задевает не железо, а архитектуру софта. Следующий рубеж уже не в том, чтобы открыть E1M1 на очередном экране с микроконтроллером, а в том, чтобы честно спросить: какие еще «неподходящие» системы мы недооцениваем, пока они тихо становятся достаточно быстрыми для совсем нештатных задач? Подробности и исходный контекст проекта — у .