DOOMQL：用SQLite做游戏引擎，GPT-5.6生成的复古FPS，在终端里玩

一句话看懂

Peter Gostev用GPT-5.6 Sol构建了一个Doom风格游戏，整个游戏引擎完全基于SQLite，所有逻辑和渲染都由SQL查询驱动。

详细发生了什么

Peter Gostev 用 OpenAI 的 GPT-5.6 Sol 模型做了一个实验项目 DOOMQL。核心想法很简单：让 SQLite 当游戏引擎，不只是存数据。

结果是一个跑在终端里的复古第一人称射击游戏。所有游戏逻辑——移动、碰撞检测、敌人AI、战斗、进度——以及屏幕上每一个RGB像素的渲染，全由SQLite的SQL查询完成。项目以Python终端脚本形式实现，克隆仓库后通过 uv run host/doomql.py 就能跑起来。

最让人印象深刻的是，游戏里的光线追踪渲染器是用一个巨大的递归CTE（Common Table Expression）实现的，相关SQL文件在 sql/003_render.sql 里。运行游戏后，会在 /tmp/doomql/.doomql/doomql.sqlite 生成一个SQLite数据库，可以用Datasette等工具直接查游戏状态。

中文圈视角

这个项目对中文开发者来说有几个值得关注的点：

SQLite的极限玩法：国内很多开发者对SQLite的认知还停留在“轻量级数据库”，DOOMQL展示了SQLite在计算和逻辑处理上的潜力——递归CTE做光线追踪，SQL管理游戏状态。这可能会启发一些国产数据库（如TiDB、OceanBase）的爱好者思考类似的应用场景。
AI生成代码的示范：项目由GPT-5.6 Sol生成，说明当前AI已经能产出结构完整、可运行的复杂项目。国内类似模型（如DeepSeek、Qwen）的用户可以尝试用类似prompt生成自己的创意项目。
无需GPU的复古游戏：游戏运行在终端中，不需要任何图形硬件，对国内配置不高的机器友好。同时，终端游戏在中文开发者社区（如V2EX、即刻）中一直有怀旧受众。
数据可观测性：游戏状态直接存储在SQLite中，可以用SQL查询实时分析，这种“数据库即游戏引擎”的思路对教育、调试和数据分析场景有启发。

不过，目前项目依赖 uv 和 Python 3.14，国内用户可能需要配置环境，且游戏本身是实验性质，没有完整的游戏体验。

几条值得记住的细节

项目完全由GPT-5.6 Sol生成，提示词是“如果SQLite是游戏引擎会怎样”。
光线追踪渲染器由单个递归CTE SQL查询实现，代码在 sql/003_render.sql。
运行后生成SQLite数据库，可用Datasette直接查询游戏状态。
游戏控制：WASD移动，J/L或方向键转向，空格射击，E使用，P暂停。
游戏目标是找到“INDEX TOKEN”，界面显示HP、弹药、分数和游戏刻数。

一句话总结

DOOMQL证明了SQLite的潜力远超数据库，也展示了AI生成复杂可运行代码的能力，对喜欢折腾的开发者来说是个有趣的周末项目。