DOOMQL: шутер на чистом SQL — игровой движок внутри базы данных

Что если взять базу данных — и превратить её в полноценный игровой движок? Не просто хранить в ней игровое состояние, а поручить ей вообще всё: движение персонажа, столкновения, врагов, бой, прогресс и каждый пиксель на экране? Именно с этого провокационного вопроса начался проект DOOMQL — и ответ оказался положительным.

Симон Уиллисон (Simon Willison), известный разработчик и автор популярного блога об AI-инструментах, обратил внимание на этот проект и попробовал его лично. Проект создан Питером Гостевым (Peter Gostev) с помощью GPT-5.6 Sol — новейшей модели из семейства OpenAI.

«DOOMQL начался с намеренно абсурдного вопроса: а что если SQLite станет не местом, где игра хранит данные, а самим игровым движком?»

Что такое DOOMQL

Разработчик довёл технологию баз данных до предела, создав DOOMQL — полноценный многопользовательский шутер от первого лица, работающий целиком внутри SQL-базы данных. Проект использует CedarDB для управления всем: от игровой логики и движения игроков до трёхмерного рендеринга через сложные SQL-запросы.

Но в оригинальной заметке Саймона Уиллисона речь идёт о несколько иной версии: Питер Гостев создал собственный небольшой Doom-подобный клон на основе SQLite (а не CedarDB), где SQL управляет движением, коллизиями (обнаружение столкновений), врагами, боём, прогрессией и каждым RGB-пикселем на экране. Проект реализован в виде терминального Python-скрипта.

ℹ Контекст: семейство DOOMQL
Существует несколько родственных проектов под этим названием. Оригинальный CedarDB/DOOMQL — это многопользовательский шутер на CedarDB от Лукаса Фогеля (Lukas Vogel). Версия petergpt/doomql — отдельный эксперимент Питера Гостева на SQLite, созданный с помощью GPT-5.6 Sol.

Архитектура: SQL как игровой движок

Ключевая идея — «всё есть данные». Концепция «Everything is data» подразумевает, что игровые состояния, движения игроков, события и настройки хранятся в таблицах.

Посмотрим на архитектуру:


graph TD
    A[Таблицы БД\nКарты, игроки, мобы, спрайты] --> B[SQL-запросы\nИгровая логика]
    B --> C[SQL-представления Views\nРендеринг сцены]
    C --> D[HUD / Minimap / 3D-сцена]
    B --> E[Game Loop\nШелл-скрипт ~30 Гц]
    E --> F[Python-клиент\n~150 строк]
    F --> G[Терминал пользователя]
    G -->|Ввод с клавиатуры| F
    F -->|INSERT в таблицу inputs| A

Чистый SQL-рендерер реализует рейкастинг (raycasting — алгоритм трёхмерного рендеринга на основе лучей), проекцию спрайтов, отсечение и HUD (heads-up display, игровой интерфейс) — всё через механизм SQL-представлений (VIEWS).

Карты, мобы, игроки, вводы и спрайты — всё это данные в таблицах. Слои SQL-представлений трансформируют состояние игры в трёхмерный вид: сцену, HUD и миникарту. Игровой цикл реализован в виде небольшого шелл-скрипта, который запускает SQL примерно 30 раз в секунду: двигает пули, проверяет коллизии, обрабатывает ввод, восстанавливает игроков после смерти.

Ключевые особенности

ХарактеристикаОписание
РендерингРейкастинг, проекция спрайтов — только через SQL VIEWS
Многопользовательский режимСинхронизация состояний нескольких игроков через транзакции БД
Частота кадров~30 FPS в режиме CedarDB; SQLite-версия — терминальный режим
Python-клиентОколо 150 строк — только ввод с клавиатуры и вывод фреймов
ЧитыВстроены: любой SQL-запрос может изменить состояние игры
ЛицензияMIT — полностью открытый код
💡 Встроенная поддержка читов
Состояние игры полностью открыто: можно изменить конфиг, телепортировать игроков или перебалансировать оружие одним запросом UPDATE. Поскольку все общаются с базой данных на SQL, половина веселья — придумать хитрые читерские запросы.

Предыстория: DuckDB-DOOM

DOOMQL возник не на пустом месте. Вдохновением послужил проект DuckDB-DOOM Патрика Трейнера (Patrick Trainer) — более ранний эксперимент по созданию Doom-подобного шутера на SQL. Однако тот код, работающий в браузере через WebAssembly, использует JavaScript для рендеринга и обработки ввода.

Ключевое отличие DOOMQL — многопользовательность, а SQL используется и для рендеринга, и для ввода, достигая ~30 FPS при разрешении 128×64 пикселя. По словам автора, «иметь части рендеринг-пайплайна на JavaScript — это как жульничество».

DuckDB-DOOM — экспериментальная игра, демонстрирующая возможности SQL для вычислительных задач: вся игровая логика, включая 3D-рейкастинг, AI врагов, определение коллизий и рендеринг, реализована через SQL-запросы в WebAssembly-сборке DuckDB.

GPT-5.6 Sol как соавтор

Отдельного внимания заслуживает инструмент разработки. Питер Гостев создал свою версию DOOMQL с помощью GPT-5.6 Sol — флагманской модели из нового семейства OpenAI.

Все три модели GPT-5.6 имеют окно контекста в миллион токенов и максимум 128 000 выходных токенов. Главное достижение OpenAI в рамках GPT-5.6 — производительность в долгосрочных агентных задачах: на бенчмарке Agents’ Last Exam, оценивающем профессиональные рабочие процессы в 55 областях, GPT-5.6 Sol установил новый рекорд в 53,6 балла, опередив Claude Fable 5 на 13,1 пункта.

По оценке самого Питера Гостева, Fable — «мудрая сова» для архитектурных решений, а Sol — надёжный исполнитель. Именно Sol и взял на себя роль соавтора в написании DOOMQL.

📝 Как запустить DOOMQL

Проект Питера Гостева запускается локально через uv — современный Python-пакетный менеджер:

cd /tmp
git clone https://github.com/petergpt/doomql
cd doomql
uv run host

Для оригинального CedarDB/DOOMQL потребуется Docker:

git clone https://github.com/cedardb/doomql
cd doomql
# Следуйте инструкциям в README для запуска через Docker

Почему это важно

Проект DOOMQL демонстрирует, как разработчики продолжают находить новые способы расширять границы технологий. Хотя запуск шутера в базе данных вряд ли практично для коммерческой разработки игр, это наглядно показывает гибкость современных СУБД и даёт ценные идеи для альтернативных подходов к многопользовательской архитектуре.

Разработка DOOMQL позволила автору многое узнать о SQL как инструменте для реализации игровой логики и управления состоянием: из усилий возник «на удивление элегантный игровой цикл».

Это также отличный пример так называемого vibe coding — подхода, при котором разработчик описывает задачу языковой модели, а та генерирует рабочий код. Сложность задачи (реализовать рейкастинг через рекурсивные SQL-запросы) делает результат особенно впечатляющим.

Сравнение SQL-игровых движков

ПроектБаза данныхРендерингМногопользовательскийFPSЗапуск
CedarDB/DOOMQLCedarDBЧистый SQL✅ Да~30 FPSDocker + Python
petergpt/doomqlSQLiteSQL + Python❌ НетТерминалuv run
DuckDB-DOOMDuckDB (Wasm)SQL + JS❌ Нет~8 FPSБраузер

Итог

DOOMQL — это не просто технический курьёз. Это живая демонстрация того, что SQL — не просто язык запросов к таблицам, а полноценная вычислительная среда, способная взять на себя задачи, о которых её авторы не думали. А то, что подобный проект был реализован с помощью GPT-5.6 Sol за разумное время, говорит о реальном уровне современных языковых моделей в роли инструмента разработки.

DOOMQL был создан в период декретного отпуска автора и стал способом глубже разобраться в возможностях SQL. Код проекта опубликован на GitHub под лицензией MIT и запускается локально через Docker и Python.

Если вас тянет к экспериментам — репозитории открыты, лицензия свободная, а SQL-запросы ждут ваших читов.