Doom no euclidiano: qué le pasa a un juego cuando pi no es 3.14159 (2022) [video]

 (media.ccc.de)
3 puntos por GN⁺ 2024-05-18 | 1 comentarios | Compartir por WhatsApp
  • A partir del valor incorrecto de pi en el código fuente de Doom, explora cómo cambian el renderizado y la percepción espacial de un juego de disparos en primera persona cuando se alteran deliberadamente aún más las constantes matemáticas
  • Los gráficos de videojuegos dependen no solo de pi, sino también de la trigonometría y de varias técnicas matemáticas, por lo que incluso pequeños cambios matemáticos pueden afectar la forma en que se ve el mundo y se navega por él
  • Doom es un FPS clásico cuyo código fuente fue publicado bajo GPL en 1999, por lo que pudo usarse como sujeto de experimentos para modificar pi, funciones trigonométricas y constantes
  • El experimento también repasa las técnicas de optimización que hicieron que Doom funcionara bien en el hardware de la época, y ofrece instrucciones para compilar directamente la versión con matemáticas incorrectas
  • Examina si la geometría no euclidiana puede crear nuevas experiencias espaciales dentro de un juego, y también enlaza otros juegos que usan valores incorrectos de pi y repositorios públicos de código fuente

Desajustar deliberadamente las matemáticas de Doom

  • Pi se conoce como una constante con un valor fijo, pero el código fuente de Doom usa un valor incorrecto de pi
  • El renderizado de gráficos depende no solo de pi, sino también de la trigonometría y de varias técnicas matemáticas
  • El experimento verifica cómo cambia el juego si se modifica el valor de pi en el código fuente de Doom para hacerlo aún más impreciso
  • Al cambiar también otras funciones trigonométricas y constantes, observa cómo se altera la sensación de comprender y desplazarse por un mundo virtual familiar

Código fuente de Doom y alcance del experimento

  • Doom es un conocido juego de disparos en primera persona clásico
  • El código fuente de Doom fue publicado bajo GPL en 1999
  • El experimento incluye lo siguiente:
    • Cambiar el valor de pi por uno aún más incorrecto
    • Cambiar otras funciones trigonométricas por valores incorrectos
    • Cambiar constantes matemáticas relacionadas por valores imprecisos

Posibilidades de juegos no euclidianos

  • Si se cambian las matemáticas, también puede cambiar la estructura del espacio virtual que el jugador conocía y la sensación de desplazamiento
  • Examina si estos cambios pueden conducir a posibilidades interesantes de juego basadas en geometría no euclidiana

Optimización de rendimiento y ejecución directa

  • También aborda brevemente las técnicas de optimización que hicieron que Doom corriera bien en el hardware de la época
  • Al final de la charla, se ofrecen instrucciones para compilar directamente la versión de Doom con matemáticas incorrectas

Material relacionado

  • También se proporcionan enlaces a otros juegos que usan valores incorrectos de pi y a repositorios públicos de código fuente
  • El video de la charla está disponible como contenido de MCH2022 en media.ccc.de

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-05-18
Comentarios de Hacker News

  • También había un ejemplo de esto en el clásico Duke Nukem 3D. Era el nivel “Lunatic Fringe”, creado por Richard “Levelord” Gray.
    https://dukenukem.fandom.com/wiki/Lunatic_Fringe
    El nivel tenía un pasillo circular en el exterior, con una estructura que daba dos vueltas completas sin cruzarse consigo mismo, y aprovechaba la capacidad del innovador motor Build de la época para separar áreas mediante conexiones entre salas. Esa función también se usaba para la técnica de “sala sobre sala”.
    Era divertido en multijugador y la ilusión óptica se mantenía bastante bien. Si mal no recuerdo, la sala central tenía 4 entradas, pero en cada vuelta por afuera solo te encontrabas con 2 de ellas.
    Mientras experimentaba con el motor, también llegué a hacer un nivel de juguete que resolvía con esta técnica el rompecabezas de “conectar 3 casas y 3 servicios públicos sin que las líneas se crucen”.

    • No entiendo en qué sentido lo de Duke Nukem es “un ejemplo de esto”. Lo de Duke es un comportamiento programático internamente coherente, mientras que esto se parece más a errores aleatorios producidos por un cambio arbitrario en el código fuente.
      Duke podría ser algo parecido a geometría no euclidiana, pero cambiar pi en Doom no tiene mucho que ver con la geometría y parece más bien un caso de “si entra basura, sale basura”.
    • Si hablamos de la “innovadora técnica de ‘sala sobre sala’ de la época”, Marathon de Bungie, de 1994, ya podía hacerlo y lo mostró en el mapa de deathmatch 5-D Space[1].
      En realidad, prácticamente solo Doom se rompía con sectores superpuestos.
      [1] https://www.lhowon.org/level/marathon/30
    • Hace mucho hice un motor pequeño con una función de este tipo. En ese momento no conocía el motor Build, y dividí el mundo en sectores convexos, pero en vez de seguir un árbol BSP permití enlaces arbitrarios, es decir, portales. El renderizado avanzaba de adelante hacia atrás y recortaba en los límites de los portales.
      Si puedes rasterizar el interior de una figura convexa, también puedes rasterizar un mundo de sectores y portales marcando una cara determinada como portal, definiendo la zona donde esa cara es visible como región de clipping o como stencil buffer, y luego renderizando el sector del otro lado con la transformación adecuada contenida en los datos del portal y el ID del sector opuesto.
      El manejo de colisiones al atravesar portales es mucho más difícil que renderizar lo que hay más allá de ellos.
    • La sala sobre sala que implementaron los juegos posteriores con Build normalmente no requiere que los sectores se superpongan de esta forma. Es una extensión de la manera en que se implementaba el agua nadable: el motor renderiza otro sector en lugar del piso o el techo.
      Lunatic Fringe es un ejemplo directo de geometría imposible en Build, pero los mapas de Duke3D contienen mucha más geometría intersectada. En Doom no se puede construir un árbol BSP con una estructura así y, además, jugadores y monstruos solo rastrean coordenadas X/Y, así que obviamente es imposible.
    • Hay un juego de VR interesante llamado Tea For God. Dentro del espacio físico real de juego, cada vez que doblas una esquina o tomas un elevador, crea de forma ingeniosa nuevos pasillos y salas, dando la ilusión de estar en un lugar enorme aunque nunca salgas de la misma habitación. Está implementado sin joystick ni teletransporte.

  • Justo estaba leyendo el clásico Operation Chaos de Poul Anderson.
    https://en.wikipedia.org/wiki/Operation_Chaos_(novel)
    Está ambientado en un mundo paralelo donde la magia es real y avanza rápidamente junto con la ciencia. Por ejemplo, Edwin Land inventa un dispositivo que usa polarización para transformar a hombres lobo sin luz de luna.
    El hijo de los protagonistas es secuestrado y llevado al infierno, y ellos se enteran de que el ejército intentó investigar el infierno 20 años antes, pero todos terminaron enloqueciendo. El antagonista deja caer una pista: como la geometría del espacio-tiempo del infierno es distinta de la nuestra, podrían volver al instante en que el niño llega y llevárselo.
    Solo con esa pista, los científicos deducen que la geometría del infierno es geometría no euclidiana y calculan hechizos para entrar de forma segura, resistir allí y regresar. Para encontrar el camino, rezan pidiendo ayuda a dos geómetras del siglo XIX, uno de ellos un santo.

    • La geometría del espacio-tiempo de nuestro mundo tampoco es euclidiana, y ni siquiera es geometría riemanniana. Operation Chaos parece más caótica que científica.
      En las obras de Poul Anderson que he leído, como la excelente High Crusade, él tampoco se preocupa demasiado por el barniz científico; le gusta avanzar a lo bruto.
      Como otra obra sobre geometría no euclidiana, recuerdo con cariño Inverted World, de Christopher Priest.
    • Quizá suene trillado, y tal vez lo sea, pero últimamente no entiendo por qué ya no salen tantas novelas creativas.
    • También vale la pena leer la excelente colección de relatos Tales of the Dying Earth de Jack Vance. Incluye magia/ciencia y dimensiones demoníacas.
    • Me gustó Operation Chaos, pero la secuela que salió mucho después me decepcionó.

  • Puede que John Carmack haya recordado mal el décimo dígito de pi, pero estaría bueno que todos buscaran 84,600 en su base de código para ver si alguien escribió mal la cantidad de segundos que tiene un día.
    Es sorprendentemente común, y deja una lección sobre si conviene ingresar constantes directamente en el programa o usar valores que ya existen en la biblioteca estándar del lenguaje de programación.

  • En realidad, los gráficos y el movimiento se vuelven raros hasta que al final ya no se puede jugar. Más que llamarlo Doom no euclidiano, parece más correcto llamarlo “las consecuencias de tocar una constante del universo”.
    Esperaba que un Doom realmente no euclidiano se viera así: https://youtu.be/kEB11PQ9Eo8?si=0HNlpGFBii2AIK1n

    • Si nos ponemos un poco quisquillosos, ese video también usa mal el término no euclidiano. La gente de HyperRogue hizo algunos videos que muestran geometría no euclidiana real.
      https://youtu.be/yqUv2JO2BCs?si=AutaqS5unvT7cDjw
      Al ver los efectos geométricos extraños del video de Doom, como cuando al avanzar parece que los objetos se deslizan hacia los costados, llamar no euclidiano a este Doom también parece hasta cierto punto razonable.
    • Eso tampoco es lo que significa no euclidiano. Es simplemente un mundo 3D común con portales. En esa época, los motores de juegos de disparos en primera persona normalmente conectaban habitaciones mediante umbrales, es decir, portales, y los usaban para la eliminación de partes ocultas.
      Podían representar geometría normal, pero la geometría no tenía por qué tener sentido de ninguna manera, y también permitían conexiones arbitrarias entre habitaciones. No quiero ponerme puntilloso, pero es un malentendido común.
      Para no euclidiano de verdad, recomiendo el trabajo de ZenoRogue. Por ejemplo, un juego simple que usa geometría Nil[1], una enorme batalla contra un jefe en un roguelike de mundo no euclidiano[2], rarezas geométricas en general[3], etc. Básicamente, miren cualquiera de sus trabajos.
      [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...
    • Me sorprende que todavía no haya aparecido Antichamber. Fue un gran juego que convirtió un concepto parecido en puzzles reales.
      Ahora que lo pienso, ya pasó suficiente tiempo como para que valga la pena jugarlo de nuevo.
    • Esto parece un portal. En aquella época, los juegos de disparos en primera persona básicamente conectaban habitaciones mediante umbrales, es decir, portales, para hacer eliminación de partes ocultas.
      No había problema para representar geometría normal, pero no existía la condición de que la geometría necesariamente tuviera sentido, y se podían conectar habitaciones de forma arbitraria.
    • Yo esperaba exactamente algo así. Acá hay otra implementación no euclidiana que además incorpora algunas ideas nuevas.
      https://www.youtube.com/watch?v=tl40xidKF-4

  • Doom no es una simulación, así que cambiar una constante no sirve como buen ejemplo de nada.
    Es más bien romper algunas rutinas, y por eso la mayoría de los cambios terminan haciendo que no se pueda jugar.

    • No termino de entender por qué esto es interesante. Si cambias una constante por un número incorrecto, obviamente vas a obtener comportamientos raros o errores. ¿Qué otra cosa podría pasar? El comportamiento raro tampoco parece especial; no sé qué me estoy perdiendo.

  • Toma el código fuente de tu emulador de consola favorito y mételes errores de punto flotante al azar, o invierte el significado de algunas instrucciones de bifurcación. Cuanto más viejo sea el juego, más probable es que siga funcionando, y también más probable es que parezca un mal viaje alucinógeno.

    • Hace mucho existía una herramienta para emuladores de N64 que hacía algo así. La probé y fue divertida por un tiempo, aunque, como era de esperarse, se colgaba seguido.
      También había proyectos de glitch art que rompían secciones concretas de archivos de imágenes y videos famosos para crear algo nuevo. Me gustaría volver a encontrar ambos, pero no logro hacerlo.

  • Marathon 1 (1994) admitía espacios no euclidianos, pero se usaban muy rara vez. Al jugar todo el juego, compuesto por varios niveles con mapas, en apenas uno o dos niveles aparecen espacios imposibles, y el juego no advierte ni informa que eso sea posible.
    Por eso quizá era la mejor ubicación para un easter egg que se podía encontrar en el juego.
    También encontré un video de demostración: https://www.reddit.com/r/Marathon/comments/vclu55/probably_n...

  • La última pregunta es: “¿cuál es el valor máximo de pi que sigue siendo jugable y no crashea?”. La razón por la que con pi igual a 4 se produce un error de segmentación probablemente sea que algunos accesos a tablas de consulta se pasan del final de la tabla; si es así, es muy probable que el valor máximo jugable sea apenas un poco mayor que el propio pi.

  • Me habría gustado que este video profundizara más en las mecánicas del juego y en por qué cambiar Pi causó problemas de esa manera.

  • Me pregunto si este experimento sería más interesante en el Doom con trazado de rayos mencionado. El resultado de hackear la constante en la técnica de rasterización fue casi el esperado. Pero con trazado de rayos podrían aparecer resultados más interesantes.