Le nouveau foyer de Doom est une base de données
Doom vient de trouver un nouveau foyer : une base de données. SQLDoom, un projet de Lukas Vogel chez CedarDB, n'est pas simplement un jeu qui stocke des scores dans une base de données ou une imitation visuelle. Il s'agit d'une réimplémentation complète du Doom original de 1993, dont la logique de jeu et le rendu graphique s'exécutent entièrement en SQL.
Cette architecture est élégamment découplée. La logique du jeu et le moteur de rendu s'exécutent sous forme de requêtes SQL, tandis que Python sert de pont léger. Le rôle de Python se limite à capturer les entrées du clavier, à gérer le timing de la boucle de jeu et à afficher le tampon de trame résultant. Chaque image que vous voyez est le résultat d'une seule requête SQL massive.
L'ampleur de cette entreprise est impressionnante. La résolution de 320x200 du jeu, totalisant 64 000 pixels, est calculée par le moteur de rendu, qui comprend environ 1 300 lignes de SQL réparties sur environ 89 Common Table Expressions (CTE). La logique du jeu ajoute 5 900 lignes de SQL supplémentaires. L'intégralité de cette base de code SQL est nettement plus courte que les quelque 9 000 lignes de logique de jeu en C du Doom original.
Une requête pour peindre 64 000 pixels
Chaque image rendue dans SQLDoom provient d'une seule requête de base de données complexe. Cette requête calcule la couleur de chacun des 64 000 pixels (résolution 320 × 200) à l'écran, renvoyant l'image sous forme de données bitmap brutes, avec une ligne représentant chaque pixel. La requête de rendu seule couvre environ 1 300 lignes de SQL, utilisant environ 89 Common Table Expressions (CTE).
Les opérations relationnelles diffèrent fondamentalement du code procédural traditionnel. Au lieu de boucles explicites itérant sur les objets du jeu, SQLDoom exploite des opérations basées sur des ensembles pour traiter les entités collectivement. Cela permet à une seule instruction UPDATE, par exemple, de modifier simultanément l'état de tous les monstres, un contraste frappant avec les nombreuses boucles for ou while de l'implémentation originale en C.
Les mesures de performance sont impressionnantes pour un jeu natif de base de données. La logique de jeu principale respecte les 35 tics par seconde originaux de Doom, garantissant un rythme de jeu authentique. Cependant, le moteur de rendu peut atteindre jusqu'à 60 images par seconde (FPS) sur du matériel moderne en interpolant les positions de la caméra entre ces tics de jeu, offrant une expérience visuelle plus fluide que l'original de 1993. Lukas Vogel chez CedarDB a démontré avec succès la capacité surprenante du SQL en tant que moteur de jeu.
La base de données fait le gros du travail
Rendre Doom dans une base de données présente un compromis fascinant. Le moteur original de 1993, conçu par John Carmack, économisait magistralement les cycles CPU grâce aux arbres Binary Space Partitioning (BSP) pour déterminer la visibilité. SQLDoom, en revanche, calcule en force brute la profondeur et l'occlusion sur ses 64 000 pixels par image. Cela fait de la visibilité la partie la plus lente du pipeline de rendu SQL.
Cette approche par force brute n'est viable que grâce à l'architecture de CedarDB. Son moteur de requête compile les requêtes SQL directement en LLVM IR, puis en code machine natif, permettant aux charges de travail analytiques complexes de s'exécuter avec une vitesse impressionnante, jusqu'à 60 images par seconde sur un ordinateur portable. Cette compilation est cruciale pour gérer les 1 300 lignes de SQL dans une seule requête de rendu, comme décrit dans l'article de blog du projet : We Ported the Original Doom to SQL - CedarDB.
Le monde du jeu lui-même se transforme en données structurées. Les actifs WAD emblématiques de Doom, qui définissent tout, de la géométrie de la carte aux textures, trouvent de nouveaux foyers sous forme de tables relationnelles. Cela inclut :
- Cartes
- Secteurs
- Linedefs
- Textures
Même des éléments individuels comme le shotgun deviennent des lignes dans une table, permettant une manipulation SQL directe pour modifier les mécaniques de jeu, comme mettre à jour une arme pour tirer 500 plombs avec une simple instruction UPDATE. Cela rend l'ensemble de l'univers du jeu interrogeable et modifiable via des opérations de base de données standard.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Quand les mécaniques de jeu deviennent des lignes éditables
Une conception inhabituelle produit également des résultats surprenants. Comme les armes et les statistiques des joueurs résident sous forme de données de table, une simple mise à jour SQL peut modifier le nombre de plombs d'un shotgun ou la santé de base d'un joueur. Cela démontre les capacités dynamiques de la base de données, bien qu'une partie en direct restreindrait une telle manipulation directe.
La fonctionnalité multijoueur émerge naturellement des transactions de base de données. Chaque tick de jeu est traité comme une transaction isolée, garantissant que tous les joueurs interrogent une vue cohérente et synchronisée de l'univers du jeu. Des fonctions restreintes empêchent les clients de modifier directement des valeurs protégées, comme leur propre santé, préservant ainsi l'intégrité du jeu.
SQLDoom transcende la simple nouveauté, servant de banc d'essai rigoureux pour les moteurs de requêtes de bases de données en tant que plateformes de calcul. Ce projet s'appuie sur le prototype de raycasting ASCII précédent de Lukas Vogel, DOOMQL, repoussant les limites de ce que les bases de données relationnelles peuvent accomplir. SQLDoom nous invite à reconsidérer comment d'autres mécaniques de jeu complexes pourraient être représentées et exécutées sous forme de données et de requêtes pures.
Questions fréquemment posées
Qu'est-ce que SQLDoom ?
SQLDoom est un projet de Lukas Vogel chez CedarDB qui réimplémente la logique de jeu et le rendu graphique de Doom en SQL.
SQLDoom fonctionne-t-il entièrement en SQL ?
La logique de jeu et le moteur de rendu fonctionnent en SQL. Python gère les entrées clavier, le timing et l'affichage de l'image rendue.
Combien de pixels SQLDoom rend-il par image ?
Il calcule 64 000 pixels par image, correspondant à la résolution 320x200 de Doom.
Comment SQLDoom gère-t-il le multijoueur ?
Les ticks de jeu s'exécutent en tant que transactions de base de données, offrant aux joueurs une vue synchronisée de l'état partagé du jeu.