Core War es un juego de programación de 1984creado por DG Jones y AK Dewdney en el que dos o más programas de batalla (llamados "guerreros") compiten por el control de una computadora virtual . Estos programas de batalla están escritos en un lenguaje ensamblador abstractollamado Redcode .
Guerra del Núcleo | |
---|---|
Desarrollador (es) | DG Jones y AK Dewdney |
Lanzamiento | Marzo de 1984 |
Género (s) | Juego de programación |
Como se Juega
Al comienzo de un juego, cada programa de batalla se carga en la memoria en una ubicación aleatoria, después de lo cual cada programa ejecuta una instrucción por turno. El objetivo del juego es hacer que los procesos de los programas opuestos terminen (lo que sucede si ejecutan una instrucción no válida), dejando el programa victorioso en posesión exclusiva de la máquina.
La primera versión publicada de Redcode definía solo ocho instrucciones. El estándar ICWS-86 aumentó el número a 10 mientras que el estándar ICWS-88 lo aumentó a 11. El borrador de estándar de 1994 actualmente utilizado tiene 16 instrucciones. Sin embargo, Redcode admite varios modos de direccionamiento diferentes y (a partir del borrador del estándar de 1994) modificadores de instrucción que aumentan el número real de operaciones posibles a 7168. El estándar Redcode deja la representación de la instrucción subyacente indefinida y no proporciona ningún medio para que los programas accedan a ella. . Las operaciones aritméticas se pueden realizar en los dos campos de dirección contenidos en cada instrucción, pero las únicas operaciones admitidas en los códigos de instrucción mismos son copiar y comparar por igualdad.
- Duración y tiempo de instrucción constante
- Cada instrucción de código rojo ocupa exactamente una ranura de memoria y tarda exactamente un ciclo en ejecutarse. Sin embargo, la velocidad a la que un proceso ejecuta instrucciones depende del número de otros procesos en la cola, ya que el tiempo de procesamiento se comparte por igual.
- Memoria circular
- La memoria se direcciona en unidades de una instrucción. El espacio de memoria (o núcleo ) es de tamaño finito, pero solo se usa el direccionamiento relativo , es decir, la dirección 0 siempre se refiere a la instrucción que se está ejecutando actualmente, la dirección 1 a la instrucción posterior, y así sucesivamente. El valor máximo de la dirección se establece en uno menos que el número de ubicaciones de memoria y se ajustará si es necesario. Como resultado, existe una correspondencia uno a uno entre direcciones y ubicaciones de memoria, pero es imposible que un programa Redcode determine una dirección absoluta. Un proceso que no encuentra instrucciones inválidas o de salto continuará ejecutando instrucciones sucesivas sin cesar, y eventualmente regresará a la instrucción donde comenzó.
- Multiprocesamiento de bajo nivel
- En lugar de un solo puntero de instrucción, un simulador de Redcode tiene una cola de proceso para cada programa que contiene un número variable de punteros de instrucción que recorre el simulador. Cada programa comienza con un solo proceso, pero se pueden agregar nuevos procesos a la cola usando la
SPL
instrucción. Un proceso muere cuando ejecuta una instrucción DAT o realiza una división por cero. Un programa se considera muerto cuando no le quedan más procesos.
- Sin acceso externo
- Redcode y la arquitectura MARS no proporcionan funciones de entrada o salida. El simulador es un sistema cerrado, en el que la única entrada son los valores iniciales de la memoria y las colas de procesos, y la única salida es el resultado de la batalla, es decir, qué programas tenían procesos supervivientes. Por supuesto, el simulador aún puede permitir la inspección externa y la modificación de la memoria mientras se ejecuta la simulación.
Versiones de Redcode
Existen varias versiones de Redcode. La primera versión descrita por AK Dewdney [1] difiere en muchos aspectos de los estándares posteriores establecidos por la International Core War Society, y podría considerarse un lenguaje diferente, aunque relacionado. La forma de Redcode más comúnmente utilizada en la actualidad se basa en un borrador de estándar presentado al ICWS en 1994 que nunca fue aceptado formalmente, ya que el ICWS se había extinguido efectivamente en esa época. El desarrollo de Redcode, sin embargo, ha continuado de manera informal, principalmente a través de foros en línea como el grupo de noticias rec.games.corewar
[2] .
Estrategia
Los guerreros se dividen comúnmente en varias categorías amplias, aunque los guerreros reales a menudo pueden combinar el comportamiento de dos o más de ellos. Tres de las estrategias habituales ( replicador , escáner y bombardero ) también se conocen como papel, tijeras y piedra , ya que su actuación entre sí se aproxima a la de sus homónimos en el conocido juego infantil. [3]
- Papel (o replicador)
- Un replicador hace copias repetidas de sí mismo y las ejecuta en paralelo, eventualmente llenando todo el núcleo con copias de su código. Los replicantes son difíciles de matar, pero a menudo tienen dificultades para matar a sus oponentes. Por lo tanto, los replicadores tienden a anotar muchos empates, particularmente contra otros replicadores.
- Una seda es un tipo especial de replicador muy rápido, llamado así por el Guerrero de la Seda [4] por Juha Pohjalainen. La mayoría de los replicadores modernos son de este tipo. Los replicadores de Silk utilizan la ejecución en paralelo para copiar todo su código con una instrucción y comienzan la ejecución de la copia antes de que finalice. [5]
- Tijeras (o escáner)
- Un escáner está diseñado para vencer a los replicadores. Un escáner no ataca a ciegas, sino que intenta localizar a su enemigo antes de lanzar un ataque dirigido. Esto lo hace más efectivo contra oponentes difíciles de matar como los replicadores, pero también lo deja vulnerable a los señuelos. Un escáner usualmente bombardea la memoria con Instrucciones SPL 0 . Esto hace que el enemigo cree una gran cantidad de procesos que no hacen más que crear más procesos, lo que ralentiza los procesos útiles. Cuando el enemigo se vuelve tan lento que no puede hacer nada útil, la memoria se bombardea con Instrucciones DAT . Los escáneres también son generalmente más complejos y, por lo tanto, más grandes y frágiles que otros tipos de guerreros. [6]
- Un one-shot es un escáner muy simple que solo escanea el núcleo hasta que encuentra el primer objetivo, y luego cambia permanentemente a una estrategia de ataque, generalmente un núcleo limpio. Myrmidon [7] de Roy van Rijn es un ejemplo de un one-shot.
- Piedra (o bombardero)
- Un bombardero copia a ciegas una "bomba" a intervalos regulares en el núcleo, con la esperanza de golpear al enemigo. La bomba es a menudo un La instrucción DAT , aunque se pueden utilizar otras instrucciones, o incluso bombas de instrucciones múltiples. Un bombardero puede ser pequeño y rápido, y obtienen una ventaja adicional sobre el escaneo de oponentes, ya que las bombas también sirven como distracciones convenientes. Los bombarderos a menudo se combinan con espirales de diablillos para ganar resistencia adicional contra los replicadores.
- Vampiro (o trampero)
- Un vampiro intenta hacer que los procesos de su oponente salten a un fragmento de su propio código llamado "pozo". Los vampiros pueden basarse en bombarderos o escáneres. Una de las principales debilidades de los vampiros es que pueden ser fácilmente atacados indirectamente, ya que por necesidad deben esparcir punteros a su código por todo el núcleo. Sus ataques también son lentos, ya que se necesita una ronda adicional para que los procesos lleguen al pozo. myVamp [8] de Paulsson es un ejemplo de vampiro.
- Diablillo
- Los diablillos llevan el nombre del primer guerrero publicado, Imp [9] por AK Dewdney , un guerrero móvil trivial de una sola instrucción que copia continuamente su única instrucción justo antes de su puntero de instrucción . Los diablillos son difíciles de matar pero casi inútiles para la ofensiva. Su uso radica en el hecho de que pueden engendrarse fácilmente en grandes cantidades y pueden sobrevivir incluso si el resto del guerrero muere.
- Un anillo de diablillos (o espiral de diablillos ) consiste en diablillos espaciados a intervalos iguales alrededor del núcleo y que se ejecutan alternativamente. Los diablillos en cada brazo del anillo / espiral copian su instrucción al siguiente brazo, donde se ejecuta de nuevo inmediatamente. Los anillos y las espirales son incluso más difíciles de matar que los simples diablillos, e incluso tienen una (pequeña) posibilidad de matar a guerreros que no estén protegidos contra ellos. El número de brazos en un anillo o espiral de diablillos debe ser relativamente primordial con el tamaño del núcleo.
- Quickscanner (o q-scan)
- Un escáner rápido intenta atrapar a su oponente temprano usando un ciclo de escaneo desenrollado muy rápido. Quickscanning es una estrategia inicial del juego y siempre requiere alguna otra estrategia como respaldo. Agregar un componente de escaneo rápido a un guerrero puede mejorar su puntuación contra guerreros largos como otros escáneres rápidos. Sin embargo, el escaneo desenrollado solo puede apuntar a un número limitado de ubicaciones y es poco probable que atrape a un oponente pequeño.
- Núcleo claro
- Un núcleo claro sobrescribe secuencialmente cada instrucción en el núcleo, a veces incluso incluyéndose a sí mismo. Los despejes del núcleo no son muy comunes como guerreros independientes, pero a menudo los bombarderos y escáneres los utilizan como estrategia de final de juego.
Programación básica de guerra
Con una comprensión de las estrategias de Core War , un programador puede crear un guerrero para lograr ciertos objetivos. Las ideas revolucionarias surgen de vez en cuando; la mayoría de las veces, sin embargo, los programadores basan sus programas en guerreros ya publicados. Usando optimizadores como OptiMax o herramientas de optimización de pasos centrales, se puede crear un guerrero más efectivo.
Los guerreros también se pueden generar mediante algoritmos genéticos o programación genética . Los programas que integran esta técnica evolutiva se conocen como evolutivos . La comunidad de Core War introdujo varios evolucionadores y tienden a centrarse en generar guerreros para entornos centrales más pequeños. El último evolucionador con un éxito significativo fue μGP [10], que produjo algunos de los nano y diminutos guerreros más exitosos. Sin embargo, la estrategia evolutiva aún debe demostrar su eficacia en entornos centrales más grandes. [11]
Desarrollo
Core War se inspiró en un programa de autorreplicación llamado Creeper y un programa posterior llamado Reaper que destruyó copias de Creeper. [12] Creeper fue creado por Bob Thomas en BBN . [13] Dewdney no estaba al tanto del origen de Creeper y Reaper y se refiere a ellos como un rumor que se originó en Darwin y los experimentos con gusanos de Shoch y Hupp. El artículo de 1984 de Scientific American sobre Core War [12], sin embargo, cita el juego Darwin , interpretado por Victor A. Vyssotsky , Robert Morris y Douglas McIlroy en Bell Labs en 1961. La palabra "Core" en el nombre proviene de una memoria de núcleo magnético. , una tecnología de memoria de acceso aleatorio obsoleta .
La primera descripción del lenguaje Redcode se publicó en marzo de 1984, en Core War Guidelines por DG Jones y AK Dewdney . [1] El juego se presentó al público en mayo de 1984, en un artículo escrito por Dewdney en Scientific American . Dewdney volvió a visitar Core War en su columna "Computer Recreations" en marzo de 1985, [14] y nuevamente en enero de 1987. [15]
La International Core Wars Society (ICWS) se fundó en 1985, un año después del artículo original de Dewdney. El ICWS publicó nuevos estándares para el lenguaje Redcode en 1986 y 1988, y propuso una actualización en 1994 que nunca se estableció formalmente como el nuevo estándar. [16] No obstante, el borrador de 1994 fue comúnmente adoptado y ampliado, y constituye la base del estándar de facto para Redcode en la actualidad. El ICWS fue dirigido por Mark Clarkson (1985-1987), William R. Buckley (1987-1992) y Jon Newman (1992-); actualmente el ICWS está extinto. [17]
Código Rojo
0000 : AÑADIR . AB # 4 , $ 3 0001 : MOV . F $ 2 , @ 2 0002 : JMP . B $ - 2 , $ 0 0003 : DAT . F # 0 , # 0
Redcode es el lenguaje de programación utilizado en Core War . Es ejecutado por una máquina virtual conocida como Memory Array Redcode Simulator , o MARS . El diseño de Redcode se basa libremente en los lenguajes ensambladores CISC reales de principios de la década de 1980, pero contiene varias características [ vagas ] que normalmente no se encuentran en los sistemas informáticos reales.
Tanto Redcode como el entorno MARS están diseñados para proporcionar una plataforma simple y abstracta sin la complejidad de las computadoras y procesadores reales. Aunque Redcode está destinado a parecerse a un lenguaje ensamblador CISC ordinario, difiere en muchos aspectos [ ¿cuál? ] del montaje "real".
Implementaciones
El desarrollo de implementaciones del juego continuó a lo largo de los años por varios autores. Hay varias versiones del juego disponibles, [18] portadas para varias plataformas. Por ejemplo pMARS que es el software de código abierto con el código fuente en Sourceforge , [19] o los SDL basado pMARS SDL para Windows. [20] Recientemente se ha creado un simulador completamente basado en web https://www.corewar.io/ eliminando la necesidad de descargar cualquier herramienta específica de la plataforma.
La implementación común pMars se descargó más de 35.000 veces entre 2000 y 2021 desde Sourceforge . [21]
Referencias
- ^ a b Jones, DG; Dewdney, AK (marzo de 1984). "Directrices fundamentales de la guerra" . Consultado el 11 de marzo de 2013 .
- ^ "rec.games.corewar en Grupos de Google" . Consultado el 11 de marzo de 2013 .
- ^ Wangsaw, Mintardjo. "Introducción al arte en el '88: Trilogía Papel - Piedra - Tijeras" . Consultado el 11 de marzo de 2013 .
- ^ Pohjalainen, Jippo. "Silk Warrior 1.3" . Consultado el 11 de marzo de 2013 .
- ^ Pohjalainen, Jippo (abril de 1995). "¿Replicadores? - Fuente Phoenix y TimeScape" . Consultado el 11 de marzo de 2013 .
- ^ Metcalf, John (abril de 2004). "Anatomía del escáner, una introducción básica" . Consultado el 11 de marzo de 2013 .
- ^ van Rijn, Roy. "Mirmidón" . Consultado el 11 de marzo de 2013 .
- ^ Paulsson, Magnus. "myVamp v3.7" . Consultado el 11 de marzo de 2013 .
- ^ Dewdney, AK "Diablillo" . Consultado el 11 de marzo de 2013 .
- ^ Squillero, Giovanni. "μGP (MicroGP v2)" . Consultado el 10 de septiembre de 2018 .
- ^ Vowk, Barkley; Espera, Alejandro; Schmidt, Christian. "Un enfoque evolutivo genera programas de Corewar competitivos humanos" (PDF) . Consultado el 11 de marzo de 2013 .
- ^ a b Dewdney, AK (mayo de 1984). "En el juego llamado Core War, los programas hostiles se involucran en una batalla de bits" . Scientific American . Consultado el 5 de octubre de 2017 .
- ^ Shoch, J .; Hupp, J. (marzo de 1982). "Los programas 'Gusano' - Experiencia inicial con una computación distribuida". Comunicaciones de la ACM . 25 (3): 172–180. doi : 10.1145 / 358453.358455 . S2CID 1639205 .
- ^ Dewdney, A. K. (marzo de 1985). "Un bestiario de Core War de virus, gusanos y otras amenazas a la memoria de la computadora" . Scientific American . Consultado el 5 de octubre de 2017 .
- ^ Dewdney, A. K. (enero de 1987). "Un programa llamado MICE mordisquea su camino hacia la victoria en el primer torneo Core War" . Scientific American . Consultado el 5 de octubre de 2017 .
- ^ Doligez, Damien; Durham, Mark (8 de noviembre de 1995). "Borrador anotado de la propuesta de estándar básico de guerra de 1994" . Consultado el 11 de marzo de 2013 .
- ^ Metcalf, John. "Una breve historia de Corewar" . Consultado el 11 de marzo de 2013 .
- ^ Los emuladores de Corewar en corewar.info
- ^ corewar en sourceforge
- ^ pMARS-SDL en corewar.co.uk por Joonas Pihlaja (7 de mayo de 2003)
- ^ descargar números de corewar en sourceforge (acceso 2021-06-07)
enlaces externos
- Core War - la guerra de los programadores
- La página de información de Core War
- La guía para principiantes de Redcode
- Borrador comentado del Estándar Básico de Guerra propuesto para 1994
- La bibliografía básica de la guerra
- Simulador de Corewar.io totalmente basado en web