三行命令,一个Python终端脚本,跑出来的却不是普通的命令行游戏——每一帧画面,包括屏幕上每一个像素的RGB值,都是SQLite算出来的。Peter Gostev用GPT-5.6 Sol写了这个叫DOOMQL的项目,仓库里有一个文件叫sql/003_render.sql,里面一条巨大的SQL查询,用递归CTE实现了一套完整的光线追踪。移动、碰撞、敌人、战斗、进度,连屏幕上的每个像素,全部由SQL接管。Simon Willison把它跑起来,还顺手用Datasette Apps插件配合Claude Fable 5,几句话生成了一个能实时显示游戏画面的网页前端。
好玩归好玩,真正值得琢磨的是两件事:SQL到底能不能干渲染这活儿,以及DOOMQL这个名字底下,可能不止一个项目。
从"存档柜"变成"计算引擎"
数据库通常干的是记账的活:玩家血量、坐标、物品栏,存进表里,查询的时候读出来。DOOMQL反过来了——渲染循环本身就是查询。递归CTE每一步向外推进一段光线,直到撞上墙面,这跟老式的逐列光线投射(比如《德军总部3D》的渲染方式)几乎是同一个思路,只是把计算搬进了数据库的执行引擎里,而不是应用层代码。SQLite从"存东西的地方"变成了"算东西的地方"。
Simon的体验有一条清楚的路径:先用uv run host/doomql.py跑通终端版本,再用datasette-apps打开生成的SQLite数据库,对着frame_pixels视图(x、y、r、g、b几列)自然语言让Claude Fable 5搭一个每秒刷新的网页查看器,追加一句"加个小地图",就得到了一个带战术地图、血量、弹药、分数的可视化面板。整个过程没写一行渲染代码,靠的是SQL视图加AI生成的前端胶水。
递归CTE的三道硬墙
这套玩法能跑起来,但不代表能推广。SQLite的递归CTE有个明确限制:递归项里不能用聚合函数或窗口函数,这直接卡住了更复杂渲染管线的实现方式,项目只能靠拆分查询、层层嵌套去绕。三角函数也不是开箱即用——sin、cos这类数学函数要在编译时打开SQLITE_ENABLE_MATH_FUNCTIONS开关才能用,否则得应用层自己注册。并发模型上,SQLite默认多读单写,WAL模式能提升一些读写并发,但它从设计上就不是给大规模实时模拟服务器用的。
- 风险.这几道限制意味着DOOMQL式的实现天然只适合单机、小分辨率、低帧率场景,想搬到更复杂的游戏逻辑或多人实时同步,得先解决数据库执行模型本身的瓶颈。
撞名的两个DOOMQL
搜索DOOMQL这个名字,会跳出另一个项目:cedardb/DOOMQL,基于CedarDB——一个兼容PostgreSQL的分析型数据库——搭的多人版本,官方博客称在128×64的终端分辨率下能跑到约30帧,亮点是玩家可以直接写SQL语句去操作共享游戏状态,"作弊"本身被设计成了乐趣的一部分。这和Simon报道的petergpt/doomql(SQLite、单人、GPT-5.6 Sol生成)是完全不同的代码库、不同的数据库引擎、不同的玩法机制,只是撞了同一个名字。
这不是孤例。早在2025年4月,就有人用DuckDB-WASM在浏览器里做过一个类似的光线投射游戏,同样靠递归CTE。数据库圈似乎每隔一阵就要有人拿SQL去挑战一次"这玩意到底能不能干正经计算之外的事"。
社区的反应也分成两派。一部分人觉得这是绝佳的教学素材,拿递归查询、连接、关系型思维去讲一个看得见摸得着的游戏,比讲抽象的表结构有意思得多。另一部分人觉得数据库干这活儿本身就不划算——SQLite适合做状态存储,不适合做高频渲染循环,DOOMQL更像是"能不能"的证明,而不是"该不该"的答案。还有较真的DOOM爱好者跳出来纠正命名:严格说这不是DOOM的渲染方式,DOOM引擎靠扇区和BSP遍历,这些项目全是逐列光线投射,更接近《德军总部3D》——叫DOOM,营销味重了点。
递归CTE能画像素,是本事;但数据库终究不是渲染管线。
这类实验真正有用的地方,不在于它能不能取代Godot或Unity——它显然不能——而在于它把递归CTE、窗口函数边界这些平时枯燥的数据库知识,变成了一件看得见的东西。天下熙熙,技术圈的热闹很多时候就是这样:一个荒诞的问题,认真做到底,顺手把边界画清楚了。