Présentation

Le projet SQLDoom transforme le moteur du jeu Doom en une suite de requêtes SQL exécutées sur le SGBD CedarDB. Une interface Python gère les entrées, le timing et l’affichage, tandis que plus de 1 300 lignes de SQL réparties sur 89 expressions de table communes (CTE) décrivent la logique du jeu et produisent 35 images bitmap par seconde. Le résultat est une fenêtre 640 × 480 pixels aux couleurs complètes, comparable à la sortie de l’exécutable original.

Architecture et logique SQL

La conversion des fichiers WAD de Doom en tables relationnelles repose sur la correspondance directe entre les structures du jeu (sommets, lignes, secteurs) et les colonnes de la base. Les arbres de partition spatiale (BSP) sont stockés avec un sort_key pré‑calculé ; un simple ORDER BY sort_key détermine l’ordre de rendu des murs, limitant le coût de tri à chaque image. Le rendu du sol et du plafond ne peut pas réutiliser les « visplanes » du moteur original ; le développeur a introduit un « hack » qui parcourt une liste ordonnée de panneaux pour générer ces surfaces.

SELECT ALL DEMON FROM E1M1;

Cette requête d’exemple illustre la façon dont les entités du niveau sont interrogées. D’autres CTE imbriquées calculent la visibilité, les collisions et les effets de lumière, chaque étape étant matérialisée dans la base avant le passage à l’étape suivante.

Performances et contraintes

Malgré le surcoût inhérent aux lectures/écritures en base, le développeur rapporte une performance d’environ 60 fps sur un ordinateur portable équipé d’un processeur Ryzen 7, avec des baisses ponctuelles à 35 fps lors de scènes très chargées. La limitation principale provient du nombre d’opérations SQL nécessaires pour chaque trame, ainsi que de la latence d’accès disque ou mémoire du SGBD. Le rendu en couleur complète nécessite la génération de 640 × 480 pixels, soit 307 200 valeurs de couleur par image, stockées temporairement dans des tables avant d’être transférées à l’affichage.

Implications pour le multijoueur

Le stockage de l’état du jeu dans une base relationnelle garantit un « snapshot » cohérent à chaque tick. Cette propriété élimine les incohérences typiques des jeux en réseau, telles que les mises à jour partielles ou les désaccords sur les collisions. En outre, les mécanismes de concurrence de CedarDB assurent que les actions simultanées des joueurs sont sérialisées de façon atomique, simplifiant la logique serveur. Le projet propose un dépôt GitHub contenant le code, ainsi qu’une version hébergée en ligne pour tester le concept, bien que la version distante montre des performances inférieures à celles obtenues en local.