O novo lar de Doom é um banco de dados
Doom acaba de encontrar um novo lar: um banco de dados. SQLDoom, um projeto de Lukas Vogel na CedarDB, não é apenas um jogo que armazena pontuações em um banco de dados ou uma imitação visual. É uma reimplementação completa do Doom original de 1993, com sua lógica de jogo central e renderização de gráficos sendo executadas inteiramente em SQL.
Esta arquitetura é elegantemente desacoplada. A lógica do jogo e o motor de renderização rodam como consultas SQL, enquanto o Python atua como uma ponte leve. O papel do Python limita-se a capturar a entrada do teclado, gerenciar o tempo do loop do jogo e exibir o buffer de quadros resultante. Cada quadro que você vê é o resultado de uma única e massiva consulta SQL.
A escala deste empreendimento é impressionante. A resolução de 320x200 do jogo, totalizando 64.000 pixels, é calculada pelo renderizador, que compreende aproximadamente 1.300 linhas de SQL em cerca de 89 Common Table Expressions (CTEs). A lógica do jogo adiciona outras 5.900 linhas de SQL. Toda esta base de código SQL é notavelmente menor do que as cerca de 9.000 linhas de lógica de jogo em C do Doom original.
Uma consulta pinta 64.000 pixels
Cada quadro renderizado no SQLDoom origina-se de uma única e complexa consulta de banco de dados. Esta consulta calcula a cor de cada um dos 64.000 pixels (resolução de 320 × 200) na tela, retornando a imagem como dados de bitmap brutos, com uma linha representando cada pixel. A consulta de renderização sozinha abrange aproximadamente 1.300 linhas de SQL, utilizando cerca de 89 Common Table Expressions (CTEs).
As operações relacionais diferem fundamentalmente do código procedural tradicional. Em vez de loops explícitos iterando através de objetos do jogo, o SQLDoom aproveita operações baseadas em conjuntos para processar entidades coletivamente. Isso permite que uma única instrução UPDATE, por exemplo, modifique o estado de todos os monstros simultaneamente, um contraste marcante com os numerosos loops for ou while da implementação original em C.
As métricas de desempenho são impressionantes para um jogo nativo de banco de dados. A lógica central do jogo adere aos 35 tics por segundo originais do Doom, garantindo um ritmo de jogo autêntico. No entanto, o renderizador pode atingir até 60 quadros por segundo (FPS) em hardware moderno ao interpolar posições da câmera entre esses tics do jogo, proporcionando uma experiência visual mais fluida do que o original de 1993. Lukas Vogel, da CedarDB, demonstrou efetivamente a surpreendente capacidade do SQL como um motor de jogo.
O banco de dados faz o trabalho pesado
Renderizar Doom em um banco de dados apresenta um compromisso fascinante. O motor original de 1993, projetado por John Carmack, conservava magistralmente ciclos de CPU com árvores de Binary Space Partitioning (BSP) para determinar a visibilidade. O SQLDoom, por outro lado, utiliza força bruta para cálculos de profundidade e oclusão em seus 64.000 pixels por quadro. Isso torna a visibilidade a parte mais lenta do pipeline de renderização SQL.
Esta abordagem de força bruta só é viável graças à arquitetura da CedarDB. Seu motor de consulta compila consultas SQL diretamente para LLVM IR e, em seguida, para código de máquina nativo, permitindo que cargas de trabalho analíticas complexas sejam executadas com velocidade impressionante — até 60 quadros por segundo em um laptop. Esta compilação é crucial para lidar com as 1.300 linhas de SQL em uma única consulta de renderização, conforme descrito na postagem do blog do projeto: We Ported the Original Doom to SQL - CedarDB.
O mundo do jogo em si se transforma em dados estruturados. Os ativos WAD icônicos do Doom, que definem tudo, desde a geometria do mapa até as texturas, encontram novos lares como tabelas relacionais. Isso inclui:
- Mapas
- Setores
- Linedefs
- Texturas
Até mesmo itens individuais, como a shotgun, tornam-se linhas em uma tabela, permitindo a manipulação direta via SQL para alterar mecânicas de jogo, como atualizar uma arma para disparar 500 projéteis com um simples comando UPDATE. Isso torna todo o mundo do jogo consultável e modificável por meio de operações padrão de banco de dados.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Quando as mecânicas de jogo se tornam linhas editáveis
Um design incomum também gera resultados surpreendentes. Como as armas e os atributos do jogador residem como dados de tabela, um único comando SQL pode alterar a contagem de projéteis de uma shotgun ou a vida base de um jogador. Isso demonstra as capacidades dinâmicas do banco de dados, embora uma partida ao vivo restrinja tal manipulação direta.
A funcionalidade multiplayer surge naturalmente das transações de banco de dados. Cada tick do jogo é processado como uma transação isolada, garantindo que todos os jogadores consultem uma visão consistente e sincronizada do mundo do jogo. Funções restritas impedem que os clientes alterem diretamente valores protegidos, como sua própria vida, mantendo a integridade do jogo.
O SQLDoom transcende a mera novidade, servindo como um campo de testes rigoroso para mecanismos de consulta de banco de dados como plataformas de computação. Este projeto baseia-se no protótipo anterior de raycasting ASCII de Lukas Vogel, o DOOMQL, expandindo os limites do que bancos de dados relacionais podem alcançar. O SQLDoom nos convida a reconsiderar como outras mecânicas de jogo complexas poderiam ser representadas e executadas como dados e consultas puras.
Perguntas Frequentes
O que é o SQLDoom?
O SQLDoom é um projeto de Lukas Vogel na CedarDB que reimplementa a lógica de jogo e a renderização gráfica do Doom em SQL.
O SQLDoom roda inteiramente em SQL?
A lógica do jogo e o renderizador rodam em SQL. O Python lida com a entrada do teclado, o tempo e a exibição do quadro renderizado.
Quantos pixels o SQLDoom renderiza por quadro?
Ele calcula 64.000 pixels por quadro, correspondendo à resolução de 320 por 200 do Doom.
Como o SQLDoom lida com o multiplayer?
Os ticks do jogo rodam como transações de banco de dados, oferecendo aos jogadores uma visão sincronizada do estado compartilhado do jogo.