3 pontos por GN⁺ 2024-05-18 | 1 comentários | Compartilhar no WhatsApp
  • 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

 
GN⁺ 2024-05-18
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”

    • Não sei em que sentido Duke Nukem é “um exemplo disso”. No caso de Duke, é um comportamento internamente consistente do programa; isto aqui está mais perto de erros aleatórios causados por uma alteração arbitrária no código-fonte
      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”
    • Se a “técnica de ‘sala sobre sala’, revolucionária na época” é o ponto, Marathon, da Bungie, em 1994, já conseguia fazer isso e mostrou no mapa de deathmatch 5-D Space[1]
      Na prática, praticamente só o Doom quebrava com setores sobrepostos
      [1] https://www.lhowon.org/level/marathon/30
    • Muito tempo atrás, fiz uma pequena engine com esse tipo de recurso. Na época eu não conhecia a Build engine; dividi o mundo em setores convexos e, em vez de seguir uma árvore BSP, permiti links arbitrários, isto é, portais. A renderização era feita da frente para trás, recortando nas bordas dos portais
      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
    • A implementação de sala sobre sala nos jogos posteriores da Build geralmente não exige que os setores se sobreponham desse jeito. É uma extensão do modo como implementavam água nadável: a engine renderiza outro setor em vez do piso ou do teto
      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
    • Existe um jogo de VR interessante chamado Tea For God. Dentro do espaço físico real de jogo, sempre que você vira uma esquina ou pega um elevador, ele cria de forma engenhosa novos corredores e salas, dando a ilusão de estar em um lugar enorme sem que você saia do mesmo cômodo. É implementado sem joystick nem teletransporte
  • 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

    • A geometria do espaço-tempo do nosso mundo também não é euclidiana, e nem sequer é geometria riemanniana. Operation Chaos parece mais caótico do que científico
      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
    • Pode soar clichê, e talvez realmente seja, mas hoje em dia não entendo por que quase não saem romances criativos assim
    • Também vale conferir a excelente coletânea Tales of the Dying Earth, de Jack Vance. Ela traz magia/ciência e dimensões demoníacas
    • Gostei de Operation Chaos, mas a continuação, publicada muito mais tarde, foi decepcionante
  • 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

  • Na 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

    • Sendo um pouco pedante, esse vídeo também usa o termo não euclidiano de forma errada. O pessoal do HyperRogue fez alguns vídeos que mostram geometria não euclidiana de verdade
      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
    • Isso também não é o que não euclidiano significa. É só um mundo 3D comum com portais. Os engines de FPS daquela época normalmente conectavam salas por portas, ou seja, portais, e usavam isso para remoção de partes ocultas
      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...
    • É surpreendente que Antichamber ainda não tenha sido mencionado. Foi um ótimo jogo que criou puzzles reais com um conceito parecido
      Pensando bem, já passou tempo suficiente; acho que seria divertido jogar de novo
    • Isso parece um portal. Os FPS da época basicamente conectavam salas por portas, ou seja, portais, para fazer a remoção de partes ocultas
      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
    • Eu também esperava exatamente algo assim. Aqui há outra implementação não euclidiana com algumas outras ideias novas incluídas
      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

    • Não entendo muito bem por que isso é interessante. Se você troca uma constante por um número errado, é claro que vai surgir comportamento estranho ou erro. O que mais aconteceria? O comportamento estranho também não parece especial; não sei o que estou deixando passar
  • 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

    • Muito tempo atrás havia uma ferramenta que fazia isso para emuladores de N64. Usei e foi divertido por um tempo, mas, como esperado, travava com frequência
      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