Doom não euclidiano: o que acontece com um jogo quando pi não é 3,14159 (2022) [Vídeo]
(media.ccc.de)- Partindo do valor incorreto de pi no código-fonte de Doom, explora como a renderização e a percepção espacial em um jogo de tiro em primeira pessoa mudam quando constantes matemáticas são propositalmente distorcidas
- Como os gráficos de jogos dependem não só de pi, mas também de trigonometria e várias técnicas matemáticas, até pequenas mudanças matemáticas podem afetar a forma de ver e se mover pelo mundo
- Doom pôde ser usado como objeto desse experimento porque é um FPS clássico cujo código-fonte foi liberado sob GPL em 1999, permitindo testar alterações em pi, funções trigonométricas e constantes
- O experimento também aborda técnicas de otimização usadas para fazer Doom rodar bem no hardware da época e oferece instruções para compilar diretamente uma versão com matemática incorreta
- Analisa se a geometria não euclidiana pode criar novas experiências espaciais dentro de jogos e também relaciona outros jogos que usam valores incorretos de pi e repositórios públicos de código-fonte
Distorcendo de propósito a matemática de Doom
- Pi é conhecido como uma constante de valor fixo, mas o código-fonte de Doom usa um valor incorreto de pi
- A renderização gráfica depende não só de pi, mas também de trigonometria e de várias técnicas matemáticas
- O experimento verifica como o jogo muda quando o valor de pi no código-fonte de Doom é substituído por um valor ainda mais impreciso
- Também altera outras funções trigonométricas e constantes para observar como a sensação de compreender e navegar por um mundo virtual familiar se desestabiliza
Código-fonte de Doom e escopo do experimento
- Doom é um clássico e conhecido jogo de tiro em primeira pessoa
- O código-fonte de Doom foi liberado sob GPL em 1999
- O experimento inclui os seguintes pontos
- alterar o valor de pi para um valor ainda mais incorreto
- alterar outras funções trigonométricas para valores incorretos
- alterar com imprecisão constantes matemáticas relacionadas
Possibilidades de jogos não euclidianos
- Ao mudar a matemática, a estrutura do espaço virtual e a sensação de movimento que o jogador conhecia também podem mudar
- Examina se esse tipo de mudança pode levar a possibilidades interessantes de jogos baseados em geometria não euclidiana
Otimização de desempenho e execução direta
- Também aborda brevemente técnicas de otimização usadas para que Doom rodasse bem no hardware da época
- No fim da apresentação, são fornecidas instruções para compilar diretamente a versão de Doom com matemática incorreta
Materiais relacionados
- Também são fornecidos links para outros jogos que usam valores incorretos de pi e para repositórios públicos de código-fonte
- O vídeo da apresentação está disponível como conteúdo do MCH2022 em media.ccc.de
1 comentários
Opiniões no Hacker News
Havia um exemplo assim também no clássico Duke Nukem 3D. É a fase “Lunatic Fringe”, criada por Richard “Levelord” Gray
https://dukenukem.fandom.com/wiki/Lunatic_Fringe
Essa fase tinha um corredor circular do lado de fora, estruturado de modo que dava duas voltas completas sem se cruzar, usando a capacidade, revolucionária na época, do Build engine de separar áreas com base na conexão entre salas. Esse recurso também era usado na técnica de “sala sobre sala”
Era divertida no multiplayer, e a ilusão de ótica se mantinha bem. Se minha memória não falha, a sala central tinha 4 entradas, mas a cada volta pelo lado de fora você só encontrava 2 delas
Enquanto experimentava com a engine, eu também cheguei a fazer uma fase de brinquedo que resolvia, com essa técnica, o quebra-cabeça de “conectar 3 casas e 3 serviços públicos sem que as linhas se cruzem”
Duke talvez seja algo como geometria não euclidiana, mas essa mudança de pi no Doom não tem muita relação com geometria e parece mais um caso de “entra lixo, sai lixo”
Na prática, praticamente só o Doom quebrava com setores sobrepostos
[1] https://www.lhowon.org/level/marathon/30
Se você consegue rasterizar o interior de uma forma convexa, também consegue rasterizar um mundo setor-portal marcando uma determinada face como portal, definindo a área onde essa face ficaria visível como região de clipping ou stencil buffer e, em seguida, usando a transformação apropriada contida nos dados do portal e o ID do setor do outro lado para renderizar o setor atrás dele
O tratamento de colisão ao atravessar portais é muito mais difícil do que renderizar através deles
Lunatic Fringe é um exemplo direto de geometria impossível na Build, mas os mapas de Duke3D têm muito mais geometria que se cruza. No Doom, não dá para construir uma árvore BSP com esse tipo de estrutura, e jogadores ou monstros só acompanham coordenadas X/Y, então obviamente é impossível
Por coincidência, eu estava lendo o clássico Operation Chaos, de Poul Anderson
https://en.wikipedia.org/wiki/Operation_Chaos_(novel)
A história se passa em um mundo paralelo onde a magia é real e se desenvolve rapidamente junto com a ciência. Por exemplo, Edwin Land inventa um dispositivo que usa polarização para transformar lobisomens sem luar
O filho dos protagonistas é sequestrado e levado para o inferno, e eles ficam sabendo que, 20 anos antes, o exército tentou investigar o inferno, mas todos enlouqueceram. O antagonista deixa escapar uma pista de que, como a geometria do espaço-tempo do inferno é diferente da nossa, seria possível voltar ao momento em que a criança chega e resgatá-la
Só com essa pista, os cientistas deduzem que a geometria do inferno é uma geometria não euclidiana e calculam feitiços para entrar com segurança, sobreviver e voltar. Para encontrar o caminho, eles rezam para receber a ajuda de dois geômetras do século XIX, um dos quais é santo
Nas obras de Poul Anderson que li, como o excelente High Crusade, ele gosta de avançar sem muita delicadeza, sem se preocupar muito com o verniz científico
Outra obra que trata de geometria não euclidiana e da qual guardo boa lembrança é Inverted World, de Christopher Priest
John Carmack pode ter lembrado errado a 10ª casa decimal de pi, mas seria bom todo mundo procurar por 84.600 na base de código e ver se alguém digitou errado o número de segundos em um dia
É surpreendentemente comum, e há uma lição aí sobre se você deve inserir constantes diretamente no programa ou usar valores que já existem na biblioteca padrão da linguagem de programação
https://github.com/search?type=code&auto_enroll=true&q=84600
https://github.com/mysql/mysql-server/blob/824e2b4064053f7da...
https://github.com/textmate/textmate/blob/346b52b108b387462d...
15 * 60 * 60Na prática, os gráficos e o movimento ficam estranhos e, no fim, o jogo se torna injogável. Em vez de chamar isso de Doom não euclidiano, parece mais correto chamar de “resultado de mexer nas constantes do universo”
Eu esperava que um Doom realmente não euclidiano fosse algo assim: https://youtu.be/kEB11PQ9Eo8?si=0HNlpGFBii2AIK1n
https://youtu.be/yqUv2JO2BCs?si=AutaqS5unvT7cDjw
Vendo os efeitos geométricos estranhos no vídeo de Doom, como objetos parecendo deslizar para o lado quando você anda para a frente, chamar esse Doom de não euclidiano até parece razoável em certa medida
Eles podiam representar geometria normal, mas a geometria não precisava fazer sentido de maneira alguma, e conexões arbitrárias entre salas também eram permitidas. Não quero ficar implicando com detalhes, mas é um mal-entendido comum
Para não euclidiano de verdade, recomendo o trabalho do ZenoRogue. Por exemplo, há um jogo simples que usa geometria Nil[1], uma luta de chefe enorme em um roguelike de mundo não euclidiano[2], estranhezas geométricas em geral[3] etc. Basta ver qualquer coisa deles
[1] https://m.youtube.com/watch?v=gejRg_q70EA&pp=ygUJemVub3JvZ3V...
[2] https://m.youtube.com/watch?v=jcnXI8IArRI&pp=ygUJemVub3JvZ3V...
[3] https://m.youtube.com/watch?v=yqUv2JO2BCs&pp=ygUJemVub3JvZ3V...
Pensando bem, já passou tempo suficiente; acho que seria divertido jogar de novo
Não havia problema em representar geometria normal, mas não existia a condição de que a geometria necessariamente fizesse sentido, e era possível conectar salas arbitrariamente
https://www.youtube.com/watch?v=tl40xidKF-4
Doom não é uma simulação, então mudar uma constante não serve como um bom exemplo de alguma coisa
É mais como quebrar algumas rotinas, e por isso a maioria das mudanças torna o jogo injogável
Você pode pegar o código-fonte do seu emulador de console favorito e inserir erros de ponto flutuante aleatórios, ou inverter o significado de algumas instruções de desvio. Quanto mais antigo o jogo, maior a chance de ele ainda rodar, e maior a chance de parecer uma bad trip alucinógena
Também havia projetos de glitch art que corrompiam trechos específicos de arquivos famosos de imagem e vídeo para criar algo novo. Queria encontrar os dois de novo, mas não consegui
Marathon 1 (1994) dava suporte a espaços não euclidianos, mas isso era usado apenas raramente. Ao jogar o jogo inteiro, composto por vários níveis com mapas, espaços impossíveis aparecem só em um ou dois níveis, e o jogo não avisa nem informa que algo assim é possível
Então talvez tenha sido o melhor lugar para um easter egg encontrado no jogo
Também encontrei um vídeo de demonstração: https://www.reddit.com/r/Marathon/comments/vclu55/probably_n...
A última pergunta é: “qual é o valor máximo de pi que ainda é jogável e não trava?”. O motivo de ocorrer um erro de segmentação quando pi é 4 provavelmente é que alguns acessos à tabela de consulta passam do fim da tabela; se for esse o caso, o valor máximo jogável provavelmente é só um pouco maior que o próprio pi
Eu gostaria que este vídeo explorasse mais a fundo a mecânica do jogo e por que a alteração de pi causou problemas daquela forma
Fico curioso se esse experimento seria mais interessante no Doom com ray tracing mencionado. Os resultados de hackear a constante na técnica de rasterização foram praticamente os esperados. Mas, com ray tracing, talvez surgissem resultados mais interessantes