Doom в SQL теперь не шутка для конференционного слайда, а рабочий проект: разработчик баз данных Лукас Фогель перенёс игровую логику классического шутера 1993 года в CedarDB. Получилось 5 900 строк SQL против примерно 9 000 строк C в оригинальной логике игры, сообщает Tom's Hardware. Для разработчиков это редкий случай, когда мем «запустили Doom на чём угодно» внезапно превращается в занятный разбор реляционной модели, транзакций и параллельных обновлений.
Проект называется SQLDoom. Фогель уже экспериментировал с DoomQL, а теперь сделал более полноценную версию для CedarDB — производительной СУБД, совместимой с PostgreSQL. Важно: картинка, звук и ввод не живут прямо в базе. За фронтенд отвечает Python, но он работает скорее как монитор, клавиатура и звуковая карта: принимает ввод, показывает результат и проигрывает звук. Основные вычисления, состояние мира и игровой цикл выполняются внутри базы данных.
Архитектура похожа на современные порты Doom. Один контур работает на оригинальной частоте игры — 35 тиков в секунду — и отвечает за игровую логику. Второй поток занимается отображением и интерполирует положение камеры между обновлениями состояния. Иначе говоря, база не просто хранит таблички с монстрами и патронами, а реально считает, кто куда двинулся, во что попал и что после этого изменилось.
Первым делом Фогелю пришлось превратить данные из WAD-файла Doom в набор таблиц. Это оказалось проще, чем звучит: по его словам, данные игры уже во многом устроены как реляционная модель. Уровни, объекты и связи между ними ложатся в иерархии родительских и дочерних сущностей, которые легко представить в обычных таблицах. Конвертер занял около 1 000 строк Python.
Главный игровой цикл тоже лег на SQL неожиданно ровно. В C разработчику обычно приходится явно проходить по сущностям через циклы и обновлять их состояние по одной или группами. В SQL многие такие операции превращаются в один запрос вида UPDATE ... WHERE, который меняет сразу набор строк. Плюс СУБД может распараллелить часть работы сама. Бонус для тех, кто когда-либо правил баланс в играх: если оружие, враги и параметры поведения лежат в таблицах, их можно менять на лету обычными запросами.
Графический рендерер вышел компактнее — около 1 300 строк, но технически он выглядит куда более экзотично. По описанию Фогеля, центральная часть рендера — это один запрос, который затрагивает 89 таблиц. В Doom используется обход BSP-дерева, то есть структуры, с помощью которой движок понимает, в каком порядке рисовать стены. В табличном мире это тоже оказалось представимым: левую и правую ветви можно кодировать значениями, порядок вершин сводить к числам, а сортировку отдать запросу SELECT ... ORDER BY. Где-то в этот момент SQL перестаёт быть «языком для отчётов» и начинает подозрительно напоминать движок.
Не всё перенеслось так красиво. Рендеринг пола и потолка, по словам автора, хуже ложится на SQL, потому что там используются алгоритмы заливки. Они не так естественно выражаются через таблицы и декларативные запросы. Это хороший контраст к остальному проекту: реляционная модель сильна там, где есть множества объектов, связи и массовые обновления, но не обязана быть удобной заменой любому процедурному алгоритму.
Самая неожиданная часть — мультиплеер. Тут база данных выглядит не хаком, а почти родной средой. Синхронизация состояния между множеством взаимосвязанных таблиц, снимки состояния, авторизация и контроль доступа — ровно те задачи, ради которых СУБД и существуют. Игровой тик можно обернуть в транзакцию: начать, выполнить логику, зафиксировать изменения. Для бизнес-разработчика это звучит почти буднично, если забыть, что речь всё ещё о демонах, дверях и дробовике.
Практического смысла запускать Doom в SQL немного, и в этом его ценность. SQLDoom показывает не «замену игровым движкам», а границы и сильные стороны привычных инструментов: декларативные операции, параллельные обновления, транзакционность и удобную работу со связанными состояниями. Подробности эксперимента и ссылки на артефакты проекта можно найти в материале ; следующий логичный вопрос — не где ещё запустят Doom, а какие «неподходящие» платформы мы недооцениваем только потому, что привыкли использовать их скучно.