Présentation

Le projet SQLDoom transpose le moteur complet du Doom de 1993 – logique de jeu et rendu – dans des requêtes SQL. Le client Python ne gère que l’entrée clavier, le chronométrage (35 tics par seconde) et l’affichage du bitmap retourné par la base. Le jeu fonctionne en multijoueur deathmatch à quatre joueurs, avec file d’attente et accès en lecture‑seule aux tables d’état pendant l’attente.

Architecture et stockage

Le format .wad de Doom se traduit naturellement en tables relationnelles : VERTEXES, LINEDEFS, SIDEDEFS et SECTORS. L’importation complète du fichier Doom 1, réalisée avec un script Python de ~1000 lignes, dure environ 18 s sur un ordinateur portable. Une fois les tables créées, le moteur de jeu lit et met à jour ces tables à chaque tic, tandis que le rendu interroge les mêmes tables pour produire un tableau de pixels RGB.

WITH wall AS (
  SELECT round((v1.x + (v2.x - v1.x) * t / 32.0) / 48) AS col,
                round((v1.y + (v2.y - v1.y) * t / 32.0) / 96) AS row,
                l.left_sd_id < 0 AS solid
    FROM linedefs l,
         generate_series(0, 32) AS t
    JOIN vertexes v1 ON (v1.map_id, v1.id) = (l.map_id, l.v1_id)
    JOIN vertexes v2 ON (v2.map_id, v2.id) = (l.map_id, l.v2_id)
    WHERE l.map_id = 1)
SELECT string_agg(
       CASE WHEN (col, row) IN (SELECT col, row FROM wall WHERE solid)
            THEN '#'
            WHEN (col, row) IN (SELECT col, row FROM wall)
            THEN '.'
            ELSE ' '
       END, '' ORDER BY col)
FROM generate_series(-16, 79) AS col,
     generate_series(-51, -21) AS row
GROUP BY row ORDER BY row DESC;

Performances

Le boucle de jeu tourne à la fréquence originale de 35 tics s⁻¹, tandis que le rendu, pure fonction SQL, atteint jusqu’à 60 images s⁻¹ sur un processeur AMD Ryzen 7 7840U. Le rendu produit un framebuffer 320×200 avec codage RGB complet, sans recours à des fonctions graphiques externes. La séparation entre logique (35 Hz) et rendu (max 60 Hz) permet au client de demander de nouveaux cadres dès que possible, limitant ainsi la latence perçue.

Analyse des limites

Le modèle repose sur un SGBD capable de gérer des requêtes massives en temps réel ; la latence d’accès aux tables devient le facteur limitant dès que le nombre de joueurs augmente ou que la complexité de la scène dépasse les capacités de génération de séries. Le code Python, bien que minimal, reste indispensable pour le timing précis, ce qui introduit une dépendance à l’horloge du système hôte. Enfin, le port ne couvre que le premier épisode shareware, et aucune extension de niveaux ou de mods n’est prise en charge.