0% encontró este documento útil (0 votos)

104 vistas160 páginas

Juegos de Estrategia y Programación Evolutiva

Este documento describe un proyecto para implementar juegos de estrategia usando programación evolutiva. Explica conceptos clave como inteligencia artificial, programación evolutiva y juegos de estrategia, y detalla el diseño e implementación de un juego de este tipo incluyendo aspectos como la interfaz gráfica, los agentes y los estimadores usados.

Cargado por

piopio1234

Derechos de autor

Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.

Formatos disponibles

Descarga como PDF, TXT o lee en línea desde Scribd

0% encontró este documento útil (0 votos)

104 vistas160 páginas

Juegos de Estrategia y Programación Evolutiva

Cargado por

piopio1234

Derechos de autor

Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.

Formatos disponibles

Descarga como PDF, TXT o lee en línea desde Scribd

Sistemas Informticos

Curso 2004 - 2005

Implementacin
De Juegos de Estrategia
Con Programacin
Evolutiva

Palabras clave
Se usarn con motivos de futuras bsquedas bibliogrficas

1. Juegos de estrategia
2. Programacin Evolutiva
3. Aprendizaje adaptativo
4. Inteligencia Artificial
5. Algoritmos genticos
6. Algoritmos evolutivos
7. Evolucin

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Resumen inicial
Castellano
El objetivo de este trabajo es implementar juegos de contrincante, que tengan la
suficiente complejidad para que la seleccin de la jugada a realizar no pueda abordarse
mediante una bsqueda exhaustiva.
Entre estos juegos estn los de estrategia del tipo ``civilizacin'', en los que cada jugador
hace el papel de regente de una civilizacin empezando con unos pocos pobladores y
trata de construir un imperio compitiendo con otras civilizaciones. El objetivo del juego
es dirigir esta civilizacin desde su inicio hasta conquistar el sistema.
Los algoritmos evolutivos constituyen un mtodo de bsqueda alternativo para abordar
problemas complejos de bsqueda a travs de modelos computacionales de procesos
evolutivos. El propsito genrico de estos algoritmos consiste en guiar una bsqueda
estocstica haciendo evolucionar un conjunto de estructuras y seleccionando de modo
iterativo las ms adecuadas. La principal aportacin de la Computacin Evolutiva a la
metodologa de resolucin de problemas consiste en el uso de mecanismos de seleccin
de soluciones potenciales y de construccin de nuevos candidatos por recombinacin de
caractersticas de otros ya presentes, de modo parecido a como ocurre en la evolucin
de los organismos naturales.
En este trabajo utilizaremos este tipo de algoritmos para la seleccin de las jugadas de la
mquina, definiendo previamente una serie de parmetros a optimizar en el juego de que
se trate.
Por otra parte, los juegos de estrategia constituyen un excelente banco de pruebas para
el estudio de procesos al nivel colectivo. El objetivo es determinar los mecanismos de
interaccin entre los individuos de una colectividad que hacen emerger
comportamientos adaptativos o inteligentes al nivel de toda la colectividad de
organismos. La simulacin de hormigueros es un ejemplo, y sugiere mltiples
aplicaciones a la Informtica, como la computacin distribuida. Otro campo
relacionado es la evolucin filogentica, que investiga las leyes que rigen la evolucin
de las poblaciones, los mecanismos de transmisin gentica, seleccin natural y
adaptacin de las especies.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En el trabajo tambin aplicaremos estas ideas, permitiendo que la mquina realice su

propia evolucin, lo que dar lugar a estrategias a comparar con las obtenidas con
mtodos de bsqueda sobre un conjunto de criterios predefinidos.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

2. Introduccin y
Estudio
Preliminar.
2.1
Introduccin
Relacionadas

reas

2.1.1 Introduccin a la IA
La inteligencia artificial (IA abreviado) es la ciencia que se encarga de estudiar las
maneras para simular o hacer que un ordenador piense en la medida que lo hace un
ser humano. Se dedica al estudio de los campos que todava poseen problemas no
resueltos. Cuando se resuelven, pasan a salir del estudio de la IA.

MAX

MIN

MAX
...

...
15

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Cabe destacar que el algoritmo minimax con poda alfa-beta se comporta igual que el
algoritmo minimax, pero es ms eficiente. ste se basa en la poda de las zonas del rbol
que no influyen, debido a la exploracin que se lleva hasta el momento.
Sin embargo, en la mayora de juegos, dado el gran factor de ramificacin y
profundidad de estos supuestos rboles, aplicar el algoritmo minimax como lo hemos
explicado anteriormente es inabordable. Para ello usaremos lo que, en la traduccin del
libro Inteligencia Artificial de Russel & Norving, se denomina decisiones
imperfectas. Estas decisiones imperfectas se basan en limitar la profundidad del rbol
minimax, de tal forma que las hojas que no representen un final de partida se les asigne
un valor estimado. Esto lo determina la funcin de evaluacin o funcin de estimacin.
Esta funcin de estimacin se basa en ciertas heursticas que determinan la calidad de
un estado para uno u otro jugador, e intentan asemejarse al valor que tendra el rbol de
valoracin para ese estado si se realizara la exploracin completa. Esta estimacin es
imprecisa, ya que en ningn momento se puede saber con certeza la precisin de dicha
estimacin.
Esta funcin de estimacin suele tener en cuenta diferentes factores (por ejemplo, en el
ajedrez sera suma de valores de todas las fichas, quin ocupa las casillas centrales del
tablero, etc.). La funcin de estimacin total suele ser una funcin de ponderacin que
asigna pesos (wi) a los distintos factores (fi):
estimacin(estado) = w1 * f1(estado) + ... + wn*fn(estado)

Nuestro proyecto usa minimax con decisiones imperfectas, y que ser la programacin
evolutiva la que calcule dichos pesos wi.

2.1.2 Introduccin a la programacin evolutiva.

ORGENES
La principal caracterstica de la programacin evolutiva es que est inspirada en la
naturaleza, y en como resuelve sta los problemas bsicos para la supervivencia y
evolucin de una especie de individuos. Es por tanto que es una forma de programar
basada en la evolucin natural de los organismos vivos.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En la naturaleza todos los seres vivos se enfrentan a problemas que deben resolver con
xito, como conseguir ms luz del sol, o cazar una mosca. La Computacin Evolutiva
interpreta la naturaleza como una inmensa mquina de resolver problemas y trata de
encontrar el origen de dicha potencialidad para utilizarla en nuestros programas.
Bajo condiciones ambientales ventajosas, la poblacin tiende a crecer a ritmo
exponencial, y dado que los alimentos, espacio fsico, etc. no lo hacen en la misma
proporcin, nacern muchos ms individuos de los que es posible que sobrevivan. En
consecuencia, se desprende que un individuo, si acta de un modo provechoso para l,
tendr una mayor probabilidad de sobrevivir, y ser seleccionado naturalmente.
La teora de la seleccin de las especies (Darwin) sostiene que aquellos individuos de
una poblacin que posean los caracteres ms ventajosos dejarn proporcionalmente ms
descendencia en la siguiente generacin; y si tales caracteres se deben a diferencias
genticas, que pueden transmitirse a los descendientes, tender a cambiar la
composicin gentica de la poblacin, aumentando el nmero de individuos con dichas
caractersticas. De esta forma, la poblacin completa de seres vivos se adapta a las
circunstancias variables de su entorno. El resultado final es que los seres vivos tienden a
perfeccionarse en relacin con las circunstancias que los envuelven.
Podemos decir que la Computacin Evolutiva surge a finales de los aos 60 de mano de
John Holland. Fue l quien plante la posibilidad de incorporar estos mecanismos de
seleccin y adaptacin que muestra la naturaleza a programas que simulasen una
Inteligencia Artificial. Como es de suponer, dada la poca capacidad computacional de
los ordenadores de aquella poca, este estudio fue meramente acadmico, y no fue hasta
mediados de los 80 cuando se pudieron empezar a aplicar estos algoritmos en la
resolucin de ciertos problemas hasta entonces inabordables.
En la actualidad podemos encontrar estas tcnicas funcionando con xito en
aplicaciones tales como:

Decisin y Estrategia:
o Toma de decisiones financieras (presupuestos)
o Bsqueda de reglas en juegos
o Experimentacin de alternativas de marketing
o Gestin de franquicias

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Diseo y parametrizacin:
o Diseo de pistas de circuitos integrados VLSI
o Parametrizacin de Sistemas (configuraciones de equipos hardware)
o Diseo de redes (telecomunicaciones, carreteras) Ubicacin de nodos

Planificacin y asignacin de recursos:

o Asignacin del orden de N procesos en M CPU
o Ordenacin (ordenar cajas en un almacn)
o Asignacin de horarios de clase o turnos de trabajo en un hotel
o Resolucin de sistemas de ecuaciones no lineales
o Enrutamiento
o El problema del viajante de comercio (TSP, Travel Salesman Problem)
o Prediccin
o Seleccin de combinacin de mtodos de realizacin de series
temporales

ESTRUCTURA
Tenemos un problema Qu fastidio! Bueno, vamos a intentar solucionarlo. Sabemos
cmo hacerlo? No. Entonces, a probar. Podemos generar varias soluciones vlidas a
ese problema? Ya, claro que podemos, pero van a ser todas muy malas soluciones.
Bueno, no importa. Las generamos: 40, 100, las que sean. Alguna es mejor que otra?
Todas son malas, pero unas son menos malas que otras. Cogemos las mejores, las otras
las eliminamos. Y ahora qu? Bueno, las podemos coger de dos en dos y mezclarlas a
ver si sale algo bueno S? Bueno, a veces funciona. Vamos a hacerlo otra vez. Y otra.
Tambin podemos mezclarlas de otra forma. Oye esto se estanca, ahora son todas
iguales! Entonces, vamos a coger de vez en cuando alguna de las malas, no slo de las
buenas. Y si hacemos pequeos cambios al azar en pequeas zonas de alguna
solucin, a ver si alguna da en el clavo? Vale... Oye, esto est mejorando! [REF 1]

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En un Algoritmo Evolutivo tenemos que definir una estructura de datos que admita
todas las posibles soluciones a un problema. Cada elemento perteneciente a una de estas
estructuras ser una solucin al problema, que podr ser mejor o peor (tendremos que
analizarlas).
Solucionar el problema consistir en encontrar la solucin ptima, y por tanto, los
Algoritmos Evolutivos son en realidad un mtodo de bsqueda. Pero no solo son un
mtodo de bsqueda, sino algo ms, ya que las soluciones al problema son capaces de
reproducirse entre s, combinando sus caractersticas y generando nuevas soluciones.
En cada ciclo se seleccionan las soluciones que ms se acercan al objetivo buscado,
eliminando el resto de soluciones (ya que a veces no se eliminan, sino que se
mantienen en la poblacin pero con muy baja probabilidad de ser seleccionadas). Las
soluciones seleccionadas se reproducirn entre s, permitiendo de vez en cuando alguna
mutacin o modificacin al azar durante la reproduccin.
En definitiva, los pasos que realiza un algoritmo gentico son:
Se genera un conjunto de N soluciones vlidas al problema. Valores tpicos de N son
desde 1 hasta 200. Cada una de estas entidades representa una solucin distinta a un
mismo problema. Estas entidades se pueden generar al azar. Tambin se pueden generar
a partir de soluciones ya conocidas del problema, que se pretendan mejorar, o mediante
posibles trozos de soluciones (ms conocidos como bloques constructores), es decir,
con lo que creemos que pueden ser elementos componentes de la solucin final aunque
no sepamos cmo combinarlos.
Se evalan las soluciones existentes y se decide, en funcin de esta evaluacin, dos
cosas. Por una parte, qu soluciones van a sobrevivir y cules no; y por otra, cules se
van a reproducir y cules no. En el caso de reproducirse, se especifica la potencia
reproductora de la solucin, de forma que es posible decidir que unas soluciones se
reproduzcan ms que otras.
Tal como se ha establecido en el paso anterior, se eliminan ciertas soluciones y se
mantienen otras, y se efecta la reproduccin o recombinacin de genes (normalmente
por parejas) de las entidades existentes. Por ejemplo, se realizan cruzamientos de
patrones a partir de cierto punto elegido al azar, de forma que los nuevos patrones
posean un segmento de cada uno de los progenitores.
Se efectan mutaciones (cambios al azar en los genes) de los nuevos patrones, segn
una tasa determinada. Algunos estudios aconsejan realizar mutaciones tambin sobre los
padres.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Se vuelve al paso 2 hasta que se cumpla el criterio de parada, que puede ser por
ejemplo, que el peso de la mejor entidad supere cierto valor, o que se halla alcanzado el
lmite mximo de generaciones.
BASES DE LA PROGRAMACIN EVOLUTIVA
Tal y como dijimos anteriormente, los Algoritmos Genticos (AG) se pueden entender
como una estrategia ms de bsqueda, al igual que las conocidas a lo Ancho, en
Profundidad, Escalar-Colinas, Mejor-Primero, y A*. El algoritmo selecciona una serie
de elementos tratando de encontrar la combinacin ptima de estos, utilizando para ello
la experiencia adquirida en anteriores combinaciones, almacenada en unos patrones
genticos. Sin embargo, en este caso, las posibilidades de esta metodologa transcienden
de la bsqueda heurstica, debido a una razn de peso: el algoritmo no trabaja ArribaAbajo, sino Abajo-Arriba: es decir, no es necesario disponer de un conocimiento
profundo del problema a resolver, para que ste pueda ser descompuesto en subproblemas, sino que se parte de estructuras simples que interactan, dejando que sea la
evolucin quien haga el trabajo.
Gracias a esto slo es necesario ser capaces de identificar en qu casos las soluciones
intermedias se acercan o se alejan de la solucin buscada, para que el sistema se
perfeccione automticamente, desarrollando sus propios comportamientos,
funcionalidades y soluciones. Ciertamente, se puede decir con humildad que esta
tcnica ha demostrado ya su relativa utilidad, en la vida biolgica, crendonos a
nosotros mismos.
REPRODUCCIN: La reproduccin sexual tiene la ventaja de que combina dos (o
ms) bloques de genes que ya han probado su efectividad, de manera que es posible que
el patrn resultante herede las caractersticas deseables en ambos progenitores, en cuyo
caso ser seleccionado, aumentando la existencia de dichas caractersticas en la
poblacin. Precisamente, ms del 95% de las especies vivas en el planeta poseen
reproduccin sexual.
MUTACIN: Aunque es poco probable que un cambio cualquiera en un gen sea
beneficioso, las mutaciones producen varias ventajas: dificultan el estancamiento de la
poblacin aumentando la variedad, de manera que ante un cambio brusco del entorno, la
comunidad pueda adaptarse a la nueva situacin; adems, permiten la generacin de
cualquier segmento de patrn, de manera que si en el conjunto inicial de patrones no se
encuentran todos los elementos necesarios para formar el ptimo, sea posible llegar a
ella.
SELECCIN: Aqu existe una gran diferencia entre la seleccin que se presenta en la
naturaleza y la que nosotros establecemos en nuestras granjas o programas. Nosotros
podemos seleccionar para la reproduccin los seres que ms nos interesan, ya sean las
20

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

vacas que ms leche dan o los agentes software que mejor resuelven un problema. En
cambio, en la naturaleza no existe -en principio- una inteligencia exterior que determine
la direccin de la evolucin. Y sin embargo, la evolucin en la naturaleza s se produce.
Todo esto nos lleva a pensar que, aparentemente, es mejor guiar nosotros la seleccin y
acelerar la mejora de una poblacin de individuos de esta forma. Sin embargo, es algo
que no est demostrado, ya que uno de los principales problemas de los algoritmos
genticos es el que se puede expresar con la siguiente pregunta, Cmo han podido
generarse gradualmente rganos complejos, como las plumas para el vuelo, si slo el
rgano completamente funcional es til al individuo? No siempre es fcil explicar todos
los rasgos que presenta un organismo con un mecanismo adaptativo.

PRINCIPALES CARACTERISTICAS
CUNDO PODEMOS APLICAR UN ALGORITMO EVOLUTIVO?
En primer lugar, en el problema a resolver, la meta ha de poder ser observada en grados
cualitativamente comparables. Por otra parte, las principales dificultades a la hora de
implementar un algoritmo gentico son:

Definir una estructura de datos que pueda contener patrones que representen, la
solucin ptima buscada (desconocida) y todas las posibles alternativas de
aproximaciones a la solucin.

Definir un tipo de patrn tal que si un patrn es seleccionado positivamente, que

esto no sea debido a la interaccin de los distintos segmentos del patrn, sino
que existan segmentos que por s solos provocan una seleccin positiva.

Definir una funcin de evaluacin que seleccione los mejores individuos.

Las condiciones que debe cumplir un problema para ser abordable por algoritmos
evolutivos son:

El espacio de bsqueda deber ser acotado.

Debe existir un procedimiento relativamente rpido que asigne un grado de

utilidad a cada solucin propuesta, de forma que este grado de utilidad asignado
corresponda, o bien directamente con la calidad de la solucin en cuanto al
problema a resolver, o bien con un valor de calidad relativo al resto de la
poblacin que permita obtener en el futuro mejores soluciones.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Debe existir un mtodo de codificacin de soluciones que admita la posibilidad

de que los cruzamientos combinen las caractersticas positivas de ambos
progenitores. Este mtodo debe permitir tambin aplicar algn mecanismo de
mutacin que sea capaz de conseguir tanto soluciones muy dispares respecto de
la solucin sin mutar, como muy parecidas a sta.

QU PODEMOS VARIAR PARA REFINAR?

Nmero de entidades inicial

Mtodo de generacin de estas entidades (al azar o segn una funcin)

Tasa de reproduccin (constante, variable segn una distribucin estadstica

determinada)

Tasa de defunciones

Mtodo de reproduccin: asexual, sexual con 2 progenitores, 3, etc.

Tasa de mutacin (constante, variable)

Tipos de mutaciones producidas

Permitir o no la transmisin gentica de la experiencia

Todo tipo de restricciones que hagan que el funcionamiento de cada uno de los
aspectos anteriores dependa de ciertas condiciones.

OPCIONES DE UN ALGORITMO EVOLUTIVO

Opciones Generales:
-

Nmero de entidades.

Nmero de elementos (genes, reglas) por cada agente.

Mtodo de Evaluacin: Asignar un peso

Desordenar las entidades antes de evaluarlas

Diferentes formas de modificacin de los pesos despus de la evaluacin. Por

ejemplo, el peso de una entidad se puede calcular independientemente de las
22

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

dems entidades, o se puede modificar posteriormente este valor, disminuyendo

el peso si existe otra entidad muy parecida, analizando para ello un cierto
subconjunto de la poblacin vecina.
Mtodo de Seleccin: Quin muere? Quin se reproduce?
-

Con o sin reemplazamiento

Mtodo de la ruleta

Mtodo de los torneos

Seleccionar el n mejor y el m peor

Mtodo de Reproduccin: Generar y mutar nuevos hijos

Los padres pueden tomarse por parejas o en grupos ms numerosos, elegidos al

azar o en orden de pesos

En el caso de detectar que los progenitores son muy parecidos, se puede realizar
una accin especial, como incrementar la probabilidad de mutacin

Las entidades pueden comunicar a otras su conocimiento, ya sea a toda o a una

parte de la poblacin, directamente o a travs de una pizarra, (una especie de
tabln de anuncios)

Mtodo de recombinacin de genes: se pueden tomar genes de uno u otro progenitor al

azar, en un cierto orden, con uno, dos o ms puntos de corte, etc.
-

Tasa de mutacin variable

Fijar una tasa de mutacin diferente para cada individuo o incluso para cada gen

Hacer que sea ms probable que se produzca una mutacin en un gen si en su vecino ya
se ha producido
-

Sustituir por mutaciones genes sin utilidad, como reglas incorrectas o repetidas

Tipos de mutaciones

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

2.1.3 Introduccin a los Juegos de Estrategia

Los juegos de estrategia son uno de los estilos de juego ms completos e importantes
dentro del mundo de los videojuegos. Hoy en da la mayora permiten muchas
posibilidades tales como el juego online, mltiples bandos aliados o enemigos
combatiendo a la vez, vista isomtrica, grficos espectaculares,...
Repasaremos algunos de los ms conocidos juegos que hay en el mercado a da de hoy:

[Link] Age of Empires

Creado por los estudios Ensemble, actualmente est en una fase de desarrollo bastante
avanzada su tercera entrega (la salida se espera para la segunda mitad del 2005).
Una captura de pantalla del programa funcionando es:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En la segunda parte, el objetivo era que los jugadores comandaran hasta la victoria una
de las 13 civilizaciones ms poderosas. Estas incluyen: los Francos, Japoneses,
Bizantinos, Vikingos, Mongoles, Celtas,...
Cada civilizacin tiene atributos nicos, construcciones y tecnologas tambin as como
una unidad de combate basada en su antecedente histrico. Esta saga, apadrinada por
uno de los grandes de la informtica como es Microsoft, es una de las sagas ms
importantes dentro de los juegos de estrategia. Su forma de ver el terreno la han hecho
uno de sus elementos ms caractersticos. Ofrece bastante informacin, imgenes,
msica,... en la web para consultar.
Los requerimientos necesarios, para poder hacernos una idea de lo que deberamos
poseer, son:
PC multimedia con Pentium 166MHz o un procesador ms rpido.
Sistema operativo Microsoft Windows 95, Windows 98, Windows NT 4.0 con Service
Pack 5.
32 MB de RAM
200 MB de espacio de disco duro; 100 MB adicionales de espacio de disco duro para
archivos de intercambio.
Monitor Super VGA con soporte de resolucin de 800x600.
Tarjeta local de video bus que soporte 800x600, resolucin de 256 colores y 2 MB de
VRAM
Unidad de CD-ROM drive de dos bits.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Microsoft Mouse o un dispositivo apuntador compatible.

Mdem 28.8Kbps (o ms veloz) para Internet o juego de uno contra otro.

Tarjeta de audio con audfonos o bocinas.

Para acceder a MSN Gaming Zone necesita Internet Explorer 3.02 o posterior o
Netscape Communicator 4.0 o posterior.
Se requiere acceso a Internet para juego en Internet. Puede requerir el pago de una
cuota por separado a un proveedor de Servicios de Internet. Pueden aplicar cargos por
tiempo de conexin y telefona local.

El tema del idioma es algo a lo que debemos los hispanohablantes irnos acostumbrando,
al menos de momento. La mayora de las empresas tanto desarrolladoras como
distribuidoras son o pertenecen al mercado anglosajn. Por otro lado, la mayora de los
equipos de programacin (salvo honrosas excepciones como puede ser Pyro Studios),
vienen de pases de habla inglesa. Por si ello fuese poco, el ingls es el idioma
internacional en Internet, foco masivo de difusin para estos programas.
Casi todos los programas que vamos a ver suelen destacar las mejoras en la IA que van
aadiendo siendo de los aspectos a los que ms importancia se da.
Ej. Las unidades son ms inteligentes con nueva inteligencia artificial (AI) opciones
como Guardia, Patrulla y Seguimiento as como mltiples niveles de agresin.
Habitualmente, estos juegos se valen de campaas de tutorial para explicar a los
jugadores novatos el funcionamiento de los controles, mens,... que posteriormente
debern manejar con soltura para desenvolverse sobre el terreno de batalla.
El listado de premios que ha obtenido este programa es bastante largo. Puede verse en
su web:
[Link]

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

[Link] Caesar 3
Destaca sobremanera la tercera entrega de este programa. Una primera nocin nos la da
Internet sobre este programa. Gran juego en el que nos pondremos al servicio del
Imperio Romano en misiones tan dispares como construir una ciudad para abastecer de
alimentos a Roma o para defender el avance de los enemigos del Imperio. En esta
misma pgina se destaca:

VENTAJAS:
Gran adiccin, que nos har pasar numerosas horas delante del ordenador
El nivel de dificultad, que est muy bien logrado y nos hace engancharnos an ms...

INCONVENIENTES:
Se le coge el truco y al final siempre haces lo mismo... (aunque sea despus de 1000
horas de juego, bueno, no tantas!)
La lucha de los ejrcitos es un poco simple as que si queris un juego de verdadera
estrategia jugar a otro...
Posteriormente, esta misma compaa descubri un filn con este estilo de juego, y cre
sucesivas sagas pero ambientadas en otros imperios como por ejemplo Faran (Egipto),
Zeus (Grecia),...
Como bien dice un usuario de un foro dedicado al tema:
Siguiendo la estela de la saga de juegos de Sierra llamados Caesar, Faran hace la
versin egipcia de este popular juego de construccin, direccin, organizacin y
administracin de ciudades ambientado en la Antigua Roma trasladndolo esta vez al
Antiguo Egipto, a tierras de los faraones.
Un problema al que se han tenido que enfrentar continuamente estos desarrolladores ha
sido a que es complicado intentar explotar la misma idea continuamente. De hecho,
como dice otro usuario del foro:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

He jugado a varios juegos de Sierra, como el Caesar en todas sus versiones... Este
juego, esta en la lnea de los anteriores, no aporta nada nuevo, si no has jugado a
versiones anteriores si te lo recomiendo... [REF 2]

Aqu arriba tenemos una captura de pantalla a todo gas del programa del que estamos
hablando. El prximo juego que vamos a comentar debemos destacar que es el ms
parecido al nuestro en concreto, tanto en reglas como en objetivos.

[Link] HEROES OF MIGHT & MAGIC

CIVILIZATION

Hace tiempo ya de la aparicin de este juego, uno de los ms aclamados y ms jugados

por todo tipo de usuarios del PC. El realizador de este juego Sid Meier's, es uno de los
mejores productores de juegos para el ordenador, ttulos posteriores como Colonization,
Civilization II (juegos que tambin comentaremos aqu), le han dado el prestigio y el
puesto que se merece.
La temtica de este juego de Microprose (compaa importantsima en este tipo de
juegos), es dominar el mundo. A grandes rasgos el juego discurre desde la edad de
piedra, ao 3300 antes de Jesucristo, hasta la poca actual.
Para comenzar se dispone de una unidad de colono, con la que debemos fundar nuestra
primera ciudad y empezar a desarrollarnos como civilizacin. Hay muchos tipos de
unidades, stas varan segn la poca en la que estemos y los progresos tcnicos y
conocimientos que vayamos adquiriendo. Pueden ser desde unos simples guerreros con
lanzas, hasta unos temibles tanques, pasando por caballeros, milicianos, guerreros con
lanzas y espadas, catapultas y adems de tipos marinos, como pueden ser galeones,
cruceros, portaaviones, submarinos, etc.
El terreno por el que discurre el juego puede ser un mundo aleatorio, uno creado por el
propio usuario o el mapa terrestre. Este est dividido en celdas o, ms precisamente, las
unidades estn condicionadas por sus movimientos, lo cual hace que parezca el terreno
dividido en celdas invisibles
Las ciudades que vamos construyendo, o mejor dicho fundando, deben ser
acondicionadas por elementos comunes, como pueden ser bancos, granero, barracones,
etc... Estos elementos a la vez de apaciguar el nimo de los ciudadanos nos benefician
de una serie de factores sobre nuestra economa y sobre capacidades de nuestras
unidades. Cabe destacar tambin que es posible construir determinados monumentos
histricos o de envergadura, los cuales son elogiados y nos regalan modificadores extras
tambin sobre las unidades y ciudades.
En el juego hay que controlar los descubrimientos que vamos haciendo, las relaciones
con otras civilizaciones, las cuales nos pueden aportar a su vez nuevos conocimientos,
tributos o en su defecto plantearnos una guerra a muerte.
Como se puede ver este juego, es un sinfn de actividades, llegando en algunos
momentos a no saber como dominar todos los factores que se nos presentan, la
capacidad del jugador de afrontar las continuas revoluciones en las ciudades, el golpeo
incesante de unidades enemigas viene muy condicionado por el nivel de dificultad que
se elija, entre 5, de caudillo a emperador, y del numero de civilizaciones junto con el
que se quiera jugar, llegando a poder ser estas un total de 10.
31

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Ya para finalizar conviene decir que este juego es uno de los pioneros dentro del gnero,
sent muchas bases para futuros juegos, y ha sido y seguir siendo, rey entre reyes.
Destacar tambin en el aspecto grfico y sonoro no esta muy logrado, aunque ello no
reste emocin y jugabilidad al mismo. Este es un juego echo por y para jugar, no para
deleitarse mirando grficos, ya que estos son los justos. Cabe decir que hay que jugar a
l para saber lo que engancha y decir tambin que todo estratega que se precie debe
haber jugado en alguna ocasin a este juego, porque si no es as, no sabe lo que se
pierde.
Es del ao 1991, as que lleva ya un tiempecito el abuelete .

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En la ltima versin que tenemos del juego, las cosas han cambiado un tanto:

[Link] WARHAMMER 40000

Cada una de las razas de este juego viene bastante bien detallada, as como toda la
historia y el guin que lo rodea, demostrando que hay mucho ms que el videojuego
detrs de este universo. Como ejemplo, podemos tomar la raza Marines Espaciales
[REF 3] :
Es una fuerza creada por el Emperador y curtida en la forja de la guerra, los
MARINES ESPACIALES son monjes guerreros dedicados a servir a su creador y hay
un fuerte lazo de honor que les une a su sagrada tarea. Aunque son relativamente pocos
en nmero, los MARINES ESPACIALES estn siempre en el frente luchando ferozmente
por la supervivencia de la Humanidad contra los ataques viciosos y constantes de los
enemigos de la Humanidad.
La superioridad sobrehumana de los Marines Espaciales es el resultado de numerosas
modificaciones genticas, de acondicionamiento psquico, de entrenamiento fsico
riguroso y de una fe incuestionable. Un Marine luchando en solitario es por s solo un
guerrero formidable, pero cuando lucha al lado de un millar de hermanos (en
organizaciones conocidas por el nombre de CAPTULOS), estos entonces se convierten
en el arma frrea de la justicia - son las espadas vivas del Emperador, que realizan su
voluntad y protegen a su gente a lo largo y ancho del Imperio.
33

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Se podra decir que un Marine Espacial sirve al Emperador hasta su ltimo aliento,
pero eso sera infravalorar su devocin, ya que algunos le continan sirviendo incluyo
ms all de la muerte - se trata de los mortferos Dreadnoughts. Un Dreadnought es un
vehculo inteligente que lucha, se desplaza y es particularmente sobresaliente en la
destruccin de objetivos difciles, como edificios y vehculos. Los Dreadnoughts son
pilotados por un Marine Espacial que ha sido gravemente herido en el campo de
batalla, y que ha cambiado la certeza de una muerte segura por un entierro permanente
en el interior de un sarcfago blindado.

Y los Dreadnoughts son slo una de las muchas unidades que componen un Captulo de
Marines Espaciales.
Cada Captulo tiene un lder que es el Seor del Captulo, cuyo herosmo y
extraordinaria habilidad hace que sobresalga incluso entre sus excepcionales
compaeros. Veterano, aguerrido en mil batallas, el Seor del Captulo siempre est en
el frente ms avanzado del campo de batalla, dirigiendo cada carga y liderando a sus
tropas con total autoridad.
El BIBLIOTECARIO es el recipiente de la sabidura antigua del Captulo. Puede
canalizar su potente energa psquica para hacer que desaparezcan demonios, para
someter enemigos, para proteger a sus tropas de ataques psquicos o para aumentar su
resistencia fsica en el fragor de la batalla.

El APOTECARIO es uno de los especialistas clave en el Captulo de Marines

Espaciales. Aunque empua una espada de sierra con habilidad y precisin, la misin
principal del Apotecario es sanar las heridas de sus hermanos Marines en el fragor de
la batalla. Cuando un hermano sucumbe en combate, la misin sagrada del Apotecario
es recoger su material gentico. Las semillas genticas, del cado son un material nico
y comn a todos los miembros del Captulo. Estas semillas pueden usarse de nuevo
para crear nuevos Marines Espaciales y as continuar la historia del Captulo. Las
escuadras DE INFANTERA constituyen el ncleo de los Marines Espaciales. Otras
tropas importantes son los EXPLORADORES, que se desplazan con velocidad y sigilo;
y los Exterminadores, que van armados hasta los dientes y poseen una gran experiencia
y que pueden ser teletransportados directamente al combate. Cada escuadra
desempea una funcin vital dentro del Captulo.
Todos los Marines, ya sean eruditos o soldados de infantera, se encuentran bajo el
mando de un Comandante, conocen el propsito de su misin y sirven con herosmo y
devocin absoluta a su Captulo y a la gloria del Emperador.
34

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Son los Marines Espaciales

!No conocen el miedo!
Despus de toda esta larga parrafada, podemos decir que poco aporta nuevo a los
anteriores juegos de estrategia. De hecho, es un individuo bastante menos conocido
salvo por sus admiradores jeje, que los anteriormente citados.

Otro modo muy interesante de ver las caractersticas de cada programa, y que
evidentemente deberamos de soportar como desarrolladores en el caso de que nuestro
programa estuviera incluido en el mercado, es la comparativa mediante tablas de
atributos de varios de ellos. Como ejemplo, el siguiente:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

[Link] COMPARATIVA DE 5 JUEGOS DE ESTRATEGIA

Tzar, Faran, Age of Empires II, Alpha Centauri, Home World, Pizza $yndicate.

NOMBRE

Tzar

Faran

Age of Empires
II

Alpha
Centauri

FABRICANT. FXInteractive

Sierra

Microsoft

Firaxis

DISTRIBUID. FXInteractive

Havas Inter.

Microsoft

Telfono info

91 799 01 10

91 383 26 23

902 197 198

91 304 70

Fax

91 799 12 25

91 383 24 37

91 803 83 10

91 754 52
65

Edad recom.

No especif.

SERVICIO

3 % NOTA

Telf. Ayuda

91 799 01 10

91 383 27 60

902 197 198

91 304 70
91

Serv. Online

[Link] [Link] [Link] [Link]

INSTALAC.

11 % NOTA

11 %

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

NOTA

Autoarran.

Indica
espacio
necesario?

Indica
espacio libre?

Manual

Muy completo/muy claro

Muy comple- to/muy

claro

Muy completo/muy claro

Muy
completo/muy
claro

Idioma

Espaol

DirectX

DirectX 7

Direct X 6.2

DirectX 6.1

DirectX 6

MANEJO

10 % NOTA

10 %
NOTA

Perifricos

Tecl., ratn

Opc. Conf.

Muchas

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Idioma

Espaol

CALIDAD

26 % NOTA

26 %
NOTA

Grf./video

Muy buenos

Buenos

Muy
buenos

Sonido/voz

Buenos

Muy buenos

Bueno/No

Muy
buenos

Rendimiento

Muy bueno

Jugabilidad

Muy fcil

Fcil

Amplitud

Amplio

Muy amplio

Muy
amplio

DIVERSIN

Redondo en todo Muy adictivo y

completo

Un clsico
renovado

Calidad
ante todo

Nota parcial

900

890

864

832

CALIDAD

SOBRESALIENTE

NOTABLE

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

PRECIO/CAL SOBRESALIENTE

BIEN

PRECIO

6.995 PTAS

[Link] Uso de PE para el clculo de pesos de una Red Neuronal

Para entender esta alternativa, lo ms conveniente es que expliquemos brevemente en
que consiste una red neuronal. Cmo para todo programa o problema bsico, dada una
entrada debemos obtener una salida. Pues bien las redes neuronales software imitan el
comportamiento de las redes neuronales humanas, por ejemplo. Cada neurona o unidad
bsica tiene la siguiente funcin:

NEURONA:
DENDRITAS
v1

axn
V+
w (peso)

v2
v3

Cada dendrita recibe un valor de entrada, si dichos valores de entrada (o potenciales)

suman un valor mayor o igual que el peso "w" de la neurona, emiten un valor (o
potencial) constante de V+. En caso contrario el axn emite un valor (o potencial) nulo.
Las neuronas pueden ser dispuestas de muchas formas, para formar diferentes tipos de
redes neuronales. Una de las formas ms comunes es:
42

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

RED NEURONAL EN FORMA DE ARBOL: (Tree Neuronal Network)

Las funciones que pueden abarcar las redes neuronales son completas, esto es, pueden
calcular cualquier funcin que podamos expresar formalmente. Una rpida
demostracin de ello, es que, para el caso particular de dos dendritas por neurona, en la
que todos las valores de entrada y salida de cada neurona sean '0' o'1', para valor de w =
0,5 la neurona se comporta como una puerta OR (la salida del axn es '1' con que
cualquiera de las dos dendritas valga '1'), para valor w = 1,5 se comporta como una
puerta AND ( es necesario que las dos dendritas de entrada tengan su valor a uno). Por
tanto, un caso concreto de red neuronal seran aquellas que simulan puertas lgicas
AND y OR. Como todos los informticos sabemos, estas dos puertas lgicas son un
conjunto universal. Luego queda demostrado que una red neuronal puede expresar
cualquier funcin. Sin embargo, las redes neuronales son muy ricas, ya que se pueden
tomar infinidades de valores w, que las hagan actuar de muy diversas formas.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Pues bien, un algoritmo evolutivo podra calcular los pesos de las neuronas que
proporcionan una funcin de mayor calidad. Es decir cada individuo de la poblacin
individual sera un conjunto de pesos para la red neuronal.
En nuestro caso de juegos de estrategia, la funcin que calcularamos por este mtodo
sera la funcin de estimacin para determinar la calidad de un estado del juego. Para la
funcin de adaptacin, usaramos un algoritmo minimax clsico usando los pesos
anteriores. Se realizaran torneos entre las distintas "redes neuronales" (en realidad entre
los pesos de las neuronas, ya que la red neuronal sera la misma) para ir obteniendo por
programacin evolutiva el mejor conjunto de pesos que haga a la red neuronal
comportarse mejor.
Lo realmente glorioso y fascinante de ste mtodo y distinto a la mayora de posibles
alternativas es que no se necesitara conocimiento experto humano acerca de
estimaciones del estado posible, sino que la propia red neuronal entrenada con
Programacin Evolutiva es la que determina dicha estimacin.
Las redes neuronales, en general no han tenido mucho xito (en Estados Unidos ha sido
una de las reas de investigacin en que ms se ha invertido y de las que menos
resultados productivos ha obtenido en proporcin). Sin embargo, los autores K.
Chellapilla, B. Fogel [REF 5] muestran un trabajo sobre damas, usando redes
neuronales de la forma anteriormente descrita, y con un gran xito. En su trabajo,
conectaron las dendritas correspondientes de la red neuronal a las posiciones del tablero.
Los valores de entrada variaban entre tres dependiendo si haba una ficha de uno u otro
color y si estaba vaca. Los resultados fueron ms que exitosos. Aunque tambin cabe
destacar la gran cantidad de tiempo necesario. Se necesit un Pentium de 400Hz durante
unos seis meses (con unas 840 generaciones).
Este mtodo fue descartado para nuestro proyecto, debido a la magnitud, y al excesivo
tiempo de entrenamiento, del que dada la estructura y calendario del proyecto, en
ningn momento cremos disponer.

[Link] Uso de PE para el clculo de pesos de la Funcin de Estimacin

Una tercera alternativa consistira en usar el algoritmo minimax clsico y una funcin
de estimacin ponderada esto es, que dicha funcin de ponderacin se calculase como
ponderacin de otras, segn se explic en el apartado de IA:
estimacin(estado) = w1 * f1(estado) + ... + wn*fn(estado)

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En este caso, la programacin evolutiva se utilizara para calcular los pesos "wi" de
ponderacin. Para ello, cada individuo de la poblacin de PE sera un vector de pesos.
La adaptacin (o fitness) de los individuos se calculara por medio de torneos. Es
similar al entrenamiento de redes neuronales, en la medida en que diferentes conjuntos
de pesos que influyen en la funcin de estimacin compiten entre s.
Sin embargo, observamos que las funciones f1,..., fn son funciones que parten de
conocimiento humano. Luego dicha "bsqueda de la funcin de estimacin" est mucho
ms "guiada" que en el caso de las redes neuronales (en nuestro proyecto apenas varios
segundos bastarn para reproducir una funcin de estimacin aceptable). El incluir
conocimiento heurstico humano supone una ventaja y un inconveniente en s. La
desventaja es que es necesario disponer de dicho conocimiento (en el ajedrez por
ejemplo cantidad de reglas tcticas, como es positivo ocupar posiciones centrales, y
negativo tener dos peones en la misma columna, etc.). La ventaja es que el proceso de
aprendizaje se acelera enormemente.
Un ejemplo de esta tercera alternativa de uso de la programacin evolutiva es el trabajo
de k. Chisholm y P. Bradbeer en la Universidad de Napier en Edinburgo, Escocia [REF
6]. En este trabajo se muestra la tcnica anteriormente descrita para desarrollar un juego
de damas.

cada cierto nmero de jugadas se evaluaran los resultados. En caso de ser cada partida
se mirara el resultado final de la partida y en caso de ser cada cierto nmero de jugadas
se observara si ha sacado desventaja o desventaja y se almacenara.
En cada reclculo de los pesos por programacin evolutiva se introducira en la
poblacin inicial, un individuo inicial con el conjunto de pesos que mejor resultado
haya tenido hasta el momento.
Cada vez que se evaluasen los resultados se observara si dichos resultados son mejores
o peores que los resultados obtenidos hasta el momento. En caso afirmativo, se
guardarn como mejores resultados el conjunto de pesos nuevo. En caso negativo
continuaremos con el conjunto de pesos antiguos.
El conjunto de pesos "mejor" as como dicho "mejor resultado" que obtuvo, se
guardarn en un fichero y sern recordados cada vez.

[Link] Alternativas Elegida en el aprendizaje contra humano:

En conclusin hemos estimado que la alternativa ms adecuada en nuestro proyecto
para el aprendizaje contra el ser humano es algoritmo de escalada.
El razonamiento basado en casos es de complejidad razonable y estn fuera de los
objetivos de este proyecto, el estudio de PE en juegos de estrategia. El razonamiento
basado en casos tiene entidad como para formar otro proyecto entero.

El uso del humano como herramienta para calcular la adaptacin (fitness) en la PE, se
hara muy pesado para el jugador humano, y lo consideramos innecesario.
Por el contrario, el uso del algoritmo de escalada es sencillo y cmodo; adems se
adapta a las necesidades de nuestro proyecto sin un gran coste extra, como el que
tendran las otras dos opciones. Tambin se esperan unos resultados satisfactorios,
aunque eso son ya conclusiones que deberemos sacar en el correspondiente apartado de
validacin.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

3. Especificacin
del Proyecto
3.1 Especificacin del Sistema
3.1.1 Requisitos Funcionales
El sistema cumplir los objetivos expuestos en el apartado 1.2, en lo referente a
implementacin, aprendizaje e interfaz grfica.

3.1.2 Requisitos No Funcionales

El sistema, en la interaccin con el usuario, deber tener unos tiempos de respuesta
aceptables, incluso en los pasos en los que intervenga un proceso de aprendizaje, al
iniciar una partida, por ejemplo, no ms de varios segundos. Asimismo, deberan
mantenerse por la calidad del juego unos tiempos de respuesta durante la accin casi
inmediatos. No debera asimismo requerir un supercomputador para poder funcionar
fluidamente, ya que la idea es que sea un juego que cualquier o casi cualquier persona
pueda hacer correr en la mquina de su casa.

3.2 Especificacin del Juego

El juego de estrategia usado en nuestro proyecto es un juego nuevo inventado por
nosotros mismos. Esto da un rasgo de originalidad al proyecto. El juego constar de dos
modos: el modo general, y el modo batalla, que ser un modo que complemente al
primero.
49

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

3.2.1 Modo General

Habr dos jugadores (generalmente uno ser dirigido por el humano y otro por la
mquina) .Cada jugador dirige un ejrcito. Dicho ejrcito tendr:
- Ciudades (pueden tener en su interior un lder del mismo jugador)
- reas de Recursos Apropiados
- Lderes (cada uno de los cuales con un nmero de soldados dados)
- Nmero de recursos (representan alimento, dinero y otras cosas)
Asimismo, habr recursos y ciudades que no sean de nadie y que se puedan conquistar
por cualquiera de los lderes.
El juego ser por turnos, que se irn alternando entre los dos jugadores. El jugador que
tenga el turno podr realizar alguna de las siguientes operaciones:
- Mover un lder (en cualquiera de las direcciones: arriba, abajo, izquierda y derecha):
- Si un lder llega un rea vaca se situar en ella.
- Si llega a un recurso o ciudad de su propiedad slo podr entrar si no hay ningn lder
en ella.
- Si el lder entra en una ciudad del oponente, el lder se situar en dicha casilla, y la
ciudad quedar conquistada.
- Si el lder entra en un rea de recursos del oponente, dicha rea de recursos pasar a
pertenecer al jugador que dirige dicho lder.
En cualquier caso en el que un lder llegue a la casilla donde este otro lder (el otro lder
podr estar en una casilla sin nada ms o podr estar en dentro de una ciudad o recurso),
se libra una batalla entre los dos lideres. El lder ganador se situar en la casilla de la
batalla, sometindose a las reglas de movimiento anteriores (vase el subapartado de
modo batalla).
- Comprar un lder en una ciudad vaca de su propiedad. En cuyo caso el nuevo lder
tendr cero soldados y se encontrar en la ciudad correspondiente. Para ello es necesario
tener y gastar cierto nmero de recursos.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

- Comprar un soldado en una casilla que contenga un lder de su propiedad. En dicho

caso el lder incrementar su nmero de soldados. Para ello, es necesario tener y gastar
cierto nmero de recursos.
Despus de cada turno, cada ejrcito ver incrementado su nmero de recursos de forma
proporcional a las reas de recursos apropiadas en dicho instante.
La disposicin inicial del juego, tanto el tamao del campo de batalla, como disposicin
inicial de los ejrcitos, ser variada.

3.2.2 Modo Batalla

Cada vez que se libre una batalla entre dos lderes, se abrir una nueva subpartida. En
dicha partida de batalla, slo habr un tipo de unidad, los soldados.
Dichos soldados podrn moverse en las cuatro direcciones. Si un soldado se mueve
sobre la posicin del soldado enemigo ser un ataque con xito, en el cual el soldado
enemigo desaparece y el soldado atacante pasa a ocupar su posicin.
El numero de soldados de cada jugador ser el numero de soldados de cada lder
enfrentado en la batalla ms uno (suponemos que el propio lder juega como un soldado
ms en la batalla). La batalla se acabar cuando finalice el tiempo o alguno de los dos
jugadores se quede sin soldados.
El lder ganador ser aquel que al final tenga ms soldados, el nmero de soldados de
ese lder en el juego general, tendr en cuenta las prdidas en la batalla. En concreto,
ser la diferencia de soldados de un jugador con otro (sin tener en cuenta el soldado que
representa al lder).

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

4. Diseo e
Implementacin
4.1 Diseo General
Nuestro proyecto consta de los siguientes mdulos o clases:
Principal

Partida

Escenarios

PartidaIA

PartidaGUI

Operador

Estado

UAlgoritmoEvolutivo

Estimador

Estimador
Compuesto
52

minimax

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Los anteriores mdulos son usados indistintamente por los dos modos de juego, el modo
general (con recursos, ciudades y lderes) y el modo batalla (slo con soldados). El
conseguir que tengan tantos mdulos o clases compartidos entre dos modos tan
diferentes de juego lo consideramos una cualidad positiva, en especial los referentes a
"partida" , "minimax" y "UAlgoritmoEvolutivo", esto se consigue por medio de
interfaces "clases abstractas en C++" como "Estado", "Estimador" y "Operador"
Sin embargo hay mtodos que son especficos de cada mdulo, y en los cuales se
distinguen con el siguiente convenio:
* Terminan con "G" aquellos especficos del modo General
* Terminan con "B" los del modo Batalla
Obsrvese el siguiente diagrama:

Estado
Operador

EstadoG

EstadoB
OperadorG

PartidaGUI

Estimador

EstimadorG

OperadorB

EstimadorB

PartidaGUIG

PartidaGUIB

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Hemos intentado desde un principio crear un diseo para nuestro programa lo ms

genrico posible, de modo que tanto el mantenimiento como posibles ampliaciones
fuesen posibles de un modo rpido y sencillo.
Durante la primera fase de creacin del videojuego, todo el aspecto relacionado con el
diseo tuvo una importancia capital, ya que en buena medida el diseo (aunque es
posible cambiarlo) determina el proyecto en gran parte.
Posteriormente, se lleg a un punto donde la implementacin fue ganando terreno, lo
cual era una evolucin lgica en el programa.
Sin embargo, y pese a echarle dedicacin, como en casi todos los proyectos grandes de
programacin, el diseo fue cambiando sucesivamente pasando por diversas versiones
por varios motivos: a veces porque se encontraban formas mas elegantes o sencillas de
hacer las cosas, a veces porque llegbamos a un punto donde nuestro diseo no era
consistente, o en parte no cuadraba con las ideas de POO (programacin orientada a
objetos), como por ejemplo, la independencia, y la encapsulacin...
Al estar trabajando en C++, podamos optar por usar clases, mdulos con funciones,
combinados... Al final , elegimos este ltimo aspecto, y segn creamos conveniente
usbamos un modo de trabajo u otro.

El primer mdulo a citar es Principal, que contiene las funciones que inicializan
ratn, teclado, sonido, el modo grfico...
Adems, es quien lleva el control sobre Allegro (librera grfica utilizada para la
creacin del juego), al ser quien le dice cundo debe inicializarse y finalizarse.
Otro detalle es que en l se ubica la funcin main de nuestra aplicacin. En ella
se crea el men principal, se visualiza, se recoge la opcin que se haya marcado,
y se pone en marcha la partida si es necesario. Aunque no lleva carga lgica en
el programa de aqu en adelante, hasta que la partida no finalice, es una clase
muy importante, ya que tambin la utilizamos para poder enlazar varias partidas
sin tener que salir. Es importante decir que para evitar la inclusin mltiple, en
los mdulos se han incluido las siguientes lneas:

-- al comienzo del mdulo -#ifndef (Nombre_Mdulo)H // Evitar inclusiones mltiples

#define (Nombre_Mdulo)H
54

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

--al final del mdulo -#endif

Asimismo, es un sitio muy til, al ser tan general, para poder realizar pruebas en
los largos periodos de depuracin por los que ha tenido inevitablemente que
pasar la aplicacin.

La clase que se encarga de mostrar el men principal , e ntimamente ligada a la

anterior es la clase Men, que lleva buena parte de interactividad con el usuario,
y devuelve al programa lo que el usuario va eligiendo para que este lo pueda
procesar. En lugar de crear y destruir cada visualizacin del men, creamos una
sola instancia de esta clase, para usarla todas las veces que sea menester. El
mtodo principal de esta clase es el mtodo Mostrar que se encarga de mostrar
la pantalla principal de seleccin del men. A partir de ah, tenemos mtodos
para poder ver las pantallas especificas segn la opcin. Como podemos ver,
nuestro diseo tambin conlleva una externa organizacin de directorios en
Msica, Imgenes... dado que si no fuera as, encontrar posteriormente un
archivo entre el total poda ser un caos, y no quedara un sistema de archivos
para nada legible.

Por otro lado, y aunque parezcan mdulos algo desconectados del resto, tenemos dos
bastante curiosos: Sonido y Archivos.

Sonido se encarga de llevar, a excepcin de la inicializacin y finalizacin de

drivers de sonido, lo cual es misin de Principal, de todo lo relacionado con el
sonido. En principio, tiene funciones para poder reproducir un archivo WAV
que tengamos en nuestro disco duro (la edicin de estos ficheros debera hacerse
externamente, desde nuestro programa lo que hacemos es simplemente
reproducirlos), parar la msica que est actualmente reproducindose y controlar
los parmetros de reproduccin (frecuencia de reproduccin, volumen,
panoramizacin...). En principio, no es muy recomendable que alguien manipule
sin saberlo estos parmetros, ya que puede tener efectos curiosos sobre las
melodas. No obstante, el volumen es perfectamente modificable desde el
exterior (altavoces...). Nosotros nos encargaremos de rellenar estos parmetros.
En este apartado nos valemos del tipo SAMPLE incluido en Allegro. En este
caso, podemos considerar que SAMPLE es una estructura de alto nivel, ya que
es posible modificar los sonidos a ms bajo nivel. Para ello se emplean las
voces. Se debe reservar y liberar las voces explcitamente, ya que stas no se
55

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

liberan solas al acabar la reproduccin, pero esto le permite especificar

precisamente lo que quiere hacer con el sonido. Incluso puede modificar algunos
campos de la estructura sample.

El otro mdulo del que queremos hablar en este momento es Archivos. Aqu se
encuentra la informacin relacionada con los archivos en nuestro caso, y
tambin con el aprendizaje. En nuestro caso, tenemos un aprendizaje
personalizado consistente en almacenar en un archivo nombrado con el nombre
del jugador que est actualmente jugando, con una extensin conocida (txt) para
que pueda ser observado y estudiado tanto por nosotros como por otras personas.
Dentro almacenamos el individuo que le venci anteriormente y del cual
extraeremos informacin sobre como jugar. Para el caso del diseo, lo
importante es que necesitamos funciones para poder llevar a cabo estas acciones:
CargarInd y GuardarInd cargan y guardan respectivamente, usando como
parmetros el individuo donde queremos cargar o guardar la informacin, y la
ruta del archivo. Uno de los grandes problemas con el que nos hemos encontrado
aqu ha sido transformar objetos de tipo cadena de caracteres a tipo real. Para
ello, es por lo que se han creado funciones del tipo strToFloat (cadena a real) o
charToDig (carcter a digito). Estas funciones estn predefinidas para C++, pero
debido a problemas con el compilador tuvimos que crearlas nosotros mismos.

Otro de los grandes pilares de nuestro juego es la clase Partida. Se puede decir
que esta clase es posiblemente la que lleva una mayor carga lgica de nuestro
programa. Por una parte, lleva la parte inteligente tanto de lo que podramos
considerar juego general como la del apartado de las batallas. Por otro lado,
lleva la informacin de todos los jugadores que tenemos en la partida, una
indicacin o flag de finalizacin para saber cuando se ha acabado, el mejor
individuo obtenido por el algoritmo evolutivo (del cual obtenemos los pesos
para jugar), y adems un puntero a la parte grfica, donde realizaremos toda la
interaccin de esta parte con el usuario. Como mtodos fundamentales podemos
resear todos: Jugar, JugarHumano, JugarMaquina, JugarBatalla... En esta
clase, problemas constantes han sido que atributos necesitaba, que usos y
formato les bamos a dar (dudas entre usar listas, vectores...), cuantos y que
parmetros iban a tener los constructores...
Tambin estuvo en los primeros momentos de creacin la duda de cuantos
jugadores simultneos bamos a permitir en una misma partida, pero al final
decidimos que fuesen dos. Desde Partida nos encargamos de inicializar tanto la
parte grfica como inteligente del juego, y posteriormente de controlarlas.

La parte inteligente de la partida es un objeto de la clase PartidaIA. Esta clase

esta preparada para, teniendo un atributo de tipo Estado, extraer toda la
56

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

informacin posible del estado actual de la partida. Tambin tiene informacin

de la profundidad con la que estamos realizando minimax, e informacin sobre
los jugadores y los estimadores. Su mtodo estrella es jugar, que tal como reza
su comentario:
/*
METODO: jugar()
DESCRIPCION: Se juega una partida completa y se devuelve el resultado.
Esta operacin slo se podr invocar en partidas de maquina contra maquina.
*/
De aqu deducimos que esta clase es usada tanto para el entrenamiento de
nuestro programa a travs de la PE en los torneos, como posteriormente para
realizar jugadas durante el juego por la mquina. Para ello hace uso de los
mtodos JugarMaquina y JugarHumano. Sus cambios los va aplicando sobre
el estado, de modo que a nivel lgico esta cambiando la partida de situacin. En
esta clase usamos vectores de C++, extremadamente tiles por sus posibilidades
de acceso. En funcin de nuestras necesidades, en otros puntos del cdigo lo que
usamos es la clase Lista, clase implementada por nosotros, que implementa una
lista enlazada (sus atributos y mtodos son los clsicos para este TAD).Usamos
plantillas para generar listas genricas.

Mdulos que nos han resultado tambin de utilidad, aunque no participan de

modo fundamental en la aplicacin, han sido por ejemplo Mensajes, muy usado
en tareas de comunicacin con el usuario, y sobre todo depuracin, ya que
hemos tenido algunos problemas con el debugger del propio Dev-Cpp, o
Matemtico, donde implementamos pequeas funciones exclusivamente
matemticas para usar en los algoritmos.

Otra clase que nos servir enormemente a posteriori es la clase Posicin. En

ella, aunque de un contenido muy trivial, implementamos una posicin en 2D,
pero con mtodos para acceder y modificar sus parmetros.

Las clases Operador (implementada a travs de OperadorG y OperadorB),

nos permiten crear diferentes operadores para la batalla y para el juego general.
Evidentemente, debamos tener separados estos detalles en el diseo, ya que el
hecho de comprar un soldado por poner un ejemplo no tiene mucho sentido una
vez ha comenzado una batalla al menos en nuestra aplicacin.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Algo parecido ocurre con los estimadores. En nuestro diseo hemos procurado
que el hecho de aadir un estimador sea lo ms sencillo posible, ya que
pensamos que puede ser de los sitios donde ms cambios tengamos que realizar
en un breve periodo de tiempo.

Por ltimo, comentar la estructura que le otorgamos a cada una de las posiciones
del tablero. Cada una de ellas es un ObjetoMapa, pero ms en concreto puede
ser una especificacin de esto ltimo, como puede ser Lder, Ciudad o
Recurso.

Como bien se dijo en la especificacin, se trata de un juego de ejrcitos, de ah

que existan las clases Unidad y GrupoUnidad (la cual es un conjunto
numerado de la anterior clase), para que, por ejemplo, en nuestro programa los
lderes puedan llevar batallones.

4.2 Diseo
Artificial

Inteligencia

Hemos usado el algoritmo "minimax" clsico. Obsrvese el apartado Inteligencia

Artificial en juegos. Adems hemos usado clases que encapsulen los comportamientos
de una partida.
La clase Estado
La clase Estado es abstracta y representa un estado de un juego (mrese el apartado
sobre IA). Esta clase contiene atributos comunes a los dos juegos
* turno: Enumerado cul de los jugadores tiene el turno en instante dado.
* tiempo: Tiempo lmite restante
Los mtodos abstractos principales son:

Proyecto SI

Curso 2004 2005

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

frente a representaciones binarias, por mejorar el cruce, al poder usar as funciones

matemticas como medias.

w1 = ...

w2 = ...

...

wi = ...

...

wn = ...

Algoritmo Evolutivo General

El algoritmo tendra el esquema clsico de un algoritmo evolutivo. Tendra el siguiente
aspecto.
// Algoritmo Gentico
pob=poblacion_inicial( ... );
// Calculo de la calidad de los individuos
adaptacin(pob, ... );
// Calculo de los valores para ser seleccionados
evaluacin( .... );
for(int generacion=0;generacion<num_max_gen;generacion++){
seleccion(pob,pos_mejor);
//guardo a el mejor individuo de la poblacin (elitismo)
indiv_mejor=pob[p.tam_pob-1];
pob.pop_back();
reproduccion(pob,p.prob_cruce);
if((generacion%p.periodo_mut)==0)
mutacion(pob,p.prob_mut);
//coloco en la nueva poblacin al que antes era el mejor individuo
62

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

pob.push_back(indiv_mejor);
adaptacion(pob,.. );
evaluacion(pob, ...);
}
NOTA: En el anterior esquema de algoritmo, y siguientes usamos como sintaxis la de
C++ y como convenio usamos los nombres de funciones utilizados en la asignatura de
Programacin Evolutiva de la UCM (Madrid).

Adaptacin (fitness)
Lo ms caracterstico de la alternativa usada en nuestro proyecto es la forma de calcular
la adaptacin (o fitness) o calidad de nuestros individuos. Para calcular dicha calidad, se
har un torneo entre los conjuntos de pesos correspondientes, en la que todos jugarn
contra todos ida y vuelta. Lo de jugar dos partidas, es para eliminar las posibles ventajas
de empezar primero o posibles caractersticas de estar situado en una posicin u otra del
tablero. Dicha adaptacin se calcula con el siguiente algoritmo:

// Puesta a cero de la aptitud. Inicialmente cero partidas ganadas por

// cada individuo
for(int i = 0; i< size; i++)
pob[i].aptitud =0;

// Torneo: La aptitud de cada individuo ser el numero de partidas ganadas

for(int i=0;i<pob_size;i++)
{
for(int j=0; j<pob_size;j++)
{
63

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

if ( i!=j)
{
// Copiamos los pesos en los estimadores
estim1->setPesos(pob[i].pesos);
estim2->setPesos(pob[j].pesos);
// Jugamos la partida
partidaAux = new PartidaIA(estado,estim1,estim2);
while(!partidaAux->final())
{
op = partidaAux->jugarMaquina();
delete op;
}
// Obtenemos el resultado
result = partidaAux->getResultado();
// Dependiendo del resultado incrementaremos la aptitud de uno u otro individuo.
En caso de
// empate no incrementaremos la aptitud de ningn individuo
if (result > 0)
pob[i].aptitud++;
if (result < 0)
pob[j].aptitud++;
}

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

}
}

Cruce (crossover)
Para el cruce usamos una reproduccin sexual (en la que intervienen dos individuos)
despus de mucho probar usamos medias ponderadas para entre los vectores de pesos.
Inicialmente usamos medias aritmticas. Esto es:
Sean dos vectores de pesos:
wa1, wa2, ... , waN
wb1, wb2, ... , wbN
de dos individuos a y b, los pesos nuevos serian, para todo i en (1..N)
wai = 1/2*wai ' +1/2* wbi '
wbi = 1/2*wai ' +1/2* wbi '

Sin embargo, experimentalmente observamos que dicho clculo no se comportaba del

todo bien. Se comportaba mejor el siguiente clculo ponderado:
wai = 2/3*wai ' +1/3* wbi '
wbi = 1/2*wai ' +2/3* wbi '

A posteriori, vimos que esto era muy coherente. Esto es, en el primero caso los dos
individuos cruzados pasaban a tener exactamente los mismos pesos y por tanto pasaban
a ser el "mismo" individuo duplicado. Esto empeoraba ligeramente la riqueza y variedad
de los individuos en la poblacin, frente a la segunda opcin en la cual el resultado del
cruce de los individuos eran dos individuos distintos.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Elitismo
Otro rasgo caracterstico es el uso de elitismo en cada generacin, esto es conservar
siempre de una generacin el individuo con mayor calidad o adaptacin (fitness).

Poblacin Inicial y Mutacin

La poblacin inicial se escoger dando valores aleatorios en el rango permitido [0..1] a
cada peso.
En el caso de la mutacin, cada peso de cada individuo, con una probabilidad de
mutacin (muy baja), se volver a escoger aleatoriamente en el rango permitido.

Uso de juegos reducidos para el entrenamiento

Aunque el juego contra el humano podra tener tamao y tiempos lmites grandes; Por
motivos de eficiencia, al igual que en el trabajo de Chisholm y Bradbeer de la
Universidad de Napier [REF 6] anteriormente mencionado, en los torneos desarrollados
en el algoritmo evolutivo usamos juegos de tamao y tiempo lmites reducidos. El
motivo de esto es el gran nmero de partidas que se deben realizar en dicho algoritmo
evolutivo. Por tanto, para mantener una eficiencia aceptable (varios segundos), fue
necesario usar estos juegos "reducidos".
Esto tiene la ventaja de la mejora notable de la eficiencia. Sin embargo, en juegos
grandes el comportamiento es ligeramente peor en algunos casos, ya que la funcin de
estimacin se ha "entrenado y aprendido" en tableros pequeos.
Por ejemplo, entrenndose el modo batalla en tableros cuatro por cuatro, la funcin de
estimacin da un peso enorme a las cuatro casillas centrales:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Observamos que dichas posiciones centrales permitan acorralar a cualquier

contrincante sin escapatoria alguna. Por ejemplo, el soldado "-" se encuentra sin
escapatoria ante los soldados "+"

Sin embargo, la partida real se jugaba en seis por seis, la estimacin segua asignando
un gran peso a estas casillas centrales, sin embargo en este tipo de batallas las cuatro
posiciones centrales no permiten acorralar al soldado "-". Obsrvese como el soldado "" puede escaparse:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Al final, decidimos que era mejor entrenar el juego en un tamao ms parecido al

tamao de la partida real. Entendemos por tamao de la partida real al tamao de la
partida contra la que jugar el usuario. Con esto, evitamos problemas parecidos al que
acabamos de mencionar.

4.4 Diseo parte grfica

install_mouse(). Para reconocer el ratn.

install_timer(). Para iniciar los temporizadores.

install_sound(). Para instalar el sonido.

set_color_depth(). Fija el color de fondo.

set_gfx_mode(). Fija la resolucin de la pantalla.

Otras se encargan de la interaccin con el usuario:

mouse_b &1. Variable que indica si esta pulsado el botn izquierdo del ratn.

mouse_b &2. Variable que indica si esta pulsado el botn derecho del ratn.

mouse_x. Variable que indica en que posicin del eje X se encuentra el ratn.

mouse_y. Variable que indica en que posicin del eje Y se encuentra el ratn.

keypressed(). Funcin que indica si hay alguna tecla pulsada.

Y otras de dibujar en la pantalla:

blit(). Dibuja un BITMAP en la posicin indicada.

stretch_blit(). Dibuja un BITMAP en la posicin indicada, y encajndolo en

unas dimensiones dadas. (Esta funcin no la encontramos hasta muy tarde, con
lo que tuvimos algunos problemas que ya relataremos ms tarde)

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

textout_ex(). Dibuja el texto indicado en la posicin deseada.

load_tga(). Para cargar imgenes .tga

destroy_bitmap(). Para destruir BITMAPS.

Estas son algunas de las principales funciones de Allegro, y que hemos usado bastante a
menudo. Como se puede observar, hemos trabajado con BITMAPS en formato TGA,
que son todas nuestras imgenes (la gran mayora las hemos creado nosotros mismos).
Bsicamente, el proceso para mostrar una de estas imgenes por pantalla consiste en
cargarla, elegir dnde la queremos colocar y cunto queremos que ocupe, y pintarla.
Las funciones descritas anteriormente pueden parecer algo rudimentarias, y en verdad lo
son. Esto por una parte es ventajoso, ya que te permite trabajar a un nivel de abstraccin
bastante bajo y realizar prcticamente lo que uno desee sin ningn impedimento. Ahora
bien, trabajar a ese nivel es realmente complicado, y realizar cualquier operacin, por
sencilla que pueda parecer, lleva muchsimo tiempo y quebraderos de cabeza.

Otra de las grandes pruebas que realizamos consisti en un escenario de juego bsico.
Principalmente era un mapa de color verde y dividido en casillas. Sobre l dibujamos
varios soldados, y conseguamos seleccionar alguno de ellos pinchndolo con el ratn, y
moverlo a otra casilla del mapa pinchando tambin con el ratn.

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Una cosa que si que tuvimos que tener en cuenta fue que si seleccionbamos un soldado
y lo intentbamos mover fuera del mapa (a algn men), no nos diese ningn error y
simplemente dejase de estar seleccionado ese soldado.
El resultado que obtuvimos fue el siguiente:

(S, es cierto se poda mejorar bastante el diseo y los colores)

Se puede ver como en este momento mostrbamos la informacin sobre en qu casilla

se encuentra cada soldado. Ntese que aqu la fila es la primera coordenada y la
columna la segunda. Esto lo cambiaremos mas tarde, a la hora de integrar con la parte
lgica, para estandarizar los convenios de notacin. En ese momento las columnas
pasarn a ser la primera coordenada, y las filas la segunda.
75

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Esta vista principal requera estructuracin o modularizacin, que describimos a

continuacin.
Dividimos el diseo en diversas funciones de forma que la dependencia entre ellas fuese
solo la necesaria. De esta forma se pretende que, ante un cambio o retoque en el aspecto
grfico, el cdigo que se deba cambiar no sea mucho y se localice fcilmente. As
mismo, tenemos la posibilidad de dibujar los botones internamente dentro de cada men
y usando medidas relativas a ste y no a toda la pantalla.
Las funciones que implementamos son:

dibujaVistaPrincipal(). Se encarga de dibujar todo lo que mostramos por

pantalla. La vista general.

dibujaMenuDcho(). Dibuja el men de la derecha. Desde esta funcin se

llamar las veces que sea necesario a la de dibujar los botones.

dibujaMenuBajo(). Igual que el anterior pero ahora para el men inferior.

dibujaMapa(). Dibuja el mapa principal de juego, en el que se desarrolla la

accin. Tambin es el mtodo encargado de calcular el ancho y alto del
escenario.

dibujaBotonConEtiqueta(). Dibuja un botn con un texto en su interior.

Adems aade una etiqueta justo encima del botn mostrando el mensaje pasado
por parmetro.

Cuando integramos el dibujo de los mens y el mapa con la parte del movimiento de los
soldados observamos que el juego se ralentizaba muchsimo. Al principio pensamos que
poda ser debido a que en el bucle principal ejecutbamos demasiadas cosas o
asignbamos memoria y se produca un fallo en el rendimiento del sistema. Pero
despus de observar el cdigo descartamos esta opcin ya que no poda ser debido a
eso.
Al final el problema era que estaba cargando los BITMAPS necesarios una y otra vez en
cada vuelta del bucle, con lo que segn iba pasando el tiempo nos bamos quedando sin
recursos. Para solucionar este problema creamos una nueva funcin
cargarBITMAPS() que se encarga de cargar los BITMAPS necesarios una nica vez al
principio del programa.
Como ltimo apunte para esta seccin, resaltar que tambin conseguimos integrar el
men principal con esta versin, de forma que al pulsar sobre el botn Empezar del
men, cambibamos de pantalla y apareca todo lo explicado anteriormente.
76

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

4.4.4 Crecemos y nos juntamos

La siguiente etapa importante en el desarrollo de la parte grfica fue el intento de unirla
con la parte lgica (Inteligencia Artificial) del juego.
Tenamos dos posibilidades a la hora de afrontar esta tarea:
- Realizar una clase que englobase todo.
- Dejarlo en un mdulo aparte con las funciones que fuesen necesarias.
Tras debatir y analizar los pros y los contras de cada posibilidad decidimos dejarlo
como un mdulo, ya que hacerlo como una clase iba a consumir ms recursos, y
supondra tener que realizar algunos cambios en el diseo que llevbamos hasta el
momento. Tal vez estos motivos no eran demasiados concluyentes, pero como hasta ese
momento lo habamos estructurado todo como un mdulo, decidimos que era mejor
seguir hacindolo as.
Primero se integr todo lo que estaba hecho de la parte grfica en un mdulo llamado
PartidaGUI. Aqu es donde se encontraban todas las funciones que tenan que ver con
Allegro y con los grficos de la aplicacin. Lo que pretendamos hacer era separar lo
mximo posible los grficos de la lgica de la aplicacin, para que los posibles cambios
en un sitio no afectasen al resto. Es por ello por lo que decidimos que la interfaz
nicamente necesitara dos funciones para relacionarse con el exterior:
refrescarEstado(Estado e) y consigueOperador(Estado e). La primera se encarga de
representar en pantalla el estado que se le pasa por parmetro. La segunda se encarga de
analizar el operador que realiza el usuario (comprar soldado, mover a la izquierda,
derecha) y devolverlo.
Realizar la funcin refrescarEstado() fue relativamente sencillo, ya que es
prcticamente lo mismo que ya tenamos realizado. Solo haca falta cambiarle el
nombre a la funcin DibujaVistaPrincipal() (la cual posea todo el cdigo necesario)
de antes, y hacer algunos retoques. Si acaso, lo ms complicado fue ponernos de
acuerdo en qu datos tenamos que guardar en el estado para poder representarlo.
Nos encontramos con algunos problemas, como por ejemplo:

Ahora el nmero de soldados y su posicin vena dado por el estado, con lo que
hubo que cambiar la forma en que los dibujbamos en sus casillas iniciales hasta
ese momento.

Al ser los BITMAPS de un tamao fijo, el mapa no poda tener un nmero de

filas y columnas cualquiera, sino que tena que ser el exacto para que los
77

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

soldados se dibujasen bien en sus casillas. Este es un problema debido al cual

tenamos que fijar el ancho y alto del escenario desde el mdulo PartidaGUI.
Nosotros no queramos que esto fuera as, ya que lo lgico era que se fijase el
tamao del mapa al construirlo en el algoritmo principal del juego. Pero de
momento este problema no lo pudimos solucionar.

Debido al problema anterior, ya no podamos tener solo dos mtodos que se

relacionasen con el exterior, sino que tuvimos que hacer otros dos ms para
averiguar el ancho y el alto del tablero: dameAncho() y dameAlto().

Queramos que en el men de la derecha se mostrase informacin acerca del

mejor individuo obtenido en la programacin evolutiva. Esta informacin no
saldr en la versin definitiva del juego, pero la queramos tener para poder
depurar mejor, y ver como jugaba realmente el ordenador. Para hacer esto
tenamos dos posibilidades: meter esa informacin en el estado, o pasarle un
parmetro ms a la funcin refrescarEstado(): Optamos por esta ltima forma
de hacerlo, ya que considerbamos que alterar la clase Estado era mas crtico y a
la larga podra traernos ms problemas. De modo que hicimos otra funcin
refrescarEstado2(Estado e, TIndividuo i) para no alterar la que ya tenamos
hecha y que funcionaba correctamente. Esta nueva funcin sera eliminada ms
tarde, una vez que ya no necesitsemos conocer esa informacin.

En cuanto a la funcin consigueOperador(), tuvimos la suerte de poder

aprovechar bastante cdigo del que ya tenamos hecho, aunque nos encontramos
con algunas dificultades. Por ejemplo, antes seleccionbamos un soldado y lo
movamos a cualquier otra casilla. Ahora esto no poda ser as, ya que un
soldado solo puede mover una casilla hacia la izquierda, derecha, arriba o abajo.
Para controlar esto tuvimos que tratar cada pulsacin del ratn y comprobar que
si haba un soldado seleccionado y habamos pinchado en una casilla vaca, solo
moveramos el soldado all en caso de que la casilla fuese adyacente a donde se
encontraba el soldado. Y despus de controlar esto todava tenamos que generar
el operador correspondiente y devolverlo.

Con todo lo anterior conseguamos resolver solo algunos de los problemas, ya que otro
muy importante era el que se derivaba de que ahora existan dos jugadores distintos que
se podan atacar unos a otros. Para realizar todo lo necesario tuvimos que tener en
cuenta varias cosas:

Cmo distinguir los soldados de un jugador y los de la mquina? Creamos

nuevos BITMAPS, con el mismo dibujo, pero de distinto color. As
distinguamos entre unos y otros. Esta solucin se convirti, a partir de este
momento, en una tnica a seguir. Como curiosidad, diremos que para cada
78

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

dibujo que aparece en la versin final (soldados, castillos, recursos) tuvimos

que realizar entre 3 y 4 distintos: uno para el jugador humano, otro para el
jugador CPU, otro para cuando estaba seleccionado un jugador humano, y otro
para cuando un recurso o ciudad no eran de nadie.

Decidimos dibujar de un color distinto las casillas a las que te puedes mover,
para que sea ms sencillo para el usuario a la hora de jugar.

A la hora de mover un soldado, tenamos que distinguir si lo movamos a una

casilla vaca o a una ocupada por un soldado del jugador contrario. Tambin
haba que tener en cuenta que nosotros no podamos seleccionar ni mover los
soldados del enemigo.

Aadimos un botn para salir, de forma que al pulsarlo se acabase la partida y se

volviese al men principal. Debido a este botn nos encontramos con los dos
problemas de a continuacin.

Al pulsar el botn de salir no volvamos al men principal, sino que la

aplicacin se quedaba colgada y no podamos continuar. Esto fue arreglado ms
tarde. El fallo estaba en que al dejar de mostrar el men principal destruamos
sus BITMPAS (con la funcin destroy() explicada anteriormente), pero al ir
a mostrarlo otra vez no los recargbamos.

A veces, al pulsar en el botn de salir no te detectaba la pulsacin y por lo tanto

no haca nada. Lo mismo pasaba al pulsar sobre algn soldado. Esto era debido a
un problema de diseo, ya que en el hilo de ejecucin de nuestro programa
existan dos puntos en los que se detectaba una pulsacin del ratn. En uno de
ellos se detectaba si se haba pulsado el botn de salir, y en el otro se detectaban
las pulsaciones dentro del mapa. Por ello, si por ejemplo pulsbamos el botn de
salir, pero el algoritmo se meta en la deteccin de una pulsacin en el mapa, no
se realizaba ninguna accin.

Otra consecuencia de aadir un botn para salir, es que esa informacin la

tenamos que devolver al exterior, con lo que creamos una nueva funcin
dameSalir(), que devuelve un booleano indicando si se ha pulsado el botn de
salir o no. Al contrario de lo que nos ocurra con las funciones dameAlto() y
dameAncho(), esta nueva creada de dameSalir() s que era necesaria e
importante para el funcionamiento del juego y queramos que estuviese as
diseado.

Y al final, despus de lograr vencer tantas adversidades, conseguimos jugar nuestra

primera partida con la interfaz grfica funcionando! Vemos un instante de una partida
en la siguiente captura de pantalla:
79

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

(S, es cierto seguamos pudiendo mejorar bastante el diseo y los colores y

tambin podamos hacer el botn de salir un poco ms grande para que no se saliese el
texto)
Nota: obsrvese que en esta captura de pantalla se ve el puntero del ratn, pero sin
embargo en las realizadas anteriormente no se apreciaba. Esto es debido al problema
que comentbamos de que el ratn parpadeaba.
Tambin se aprecia que hay un soldado seleccionado (ubicado en la segunda fila y
primera columna), y sus casillas adyacentes (a las que se puede mover) estn en gris.
Tambin se ve como los jugadores contrarios en vez de tener el fondo verde(claro) lo
tienen gris (oscuro).
Vemos que al principio, aunque el mapa fuese mucho ms grande, se dibujaban los
soldados en las 4 primeras filas y columnas. Esto es porque la parte lgica de momento
80

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

solo estaba implementada para jugar en tableros de 4x4. Ms tarde se cambiar para
jugar en tableros de cualquier dimensin.
Un problema que se nos plantear, y que no tendr fcil solucin, es que solo podamos
jugar poniendo los soldados en tableros cuadrados (del mismo ancho que alto). Aunque
el mapa (tablero verde cuadriculado) es rectangular, la alineacin de los soldados ha de
ser cuadrada para que funcione la aplicacin. Este problema tardaremos bastante en
arreglarlo. Lo veremos ms adelante.
Mostramos aqu una versin ms avanzada que la anterior, en la que se ve un estado
intermedio de una partida. Se puede ver como en el men de la derecha aparecen datos
sobre los estimadores que utiliza la Inteligencia Artificial para jugar. Son los
estimadores (estimador central, estimador fichas malo y estimador fichas bueno).

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Volvemos a recalcar que, aunque ahora hay ms soldados y juegan en un tablero ms

grande, ste sigue siendo cuadrado.

4.4.5 Mejoramos diseo y nos convertimos en clase

Nuestro siguiente reto consista en: mejorar el diseo (aspecto grfico), y convertir el
mdulo PartidaGUI en una clase.
Hablaremos primero de la mejora del diseo. Lo que queramos conseguir es muy fcil
de explicar. Simple y llanamente, queramos que el juego fuese ms bonito y atractivo.
Este es un tema que hasta el final estuvimos mejorando constantemente, como se podr
comprobar en las distintas capturas de pantalla que mostraremos.
Como este paso solo implicaba el crear nuevos BITMAPS y aadirlos, y ningn cambio
en el cdigo, no nos supuso un gran problema. Vemos el resultado final:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

(S, los soldados necesitaban todava algn que otro retoque pero el resto ha mejorado
bastante)

Desde este momento empezamos a tener dos tipos de botones: los marrones, que son
slo de informacin, y los grises, que realizan acciones. De momento, las acciones de
Comprar Soldado y Comprar Hroe (tena que cambiarse a Lder) solo estaban a modo
de ejemplo, ya que la parte lgica no las tena en cuenta.
Tambin es importante destacar que ya para esta versin estaban solucionados los dos
problemas relacionados con el botn salir.
Por una parte volvamos al men principal cuando lo pinchbamos, y ya no daba ese
error. Como dijimos anteriormente, lo solucionamos volviendo a cargar los BITMAPS
necesarios, y realizando algunos cambios en cuanto a la clase Men, tales como cambiar
el destructor, y retocando el mtodo mostrarMenu().
Y por otro lado, solucionamos el problema de que al pinchar en l no nos hiciese caso.
Esto conseguimos arreglarlo metiendo todo el cdigo que detecta una pulsacin en la
parte que antes tenamos nicamente para detectar pulsaciones en el mapa. Esto era algo
lgico y sencillo como idea, ya que al tener una nica zona de deteccin de pulsacin no
se nos escapara nunca una pulsacin del ratn. En un principio era fcil distinguir entre
una pulsacin dentro del mapa o fuera, pero claro, cmo saber qu botn hemos
pulsado? Para ello creamos una estructura que guardase informacin acerca de la
posicin inicial en pxeles del botn (x,y), el ancho y el alto del mismo, y un cdigo al
cual le asociaramos ms adelante una accin, para saber si lo que queremos es salir,
comprar un soldado
struct TBoton
{
int x,y,ancho,alto,codigo;
};
Otro objetivo a realizar era construir una clase para la parte grfica en vez de dejarlo
como un modulo. Desde la parte lgica estbamos empezando a trabajar en el otro tipo
de juego de que bamos a disponer. Es decir, estbamos empezando a distinguir entre la
partida general (la que juega con lderes, recursos y ciudades) y la partida batalla (en la
que se pelean los soldados de dos lderes contrarios). Hasta el momento, lo que

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

tenamos realizado nos serva bastante bien para la parte de la batalla, pero tenamos que
implementar y disear toda la parte de la partida general.
Para seguir el mismo modelo que estbamos realizando en el resto de la aplicacin,
decidimos construir una clase abstracta PartidaGUI, que fuese extendida por las clases
PartidaGUIG, y partidaGUIB, para la partida general y la partida batalla
respectivamente.

PartidaGUI
refrescarEstado(e : Estado) : int
consigueOperador(e : Estado) : Operador
dameSalir() : bool

PartidaGUIG

PartidaGUIB

Vemos en el anterior diagrama como solo necesitamos 3 funciones para relacionar la

parte grfica con el exterior, gracias al cuidadoso diseo para evitar dependencias entre
distintas partes.
Con lo cual, primero creamos la clase abstracta PartidaGUI, y a continuacin
reestructuramos el mdulo que tenamos para convertirlo en la clase PartidaGUIB. Este
cambio no result demasiado complicado, ya que con el tiempo habamos conseguido
tenerlo bastante bien organizado.
Lo que s que tuvimos que hacer fue, por ejemplo, quitar las opciones para comprar
soldados y lderes, ya que en la partida batalla estas acciones no se pueden realizar.
Al final, las funciones que componen la clase PartidaGUIB son las siguientes:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Las necesarias para extender PartidaGUI:

o int refrescarEstado(Estado *e). Dibuja en pantalla el estado pasado por
parmetro. Devuelve 0 en caso de xito y -1 en caso de error.
o Operador* consigueOperador(Estado* e). Analiza las acciones que
realiza el usuario humano (a partir del estado pasado por parmetro) y
devuelve el operador correspondiente.
o bool dameSalir(). Devuelve cierto si se ha pulsado el botn de salir.
Falso en caso contrario.

Resto de mtodos pblicos:

o PartidaGUIB(Estado* e). Constructor de la clase a partir de un estado
dado.
o ~PartidaGUIB(). Destructor de la clase.

Mtodos privados:
o int dibujaMenuDcho(int x,int y,int ancho,int alto,EstadoB *estado).
Dibuja el men derecho a partir de la posicin (x,y), con el ancho y alto
especificados. El estado es necesario para mostrar la informacin en los
botones. Devuelve 0 si no ha habido error.
o int dibujaMenuBajo(int x,int y,int ancho,int alto,EstadoB *estado).
Similar al anterior. Devuelve 0 si no ha habido error.
o int dibujaMapa(int x,int y,int ancho,int alto,EstadoB *estado). Como
los dos anteriores, pero este se encarga de dibujar el mapa central.
Devuelve 0 si no ha habido error.
o int dibujaBotonConEtiqueta(int x,int y,int ancho,int alto,char*
etiq,char* bot,int codigo,int modoBot). Dibuja un botn con el texto bot,
y una etiqueta encima con el texto etiq. El ancho y el alto que queremos
para el botn se lo pasamos por parmetro. El parmetro modoBot indica
si se trata de un botn de accin o de informacin. Devuelve 0 si no ha
habido error.
o int estaRatonEnRect(int Xini,int Yini,int despX,int despY). Mtodo
que comprueba si el ratn est dentro del rectngulo pasado por
parmetro. Devuelve cero si no ha habido error.
85

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

o Posicion* soldadoSeleccionado(EstadoB* estado,TTurno turno,int

posX,int posY). Si existe un soldado en (posX,posY) devolvemos su
posicin. En caso contrario devolvemos (-1,-1).
o int cargarBITMAPS(). Carga todos los BITMAPS necesarios.
Devuelve 0 si no ha habido error.
o BITMAP* cargaImagenTGA(char *ruta,PALETTE *paleta). Carga el
BITMAP que se encuentra en la ruta especificada.

4.4.6 Creando la partida general

El principal objetivo de esta era implementar la clase PartidaGUIG para ser capaces de
representar grficamente el escenario de una partida general.
Una primera idea consista en partir de la base que tenamos en PartidaGUIB y
adaptarlo a la nueva partida. Pero esto, que en principio pareca que iba a ser una labor
fcil, se complic bastante debido a que la forma en que almacenbamos los datos en la
clase EstadoB (para PartidaGUIB) y en EstadoG (para PartidaGUIG) eran muy
distintos. Mientras que en EstadoB disponamos de dos listas, una para las fichas del
jugador humano y otras para las fichas del ordenador, en EstadoG tenamos una matriz
rellena de objetos de tipo ObjetoMapa. Esto supona que las ideas y estructura que
habamos desarrollado para PartidaGUIB las podamos reutilizar, pero toda la
implementacin interna haba que cambiarla.
Sin embargo, ahora resultaba un poco ms fcil dibujar el mapa, ya que lo que
hacemos son dos bucles for anidados para recorrer toda la matriz que representa el
mapa, e ir dibujando el ObjetoMapa que haya en cada posicin, en caso de que exista.
Cabe destacar que en este momento fue cuando solucionamos dos problemas
importantes que venamos arrastrando desde tiempo atrs:
Al fin conseguimos dibujar los BITMAPS del tamao que nosotros queramos sin
necesidad de crearlos de un tamao especfico. Esto lo conseguimos gracias a la funcin
de la librera Allegro stretch_blit(), que dibuja un BITMAP igual que la funcin
blit() pero pudiendo especificar el tamao del ancho y el alto en donde queremos
que se ajuste la imagen. Con esto conseguimos que el alto y el ancho del tablero se
especificase desde la clase Estado, que era lo pretendamos hacer desde un principio.
Ahora ya podamos dibujar los mapas de forma genrica.

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Conseguimos solucionar tambin el problema de que los soldados tuviesen que estar en
un mapa cuadrado en vez de en uno rectangular. Ahora ya tambin podamos jugar en
tableros rectangulares.
En cuanto a las funciones que hemos necesitado, estn todas las que ya tenamos en la
clase PartidaGUIB y adems hemos aadido alguna ms, ya que ahora es necesario
tener en cuenta muchos ms aspectos:

Tenemos que dibujar ciudades y recursos, tanto del jugador humano, como los
del ordenador, y como los que no son de nadie.

Los lderes deben tener informacin acerca del nmero de soldados que tiene
cada uno. Esto lo hacemos mostrando ese nmero en la esquina superior
izquierda del dibujo de cada lder. Habamos barajado la posibilidad de que esta
informacin apareciese en un botn en el men inferior para el lder que
tuvisemos seleccionado, pero la descartamos ya que para el usuario era mucho
ms difcil ver la informacin ya que tendra que ir seleccionando todos los
lderes para ver cuantos soldados tiene cada uno.

Tenamos que representar de alguna forma un estado en el que hubiese algn

lder dentro de una ciudad. Para dibujarlo no era demasiado complicado, ya que
lo que hicimos fue dibujar el BITMAP de la ciudad o recurso, y en la esquina
superior izquierda de ste el BITMAP del lder, pero ms pequeo (esto ltimo
fue posible gracias a que habamos conseguido dibujar BITMAPS del tamao
que nosotros quisisemos). Lo realmente complicado surgi a la hora de
implementar el mtodo consigueOperador(). Cmo saber si tenamos
seleccionada una ciudad o el lder que haba dentro? Es ms, cmo saber si
dentro de una ciudad hay un lder realmente? Despus de hablar mucho sobre el
tema, llegamos a la conclusin de que lo ms lgico y eficiente era meter en un
nuevo atributo en las clases Recurso y Ciudad que guardase el Lder que haba
dentro (NULL en caso de no existir). De esta forma, al pinchar con el ratn en
una ciudad, la seleccionamos, pero sabemos si dentro hay un lder o no, y
podremos realizar las acciones oportunas. Una situacin que nos facilit bastante
las cosas es que los operadores que se pueden realizar en una ciudad son
distintos de los que puede realizar un lder (en una ciudad solo podemos comprar
lderes, mientras que un lder puede comprar soldados o desplazarse en cualquier
direccin).

Los mtodos pblicos son los mismos que en la clase PartidaGUIB (salvo que hemos
cambiado el constructor y destructor, obviamente), y en cuanto a los nuevos mtodos
privados que hemos implementado tenemos:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

void dibujaLider(lder* l,int x,int y,int tamX,int tamY). Dibuja un lder a partir
de la posicin x,y del tamao especificado. Pasamos el lder por parmetro para
poder saber cuntos soldados tiene. Decidimos separar esta funcin del resto del
cdigo para facilitar las cosas a la hora de dibujar un lder que se encontrase
dentro de una ciudad o recurso.

bool liderSeleccionado(EstadoG* estado,TTurno turno,int posX,int posY).

Devuelve cierto si en la casilla definida por posX y posY existe un lder
perteneciente al jugador definido por turno.

bool ciudadSeleccionada(EstadoG* estado,TTurno turno,int posX,int posY).

Devuelve cierto si en la casilla definida por posX y posY existe una ciudad
perteneciente al jugador definido por turno.

bool granjaSeleccionada(EstadoG* estado,TTurno turno,int posX,int posY).

Devuelve cierto si en la casilla definida por posX y posY existe un recurso
perteneciente al jugador definido por turno.

Posicion* objetoSeleccionado(EstadoG* estado,TTurno turno,int posX,int

posY). Devuelve Posicion(posX,posY) si en la casilla definida por posX y posY
existe un objeto perteneciente al jugador definido por turno. En caso contrario
devuelve Posicion(-1,-1).

bool tengoLider(EstadoG* estado,int posX,int posY). Devuelve cierto si tengo

un lder en la casilla indicada por posX y posY, aunque este dentro de una
ciudad o recurso.

Al final, la representacin de un estado general nos qued as:

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

(S, tiene mejor pinta aunque los soldados son un poco cabezones)

Vemos como se ha mejorado el aspecto del men lateral y el inferior, as como el fondo
del mapa. Tambin podemos apreciar que hay diferentes botones para mostrar
informacin, como el nmero de recursos para comprar de que dispone cada jugador, el
nmero de recursos que cada jugador posee (granjas), el tiempo que queda para acabar
la partida, o el turno del que le toca jugar.
Tambin, aunque no se ve demasiado bien en la captura de pantalla, cada lder tiene un
nmero en la esquina superior izquierda indicando el nmero de soldados que posee.
As mismo, se puede ver como queda representado el que un lder est dentro de una
ciudad.
Hablando de otro aspecto de la parte grfica, quiz un poco ms ligado con la parte
lgica, quisimos aadir la posibilidad de que el usuario introdujese su nombre para
personalizar las partidas, y que nuestro juego fuese capaz de aprender a jugar contra un
89

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

4.6.2 Estimadores de Modo Batalla

Todos los estimadores expuestos a continuacin son sobre el modo de juego "batalla".
Este modo de juego ha sido detallado en el apartado de especificacin.
NOTA: Por norma, todos los estimadores del modo de juego de "batalla" acabarn con
la palabra "batalla". Sin embargo, se omitir esta ltima palabra si por el contexto no
queda duda. Otra opcin es abreviar dicha palabra con "B.". Un convenio similar
usaremos ms adelante con los estimadores del modo de juego "general".

[Link] Estimador Fichas Batalla

Este estimador evala la partida en modo "batalla" segn el nmero de fichas (soldados)
que tiene cada jugador. Para ello, tiene en cuenta la diferencia de fichas entre uno y otro
jugador. Ese valor es dividido por el nmero de fichas totales, para mantenerse en el
rango de valores -1.0 y 1.0. De esta manera se tiene en cuenta la proporcin de fichas de
ventaja que saca un jugador a otro.

Sea
numMax = numero de fichas de MAX
numMin = numero de fichas de MIN
entonces
estimacion = (numMax-numMin) / (numMax+numMin)

En las ejecuciones hemos observado que , al tener en cuenta una proporcin de los
soldados de uno y otro jugador, el sistema que use este estimador har "cambios"
(atacar aunque luego sea atacado) cuando se encuentra en superioridad de piezas sobre
su oponente. Por el contrario, cuando se encuentra en inferioridad de piezas, evitar
estos "cambios".

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

[Link] Estimador Central Batalla

Este estimador favorece al jugador cuyas fichas estn situadas en posiciones del tablero
ms centrales. Este estimador es ms complejo que el estimador de fichas.
En este estimador, cada posicin del tablero tendr un peso, dependiendo de lo central
que est situada. La frmula que determina el peso de una casilla es la siguiente (ms
adelante hay un ejemplo):

pesoCasilla = min((min(x,n-1-x)), min(y,m-1-y))

donde
x,y es la posicin de la casilla.
n,m son las dimensiones del tablero.
Para entenderlo mejor, mostramos grficamente los pesos que tendra las casillas de un
tablero de 6x6:
0 0 0 0 0 0
0 1 1 1 1 0
0 1 2 2 1 0
0 1 2 2 1 0
0 1 1 1 1 0
0 0 0 0 0 0

Claramente, observamos que se asigna un peso mayor a las casillas cuanto ms centrales
estn.
97

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En este estimador, cada ficha de cada jugador es multiplicado el "peso" de la casilla. La

estimacin ser la diferencia de la suma de puntuaciones de cada jugador. Para que la
estimacin se encuentre en el rango -1.0 y 1.0 ser conveniente dividir el anterior valor
por el mximo posible de puntuacin.

Sea
sumaMax = sumatorio de los pesos de las casillas de la fichas de MAX
sumaMin = sumatorio de los pesos de las casillas de la fichas de MIN
entonces
estimacion = (sumaMax - sumaMin) / maximoPuntuacion

El mximo de puntuacin posible se dar en una situacin del tablero como se describe
a continuacin. El jugador con ms fichas las tiene todas localizadas en las posiciones
ms centrales (con peso mximo). Su oponente tiene todas las fichas en las posiciones
del borde (con peso igual a cero). Por tanto, esta mxima puntuacin se calcula de la
siguiente forma:

maximoPuntuacion= maximoPeso * max (numMax, numMin)

donde
maximoPeso: peso de las casillas ms centrales (en el ejemplo de tablero 6x6,
el valor sera "2").
numMax, numMin: nmero de fichas de los jugadores MAX y MIN
respectivamente.

Como conclusin, observamos que la estimacin favorecer al jugador con sus fichas
colocadas en posiciones ms centrales, y adems se mantendr siempre en el rango -1.0
y 1.0. La mquina , al usar este estimador, mover sus fichas hacia posiciones centrales.
98

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

[Link] Estimador Agresivo Arriesgado Batalla

Este estimador valorar mejor a aquellos estados en el que las fichas (soldados) de un
jugador estn cercas de sus oponentes. El sistema, cuando est guiado por este
estimador, tiende a aproximar sus fichas a las de su contrincante.
Para cada pareja de fichas, una de cada jugador, se estimar una puntuacin. Esta
puntuacin ser mayor cuanto ms cerca se encuentren las fichas. Esta puntuacin ser
la siguiente:

puntuacion(f1,f2) = (maximaDist - dist) 2

donde
f1, f2: cada una de las fichas
dist: distancia entre las dos fichas. Esto es igual a:
dist= abs(x1-x2)+abs(y1-y2)
donde
(x1,y1),(x2,y2) son las posiciones de las fichas f1,f2.
maximaDist: = distancia mxima entre dos fichas.
maximaDist = (n-1) + (m-1)
donde
n = nmero de filas
m = nmero de columnas
NOTA: En la prctica hemos tomado un valor para la mxima
distancia ligeramente superior ( n + m)

La puntuacin de cada par de fichas tiene en cuenta la distancia. Como queramos que
fuera mayor cuanto ms cerca estuviera,la distancia se encuentra multiplicada por (-1).

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Sin embargo, queremos que la puntuacin sea positiva. Por eso, le hemos sumado la
mnima constante que lo asegura. Esto es, la mxima distancia.
Adems observamos que el valor de proximidad (puntuacin) anteriormente descrito se
encuentra elevado al cuadrado. Esto rasgo lo hemos elegido para dar mayor
puntuacin cuanto ms cerca se encuentre una ficha de una ficha cercana,
independientemente que se aleje de una ficha lejana. Si usamos una puntuacin "lineal"
respecto a la distancia, sucede que las dos siguientes situaciones se valoran con la
misma suma de puntuaciones:

Estado 1 (tablero 10 x 1)
M1

Estado 2 (tablero 10 x 1)
M1 m1

donde
M1,M2: fichas del jugador MAX
m1

: ficha del jugador MIN

Efectivamente, si usamos un puntuacin "lineal", los dos anteriores estados tendran la

misma estimacin dada que la suma (puntuacin(M1,m1) + puntuacin(M2,m1))
permanecera constante. Sin embargo, si usamos un peso "cuadratico", el "Estado 2"
tiene una estimacin mayor. Como conclusin observamos que el sistema que use una
puntuacin "cuadrtica" tiende a acercar la ficha "m1" a la ficha rival M1, esto es la
ficha rival ms cercana. Por el contrario, usando la puntuacin "lineal", no ocurre lo
mismo. Es por esto por lo que hemos escogido la puntuacin "cuadrtica".

100

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

La estimacin considera el sumatorio del peso para cada par de fichas. Adems es
dividido por la mxima puntuacin para ser un valor comprendido entre -1.0 y 1.0. Por
ltimo, es importante destacar que, para que tanto el jugador MAX como el jugador
MIN lo consideren una cualidad "buena", es necesario determinar el signo segn
el jugador que est haciendo la estimacin.

estimacion = + suma / maximaPunt

si la estimacin la hace MAX

- suma / maximaPunt

si la estimacin la hace MIN.

donde
suma = cada ficha

fi de MAX

cada ficha fj de MIN peso (fi, fj) (sumatorio)

maximaPunt = numMax * numMin * maximaDist (mxima puntuacin)

donde
numMax : nmero de fichas de MAX
numMin : nmero de fichas de MIN
maximaDist: la mxima distancia posible entre dos fichas (igual que en la
definicin de peso)

El estimador ha sido nombrado "arriesgado" ya que busca estar cerca de su oponente,

sin tener en cuenta que pueda ser atacado por el mismo. En cierta forma, se puede decir
que se "arriesga". Este problema es tenido en cuenta en el siguiente estimador.

Este factor de "arriesgarse" que produce este estimador, permite que dos jugadores
dirigidos por el sistema, se arriesguen de vez en cuando, permitiendo que se produzcan
prdidas por ambos bandos de manera natural. Cuando no se usa este estimador, en la
mayora de partidas, los jugadores dirigidos por la mquina, suelen tomar una actitud
ms "precavida". De esta forma, no se producen apenas prdidas por ninguno de los dos
bandos, y las partidas se suelen acabar por consumicin del tiempo. Por tanto, podra
101

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

decirse que este estimador sirve de "catalizador" en partidas mquina contra mquina.
En qumica, se llama "catalizador" a la sustancia que permite o provoca que se de una
reaccin qumica entre varias sustancias. En partidas de mquina contra humano, este
estimador permite que la mquina posea ciertos rasgos "humanos", al decidir
arriesgarse.

[Link] Estimador Agresivo Batalla

Este estimador buscar estar cerca de su oponente, pero adems dar mucha ms
importancia a tener ms fichas que su oponente. En realidad, este estimador
perfeccionar la tcnica "agresiva" o atacante del anterior estimador. No slo se
colocar cerca de su oponente, sino que adems no depende de la combinacin con
otros estimadores para atacar cuando ya est lo suficientemente cerca.
Este estimador tiene en cuenta los posibles ataques y la repercusin del cambio del
nmero de fichas. De esta manera, con este estimador, se favorece el ataque directo en
caso de ser posible. Tambin considera los posibles ataques del oponente. Por tanto,
tomar una actitud ms "prudente" o "precavida", a la hora de acercarse en su ltimo
paso.
Por tanto, la estimacin se produce por la combinacin de dos estimaciones, que ya han
sido detalladas anteriormente.

estimacion = ratio * estimFichas + (1-ratio)*estimAgresArr

donde
estimFich : similar a estimacin del estimador "Fichas"
estimAgresArr : similar a estimacin del estimador "Agresivo Arriesgado"
ratio : proporcin de combinacin (hemos usado 0.9)

En realidad, esta tarea de combinacin de estimaciones y eleccin del peso es ms

propia de la PE. Sin embargo, dado que este estimacin engloba un nico
comportamiento en s misma (comportamiento atacante) , hemos decidido mantenerla
para un nico estimador. Como ms adelante veremos, en la validacin, el nmero de
estimadores para el que se puede aprender pesos de manera razonable est limitado por
102

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

el tiempo de entrenamiento del que dispongamos. Por ello, hemos decidido realizar esta
combinacin en un nico estimador, y dejar al Algoritmo Evolutivo "tomar decisiones"
(elegir pesos) de ms "alto nivel".

[Link] Estimador Acorralar Batalla

Este estimador favorecer al jugador que acorrale a las fichas del rival (normalmente en
una esquina). De esta forma se consigue privar de tanta libertad de movimientos al
jugador rival y forzarle a llegar a una situacin en la cual, al mover una ficha, no le
quede ms remedio que situarse junto a una ficha rival y exponerse a que le ataquen.
Un ejemplo de esta situacin sera el siguiente:

B
A

Si el jugador B consiguiese dejar al jugador A en esa posicin, ahora cualquier

movimiento de A le llevara a perder su ficha, ya que al moverla quedara situado junto
a B y ste podra atacarle.

103

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Para conseguir un estimador que haga esto, hemos empleado una tcnica de abarcar el
mapa. Para ello, creamos un mapa del mismo tamao que el original, pero vaco, y a
cada casilla se la asignamos a uno u otro jugador dependiendo de quin est ms cerca
de ella (segn la distancia de Manhatan).
Para ver como sera uno de estos mapas, mostramos un ejemplo sencillo en el cual solo
hay una ficha de cada jugador. Las casillas en subrayadas son las posiciones donde
realmente estn las fichas, mientras que las marcadas en cursiva son las que nosotros
hemos asignado a uno u otro jugador. En caso de que una casilla est a la misma
distancia de ambos jugadores, se marcara con una N indicando que no es de nadie.

A A A A N

A A A N B

B
N N N B

N N N B B

En la situacin anterior vemos como A tiene ventaja sobre B, ya que posee mas casillas
marcadas como suyas. Para calcular la puntuacin de cada jugador y devolver un valor
entre 1.0 y 1.0 empleamos la siguiente frmula:
casillasMAX-casillasMIN)/casillasTotales

De este modo, ser ventajoso que un jugador tenga ms casillas marcadas como suyas
que el jugador contrario, y tender a acercarse a l y a dejarle en una esquina, ya que de
104

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

esa forma consigue marcar el mayor nmero de posible de casillas. As conseguiramos

dejar al rival en la posicin mostrada en el primer tablero.

4.6.3 Estimadores de Modo General

Todos los estimadores expuestos a continuacin son sobre el modo de juego "general".
Este modo de juego ha sido detallado en el apartado de especificacin.

[Link] Estimador Nmero de Lideres General

Este estimador favorece al jugador que tiene mayor nmero de lideres. En el modo
"general", cada lder representa una ficha con capacidad de movimiento.

Para favorecer al jugador con ms lideres, se tiene en cuenta la diferencia de lderes

entre uno y otro jugador. Ese valor es dividido por el nmero total de lderes, para
mantenerse en el rango de valores -1.0 y 1.0. De esta manera se tiene en cuenta la
proporcin de lderes de ventaja que saca un jugador a otro.

Sea
lideresMax = numero de lderes de MAX
lideresMin = numero de lderes de MIN
entonces
estimacion = (lderesMax-lderesMin) / (lderesMax+lderesMin)

[Link] Estimador Recursos Apropiados General

Este estimador favorece al jugador que tiene mayor nmero de recursos apropiados. En
el modo general, los recursos apropiados (almacenes) determina qu nmero de recursos
105

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

en bruto (por ejemplo, alimento) se incrementa cada turno a cada jugador. La situacin
ser ms favorable, cuanto ms recursos apropiados se tenga
Para ello, se tiene en cuenta la diferencia de recursos apropiados entre uno y otro
jugador. Ese valor es dividido por el nmero total de recursos apropiados, para
mantenerse en el rango de valores -1.0 y 1.0. De esta manera, se tiene en cuenta la
proporcin de recursos apropiados de ventaja que saca un jugador a otro.

Sea
recMax = numero de recursos apropiados de MAX
recMin = numero de recursos apropiados de MIN
entonces
estimacion = (recMax-recMin) / (recMax+recMin)

[Link] Estimador Ciudades Apropiadas General

Este estimador favorecer al jugador que tenga mayor nmero de ciudades apropiadas.
En el modo general, en las ciudades que el jugador posea podr crear nuevos lderes, lo
cual favorecer su situacin.
Para ello, se tiene en cuenta la diferencia de ciudades apropiadas entre uno y otro
jugador. Ese valor es dividido por el nmero total de ciudades apropiadas, para
mantenerse en el rango de valores -1.0 y 1.0. De esta manera, se tiene en cuenta la
proporcin de ciudades apropiadas de ventaja que saca un jugador a otro.

Sea
ciudMax = numero de ciudades apropiadas de MAX
ciudMin = numero de ciudades apropiadas de MIN
entonces
estimacion = (ciudMax-ciudMin) / (ciudMax+ciudMin)
106

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

[Link] Estimador Nmero de Soldados General

Para entender bien este estimador, quizs sea necesario recordar que ste es aplicado en
el modo "general". En este modo, las unidades con capacidad de movimiento o fichas
son los lderes. Cada lder a su vez tiene un nmero de soldados.
Teniendo clara la diferencia entre lderes y soldados de cada lder, ya podemos
comprender que este estimador calcula la proporcin de soldados de un jugador frente a
otro. Adems se considera que cada lder por si slo tiene el valor de un soldado. Por
tanto, la estimacin sera la siguiente:

Sea
solMax = nmero de soldados de MAX, contando cada lder como un soldado
solMin = nmero de soldados de MIN , contando cada lder como un soldado
entonces
estimacin = (solMax - solMin)/(solMax + solMin)

[Link] Estimador Prximo Recursos General

Este estimador valora en favor de aquel jugador que tiene los lideres ms prximos a los
recursos. Por tanto, un sistema que use este estimador tiende a acercar sus lideres hacia
los recursos, sin ser necesario un rbol de bsqueda de gran profundidad. Como un
estado simplemente mejora su calidad para un jugador si ste mueve uno de sus lderes
hacia un recurso, el sistema en cada paso tiende a mover el lder hacia el recurso ms
cercano.
El algoritmo, que seguiremos en este caso para calcular la estimacin, es el siguiente.

para cada recurso R hacer

fMax <- ficha ms acercada de MAX a R

107

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

puntMax <- punt( R, fMax)

suma <- suma + puntMax
fMin <- ficha ms acercada de MIN a R
puntMax <- punt( R, fMin)
suma <- suma - puntMax
fin para
estimacion <- suma / maximaPunt

donde
punt: puntuacin.
punt (R, f) = (maximaDist - dist) 2
donde
R: recurso,
f: ficha
dist: distancia entre la ficha y el recurso (el clculo es similar a
otras distancias explicadas anteriormente).
maximaDist: = distancia mxima entre dos casillas cualquiera
(la misma que la definida en el estimador "Agresivo
Arriesgado Batalla").
maximaPunt: mxima puntuacin
maximaPunt = numRec * max(numMax, numMin)
donde
numRec: nmero de recursos del mapa
108

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

numMax: nmero de fichas (lderes) de MAX

numMin: nmero de fichas (lderes) de MIN

Como primera observacin, la variable "suma" del algoritmo almacena el sumatorio de

puntuaciones para MAX menos el sumatorio de puntuaciones para MIN, lo que
favorece a uno u otro jugador dependiendo de la posicin relativa de sus lderes respecto
a los recursos:

suma = puntuaciones para MAX - puntuaciones para MIN

En el peso de cada par de fichas est en funcin de la distancia. Como queramos que la
puntuacin fuera mayor cuanto ms cerca estuviera (distancia menor), la distancia se
encuentra multiplicada por (-1) . Sin embargo, queremos que el peso sea positivo,
por eso le hemos sumado la mnima constante que lo asegura. Esto es, la mxima
distancia.
Adems observamos que el valor de proximidad (puntuacin) anteriormente descrito se
encuentra elevado al cuadrado. Esto lo hemos escogido para dar mayor puntuacin
cuanto ms cerca se encuentre a un recurso cercano, independientemente de que se aleje
de un recurso lejano. Si usamos un peso "lineal", no elevado al cuadrado, sucede que las
dos siguientes situaciones se valoran con la misma puntuacin:

Estado 1 (tablero 10 x 1)
R1

Estado 2 (tablero 10 x 1)

109

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

R1 m1

donde
R1,R2: recursos
m1

: ficha de un jugador

punt: puntuacin.
punt (lider1, lider2) = (maximaDist - dist) 2
donde
dist: distancia entre los dos lderes (el clculo es similar a
otras distancias explicadas anteriormente).
maximaDist: = distancia mxima entre dos casillas cualquiera (
suma del nmero de filas y nmero de columnas ).
maximaPunt: mxima puntuacin
maximaPunt = numMax*numMin*maximaDist

(mxima puntuacin)

donde
numMax: nmero de fichas (lderes) de MAX
numMin: nmero de fichas (lderes) de MIN

Como primera observacin, la variable "sumaMax" y "sumaMin" llevan la puntuacin

de cada jugador.
Para cada par de lderes, uno de cada jugador, se estimar una puntuacin (variable
"punt") segn la proximidad de cada lder. Este puntuacin ser asignada o sumada al
jugador propietario del lder ms "fuerte" (con mayor nmero de soldados). En caso de
que ambos lderes sean igual de "fuertes" , la puntuacin ser asignada al jugador que
est haciendo la estimacin. De esta manera, el sistema que use este estimador tiende
tambin a mover sus lderes hacia otros lderes rivales de igual "fuerza".
De nuevo, al igual que otros estimadores mencionados anteriormente, la puntuacin
para cada par de lderes depende "cuadrticamente" de la distancia, dando ms
importancia a las parejas de lderes que se encuentran prximos, frente a los que se
encuentran lejanos.
Adems, cabe recordar que la estimacin se divide entre el mximo de puntuacin
posible, para proporcionar un valor comprendido entre -1.0 y 1.0 .

113

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Por ltimo, mencionamos que el resultado de ejecutar partidas mquina contra mquina
con este estimador en exclusiva, provoca el efecto de que los lderes se persiguen unos a
otros. Cada lder fuerte intenta acercarse a un lder dbil rival, y cada lder dbil huye
del lder fuerte del rival ms cercano.

[Link] Estimador Acorralar General

Estimador que da mejor puntuacin al jugador que tenga acorralados a los lderes del
rival. Este estimador es similar al estimador acorralar explicado en el modo batalla, con
lo que aquella explicacin sirve tambin para este.

4.7 Lenguaje
usadas

Herramientas

Hemos usado C++, dado que el resultado segn las herramientas existentes es que la
ejecucin de sus programas son de las ms eficientes, necesarios para procesos costosos
como pueden ser los utilizados en Programacin Evolutiva. De hecho, C++ es el
lenguaje estndar para la creacin de grandes proyectos, entre los que podemos incluir
los videojuegos de un determinado tamao.
En concreto hemos usado Dev C++ como entorno de desarrollo junto con la librera
"Allegro". Esta decisin ya ha sido explicada en el apartado de diseo de la parte
grfica.

114

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

4.8 Problemas usando Dev-C++

A lo largo de la realizacin de todo el proyecto, nos hemos ido encontrando con varios
problemas con esta herramienta. Unos fueron fciles de solucionar, pero otros
requirieron muchos esfuerzos, a la vez que nos tuvimos que leer prcticamente todos los
foros que existen en Internet acerca de Dev-C++.

Al crear las primeras pruebas, que eran mdulos sueltos, todo iba bien, pero a la
hora de crear el primer proyecto empezaron a surgir los problemas. Para que
funcionase la librera Allegro, tenamos que introducir unos parmetros de
configuracin en las opciones del compilador. En principio esto era lo nico
necesario para que todo funcionase, pero al crear un proyecto y haber
dependencias entre varias clases situadas en diferentes archivos, nos surgi
nuestro primer Linker error. Como en todos los problemas que tuvimos con esta
herramienta, buscamos posibles soluciones en foros de Internet.
Una observacin importante para el correcto funcionamiento es que los archivos
de cabecera .h de las clases requieren:
#ifndef xxxxx_H
#define xxxxx_H

//cuerpo de la cabecera

#endif
Al no ponerlas, existan conflictos ya que existan mltiples declaraciones de
una misma clase, siempre que fuese incluida desde dos o ms clases externas.

Despus de solucionar el problema de las cabeceras de las clases explicado en el

primer punto, todava seguamos teniendo errores de linkado. Otra vez buscamos
en Internet y, despus de probar todas las sugerencias que encontramos,
llegamos a la conclusin de que era necesario aadir una librera exclusiva de
Allegro a las opciones del proyecto que queramos compilar, ya que sino no
funcionaba.
115

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Al fin habamos conseguido eliminar los linker error, pero nuestros problemas
no haban acabado. Ahora nos apareca un Build error, que supusimos que era
producido ya en el ltimo paso de la compilacin, al crear el fichero ejecutable.
De nuevo vuelta a los foros de Internet y a los manuales que encontrbamos en
la red. Y de nuevo, acabamos descubriendo que para solucionar el error
tenamos que cambiar un parmetro en las opciones del compilador de DevC++. En vez de generar los ejecutables con un archivo llamado [Link],
debamos generarlos con otro llamado [Link].

Para trabajar el los laboratorios de la facultad, disponamos de laboratorios que

tenan instalado Dev-C++, pero no la librera Allegro. Al no disponer de
permisos de instalacin tuvimos que idear nuestros propios truquillos para
poder fijar las variables de entorno necesarias y ejecutar una versin de DevC++ que tenamos nosotros con Allegro ya incluido, desde el directorio de local,
que es la nica carpeta donde podemos copiar archivos. Para conseguir todo esto
tuvimos que crear unos scripts especiales.

Todava, de vez en cuando, nos volva a surgir algn linker error o build error
sin que tuviese ningn motivo aparente. Investigbamos a ver si se nos haba
olvidado alguna opcin del compilador o del proyecto, pero todo estaba bien. En
este tipo de situaciones, lo que hacamos era recurrir a una versin anterior del
proyecto y volver a rehacer lo que hubisemos hecho nuevo. Debido a esto,
crebamos nuevas versiones cada muy poco tiempo, para no perder demasiada
parte del trabajo, y es por ello por lo que al final acabamos teniendo ms de 150
versiones distintas.

A la hora de usar el depurador que traa incorporado Dev-C++ (estaba bien

hecho, no tenemos ninguna queja en su contra), tenamos el problema de que
una vez que inicializbamos Allegro no podamos usarlo porque el compilador
no lo aceptaba. Con lo que depurar la parte grfica fue bastante complicado, y
tuvimos que recurrir a funciones que mostraban mensajes por pantalla (de hecho,
hasta creamos un mdulo llamado Mensajes.h para tal funcin).

A veces, al modificar las cabeceras de las clases (los archivos .h), Dev-C++ no
los recompilaba si no habas cambiado el correspondiente .CPP. Debido a esto, a
veces realizbamos cambios en el cdigo que en principio no daban errores, pero
que ms tarde s que se mostraban, llevando a confusiones ya que creamos que
el error estaba en lo ltimo que habamos cambiado, cuando no tena por que ser
as. Al final, cuando nos dimos cuenta de que esto suceda as, lo que hacamos
era recompilar todo el proyecto cada vez que cambibamos un archivo de
cabecera.

116

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5. Validacin y
Resultados
Obtenidos
En este apartado, exponemos los resultados de nuestro proyecto lo ms objetivamente
posible, de manera que puede ser til por futuros trabajos que tengan relacin con el
tema que se aborda en nuestro proyecto.
La parte principal de nuestro proyecto es la incorporacin de la Programacin Evolutiva
(PE) a los juegos de estrategia. Por este motivo, hemos dedicado parte de nuestros
esfuerzos a determinar en qu medida la PE aade un factor de aprendizaje. Si bien es
cierto que nuestro proyecto incluye informacin "experta" o heurstica (estimadores);
tambin es cierto que la manera de combinar estos distintos estimadores se deja en
mano de la PE.
En las sucesivas pruebas expuestas, simulamos partidas completas (con modo "batalla"
y modo "general" entrelazado) entre dos jugadores dirigidos por el sistema (mquina).
Ambos jugadores usan exactamente el mismo conjunto de estimadores. El primero de
ellos usa unos pesos de ponderacin para los estimadores obtenidos como fruto de un
aprendizaje por PE. Sin embargo, el segundo individuo usa unos pesos aleatorios de
ponderacin. De esta forma, sabemos cual es la calidad del aprendizaje llevado a cabo
por la PE.
En las ltimas pruebas, para validar el aprendizaje individualizado, usaremos otro
mtodo que explicaremos posteriormente.
NOTA: En lo sucesivo nos referiremos con las palabras "PE" y "aleatorio" para
determinar los jugadores con pesos calculados por PE y pesos aleatorios
respectivamente.
En todas las pruebas sucesivas ganar el jugador que, en conjunto, tenga ms lderes y
soldados cuando se acabe la partida. Una partida podr finalizar porque algn jugador se
quede sin lderes o por tiempo.

117

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.1 Mejor Prueba o Resultado

(prueba 1)
Primero, mostramos la prueba con la mejor combinacin de valores de los parmetros.
Ms adelante, intentamos dar una explicacin de por qu esos valores son mejores que
otros.
Las caractersticas usadas en esta primera prueba expuesta son:

Carctersticas

Modo "General"

Modo "Batalla"

Estimadores

- Nmero de Soldados

- Nmero de Fichas

- Prximo a Recursos

- Agresivo Arriesgado

- Agresivo
Tamao del tablero en la
partida.

8x6

Tamao del tablero en el

entrenamiento.

5x4

8x6

Tiempo Lmite en la partida 200 movimientos

100 movimientos

Tiempo Lmite en el
entrenamiento.

100 movimientos

118

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Los parmetros propios de la PE son:

Parmetros

Modo "General"

Modo "Batalla"

tamao de la poblacin

probabilidad de cruce

0.5

probabilidad de mutacin

0.1

0.3

periodo de mutacin

(cada cuantos ciclos se

hace la mutacin)
nmero de generaciones

Las prueba se hizo sobre un conjunto de 14 partidas y los resultados fueron:

Ganadas por "PE"

Empatadas

Ganadas por "Aleatorio"

119

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Prueba 1

Ganadas por PE
Empatadas
Ganadas por Aleatorio

Como observamos, el jugador entrenado por PE gan el 100% de las partidas. Estos
resultados son ms que favorables.
Las partidas de las pruebas eran visualizadas, lo que nos permita observar los diferentes
matices de cada partida.
NOTA: Los apartados siguientes, cuyo nmero empieza por 5.1 son referentes a esta
primera prueba, prueba 1. Cuando cambiemos a otra prueba lo diremos
explcitamente. Tambin es cierto que los comentarios sobre los parmetros de la
prueba 1, nos introducirn al resto de las pruebas.

5.1.1 Variedad de las partidas

En primer lugar, cabe destacar que las partidas se desarrollaban de manera totalmente
diferentes:

- En algunas partidas, el "jugador PE", tomaba una estrategia agresiva, e

eliminaba a su oponente en pocas jugadas;

120

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

- En otras, el "jugador PE" segua una estrategia ms conservadora,

apropindose de casi todos los recursos del mapa( o todos , dependiendo la
partida), pudiendo as aumentar su nmero de lideres y soldados a mayor
velocidad que su oponente y ganarle por tiempo.

Cabe destacar que, aunque las partidas se puedan clasificar en esas estrategias, la
secuencia de movimientos de una a otra partida, dentro de una misma categora, eran
tambin diferentes.
Como categoras se han expuesto los dos extremos, aunque en realidad se podra decir
que ,en cada caso, usaba una estrategia peculiar, en un punto intermedio de cada uno de
los dos extremos.
A continuacin mostramos dos ejemplos:

Ejemplo 1 de ejecucin de la prueba 1

121

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

El jugador PE es representadas por el jugador con color rojo, mientras que el jugador
gris o azul es el jugador aleatorio. Observamos que el individuo "PE" tiene
apropiados tres de los cuatro recursos disponibles en el mapa. Adems se ve cmo los
recursos apropiados por "PE" estn siendo custodiados (en cada "almacen", se puede
observar si hay un lder, fijndonos en la parte superior izquierda de dicho "almacen)
cada uno de ellos por un lder fuerte (con el mximo nmero de soldados, 12). Al tener
ms recursos apropiados, ha podido comprar lderes y soldados ms rpido que su
oponente. Ha ganado por tiempo (si el tiempo se excede gana aqul que tenga mayor
suma de lderes y soldados). En este ejemplo, se puede decir que la "PE" ha seguido una
estrategia conservadora.

122

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Ejemplo 2 de ejecucin de la prueba 1

En este otro ejemplo, el jugador PE" ha ganado eliminando a todos los lderes de su
oponente. Obsrvese que no hay ningn lder del jugador aleatorio" (color gris). Se
sigue el mismo convenio de colores que para el anterior ejemplo. Se puede decir que en
esta partida "PE" ha seguido una estrategia ms agresiva.

Tambin cabe decir que, probablemente, la variedad de finales de partida, proviene en

gran medida de las diferentes formas de jugar tanto del "jugador PE" como del jugador
aleatorio". Recordemos una vez ms que las dos anteriores ejecuciones usan los mismos
estimadores, ya que pertenecen a la misma prueba, la prueba 1. Lo que vara son los
pesos que se dan a estos estimadores.

123

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.1.2 El modo "general" es ms decisivo

Al observar, las partidas de la prueba 1, hemos podido ver cmo la PE es ms eficaz en
juegos complejos. Me explico; si bien todas las partidas completas(modo general +
modo batalla) eran ganadas por PE; sin embargo, dentro del modo general, haba
batallas entre lderes, en las que el resultado no era tan favorable para el jugador PE.
Cmo los pesos son recalculados por cada individuo, cada vez que se inicia una nueva
batalla dentro del modo general, en media, PE ganaba ms batallas y siempre ganaba
la partida general.

NOTA: Hemos hecho pruebas cambiando los estimadores del modo batalla, y hemos
llegado a la anterior conclusin. Sin embargo, hemos preferido centrarnos en este
documento a las pruebas que tienen en cuenta el modo general.

De este hecho, deducimos dos conclusiones:

- Es mucho ms decisivo, que un contrincante juegue bien en modo "general", ya

que batallas hay muchas, y en realidad son ms simples, y fciles de forzar un
empate, por ejemplo.

- El entrenamiento por PE acta mejor en juegos ms complejos, como por

ejemplo el modo "general", en el que hay recursos y ciudades, y en el que los
lderes tiene ms o menos fuerza segn su numero de soldados y donde se
pueden comprar nuevos lideres o soldados. Por contrario, el modo "batalla" es
ms simple, slo se pueden mover los soldados.

A continuacin haremos ciertos comentarios acerca de la influencia de los distintos

parmetros y caractersticas.

124

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.1.3 Tamaos del Tablero

Recordamos que los tamaos de tablero usado son:

Carctersticas

Modo "General"

Modo "Batalla"

Tamao del tablero en la

partida.

8x6

Tamao del tablero en el

entrenamiento.

5x4

8x6

Despus de las pruebas hechas, hemos observado que lo ms favorable, para un buen
entrenamiento, es que el tamao del tablero usado para el entrenamiento sea idntico al
tamao del tablero de las partidas reales. Sin embargo, por motivos de eficiencia, esto
no es siempre posible, en cuyo caso lo ms aconsejable es usar tamaos de tablero lo
ms parecido posible al tamao real.

En nuestro caso, el tamao de tablero en modo "batalla" se ha podido usar el mismo que
el tamao del tablero de entrenamiento. Esto se debe a que el modo "batalla" es un
juego simple y tiene un factor de ramificacin (nmero de jugadas posibles en cada
turno) bajo.

Por lo contrario, el juego en modo "general" es ms complejo y tiene un factor de

ramificacin ms alto, y adems el factor de ramificacin tiende a crecer segn avanza
la partida. Es normal que segn avanza la partida, cada vez hay ms lderes y por tanto
125

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

ms posibilidades y mayor factor de ramificacin. Es lo contrario que lo que ocurre en

el modo "batalla", en el que el nmero de soldados disminuye debido a los ataques de
uno u otro contrincante. Por todo esto, hemos observado empricamente, que el tiempo
necesario para entrenarse en modo general en un tablero de 8 x 6 (tamao real), con
los mismos valores para el resto de parmetros, era inabordable. Hemos usado tableros
ms reducidos para el entrenamiento, aunque no tan diferente (5 x 4).

Obsrvese los dos tamaos posibles para una partida en modo "general"

Tablero 8 x 6 de la partida real:

126

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Tablero 5 x 4 usado para el entrenamiento:

Se observan las casillas ms grandes, ya que hay menos casillas (slo 5 x 4).

5.1.4 Nmero de Movimientos Lmite

El tiempo lmite es mayor en las partidas de las pruebas de validacin que en las
partidas de entrenamiento. Esto se debe a que las partidas de las partidas de validacin
simulan partidas reales; mientras que las partidas de entrenamiento se interesa que sean
cortas por motivos de eficiencia.
127

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.1.5 Los Parmetros propios de PE

Brevemente, recordamos los parmetros usados en esta prueba 1:

Parmetros

Modo "General"

Modo "Batalla"

Tamao de la poblacin

probabilidad de cruce

0.5

probabilidad de mutacin

0.1

0.3

periodo de mutacin

(cada cuantos ciclos se hace

la mutacin)
Nmero de generaciones

En general, observamos unos valores relativamente pequeos de tamao de

poblacin. Una poblacin de slo tres individuos (nmero de vectores de pesos, no
confundir con nmero de estimadores) es una poblacin bastante pequea comparada
con la que suele usar en otros problemas resueltos por PE. Esto se debe a que para
calcular la aptitud o calidad de los individuos realizamos un torneo de todos contra
todos. A su vez simular cada partida, tiene un coste alto. Por motivos de eficiencia,
hemos usado este valor tan pequeo.
Lo mismo ocurre con el nmero de generaciones. Tambin es bastante pequeo, pero
aun as hemos obtenido buenos resultados.
La probabilidad de mutacin en el modo "Batalla" es bastante alta a lo que
acostumbramos a ver en otros problemas resueltos por PE. Este valor, es ms grande
que de costumbres, ya que el tamao de la poblacin y el nmero de generaciones para
128

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

ese modo son muy pequeos, y si no, la probabilidad de que ocurriera al menos una
mutacin en todo el algoritmo evolutivo era baja. En realidad, este valor poco usual ni
mejora ni empeora considerablemente los resultados. Recordemos una vez ms que en
este documento nos hemos centrado en la validacin del modo general.

5.1.6 Tiempos de Entrenamiento

Los entrenamientos de las pruebas de tres estimadores duraban aproximadamente de
unos 7 a 8 segundos

NOTA: Brevemente, recalcamos que en estas pruebas se juegan partidas completas, es

decir, que tienen entrelazada el modo "general" y el modo "batalla"; y que los resultados
de uno interfiere en otro, y viceversa, segn se determin en la especificacin. Sin
embargo, el entrenamiento, por PE, se realiza por separado para cada uno de los dos
modos de juego. Esto entrenamiento por separado se hace por motivos de eficiencia.
Adems el entrenamiento es ms efectivo.

5.1.7 Los Estimadores

Una de las cosas ms importante a remarcar, es que la calidad del entrenamiento
depende muchsimo de los estimadores que se usen.

- En primer lugar, la calidad del entrenamiento depende del nmero de

estimadores que se usen.
- En segundo lugar, la calidad del entrenamiento depende de la
combinacin de estimadores que se use.
Las anteriores afirmaciones las demostraremos en las siguientes pruebas.

129

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.2 Otras Pruebas

Estimadores

de Tres

En concreto , en estas pruebas haremos hincapi que, incluso manteniendo constante el

nmero de estimadores, depender mucho en el resultado de las pruebas, qu
estimadores usemos.

Mantendremos los mismos parmetros. Lo nico que cambiaremos son qu estimadores

usar, aunque mantendremos el nmero de estimadores. Los resultados son:

5.2.1 Prueba 2
Mostramos los estimadores usados:

Carctersticas

Modo "General"

Modo "Batalla"

Estimadores

- Prximo Recursos

- Nmero de Fichas

- Agresivo Inteligente

- Acorralar

- Agresivo

Los resultados hechos sobre 10 partidas fueron:

130

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Ganadas por PE

Empatadas

Ganadas por Aleatorio

Prueba 2 (otros tres estimadores)

Ganadas por PE
Empatadas
Ganadas por Aleatorio

Observamos que en esta prueba el porcentaje de victorias del jugador "PE" son
menor(60%), aunque tambin es cierto que hay bastantes empates (30%), y casi
ninguna prdida del jugador "PE".

Probablemente, esto se deba a que los estimadores usados no son tan diferentes
como los usados en la "prueba 1". En este caso los estimadores "Agresivo
General" y "Agresivo Inteligente General" se parecen, y el hecho de dar ms peso
a uno a otro no influye tanto en la manera de jugar. Por ello, la PE tiene menos
variedad donde elegir, y por tanto donde poder aprender.

131

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.2.2 Prueba 3
Mostramos los estimadores usados

Carctersticas

Modo "General"

Modo "Batalla"

Estimadores

- Nmero de Lderes

- Nmero de Fichas

- Prximo Recursos

- Acorralar

- Agresivo

Los resultados de entre cinco partidas son:

Ganadas por PE

Empatadas

Ganadas por Aleatorio

132

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Prueba 3 (otros tres estimadores)

Ganadas por PE
Empatadas
Ganadas por Aleatorio

Lo destacable de esta prueba es que todas las partidas acaban en empates (40%) o
victorias del jugador PE" (60%).

En realidad, el nico cambio frente a los estimadores del modo "general" escogidos en
la "prueba 1" (100% de victorias) ha sido el cambio del estimador "Nmero de Soldados
G. " por el estimador "Nmero de Lderes G." Este cambio ha producido que un 40% de
las victorias pasen a ser empates. Esto es razonable, si tenemos en cuenta que el
estimador "Nmero de Soldados" es ms "completo" que el estimador "Nmero
Lderes", ya que "Nmero de Soldados" cuenta el nmero de soldados y de lderes.
Cada lder por si slo cuenta como un soldado en este ltimo estimador (vase el
apartado de estimadores). Por tanto, al ser "Nmero de Soldados" (usado en Prueba 1)
ms completo, la PE dispona de una "herramienta" (estimador) ms potente a su
disposicin y por eso los resultados fueron mejores.

NOTA: Ahora y en adelante, nos fijaremos en los estimadores usados en el modo

"general", prescindiendo de los comentarios acerca de los de modo "batalla", debido a
que es el modo "general" el ms "decisivo", como hemos ya mencionado anteriormente.
En ocasiones mostramos los estimadores usados en el modo batalla, pero
simplemente como un dato ms sin centrarnos en l.

133

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.3 Pruebas con Diferentes

Nmeros de Estimadores.
En esta pruebas intentamos destacar que el nmero de estimadores usados para el
entrenamiento es decisivo. En concreto, debemos tener en cuenta que los individuos de
la poblacin del Algoritmo Evolutivo son vectores de "pesos". Por tanto, el espacio de
bsqueda tendr una dimensin igual al nmero de estimadores. Hasta ahora, las
pruebas han sido hecho con tres estimadores, luego el espacio de bsqueda era
tridimensional. Para entenderlo bien exponemos los siguientes ejemplos.

* dos dimensiones: Encontrar un punto en un cuadrado (dimensin plana)

* tres dimensiones : encontrar un punto en un cubo (dimensin espacial)
* cuatro dimensiones: encontrar un punto en un cubo en un instante de tiempo
(dimensin espacial con tiempo).
* ... y as, que se imagine el lector para ms dimensiones.

Con los anteriores ejemplos, intentamos mostrar cmo de "rpido" crece el espacio de
bsqueda, segn crece el nmero de dimensiones. Concretamente, este crecimiento
tiene orden "exponencial".

5.3.1 Seis Estimadores (Prueba 4)

Para entender este concepto, si mantenemos el mismo tamao de poblacin y mismo
nmero de generaciones que en la "prueba 1", e intentamos que el aprendizaje se
produzca, sobre un nmero de estimadores mayor ( por ejemplo seis) el aprendizaje es
nulo o prcticamente nulo. A continuacin mostramos los estimadores usados:

134

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Carctersticas

Modo "General"

Modo "Batalla"

Estimadores

- Nmero de Soldados

- Nmero de Fichas

- Prximo Recursos

- Agresivo Arriesgado

- Agresivo
- Prximo Ciudades
- Agresivo Inteligente
- Acorralar

De siete partidas jugadas los resultados fueron:

Ganadas por PE

Empatadas

Ganadas por Aleatorio

135

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Prueba 4 (seis estimadores)

Ganadas por PE
Empatadas
Ganadas por Aleatorio

En este ejemplo, en concreto, el aprendizaje se podra decir que es nulo o prcticamente

nulo, dado que el porcentaje de victorias del jugador "aleatorio" es igual al porcentaje
por el jugador por "PE".
Sin embargo, estos resultados probablemente se podran mejorar si cambiamos los
parmetros propios del algoritmo evolutivo, tales como el tamao de la poblacin y
el nmero de recursos. Al aumentar estos parmetros, tambin aumentara
considerablemente el tiempo de entrenamiento. Dado que el espacio de bsqueda
crece de forma exponencial en cuanto al nmero de estimadores, y dado que con tres
estimadores se necesitaban unos siete u ocho segundos, puede que este entrenamiento
durara del orden de das o semanas, para obtener resultados aceptables. En realidad la
estimacin del tiempo necesario es muy difcil de hacer, con los datos de los que
disponemos . Lo que si podemos asegurar es que el entrenamiento no se podra hacer al
empezar cada partida como lo hemos hecho hasta ahora.

136

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.3.2 Dos Estimadores (Prueba 5)

Tambin es curioso plantearse que ocurre si reducimos aun ms el nmero de
estimadores. Por ejemplo, si introducimos dos estimadores, la variedad de estrategias ya
es menor.
De nuevo, el aprendizaje depende los estimadores que elijamos. Se puede obtener muy
buenos resultados si se usa un ejemplo de juguete. Al principio de nuestras pruebas
del modo batalla, usamos dos estimadores "Nmero de Fichas", y "Nmero de Fichas
Malo". El segundo estimador, favoreca justo al jugador que tuviera menos fichas, justo
al contrario de lo natural. Por tanto el jugador que diera ms peso al segundo estimador
buscara tener menos fichas, o lo que es lo mismo. perder. Pues bien, en estas pruebas,
hechas ya hace tiempo, el algoritmo evolutivo siempre asignaba ms pesos al estimador
"bueno" que al "malo". Por tanto, se poda decir que el aprendizaje era "ptimo".

Aun en el anterior ejemplo de juguete podra ocurrir que un individuo totalmente

"aleatorio" produjera una combinacin "ptima" de pesos, esto es que asignara mayor
peso al estimador "bueno" que al "malo". Luego no podramos garantizar que el jugador
"PE" ganara el 100% de las veces al jugador "aleatorio". Sin embargo, no podramos
afirmar que el aprendizaje no hubiera sido "ptimo"

Algo similar, creemos que ocurre en el siguiente ejemplo con estimadores reales, ( y no
escogidos a drede como en el ejemplo de juguete) :

Prueba 5
Los estimadores usados son:
Carctersticas

Modo "General"

Estimadores

- Nmero de Lderes
- Prximo Recursos

137

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

De cinco partidas, se obtuvieron los siguientes resultados:

Ganadas por PE

Empatadas

Ganadas por Aleatorio

Prueba 5 (dos estimadores)

Ganadas por PE
Empatadas
Ganadas por Aleatorio

Dado que los dos estimadores elegidos no son uno el contrario del otro (como en el caso
del ejemplo de "juguete", no se puede afirmar que una combinacin de pesos es ptima.
Por tanto, las soluciones obtenidas por el Algoritmo Evolutivo probablemente son "casi
ptimas" (cuasiptimas), sin llegar a serlo. Probablemente el 40% de empates se deba a
las soluciones no sean ptimas totales, y al hecho de que el individuo aleatorio pueda
tener una combinacin "buena" de pesos por azar (al ser un espacio de bsqueda
reducido, dimensin plana).

Sin embargo, cabe destacar que, en esta prueba, el jugador "PE" no pierde ni una sola
partida contra el individuo "aleatorio".

138

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

5.4 Validacin del aprendizaje

individualizado.
En este ltimo apartado, intentamos medir la calidad del aprendizaje individualizado.
Para ello, tenemos dos jugadores. Ambos usan los mismo estimadores y calculan
sus pesos mediante PE. La diferencia es que el primero de ellos usar el algoritmo
de escalada para el aprendizaje contra su oponente, mientras que el segundo
mantendr fijos sus pesos, guardndolos en un archivo. De esta manera, ambos
individuos usan estrategias razonables (no aleatorias), pero slo uno de ellos aprender
a lo largo de diferentes partidas.
En todas las pruebas mostramos las partidas jugadas en orden secuencial para ver la
evolucin del aprendizaje individualizado.
NOTA: En lo sucesivo usaremos la palabra aprendizaje para referirnos al jugador que
usa aprendizaje, y participante para el jugador que mantiene fijos los pesos.
A continuacin mostramos los resultados obtenidos.

5.4.1 Aprendizaje ptimo (Prueba 6)

Mostramos los estimadores usados en esta prueba:
Caractersticas

Modo "General"

Modo "Batalla"

Estimadores

- Prximo Recursos

- Nmero de Fichas

- Agresivo

- Agresivo Inteligente

- Acorralar

Los resultados de las partidas jugadas fueron:

139

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Nmero de Partida

Aprendizaje

Empate

Participante

En esta prueba observamos como el participante, desde un principio, empez

perdiendo. Segn esto, ya en la primera partida, era mejor la estrategia de aprendizaje,
con lo cual recordara la estrategia para las siguientes partidas. Al no poder evolucionar
participante, siempre tena una estrategia peor que la de aprendizaje.
El desarrollo de la partida observado era muy parecido, e incluso idntico en la mayora
de las veces. Esto probablemente se deba a que, en la mayora de los casos, la estrategia
aprendida resultaba ganadora tras las diferentes ejecuciones del algoritmo evolutivo.
Recordamos que aunque aprendizaje tenga una buena estrategia, siempre intenta
mejorarla con una nueva ejecucin del algoritmo evolutivo.

5.4.2 Resultados heterogneos (Prueba 7)

En esta prueba el aprendizaje slo se har en el modo general. En el modo batalla
se introducir el estimador catalizador, estimador agresivo arriesgado. Este
estimador provocar que las batallas tengan resultados variados. Esto provoca que las

140

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

partidas generales tengan resultados tan heterogneos, como los que se muestran en
esta prueba.
Los estimadores usados fueron los siguientes:
Caractersticas

Modo "General"

Modo "Batalla"

Estimadores

- Prximo Recursos

- Agresivo Arriesgado

- Agresivo

- Agresivo Inteligente

- Acorralar

Los resultados fueron los siguientes:

Nmero de Partida

Aprendizaje

Empate

Participante

141

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Para ver en que medida aprende el jugador aprendizaje mostraremos los porcentajes
de los resultados de los siguientes conjuntos de partidas:
-

Las partidas hasta que aprendizaje gan la primera partida, con esta incluida
(se corresponde con las primeras cinco partidas de nuestra prueba).

El resto de las partidas (se corresponde con las cinco ltimas partidas).

Los datos referentes a los porcentajes y los grficos son:

Primeras partidas

Ganadas por "aprendizaje"

Empatadas

Ganadas por "participante"

ltimas partidas

Ganadas por "aprendizaje"

Empatadas

Ganadas por "participante"

142

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Primeras partidas (Prueba 7)

Ganadas por
"aprendizaje"
Empatadas
Ganadas por
"participante"

ltimas partidas (Prueba 7)

Ganadas por
"aprendizaje"
Empatadas
Ganadas por
"participante"

Implementacin de juegos de estrategia con programacin evolutiva

En esta pantalla, podemos seleccionar alguno de los botones de la izquierda.

El botn de Crditos muestra la siguiente pantalla:

Si pulsamos el botn de Volver regresamos al Men Principal.

Desde el Men Principal, si pulsamos el botn de Salir, saldremos de la aplicacin.
Para empezar una nueva partida, pulsaremos el botn Empezar. A continuacin nos
aparece la siguiente pantalla:

146

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En ella, debemos introducir nuestro nombre en el mismo sitio donde aparece en la

imagen el nombre de Javier (de ahora en adelante usaremos este nombre como ejemplo
de un posible nombre de usuario, pero se puede introducir el que se desee), y despus
pulsaremos el botn OK con el ratn.
Si ya habamos jugado antes con ese nombre y el ordenador nos haba ganado, usar esa
informacin aprendida, mejorndola ms todava, para jugar contra nosotros. Nos
mostrar el siguiente mensaje, y tendremos que pulsar la tecla Enter.

Despus aparecer el siguiente mensaje informativo, que nos indica que el ordenador
est realizando el proceso de aprendizaje. Cuando se nos indique pulsaremos la tecla
Enter.

147

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

A continuacin aparece el escenario principal del juego, que tiene el siguiente aspecto:

Pasamos a describir la escena:

Los soldados son Lderes. El objetivo del juego es acabar con todos los lderes del
jugador contrario. Nuestros lderes tienen la capa de color rojo, y los del ordenador de
un color ms grisceo.
Los castillos representan ciudades. Las rojas son las nuestras, las azules las del
ordenador, y las blancas no son de nadie.
148

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Los almacenes representan recursos. Los rojos son los nuestros, los azules los del
ordenador, y los blancos no son de nadie.
Cada lder posee un nmero de soldados que viene indicado como un nmero en la
esquina superior izquierda del dibujo que lo representa. En la siguiente imagen se
aprecia que el lder tiene 0 soldados.

El men de la derecha muestra varios botones:

TURNO: nombre del jugador del cual es el turno. Puede ser el nombre del jugador o
CPU indicando que juega el ordenador.
TIEMPO: tiempo restante para la finalizacin de la partida, si es que ningn jugador
acaba antes con todos los lderes rivales.
RECURSOS JAVIER: muestra el nmero de recursos de que dispone el jugador
humano.
RECURSOS CPU: muestra el nmero de recursos de que dispone el ordenador (CPU).
APROPIADOS JAVIER: muestra el nmero de almacenes que tiene en posesin el
jugador humano (los que ha conquistado durante la partida).
APROPIADOS CPU: muestra el nmero de almacenes que tiene en posesin el
ordenador (los que ha conquistado durante la partida).
SALIR: al pulsarlo sale de la partida actual y vuelve al Men Principal.
El men inferior muestra los siguientes botones:
COMPRAR SOLDADO: Si tenemos soldados disponibles (para comprarlos) y un lder
seleccionado, al pulsar este botn se incrementar en uno el nmero de soldados de que
dispone el lder que tenamos seleccionado.
149

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

COMPRAR LDER: Si tenemos lderes disponibles (para comprarlos) y una ciudad

seleccionada, al pulsar este botn aparecer un nuevo lder (inicialmente con 0
soldados) en la ciudad seleccionada. Es requisito que en la ciudad no haya en ese
momento ningn lder.

Ahora describiremos cmo se juega una partida. Como ya hemos dicho anteriormente,
el objetivo del juego es acabar con todos los lderes del jugador contrario antes de que
se acabe el tiempo. Cada jugador (humano y CPU) puede ejecutar una sola accin por
turno.
Las acciones que podemos realizar para alcanzar tal fin son las siguientes:
Desplazar un lder a una casilla adyacente. Podemos seleccionar un lder pinchndolo
con el ratn y moverlo una casilla hacia arriba, abajo, derecha o izquierda, pulsndola
tambin con el ratn. Las casillas a las que nos podemos desplazar aparecen
sombreadas.

Comprar un lder en una ciudad. En caso de que tengamos lderes disponibles, podemos
seleccionar una ciudad y pulsar el botn Comprar Lder. Esto har que se cree un nuevo
lder en esa ciudad, siempre y cuando no existiese ya un lder dentro.

150

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Comprar un soldado para un lder. En caso de que tengamos soldados disponibles,

podemos seleccionar un soldado (en caso de que est dentro de una ciudad o recurso,
seleccionaremos la ciudad o recurso correspondiente) y pulsar el botn Comprar
Soldado. Esto har que se incremente en uno el nmero de soldados de ese lder.
Cuantos ms soldados tenga un lder, ms posibilidades tendremos de ganar una batalla
contra un lder rival.
Una vez que hemos definido cada botn y cada accin, pasamos a explicar las reglas del
juego.

Los lderes se pueden mover por todo el mapa, y cada uno siempre ir con el
nmero de soldados de que disponga. Si hacemos que un soldado entre en una
ciudad o recurso, pueden ocurrir dos cosas:
o Que no haya ningn lder rival en el interior, en cuyo caso la ciudad o
recurso pasar a ser nuestro automticamente.
o Que haya un lder rival en su interior, en cuyo caso se librar una batalla
para ver quien gana (este modo de juego se explicar ms adelante).

Cada almacn que tengamos apropiado nos generar una unidad de recurso en
cada turno. Cuantos ms almacenes tengamos, ms rpido incrementaremos
nuestra cantidad de recursos y ms soldados y lderes podremos comprar.
Tambin es bueno conquistar ciudades, ya que en ellas es donde podremos crear
lderes.

Cada soldado cuesta 3 unidades de recurso y cada lder 10, aunque en principio
estos valores son modificables.

151

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Para librar una batalla contra un lder rival tendremos que situarnos en una
casilla adyacente a donde este l y desplazarnos encima suyo (da igual que est
en terreno abierto como dentro de una ciudad o almacn).

Una vez que realicemos lo anterior, cambiar el escenario de juego, pasndose a

disputar la batalla. El escenario de una batalla tiene el siguiente aspecto:

8. Divisin del
trabajo entre
miembros del
grupo
En nuestro caso, hemos llevado la mayor parte del trabajo de modo conjunto,
reunindonos habitualmente algn da de la semana en concreto, aunque siempre con un
horario relativamente flexible segn las necesidades y tiempo de cada uno.
Casi todos hemos tenido por necesidades en algn momento que releer todo el programa
para entender la parte de los dems, y as poder trabajar mejorando esas partes.
Especficamente, Ivn ha centrado ms su trabajo en la parte evolutiva inicialmente,
llevando a cabo tambin buena parte de la IA. Posteriormente, ha tenido que
involucrarse tambin en el desarrollo de cdigo lgico a medida que el diseo se
complic. A l adems se deben algunas de las ideas que han sido posteriormente
pilares en nuestro programa, como la separacin entre el modo batalla y el general.
Javier Laureano ha sido desde un primer momento del proyecto el ingeniero grfico,
el encargado de tratar desde nuestro programa con el usuario y el que era encargado de
dotar de parte visual a nuestra aplicacin. Por otro lado, y al haber trabajado bastante en
el cdigo del programa, ha sido quien ms se ha peleado con los programas como el
Dev-Cpp, que ha requerido tratar numerosos problemas.
Javier Murillo se dedic inicialmente a la formacin del resto del grupo creando un CD
con varias aplicaciones. Posteriormente, ha trabajado tocando partes muy diversas del
programa, un poco a modo de comodn. Pas de elaborar el diseo de la aplicacin en
Rational Rose, a la parte grfica con Javier Laureano creando imgenes, pasando por
Sonido, Archivos (aprendizaje), estimadores...
157

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

En general, podemos decir que el trabajo que hemos desarrollado ha sido bastante grato
y hemos tenido buenas sensaciones trabajando juntos. Creemos que en el propio
programa es donde pueden verse los frutos de lo que hemos creado.

158

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

9. Referencias y
Bibliografa

[REF 1] [Link]

[REF 2] [Link]

[REF 3] [Link]

[REF 4] Evolving chess playing programs, [Link], K. Albrecht,

[Link], [Link]

[REF 5] Evolving an expert checkers playing program without using human

expertise, [Link], David B. Fogel

[REF 6] Machine learning using a genetic algorithm to optimise a draughts

program board evaluation function, Kenneth [Link] and Peter
[Link]

Libros tambin utilizados :

o "Genetic Algotihms + Data Structures = Evolution Programs ",
Michalewicz.
o "Inteligencia Artificial" Russell & Nurving

159

Proyecto SI

Curso 2004 2005

Implementacin de juegos de estrategia con programacin evolutiva

Autorizacin
Autorizamos a la Universidad Complutense
a difundir y utilizar con fines acadmicos,
no comerciales y mencionando
expresamente a sus autores, tanto la propia
memoria, como el cdigo, la
documentacin y/o el prototipo
desarrollado.
Los abajo firmantes,
Javier Murillo Blanco

Javier Laureano Collado

Ivn Garca-Magario Garca

160

También podría gustarte

Programación de Juegos MSX
Aún no hay calificaciones
Programación de Juegos MSX
128 páginas
Formación Rugby U12: Niveles y Objetivos
Aún no hay calificaciones
Formación Rugby U12: Niveles y Objetivos
37 páginas
Planificación Estratégica en Partidos
Aún no hay calificaciones
Planificación Estratégica en Partidos
253 páginas
Guía de Programación con Allegro
100% (2)
Guía de Programación con Allegro
27 páginas
Enfoques de La Iniciacion Deportiva
Aún no hay calificaciones
Enfoques de La Iniciacion Deportiva
3 páginas
Fundamentos Diseño Gráfico Videojuegos
Aún no hay calificaciones
Fundamentos Diseño Gráfico Videojuegos
25 páginas
Guía Completa de GDevelop 2023
Aún no hay calificaciones
Guía Completa de GDevelop 2023
48 páginas
Manual Nivel 1 - Urba
Aún no hay calificaciones
Manual Nivel 1 - Urba
84 páginas
Evolución de la Educación Física en Primaria
100% (1)
Evolución de la Educación Física en Primaria
13 páginas
Iniciación Deportiva
Aún no hay calificaciones
Iniciación Deportiva
18 páginas
Aprendizaje Basado en Problemas Efectivo
Aún no hay calificaciones
Aprendizaje Basado en Problemas Efectivo
51 páginas
Análisis de UX en Realidad Virtual
0% (1)
Análisis de UX en Realidad Virtual
126 páginas
Juegos Cooperativos para Primaria
Aún no hay calificaciones
Juegos Cooperativos para Primaria
78 páginas
Arreglos Monografia
0% (1)
Arreglos Monografia
60 páginas
Tutorial Allegro
100% (1)
Tutorial Allegro
22 páginas
Sistemas Defensivos en Voleibol
Aún no hay calificaciones
Sistemas Defensivos en Voleibol
14 páginas
Recopilacion Info Internet Futbol Sala PDF
Aún no hay calificaciones
Recopilacion Info Internet Futbol Sala PDF
215 páginas
Manual de UML
Aún no hay calificaciones
Manual de UML
48 páginas
Evaluación Técnico-Táctica Fútbol Infantil
Aún no hay calificaciones
Evaluación Técnico-Táctica Fútbol Infantil
370 páginas
ZX - Spectrum 2-Manual - Del - Usuario PDF
100% (1)
ZX - Spectrum 2-Manual - Del - Usuario PDF
258 páginas
Ftbol Cuadernos Tcnicos N 34 - SISTEMA 1-4-2-3-1 FUNDAMENTOS DEFENSIVOS
Aún no hay calificaciones
Ftbol Cuadernos Tcnicos N 34 - SISTEMA 1-4-2-3-1 FUNDAMENTOS DEFENSIVOS
13 páginas
Revisión de simuladores de vuelo
Aún no hay calificaciones
Revisión de simuladores de vuelo
13 páginas
Seminario Voleibol: Entrenamiento Eficaz
Aún no hay calificaciones
Seminario Voleibol: Entrenamiento Eficaz
33 páginas
Deporte con Principios para el Desarrollo
100% (2)
Deporte con Principios para el Desarrollo
143 páginas
Escuelas Deportivas en Florida Blanca
Aún no hay calificaciones
Escuelas Deportivas en Florida Blanca
33 páginas
Técnicas de Búsqueda en Programación de Ajedrez
Aún no hay calificaciones
Técnicas de Búsqueda en Programación de Ajedrez
19 páginas
Usando Allegro
Aún no hay calificaciones
Usando Allegro
549 páginas
Modelo para Videojuegos Educativos
Aún no hay calificaciones
Modelo para Videojuegos Educativos
272 páginas
Simulador de Vuelo: Proyecto Estudiantil
Aún no hay calificaciones
Simulador de Vuelo: Proyecto Estudiantil
13 páginas
TIC en Acrosport: Innovación Educativa
100% (3)
TIC en Acrosport: Innovación Educativa
245 páginas
Tutorial RPG Maker XP
Aún no hay calificaciones
Tutorial RPG Maker XP
11 páginas
Efectos del Espacio en Juegos Reducidos de Fútbol
Aún no hay calificaciones
Efectos del Espacio en Juegos Reducidos de Fútbol
26 páginas
Pygame
Aún no hay calificaciones
Pygame
146 páginas
Curso de Entrenamiento Deportivo 2020-2021
Aún no hay calificaciones
Curso de Entrenamiento Deportivo 2020-2021
204 páginas
Librodeorodelosjuegos2014 141214065445 Conversion Gate02
Aún no hay calificaciones
Librodeorodelosjuegos2014 141214065445 Conversion Gate02
341 páginas
Centro de Videojuegos Integral
100% (1)
Centro de Videojuegos Integral
110 páginas
Chancusig - CHJ - Implementación de Un Modelo de Adopción de La TIC para El Proceso de Enseñanza Aprendizaje
Aún no hay calificaciones
Chancusig - CHJ - Implementación de Un Modelo de Adopción de La TIC para El Proceso de Enseñanza Aprendizaje
289 páginas
Manual de Entrenamiento Físico: para Árbitros de Baloncesto
Aún no hay calificaciones
Manual de Entrenamiento Físico: para Árbitros de Baloncesto
51 páginas
Programas Eder
Aún no hay calificaciones
Programas Eder
85 páginas
GDD del videojuego Doll War
Aún no hay calificaciones
GDD del videojuego Doll War
21 páginas
Los Juegos Pre Deportivos
Aún no hay calificaciones
Los Juegos Pre Deportivos
46 páginas
Informática IPLACEX
Aún no hay calificaciones
Informática IPLACEX
2 páginas
Introducción a Algoritmos en C
Aún no hay calificaciones
Introducción a Algoritmos en C
7 páginas
DEPORTES EN POSITIVO Cuaderno de Actividades
Aún no hay calificaciones
DEPORTES EN POSITIVO Cuaderno de Actividades
71 páginas
Creatividad y Neuroplasticidad en Balonmano
Aún no hay calificaciones
Creatividad y Neuroplasticidad en Balonmano
9 páginas
Prototipo de Videojuego Hyper-Casual Móvil
Aún no hay calificaciones
Prototipo de Videojuego Hyper-Casual Móvil
152 páginas
Diseño de Mecánicas
Aún no hay calificaciones
Diseño de Mecánicas
8 páginas
Crear Juegos de Mesa: 6 Consejos Clave
Aún no hay calificaciones
Crear Juegos de Mesa: 6 Consejos Clave
10 páginas
Modelo de Intervención para Organizar El Entrenamiento en Las Diferentes Categorías Base Del Balonmano
Aún no hay calificaciones
Modelo de Intervención para Organizar El Entrenamiento en Las Diferentes Categorías Base Del Balonmano
88 páginas
Reflexiones sobre metas y emociones personales
Aún no hay calificaciones
Reflexiones sobre metas y emociones personales
3 páginas
IA para Diseño de Bots en Juegos RTS
Aún no hay calificaciones
IA para Diseño de Bots en Juegos RTS
82 páginas
IA en Videojuegos: Aprendizaje Automático
Aún no hay calificaciones
IA en Videojuegos: Aprendizaje Automático
68 páginas
Aplicacion de IA en Videojuegos
Aún no hay calificaciones
Aplicacion de IA en Videojuegos
88 páginas
Algoritmos Genéticos en Juegos de Rol
Aún no hay calificaciones
Algoritmos Genéticos en Juegos de Rol
68 páginas
Algoritmos IA para el Juego 2048
Aún no hay calificaciones
Algoritmos IA para el Juego 2048
83 páginas
Unidad 1. 04. Computación Evolutiva
Aún no hay calificaciones
Unidad 1. 04. Computación Evolutiva
23 páginas
IA para Videojuego Starcraft: Desarrollo de Bot
Aún no hay calificaciones
IA para Videojuego Starcraft: Desarrollo de Bot
55 páginas
Avance Del Prototipo
Aún no hay calificaciones
Avance Del Prototipo
7 páginas
Proyecto Final Taller de Licenciatura I
Aún no hay calificaciones
Proyecto Final Taller de Licenciatura I
70 páginas
Introducción A Los Videojuegos UOC
Aún no hay calificaciones
Introducción A Los Videojuegos UOC
4 páginas
Libros de Texto 2017-2018
Aún no hay calificaciones
Libros de Texto 2017-2018
5 páginas
Preguntas Tema 2 El Relieve
100% (6)
Preguntas Tema 2 El Relieve
3 páginas
Blend Iberia 2006
Aún no hay calificaciones
Blend Iberia 2006
296 páginas
Reglas y Fundamentos del Hockey Sala
Aún no hay calificaciones
Reglas y Fundamentos del Hockey Sala
3 páginas
Partes y Funcionamiento del Motor de Arranque
Aún no hay calificaciones
Partes y Funcionamiento del Motor de Arranque
32 páginas
Tesoros Mágicos de Veracruz
Aún no hay calificaciones
Tesoros Mágicos de Veracruz
2 páginas
Problemas de Conjuntos
50% (2)
Problemas de Conjuntos
1 página
Las 6 Funciones Básicas de Un Líder
100% (1)
Las 6 Funciones Básicas de Un Líder
2 páginas
2-Ppt Planificacion Corto Plazo
100% (3)
2-Ppt Planificacion Corto Plazo
10 páginas
Síntomas y fantasías en el análisis psicodinámico
Aún no hay calificaciones
Síntomas y fantasías en el análisis psicodinámico
11 páginas
Objetivos
Aún no hay calificaciones
Objetivos
9 páginas
Orientaciones para el Prácticum III en Educación
Aún no hay calificaciones
Orientaciones para el Prácticum III en Educación
23 páginas
Montaje Tablero de Distribucion
Aún no hay calificaciones
Montaje Tablero de Distribucion
5 páginas
Estrategias de Aprendizaje en Liderazgo
100% (1)
Estrategias de Aprendizaje en Liderazgo
43 páginas
Tiranidos
Aún no hay calificaciones
Tiranidos
18 páginas
Etapas del Proyecto Tradicional en Ingeniería
Aún no hay calificaciones
Etapas del Proyecto Tradicional en Ingeniería
11 páginas
Manual ZeusHotel
67% (3)
Manual ZeusHotel
57 páginas
Trabajo de Investigacion-Metodo de Ordenamiento
100% (1)
Trabajo de Investigacion-Metodo de Ordenamiento
7 páginas
Producción de Ácido Sulfúrico: Proceso y Propiedades
Aún no hay calificaciones
Producción de Ácido Sulfúrico: Proceso y Propiedades
23 páginas
Educación Inicial en Familia Comunitaria Escolarizada
Aún no hay calificaciones
Educación Inicial en Familia Comunitaria Escolarizada
52 páginas
Enfermedades Virales de La Piel
Aún no hay calificaciones
Enfermedades Virales de La Piel
91 páginas
Fuerzas y Campos Eléctricos en Cargas
Aún no hay calificaciones
Fuerzas y Campos Eléctricos en Cargas
5 páginas
Causas de Escasez de Medicamentos en Salud
Aún no hay calificaciones
Causas de Escasez de Medicamentos en Salud
4 páginas
Automatización en Embotellado Cervecero
Aún no hay calificaciones
Automatización en Embotellado Cervecero
11 páginas
RAE-CMBD Informe Hospitalizacion 2020
Aún no hay calificaciones
RAE-CMBD Informe Hospitalizacion 2020
65 páginas
Guía de Evaluación Filosofía
Aún no hay calificaciones
Guía de Evaluación Filosofía
5 páginas
Los Secretos de Palo
Aún no hay calificaciones
Los Secretos de Palo
5 páginas
Analisis de Tiempos y Movimientos
Aún no hay calificaciones
Analisis de Tiempos y Movimientos
10 páginas
Currículum 2025 Karla Fernanda Gavilanez Revelo
Aún no hay calificaciones
Currículum 2025 Karla Fernanda Gavilanez Revelo
7 páginas
Documento Final - Ici - Surco
Aún no hay calificaciones
Documento Final - Ici - Surco
338 páginas
Christian Norberg - ESPACIO ARQUITECÓNICO.....................
Aún no hay calificaciones
Christian Norberg - ESPACIO ARQUITECÓNICO.....................
17 páginas
Formulación (Análisis Tecnico)
Aún no hay calificaciones
Formulación (Análisis Tecnico)
27 páginas
Recetas de Budín Inglés Tradicional
Aún no hay calificaciones
Recetas de Budín Inglés Tradicional
2 páginas
Incendios Forestales y Contaminación Del Agua Mediante Una
Aún no hay calificaciones
Incendios Forestales y Contaminación Del Agua Mediante Una
8 páginas