La Inteligencia Artificial (IA) en Age of Empires II es un conjunto de reglas y comandos encriptados que nos permite definir el comportamiento de un jugador de ordenador en un escenario.

Mediante estos scripts, podemos indicar cuándo y cómo un jugador debe atacar, defenderse, construir edifiicios, entrenar unidades, investigar, recolectar recursos... o incluso estarse quieto.

Para redactar los scripts de IA basta con un editor de texto sencillo, que permita visualizar los números de fila para poder encontrar y corregir posibles errores de forma cómoda y rápida. Una buena opción es el Blog de notas de Windows.




Si queremos regular el comportamiento de un jugador de ordenador en AoE II DE debemos crear dos archivos: uno con extensión ai y otro con extensión per. Es muy importante que ambos archivos tengan exactamente el mismo nombre.

NOTA: tanto en los nombres de los archivos, como en la redacción del script, evita usar caracteres no anglosajones como ¿, ¡, ñ, vocales con tilde, etc.

• El archivo *.per contiene todo el script que regirá el comportamiento del jugador de ordenador, y es el que debemos redactar.
  
• El archivo *.ai solo actúa como localizador del archivo *.per, y debe estar vacío.

Para poder utilizar ambos archivos, debes ubicarlos en el siguiente directorio:

C:\Program Files (x86)\Steam\steamapps\common\AoE2DE\resources\_common\ai

De esta forma, en el menú de Jugadores del editor de escenarios, aparecerá tu script de IA en el desplegable de personalidad.

.
También puedes crear IAs para jugar partidas estándar contra el ordenador.
.
.

En ocasiones, una redacción completa de una IA puede ser larga y laboriosa. Para ahorrar trabajo se suelen elaborar IAs secundarias que pueden ser utilizadas por varias IAs principales.

El juego trae consigo cuatro IAs secundarias:

scenario difficulty.per: regula el comportamiento de las unidades militares del jugador en función del nivel de dificultad de la partida.

scenario market.per: regula la compra y venta de recursos en el mercado por parte del jugador, en función de sus necesidades.

scenario upgrades.per: regula las investigaciones tecnológicas del jugador.

scenario resign.per: regula la rendición del jugador.

Estas IAs secundarias pueden incluirse en la IA principal mediante el comando load:


De esta forma, esta IA cargará las IAs secundarias que escribamos, siempre entre comillas y utilizando paréntesis.

Es importante que los archivos de esas IAs secundarias estén en el mismo directorio que la IA principal.

Las reglas son la base de la IA. Están formadas por condiciones y acciones, que son equivalentes a las condiciones y efectos de los desencadenadores en el editor de escenarios.

Las reglas se definen con el comando defrule, y presentan la siguiente estructura general:


Nótese que cada condición, acción, y la regla entera, van siempre entre paréntesis. Las sangrías y espacios en blanco no tienen ninguna función, y solo se usan para visualizar mejor la estructura de la regla.


Las condiciones de cada regla son testadas de forma continua por el juego, y permanecen vigentes incluso cuando éstas ya se han cumplido, similar al ciclo de desencadenador. Si queremos desactivar una regla cuyas condiciones ya se han cumplido, utilizamos la acción final disable-self:


Podemos añadir comentarios explicativos, sin ningún efecto sobre el comportamiento de la IA, precedidos siempre por el punto y coma ;


Combinando las distintas condiciones y acciones disponibles en la sintaxis propia de juego, se pueden elaborar una gran variedad de reglas que personalizarán en gran medida el comportamiento del jugador de ordenador en nuestro escenario.

Las condiciones son los elementos que se comprueban en una regla para que ésta desencadene o no sus acciones.

Las condiciones pueden hacer referencia tanto a un jugador concreto: su reserva de recursos, su puntuación... como al escenario en general: tipo de partida, tiempo transcurrido...

Las acciones son operaciones que el jugador de ordenador realiza como si fuera un jugador humano. Por ejemplo, la siguiente regla hace que el jugador entrene un aldeano si tiene más de 50 de alimento:


Más adelante veremos una lista de condiciones y acciones predefinidas como las que aparecen en el ejemplo. Puedes consultarlas en este enlace[airef.github.io].

Algunas condiciones cuentan con un operador comparativo (mayor que, menor que, igual a...) y una cantidad. También existen condiciones que no requieren compararse a ninguna cantidad, como en el siguiente ejemplo en el que la regla se ejecutará si el jugador 3 pertenece a la civilización vikinga:


Una regla puede tener una, varias, o incluso ninguna condición predefinida, es decir, que se cumple al instante, en ese caso, utilizamos la condición true:


Aquí es importante añadir la acción final disable-self, de lo contrario, la frase "estamos jugando" sería chateada de forma continua.

También puede darse el caso de que una regla contenga más de una condición y/o más de una acción:


Recuerda que cada condición, acción, y la regla entera deben ir entre paréntesis.

En las condiciones, podemos utilizar el operador or para dar opción a que la regla se desencadene:


El jugador se rendirá, bien cuando tenga menos de 100 de alimento, bien cuando tenga menos de 100 de oro. Este operador solo admite dos reglas opcionales, pero podemos añadir aún más condiciones mediante esta sintaxis:


Existe además la posibilidad de crear condiciones inversas con el operador not:


Esta regla se activará si el jugador NO está en la Edad Feudal.

Las distintas reglas de una IA pueden ejecutarse o no en función de una serie de requisitos predefinidos. Para ello se utilizan estas sintaxis:

#load-if-defined / #load-if-not-defined
#else
#end-if

que significan "ejecutar o no ejecutar si...", "de lo contrario...", y "fin. El siguiente ejemplo manda un chat distinto en función del nivel de dificultad de la partida:

Cada ítem de AoE II DE, entiéndase edificio, unidad, tecnología... está caracterizada por una constante numérica predefinida, cuyo valor se puede ver en este enlace[airef.github.io] en la columna unit ID.

Pero con el comando defconst podemos crear nuestras constantes personalizadas y darles el valor que queramos.

En el siguiente ejemplo definimos una constante llamada aldeanos-edad-media. No uses espacios en los nombres de tus constantes, reemplázalos por guiones.


De esta forma, el jugador creará aldeanos hasta tener 15, pero solo en la Edad Media. Para la Edad Feudal podemos definir otra constante diferente y darle otro valor:




Una combinación de reglas condicionadas y constantes personalizadas puede ser muy útil. Uno de los usos más comunes es el escalado de parámetros, ejemplo:


en partidas de combate a muerte, el número de aldeanos en la Edad Media será de 10, en los otros tipos de partidas será de 20.

Nótese que una misma constante personalizada no puede tener más de un valor para un determinado condicionante.

Los números estratégicos (sn) permiten establecer cantidades y porcentajes a ciertos aspectos del juego.

Para establecer un sn se utiliza la acción predefinida set-strategic-number. Algunos sn son porcentuales, otros meramente numéricos, y otros binarios de tipo SI (valor 1) o NO (valor 0)

Puedes consultar la lista completa de sn en este enlace[airef.github.io]. En esta guía citaremos los más útiles y habituales.




• sn-percent-civilian-explorers: % exploradores civiles.
• sn-percent-civilian-gatherers: % recolectores.
• sn-percent-civilian-builders: % constructores / reparadores.
La suma de estos tres sn debe ser 100.

• sn-food-gatherer-percentage: % de recolectores de alimento.
• sn-gold-gatherer-percentage: % de recolectores de oro.
• sn-stone-gatherer-percentage: % de recolectores de piedra.
• sn-wood-gatherer-percentage: % de recolectores de madera.
La suma de estos cuatro sn debe ser 100.

• sn-minimum-boar-hunt-group-size: nº mínimo de aldeanos que cazan un animal salvaje.
• sn-number-forward-builders: nº de aldeanos que embarcan en un transporte, desembarcan y construyen en otra isla.




• sn-minimum-town-size: radio mínimo de la ciudad.
• sn-maximum-town-size: radio máximo de la ciudad.
• sn-camp-max-distance: distancia máxima a la que se puede construir un campamento minero y/o maderero respecto al centro urbano inicial.
• sn-mill-max-distance: distancia máxima a la que se puede construir un molino respecto al centro urbano inicial.

• sn-food-dropsite-distance: distancia máxima que el aldeano puede recorrer para recolectar
alimento. >= 3.
• sn-wood-dropsite-distance: íd. para la madera.
• sn-stone-dropsite-distance: íd. para la piedra.
• sn-gold-dropsite-distance: íd. para el oro.

• sn-maximum-wood-drop-distance
• sn-maximum-food-drop-distance
• sn-maximum-hunt-drop-distance
• sn-maximum-fish-boat-drop-distance
• sn-maximum-gold-drop-distance
• sn-maximum-stone-drop-distance
Establecen la distancia máxima que un aldeano debe recorrer desde el recurso hasta su edificio de recolección. Se evita así que los aldeanos recorran largas distancias para extraer recursos de fuentes lejanas.




• sn-blot-exploration-map: controla si el jugador debe o no explorar zonas ya exploradas. 0 ó 1.

• sn-number-explore-groups: nº de grupos de exploración.
• sn-maximum-explore-group-size: tamaño máximo del grupo de exploración.
• sn-minimum-explore-group-size: tamaño mínimo del grupo de exploración

• sn-number-boat-explore-groups
• sn-maximum-boat-explore-group-size
• sn-minimum-boat-explore-group-size
idénticos para la exploración por mar.



• sn-task-ungrouped-soldiers: establece si los soldados deben o no defender la ciudad si ésta es atacada. 0 ó 1.
• sn-percent-enemy-sighted-response: % de unidades defensivas que responderán ante un ataque enemigo.
• sn-enemy-sighted-response-distance: radio de respuesta por parte de los soldados ante un ataque.

• sn-number-defend-groups: nº de grupos de defensa.
• sn-maximum-defend-group-size: tamaño máximo del grupo de defensa.
• sn-minimum-defend-group-size: tamaño mínimo del grupo de defensa.

• sn-number-boat-defend-groups
• sn-maximum-boat-defend-group-size
• sn-minimum-boat-defend-group-size
idénticos para la defensa por mar.

• sn-gold-defend-priority: prioridad de defender el oro. 0 indica que el oro no será defendido. 1 es la prioridad máxima y 7 la prioridad mínima.
• sn-stone-defend-priority: íd. para la piedra.
• sn-forage-defend-priority: íd para el alimento.
• sn-relic-defend-priority: íd. para defender reliquias.
• sn-town-defend-priority: íd para defender la ciudad.
• sn-dock-defend-priority: íd para defender los muelles.

• sn-defense-distance: distancia a la que los ítems (excluida la ciudad) serán defendidos.
• sn-sentry-distance: distancia a la que la ciudad será defendida.



• sn-number-attack-groups: nº de grupos de ataque.
• sn-maximum-attack-group-size: nº máximo de unidades que debe formar un grupo de ataque.
• sn-minimum-attack-group-size: nº mínimo de unidades que debe formar un grupo de ataque.

• sn-number-boat-attack-groups
• sn-maximum-boat-attack-group-size
• sn-minimum-boat-attack-group-size
idénticos para ataques por mar.

• sn-percent-attack-soldiers: % de soldados que irán al ataque en la próxima ofensiva.
• sn-percent-attack-boats: % de barcos que pasarán al ataque.

• sn-attack-intelligence: especifica si se realizan o no ataques inteligentes, es decir, atacar sin ignorar unidades enemigas, retirarse en batallas imposibles de ganar, atacar por diferentes flancos... 0 ó 1.

• sn-target-player-number: establece el nº del jugador a quién irán dirigidos los ataques.

• sn-wall-targeting-mode: indica si el jugador atacará o no muros enemigos. 0 ó 1.



• sn-relic-return-distance: distancia máxima entre el centro urbano y una reliquia para que ésta sea recogida por un monje.

• sn-minimum-amount-for-trading: cantidad mínima de recurso que el jugador puede disponer
para venderla en el mercado.

• sn-hits-before-alliance-change: número de ataques que el jugador permitirá a un aliado antes de cambiar su diplomacia a enemigo.

• sn-attack-winning-player: controla si el jugador ataca o no al jugador de mayor puntuación. 0 ó 1.

• sn-coop-share-attacking: controla si el jugador puede atacar a un enemigo que está atacando a su aliado. 0 ó 1.

Las condiciones son los hechos que se evalúan en una regla, y en caso de cumplirse, desencadenan las acciones.

Las condiciones constan de varias partes, separadas ellas por espacios en blanco. Primeramente la sintaxis de la condición, que veremos en esta sección. Una serie de parámetros (edificio, unidades, tecnologías etc) que se listan en las secciones posteriores. Números y un operador relativo [op-rel] que sirve para comparar el número con el parámetro.

El operador relativo adquiere las siguientes sintaxis:


A continuación, una lista de las sintaxis más útiles y habituales para elaborar condiciones. Puedes consultar el listado completo en este enlace[airef.github.io].

(true) la regla se cumple siempre.

(building-type-count-total edificio op-rel nº) nº de un determinado edificio que tiene el jugador, como cuarteles, centros urbanos, castillos...

(players-building-count-total jugador edificio op-rel nº) evalúa el nº de un determinado edificio VISIBLE que tiene un determinado jugador, como cuarteles, centros urbanos, castillos...

(cc-players-building-count-total jugador edificio op-rel nº) evalúa el nº de un determinado edificio VISIBLES E INVISIBLES que tiene un determinado jugador, como cuarteles, centros urbanos, castillos...

(unit-type-count-total unidad op-rel nº) nº de una determinada unidad que tiene el jugador, como arqueros, unidades únicas, brulotes...

(players-unit-count-total jugador unidad op-rel nº) evalúa el nº de una determinada unidad VISIBLE que tiene un determinado jugador, como milicias, galeones, aldeanos...

(cc-players-unit-count-total jugador unidad op-rel nº) evalúa el nº de una determinada unidad VISIBLES E INVISIBLES que tiene un determinado jugador, como milicias, galeones, aldeanos...

(can-build edificio) evalúa si el jugador dispone de recursos o desarrollo tecnológico suficiente para construir un edificio.

(can-build-with.escrow edificio) igual que el anterior, evalúa además si el jugador tiene recursos de sobra para construir el edificio.

(can-train unidad) evalúa si el jugador dispone de recursos o desarrollo tecnológico suficiente para entrenar una unidad.

(can-research tecnología) evalúa si el jugador dispone de recursos o desarrollo tecnológico suficiente para investigar una tecnología.

(can-research-with.escrow tecnología) igual que el anterior, evalúa además si el jugador tiene recursos de sobra para investigar la tecnología.

(can-spy) evalúa si el jugador puede espiar o cometer traición.

(game-time op-rel nº) evalúa el tiempo transcurrido en segundos del inicio de partida.

(resource-found recurso) evalúa si el jugador ha encontrado un recurso determinado: oro, madera...

(housing-headroom op-rel nº) espacio poblacional del que dispone el jugador con las casas, castillos y centros urbanos disponibles.

(population-headroom op-rel nº) espacio poblacional del que dispone el jugador teniendo en cuenta su límite poblacional dado por el escenario.

(town-under-attack) evalúa si la ciudad está bajo ataque.

(defend-soldier-count op-rel nº) cantidad de unidades terrestres de defensa, una unidad militar recién creada se supone que está ya defendiendo.

(defend-warboat-count op-rel nº) igual que la anterior, para barcos de guerra.

(civilian-population op-rel nº) comprueba la población civil del jugador.

(military-population op-rel nº) comprueba la población militar del jugador.

(timer-triggered temporizador) evalúa si un cierto temporizador ha expirado.

(event-detected-trigger AI-señal) evalúa si se ha enviado una señal de IA mediante desencadenador del editor de escenarios.

(cheats-enabled) evalúa si las los códigos de trampas están permitidos en la partida.

(current-age op-rel edad) evalúa en qué edad tecnológica se encuentra el jugador.

(current-score op-rel nº) evalúa la puntuación del jugador.

(food-amount op-rel nº) cantidad de comida que tiene el jugador.
(wood-amount op-rel nº) cantidad de madera que tiene el jugador.
(gold-amount op-rel nº) cantidad de oro que tiene el jugador.
(stone-amount op-rel nº) cantidad de piedra que tiene el jugador.

(goal meta nº) evalúa si el estado en que se encuentra el jugador tiene un valor concreto.

(players-stance jugador diplomacia) evalúa la relación diplomática del jugador con otro jugador concreto.

Las acciones se cumplen si se cumplen las condiciones de una regla.

A continuación, una lista de las sintaxis más útiles y habituales para elaborar acciones. Puedes consultar el listado completo de acciones en este enlace[airef.github.io].

(disable-self) hace que la regla solo se evalúe una vez, si se omite esta acción, la regla se evaluará continuamente.

(set-strategic-number sn nº) da un valor numérico a un determinado número estratégico.

(attack-now) otrdena un ataque.

(build edificio) construye un determinado edificio.

(build-with-escrow edificio) construye un determinado edificio con recursos de sobra.

(build-forward edificio) construye un determinado edificio alejado de la ciudad, cerca del enemigo.

(research tecnología) investiga una cierta tecnología.

(research-with-escrow tecnología) investiga una cierta tecnología con recursos de sobra.

(train unidad) entrena una determinada unidad.

(enable-timer temporizador nº) activa un determinado temporizador y define su duración en segundos.

(disable-timer temporizador) desactiva un determinado temporizador.

(cc-add-resource recurso nº) añade una cantidad de cierto recurso gratis al jugador.

(delete-building edificio) destruye un determinado edificio propio.

(delete-unit unidad) mata una determinada unidad propia.

(resign) el jugador se rinde.

)set-goal estado nº) define un estado y le da un valor numérico.

(set-signal IA-señal) envía una señal numérica al escenario para que se accione algún desencadenador.

(set-stance jugador diplomacia) establece un estado diplomático con un jugador.

(spy) el jugador espía o comete traición.

(tribute-to-player jugador recurso nº) tributa una cantidad de recurso a un jugador.

Edad Media


Edad Feudal


Edad de los Castillos


Edad Imperial


Existen además los parámetros de línea stone-wall-line y watch-tower-line para las torres vigia, guardia y homenaje.

villager
trade-cart




Muchos de estos parámetros son de línea. Por ejemplo, en militiaman-line, se hace referencia a milicias, hombres de armas, espadachines y/o campeones, en función del grado de desarrollo tecnológico del jugador.

Casi todos los parámetros de tecnologías van precedidos por el prefijo ri-, para distinguir entre la tecnología y la unidad, y así evitar confusión.

Encontrarás estos parámetros en este enlace[airef.github.io].

En las condiciones y acciones que hemos visto antes, además de los parámetros de edificios, unidades y tecnologías, existen otros parámetros:



food wood gold stone



Los parámetros de jugador pueden ser 1, 2, 3, 4, 5, 6, 7 y 8, de acuerdo al número asignado a cada jugador en el editor de escenarios. Existen también los parámetros comodín:

any-ally any-neutral any-enemy



Los temporizadores se asignan mediante números 1, 2, 3, 4, 5... un archivo de IA admite hasta 10 temporizadores.



El editor de escenarios permite enviar hasta 255 señales de IA al archivo de IA, y se enumeran con números: 1, 2, 3, 4, 5...



dark-age feudal-age castle-age imperial-age post-imperial-age

La Edad post-Imperial es idéntica a la Imperial, salvo que todas las tecnologías están ya desarrolladas, excepto el espionaje/traición.



Los estados se asignan con números 1, 2, 3, 4... hasta un máximo de 40.



ally enemy neutral