Guerra nuclear: una batalla en tu ordenador

© Nacho Agulló.  Todos los derechos reservados

     Jamás podré olvidar aquella mañana de verano de mil novecientos ochenta y cuatro.  Acababa de recoger del buzón el número de Julio de Investigación y Ciencia y pasaba presuroso las páginas en busca de mi sección favorita: Juegos de ordenador.  Cuando localicé la página correcta, mi sorpresa fué doble: en primer lugar, se hacía cargo de la sección un nuevo articulista, A. K. Dewdney; y en segundo lugar, el contenido rebasaba con creces mis expectativas.  Se describía nada menos que un ingenioso sistema que permitía poner dos programas en competición, buscando cada uno la aniquilación del rival.  Este original pasatiempo venía siendo desarrollado desde 1983 por el autor del artículo, profesor en la Universidad de Ontario Occidental, con la ayuda de David Jones, alumno de su departamento.

     La idea me fascinó desde el principio: un duelo de estrategias en el que el papel del jugador humano no consiste en participar directamente en el desarrollo del juego, sino en diseñar un gladiador algorítmico capaz de defenderse, contraatacar o decidir si desplazarse, todo ello en microsegundos.  ¿Serán así las guerras del futuro?  ¿Se desarrollarán a tan vertiginosa velocidad que los generales sólo podrán sentarse y observar como los ordenadores deciden, cambian y rectifican las tácticas miles de veces por segundo?  La idea no puede ser más estimulante.

     Me dediqué a aprender todo sobre el pasatiempo, conocido como Guerra Nuclear (su nombre original es Core Wars, en plural, ya que el inglés, al contrario que el castellano, es un idioma que pluraliza).  Supe que no estaba en absoluto relacionado con bombas atómicas, sino con un núcleo, escenario de los incruentos combates.  Pronto estuve familiarizado con el Código Rojo (Redcode), lenguaje en el que se escriben los programas combatientes, y con el sistema de competición, el Simulador de Código Rojo sobre Matriz de Memoria (Memory Array Redcode Simulator, cuyas siglas forman la apropiada palabra MARS, por Marte, el dios de la guerra).

     En los años siguientes he estado al corriente de las ampliaciones y modificaciones del juego; he seguido con interés las noticias acerca de los campeonatos; e incluso he tomado parte en uno.  Todo esto ha hecho que finalmente me decidiera a poner por escrito mis conocimientos, esperando que sean de utilidad a otro aficionado a la Guerra Nuclear, o simplemente a un neófito que abrigue interés por el tema.  Como dicen los artistas: para ustedes... la Guerra Nuclear.

     Introducción a la Guerra Nuclear

     Para jugar este sofisticado juego hacen falta tres cosas: un ordenador, una versión de MARS que funcione en él, y programas a los que poner en competición.  Lo normal, si ya cuentas con las dos primeras, es que estés deseando hacer tus propios programas.  Para ello, debes conocer los tres elementos del juego: el núcleo, especie de tablero de juego donde se desarrollará la lucha sin cuartel; el Redcode, el lenguaje en el que elaborarás tus programas; y la forma en que MARS dirige la partida.

     El Núcleo

     Para empezar, nada mejor que lo más sencillo: el propio Núcleo.  Este es una matriz unidimensional de 8000 direcciones, en forma de anillo, de forma que tras la última dirección volvemos a encontrar la primera.  En realidad, los programas participantes no saben cuál es la primera dirección ni la última, sino que se refieren a la dirección situada 100 posiciones hacia adelante o 800 posiciones detrás, referenciándolas como 100 o -800.  Dado que el núcleo es circular y tiene exactamente 8000 direcciones, podemos advertir que la dirección -1488 es la misma que la 6512 (de hecho, las diferentes versiones de MARS suelen manejar internamente las direcciones sin signo: en vez de restar 2, sumar 7998 da el mismo resultado; aunque esto no afecta a los programadores de Redcode).  Otra característica del núcleo es que si la dirección excede de 8000, se toma el resto de su división por esta misma cantidad.  Así, la dirección 9515 equivale a la 1515, y la -20118 a la -4118.  En cuanto al contenido de cada dirección, se divide en tres campos: el primero almacena el código correspondiente a una instrucción del lenguaje Redcode, y los otros, dos argumentos (A y B).  A continuación profundizaremos en este particular.

     El Código Rojo

     Este lenguaje de bajo nivel, similar a los ensambladores, consta de apenas una decena de instrucciones, cada una de las cuales puede ir acompañada de uno o dos argumentos que se denominan A y B.  Estos pueden ser interpretados de tres modos diferentes:

  • Modo 0 ó inmediato: expresa un valor numérico.  Se indica anteponiendo el símbolo "#". Ejemplo: #-1638.
  • Modo 1 ó directo: señala una dirección de forma directa.  Se indica sin ningún símbolo.  Por ejemplo: 6384 referencia la dirección situada 6384 posiciones delante de la actual.
  • Modo 2 ó indirecto: señala una dirección indirecta.  Se obtiene dirigiéndose a la dirección que se indica, y tomando el argumento en ella almacenado como dirección directa.  Se indica anteponiendo el símbolo @.  Por ejemplo: @1637 significa que nos dirigiremos 1637 posiciones hacia delante y leeremos el contenido de aquella dirección.  Si éste es, por ejemplo, #-1638, volveremos a desplazarnos 1638 posiciones hacia atrás (y, en este ejemplo, habremos señalado la posición contigua por detrás a nuestra casilla de partida).

     Como vemos, hay una diferencia fundamental entre el modo inmediato, que se interpreta como un valor numérico, y los modos directo e indirecto, que se interpretan como una dirección.  Por esto, a la hora de describir un argumento en modo inmediato, nos referiremos a él como "inm", mientras que otro en modo directo o indirecto lo describiremos como "dir".

     En cuanto al juego de instrucciones del Redcode, ha sufrido varias modificaciones desde su primera publicación.  Veamos cuál fué su formato original:

Instrucción Argumentos A,B Explicación
DAT inm No ejecutable. El valor inm se almacena en el argumento B
MOV inm,dir Copia el valor inm en la dirección dir
dir1,dir2 Copia el contenido de la dirección dir1 en la dir2
ADD inm,dir Suma el valor inm al contenido de la dirección dir
dir1,dir2 Suma el contenido de la dirección dir1 al de la dir2
SUB inm,dir Resta el valor inm al contenido de la dirección dir
dir1,dir2 Resta el contenido de la dirección dir1 al de la dir2
JMP dir Salta a la dirección dir, almacenada en el argumento B
JMZ dir1,dir2 Salta a dir1 si el contenido de dir2 es cero
JMG dir1,dir2 Salta a dir1 si el contenido de dir2 es mayor que cero
DJZ dir1,dir2 Resta 1 al contenido de la dirección dir2. Si el resultado es cero, salta a la dirección dir1
CMP dir1,dir2 Compara el contenido de las direcciones dir1 y dir2. Si es distinto, la siguiente instrucción será ignorada.

     Modificaciones posteriores

     Ya en el artículo de Julio del 84 Dewdney especulaba con la posibilidad de incluir la instrucción PCT dir.  Esta instrucción protege la casilla indicada contra un (y solo un) intento de escritura.

     En el artículo de Mayo del 85, Dewdney dió a conocer su decisión de incluir en el juego la nueva instrucción SPL dir.  Esta instrucción permite al programa subdividirse en dos, lo que significa que en los turnos siguiente se ejecutarán no solamente las instrucciones situadas tras el SPL, sino también las situadas a partir de la posición dir.  Posteriores usos de la instrucción SPL permitirán nuevas subdivisiones, y la aparición de todo un ejército de programas.  Se trata de un cambio trascendental, que proporciona al juego una profundidad renovada: ya no se puede hablar de programas contendientes, sino de bandos de programas.  Para vencer ya no bastará con destruir al programa enemigo, sino a todos y cada uno de sus programas.  A primera vista, esta novedad parece aconsejar la subdivisión del programa propio el máximo de veces, pero no por contar con más programas en nuestro bando estaremos en situación ventajosa: cuantos más programas formen nuestro bando, menos frecuentemente serán ejecutados.  De esta forma se conserva el equilibrio en la partida.

     En el artículo de Marzo del 87, Dewdney dió a conocer las modificaciones efectuadas en el Redcode por la Sociedad Internacional de la Guerra Nuclear.  La instrucción DJZ dir1,dir2 era sustituida por la DJN dir1,dir2.  La operación nueva realiza la misma operación de decremento y comparación pero a la hora de saltar, no lo hace si el resultado ha sido 0, sino en el caso contrario.  También la instrucción JMG dir1,dir2 era sustituida por JMN dir1,dir2.  Esta nueva instrucción provoca el salto a dir1 si el contenido de dir2 no es cero.

     Hasta donde he seguido el tema, este es actualmente el formato del Redcode:

Instrucción Argumentos A,B Explicación
DAT inm No ejecutable. El valor inm se almacena en el argumento B
MOV inm,dir Copia el valor inm en la dirección dir
dir1,dir2 Copia el contenido de la dirección dir1 en la dir2
ADD inm,dir Suma el valor inm al contenido de la dirección dir
dir1,dir2 Suma el contenido de la dirección dir1 al de la dir2
SUB inm,dir Resta el valor inm al contenido de la dirección dir
dir1,dir2 Resta el contenido de la dirección dir1 al de la dir2
JMP dir Salta a la dirección dir, almacenada en el argumento B
JMZ dir1,dir2 Salta a dir1 si el contenido de dir2 es cero
JMN dir1,dir2 Salta a dir1 si el contenido de dir2 no es cero
DJN dir1,dir2 Resta 1 al contenido de la dirección dir2. Si el resultado no es cero, salta a la dirección dir1
CMP dir1,dir2 Compara el contenido de las direcciones dir1 y dir2. Si es distinto, la siguiente instrucción será ignorada
SPL dir Subdivisión del programa, añadiéndose al programa o programas en ejecución el situado en la dirección dir

     El Intérprete MARS

     El MARS es el programa que controla el desarrollo de nuestra guerra particular.  Para empezar, se ocupa se situar a ambos contendientes sobre el núcleo.  Esta operación es realizada con sumo cuidado: los dos programas son depositados sobre localizaciones aleatorias, de forma que ninguno de los dos tenga la menor pista sobre el paradero de su rival.  La distancia mínima entre ambos será del mil casillas.  Después, comienza el combate, que MARS controla de manera absolutamente justa e implacable: por turno riguroso, una instrucción de cada bando es ejecutada.  Los programas van desarrollando sus maniobras, sus estrategias... hasta que por fin uno de ellos derrota al adversario.  ¿Cómo se produce esta victoria?  Pues de una forma bien sencilla: el programa que intente ejecutar una instrucción DAT pierde.  La estrategia más primaria y elemental consistirá, por lo tanto, en introducir el máximo de instrucciones DAT en toda la extensión del Núcleo, hasta conseguir que una de ellas quede situada en el cuerpo del programa enemigo.  Así, cuando éste tarde o temprano trate de ejecutarla...  ¡BANG!  Aunque también existe otra posibilidad: que ninguno de los dos programas llegue a perder.  En este caso, tras un límite (que puede ser de tiempo o de número de instrucciones ejecutadas) MARS decretará un empate entre ambos contendientes.

     Modificaciones posteriores

     En el número de Mayo del 85 se recogía una sugerencia de William J. Mitchell, del departamento de matemáticas de la Universidad Estatal de Pennsylvania, consistente en que limitar el alcance de los programas dentro del Núcleo.  Esta propuesta obliga a los programadores a desarrollar programas capaces de desplazarse para poder dar caza al rival... si lo que buscan es la victoria, claro está.

     En 1990 la Sociedad Internacional de la Guerra Nuclear estableció nuevas variaciones en las reglas, de las cuales tuve oportuno conocimiento a través de la Sociedad Española de Redcode.  Estas variaciones eran las siguientes:

  1. Las batallas durarán la ejecución de 125.000 instrucciones.
  2. El tamaño de la memoria donde se efectuará la batalla será de 8 Ks (o sea, 8192 casillas en vez de las 8000 primitivas).  Este cambio tiene por objeto facilitar las operaciones matemáticas al MARS para así ganar velocidad en la ejecución.
  3. El número máximo de instrucciones por guerrero será de 64.
  4. No habrá límite en la división de los guerreros (producida por SPL).

     Y este es el formato de la Guerra Nuclear en la actualidad... hasta donde yo conozco, naturalmente.  Sin embargo, por el interés que se merece, voy a mencionar además una variante del juego que he tenido ocasión de conocer: se trata de la versión de la Guerra Nuclear programada por Jesús Cea Avión, de Vigo.  Esta versión presenta las siguientes modificaciones:

  1. Se adopta la sugerencia de William J. Mitchell y se limita el acceso a la mitad del Núcleo.  Los programas solamente podrán acceder a la gama de direcciones comprendida entre la -2048 y la +2047 (4096 en total).
  2. Se adopta asimismo la sugerencia del propio Dewdney de introducir la instrucción PCT dir, pero con la denominación PRT dir.
  3. Por comodidad del programador, se suprime la instrucción SUB.  Las restas pasarán a realizarse de esta forma: ADD -sustraendo.
  4. Los combates no se deciden a 125.000 instrucciones sino a 131.072 (diferencia poco significativa).  Es más, el usuario puede optar por límites alternativos, a 32768 y 65536 instrucciones.
  5. El máximo de programas permitidos por bando es de 32767.  Si algún bando supera este límite (algo sumamente improbable), se le declarará perdedor.
  6. El número máximo de instrucciones por programa es 255.
  7. El empleo de las instrucciones DJN y ADD sobre casillas que contengan instrucciones que no sean DAT provocará, además de la correspondiente operación aritmética, la transformación de la instrucción en DAT.
  8. La copia de una casilla en otra (MOV dir1,dir2) provoca la copia COMPLETA de la casilla... incluyendo el hecho de si está protegida o no.

     Como vemos, se ponían a prueba prácticamente todos los cambios posibles.  En general, tras probar a fondo esta variante, encuentro que ha sido una aportación muy positiva, por la gran cantidad de diferencias que nos ha proporcionado ocasión de probar.  Ahí van mis impresiones personales sobre el particular:

  1. La restricción de acceso a solamente la mitad del núcleo aporta una maravillosa sofisticación al juego.  Todo programa que se precie de ganador deberá mantener una dinámica combinada de desplazamientos y ataques.
  2. El uso de la instrucción PRT ya no me gusta tanto, pues obliga a realizar los ataques dos veces para asegurar el golpe.  Lo que es indudable es que con ella implementada es preciso usarla si lo que se desea es un programa ganador.  También tiene la importante consecuencia de suprimir el uso de los trasgos tal y como los conocemos.  En efecto, con ella podemos proteger a nuestro programa de los ataques de los trasgos (para saber lo que es un trasgo, ver las anotaciones posteriores) con solamente anteponerle las siguientes dos instrucciones:

    PRT 0 (Esta casilla debe estar además protegida)
    DAT 0
    ... Resto del programa ...

    Si observamos con atención este dique, veremos lo que sucede con cualquier trasgo imprudente que se acerque a él.  Cuando llegue a la casilla inmediatamente anterior, intentará copiarse sobre la instrucción PRT 0; y no lo conseguirá, porque la protección de esta casilla resistirá ese golpe.  En el siguiente turno ejecutará el PRT 0, restituyendo la protección que él mismo acababa de derribar, y un turno más tarde se suicidará en el DAT 0.  Como vemos, el uso de la instrucción PRT significa el fin del uso de los trasgos clásicos.  Aunque, eso sí, el programador dispone de una alternativa a la que no habrá dique que se le resista: utilizar trasgos dobles (dos trasgos que avanzan a la par, ocupando simultáneamente la misma casilla).  Como en el caso de los ataques, esto tiene el inconveniente de consumir el doble del tiempo de ejecución.  En síntesis, encuentro la inclusión de la instrucción PRT perjudicial para el desarrollo del juego.

  3. El hecho de que las instruccions DJN y ADD también puedan producir instrucciones DAT aporta coherencia al juego: la idea de utilizar estas instrucciones para modificar los parámetros de los programas enemigos, en vez de para introducir instrucciones DAT en sus cuerpos, parece en comparación un tanto frívola.

     Y aquí finaliza nuestro recorrido por los formatos que ha adoptado la Guerra Nuclear en su breve pero intensa historia; a continuación veremos algunos programas básicos para que el lector se pueda ir haciendo idea de cómo son los programas de la Guerra Nuclear.

     Un enano artillero

     Vamos a ver el primer ejemplo de programa: el Enano.  Este programa sigue la estrategia que ya anticipé: introducir el máximo de instrucciones DAT en la memoria.  Este es su listado:

MOV #0, @3
ADD #8, 2
JMP -2
DAT #4

     Como vemos, lo primero que hace el programa es introducir el valor 0 en la casilla indexada por el DAT, que va a realizar la función de puntero.  De esta forma se consigue bombardear esa dirección.  A continuación, se incrementa en ocho unidades el puntero, que pasa a apuntar a otra casilla.  Por último, se salta a la primera dirección del programa y se vuelve a empezar.  Con esto, el programa va bombardeando sistemáticamente toda la memoria (una posición de cada ocho), esperando acertar al rival con un impacto.  Llega un momento en que el puntero pasa a valer 8184, lo que, como sabemos, equivale a -4... y el Enano bombardea la dirección inmediatamente anterior a la de su propio código (¡por los pelos!).  Inmediatamente después, el puntero pasa a valer 4 por segunda vez, y el bombardeo vuelve a comenzar desde el principio.

     Algunas posibles variantes de Enano consisten en realizar el bombardeo en orden descendente en vez de ascendente (decrementando el puntero en vez de incrementarlo), o arrojar las bombas a intervalos mayores que ocho casillas; si bien en este caso debemos recordar usar intervalos que sean potencias de dos, pues de lo contrario el Enano correría el riesgo de autodestruirse cuando el bombardeo diera la vuelta al núcleo.

     Como vemos, el Enano es un programa muy combativo y temible, si bien tiene algún defecto, como el hecho de bombardear siempre las mismas direcciones: si el programa rival estuviera situado exactamente entre dos de éstas direcciones, el Enano no conseguiría causarle daño jamás.  Y para terminar con este programa, un pequeño ejercicio de imaginación:  ¿Que sucede si enfrentamos a dos Enanos?  Pues que, salvo que se produzca el caso que acabo de mencionar y ambos sean incapaces de dañar a su contrincante, vencerá el que primero acierte un disparo sobre el cuerpo del rival.

     Un trasgo veloz

     Vamos a ver el ejemplo más sencillo de programa escrito en Redcode: el Trasgo.  Tan sencillo es que consta de una sola instrucción:

MOV 0,1

     ¿Qué es lo que hace el trasgo?  Pues sencillamente copiarse a sí mismo en la casilla siguiente.  De esta forma, en el próximo turno se ejecutará la copia, que a su vez realizará una nueva copia, y así sucesivamente.  El Trasgo va avanzando velozmente por la memoria dejando tras de sí una estela de copias abandonadas.  Se trata de un adversario realmente difícil de batir, puesto que para derrotarle hay que introducir la instrucción DAT justamente en la dirección donde se realizado la última copia.  Como vemos, su pequeñez hace que su caza sea más difícil que la de un mosquito con una escopeta.  Aunque esto tiene su compensación: se trata de un programa que difícilmente vence.  En efecto, no temos más que pensar en lo que sucede cuando enfrentamos a dos trasgos: ambos se dedican a correr interminablemente por la memoria, en una interminable persecución mutua.

     Otra cuestión es si enfrentamos al Enano con el Trasgo.  ¿Qué sucederá?  El Trasgo se pone en movimiento, mientras el Enano inicia su bombardeo.  El Trasgo se desplaza, acercándose cada vez más al Enano.  Este intenta acertarle con un tiro directo.  Dispone de poco tiempo; el Trasgo se acerca rápidadamente.  Si un tiro afortunado golpea al Trasgo, éste será destruido; pero si no, entonces el Trasgo aplastará al Enano pasando por encima de él y machacando su código con copias de sí mismo.  Pero esto no significará el fin del Enano, sino que en algún momento del proceso, al disponerse a ejecutar una de sus instrucciones, encontrará en su lugar el MOV 0,1... y lo ejecutará exactamente igual que si se tratara de una de sus propias instrucciones.  En ese momento el Enano se transformará en un segundo Trasgo.  El combate finalizará en empate, como ocurre siempre que se enfrentan de dos trasgos.

     Sociedades y Campeonatos de Guerra Nuclear

     En Agosto del 85 se formó la Sociedad Internacional de la Guerra Nuclear (Core Wars International Society).  El primer director fué Mark Clarkson, residente en 8619 Wassall Street, Wichita, Kansas, 67210 EEUU.  Clarkson será director de la CWIS durante varios años; al menos hasta Junio del 87, última fecha en que tengo constancia de que continuara siéndolo.  Y ello pese a sufrir un incendio en su casa en Enero del 87.  La falta de referencias posteriores, por ejemplo en el artículo de Dewdney de Mayo del 89, parece sugerir que ya había abandonado el cargo para entonces.

     En otoño del 86 tuvo lugar el primer campeonato en el Computer Museum de Boston, EEUU.  Se presentaron 31 programas, que fueron repartidos en dos grupos de 15 y 16 programas, en cada uno de los cuales se llevó a cabo una liguilla completa.  Los dos mejores clasificados de cada grupo pasaron a la liga final; se trataba de COMANDO, del propio A. K. Dewdney, ENANO y RATONES, de Chip Wendell (de Rochester, Nueva York, EEUU), y CHANG 1, de Morrison J. Chang (de Floral Park, Nueva York).  El mejor clasificado fué RATONES, que venció a COMANDO y ENANO, y empató con CHANG 1.  Este último perdió sus posibilidades al no conseguir vencer a ENANO.

     En el artículo de Junio del 87 Dewdney da cuenta de la primera publicación dedicada a la Guerra Nuclear: The Core Wars Newsletter, editada por William R. Buckley, domiciliado en el 5712 Kern Drive, Huntington Beach, California, 92649 EEUU.  En el artículo de Mayo del 89 Dewdney vuelve a mencionarlo como contacto para los lectores que deseen participar en futuros campeonatos.

     Poco se sabe del campeonato del 87; todo lo que dice Dewdney en sus artículos es que "los programas presentados por los japoneses le dieron a los programas guerreros norteamericanos tela para cortar".

     También del campeonato del 88 es poco lo que se sabe:  El premio, de 250 dólares fué para Eugene P. Lilitko, de Pereslavl-Zalessky, en las cercanías de Moscú (entonces todavía URSS), por su programa COWBOY.

     También he tenido noticias de una Sociedad Española de Redcode, que convocó a finales de 1991 el primer concurso de Guerra Nuclear en España.  Sus datos eran los siguientes:

Sociedad Española de Redcode
Parque del Genil Edf. Turquesa 33 A.  18004 GRANADA.  ESPAÑA.
Teléfonos de contacto: 958-258401 Juan Corpas
958-501476 Fernando Gonzalez
Correo electrónico: EuNet ....... JMERELO@UGR.ES
FidoNet ..... 2:345/801.15

     También sobre las mismas fechas, la Asociación Juvenil para la Informática Viguesa convocó un concurso de Guerra Nuclear: tuvo lugar durante Diciembre del 91 y Enero del 92, y yo mismo participé en él (sin obtener ningún resultado especialmente afortunado).  Sin embargo, es importante mencionar que el concurso se basó en la versión de Guerra Nuclear programada por uno de los propios organizadores, Jesús Cea Avión, con varias modificaciones sobre las normas oficiales.  En cuanto a los datos de la asociación organizadora, son los siguientes:

Asociación Juvenil para la Informática Viguesa
Rúa Caldas de Reis, 12 - 66 I.  36209 VIGO.  ESPAÑA.
Teléfono de contacto: 986-231835 Jesús Cea Avión
Correo electrónico: jcea@dtc.uvigo.es

     Y aquí finaliza este estudio, exhaustivo y diacrónico, sobre el juego de la Guerra Nuclear, sus normas, su evolución, sus campeonatos y sus sociedades.  Espero que haya servido para despertar el gusanillo por este pasatiempo en el lector, o que, si éste ya estaba en antecedentes, le haya facilitado nuevos conocimientos sobre el particular.

Noviembre, 1.994

<p align="center">&lt;<b><a href="index.es.html" title="&Iacute;ndice">VOLVER AL &Iacute;NDICE</a></b>></p> <p align="center" style="color:yellow">[ <a href="../index.html" title="Selecci&oacute;n de lengua" target="_top">Selecci&oacute;n de lengua</a> | <a href="../index.es.html" title="Entrada al Nodo en espa&ntilde;ol de Nacho Agull&oacute;" target="_top">Entrada</a> | <a href="../nov/index.es.html" title="Novedades del Nodo en espa&ntilde;ol de Nacho Agull&oacute;" target="_top">Novedades</a> | <a href="../pudre.html" title="Espa&ntilde;a se pudre" target="_top">Espa&ntilde;a se pudre</a> | <a href="../cine/index.es.html" title="Cr&iacute;ticas de cine de Nacho Agull&oacute;" target="_top">Cr&iacute;ticas de cine</a> | <u>Art&iacute;culos</u> | <a href="../enti/index.es.html" title="Entidades de las que Nacho Agull&oacute; forma parte" target="_top">Entidades</a> | <a href="../curriculum/index.es.html" title="Curriculum vitae de Nacho Agull&oacute;" target="_top"><i>Curriculum vitae</i></a> ]</p>