Voy a hacer un resumen de este concurso que quedo en el olvido porque lo desarrolle a través de los blogs que ya no existen, y me parece interesante mencionarlo para todos aquellos que quieran participar en algun GIA futuro una mejor idea de que va el concurso.
Este GIA se llevo a cabo hace cosa de un año y pico, a finales de 2008 si la memoria no me falla.
La temática de este GIA_01 era ver quien tenia los mejores tiempos y pasaba mas cantidad de niveles en un juego de puzzles plataforma de vista lateral. El concurso consistía en varias rondas y a medida que iban destrabando los niveles se iban haciendo las nuevas rondas, asi hasta llegar al noveno nivel que era el ultimo.
(http://img541.imageshack.us/img541/3051/16192213.png)
Bueno, el concurso se finalizo en 5 rondas, declarandose Campeon del GIA_01 merecidamente Raul Omega. Aunque luego agregue una "6ta" en donde participa Ciberman fuera de tiempo, pero ya que hizo su IA debia ponerlo.
(http://img8.imageshack.us/img8/6691/gia01campeonraulomega.png)
Les dejo tanto el editable (.gm6) como el .exe de la ultima versión para que puedan echarle un ojo y porque no, intentar hacer sus IAs, siempre serán bienvenidas por mi.
Aca les dejo tambien un link al video oficial del torneo + CibermanIA (que no participo oficialmente del concurso sino luego de finalizado) para que vean de va todo esta de Guerra de IAs :)
VER VIDEO (http://www.youtube.com/watch?v=xb_pqyqhbMg)
Registros
Raul Omega
----DATOS DE LA IA----
Fecha de inicio: 1-Mayo-2009
Fecha de la version 1: 2-Mayo-2009
Fecha de la version 2: 10-Junio-2009
Fecha de la version 3: 18-Junio-2009
Autor: Raul_Omega
Maximo nivel superado version 1: Nivel 6
Maximo nivel superado version 2: Nivel 8
Maximo nivel superado version 3: Nivel 9
----EXPLICACION DE SU FUNCIONAMIENTO----
En cada Step la IA detecta el proximo obstaculo a superar y tambien
los 6 obstaculos siguientes (a 16,32,48,64, etc pixeles de distancia).
Aunque apenas se ha sacado partido al calculo de obstaculos posteriores.
En total es capaz de diferenciar 13 situaciones diferentes:
1-Flechas opuestas: El droide debera saltar y andar
2-Muro: El droide debera saltar y andar
3-Pozo: El droide debera saltar y andar
4-Camino sin salida (pared): El droide cambiara su direccion
5-Dejarse caer (si el unico camino posible es dejarse caer): El droide debera andar para caer
6-Camino libre: No hay obstaculo, el droide debera andar
7-Pinchos boca arriba: El droide debera saltar y andar o bien pararse para no caer en ellos
8-Almoada: Si se detecta una almoada bajo el droide se deja de avanzar
9-Trampolin: Se salta hasta que se alcance la maxima altura, despues continua avanzando
10-Pinchos movimiento vertical: Se para mientras los detecta
11-Pinchos movimiento horizontal: Si estan a la misma altura se saltan si no se avanza
12-Mar de pinchos de movimiento horizontal: Detecta si hay pinchos con movimiento horizontal debajo y se deja caer solo
cuando estan lejos
13-Escalones: Este obstaculo no fue necesario de introducir hasta el nivel 9, en el se necesitaba dejarse caer
en un huevo para poder saltar una zona de pinchos
Existe una variable posH que indica si la salida se encuentra a la izquierda o a la derecha del droide.
En caso de haber una pared el droide cambiara posH a la direccion opuesta. (Como ocurre en el nivel 5)
La variable cambiosH cuenta las veces que posH cambia de valor sin que se haya tocado una pared
en caso de que cambiosH alcanze el valor 2 significa que el droide esta oscilando en torno a la salida
debido a que esta a una altura diferente (Como ocurre en el nivel 9), si esto ocurre se fija posH hasta que se alcance
una pared.
Aparte de los obstaculos antes mencionados que se calculan con un Script, existe un tipo de obstaculo
que no es detectado y que se trata de los pinchos que miran hacia abajo. En lugar de incluirlo como un obstaculo
el droide cuando se le manda avanzar checkea que no haya un pincho de esta clase delante suyo, en caso de que lo haya no avanza.
----PROBLEMAS SURGIDOS----
El primer problema que se me planteo fue buscar la manera de detectar los obstaculos, entonces se me
ocurrio crear un script que por medio de acciones del tipo collision detectara los proximos obstaculos
y devolviese un vector obstaculo(X) con el valor igual al tipo de obstaculo (del 1 al 9), siendo la X la del primer, segundo...
hasta el septimo obstaculo por delante del droide. Si bien, salvo para el obstaculo "Dejarse caer" no tiene
utilidad conocer futuros obstaculos, pero decidi dejar asi el script por si me hacia falta posteriormente.
Una vez definido este script y el evento step donde se actua segun el obstaculo no tuve problemas hasta el
nivel 3, donde aparecen por primera vez los pinchos. Obstaculo que aun no habia implementado. Me llevo un tiempo pensar
la manera de superarlos por que tenia que calcular cuando era necesario que el droide parase de avanzar para no chocarse con
un pincho, y sin embargo si hay pocos pinchos interesa seguir avanzando para alcanzar el otro lado.
Por lo que decidi:
-Si vspeed<=0 (estoy en el suelo o saltando): El droide sigue avanzando
-Si vspeed>1 (estoy cayendo):
-Si tengo un pincho justo delante: Se para en caso contrario sigue adelante con el salto
En realidad superar este obstaculo fue en gran medida debido a la prueba y error hasta que obtuve el resultado deseado
por ello quedo algo desordenado el codigo.
Despues de esto el siguiente problema fueron los pinchos bocaabajo que no habia incluido en el script y que
decidi en lugar de incluirlos simplemente detectarlos cuando el droide tuviese que avanzar
El siguiente problema importante aparecio en el Nivel 5, que implicaba un cambio de direccion del droide
a mitad del nivel. Para que el droide supiese para donde avanzar idee lo siguiente:
-Mientras no se choque con una pared el droide sigue la direccion impuesta por posH segun donde este la salida
-Si se encuentra una pared posH cambia de direccion y ya no se chequea donde esta la salida
se supondra que se acabara encontrando
El ultimo problema encontrado fueron los trampolines del Nivel 6, ya que el ultimo trampolin del nivel mi droide no
lo detectaba correctamente ya que las condiciones para detectar un trampolin y para dejar de saltar sobre él
se "superponian". Con lo cual decidi poner un par de variables adicionales.
-Saltando:
0: El trampolin no se ha tocado o bien no hay trampolin
1: Se esta saltando sobre el trampolin
2: Se ha alcanzado la maxima altura, el droide avanza hasta que deja de estar sobre el trampolin, momento
en el que Saltando vuelve a 0 para repetir el proceso con otro trampolin
-xsalto: Coordenada x del trampolin sobre el que se esta saltando, sirve para saber si se deja de estar sobre
el trampolin
En la version 2 el nivel 9 no se podia superar debido a que el droide se chocaba con unos pinchos que miran hacia abajo
debido a que para poder pasar esa zona habia que dejarse caer en un hueco situacion que era incapaz de detectar, en la
version 3 se incluyo que siempre que hubiese un escalon de 1 bloque de altura el droide lo bajase
Ciberman
------------------------------------
////////////////////////////////////|
/////Datos de la IA:////////////////|
////////////////////////////////////|
//Fecha de Inicio:17/09/2009////////|
////////////////////////////////////|
//Fecha de Finalizacion:24/09/2009//|
////////////////////////////////////|
//Autor: Ciberman///////////////////|
////////////////////////////////////|
------------------------------------
PROBLEMAS que tomaron mucho resolverse:
-nivel 1: Detección de el impulsador izquierda y derecha. cuando seguir y cuando saltar.
-Nivel 2: Detección de las paredes, y cuando devía saltar
-nivel 3: saber cuándo es que había que parar de caminar y parar el salto para no caer en los
pinchos. basicamente el sistema utilizado comprueba si existe un pincho y en ese caso
se fija el siguiente espacio libre, salta, e intenta caer alli.
-nivel 4: Un error. el droide detectaba que tenía que saltar al comienzo y entonces saltaba pero
no avasaba por consecuencia. con unos ajustes de revisión alcanzó.
Tambien fue dificultoso pasar un pinche normal que debía detectarse en el aire. Tambien
una barrera de pinchos del final.
-Nivel 5: No se sabía cuando debía cambiar de dirección. eso tardó mucho en resolverse... Costo
tener que bajar al nivel 2. Luego el siguiente problema fue la deteccion abanzada de pinchos.
Cuando debía parar y cuando abanzar. Siguio con problemas el hecho de una bajada llena de
pinches, se debío hacer que el droide reconociera cuando podía abanzar y cuando frenar para
una correcta caida.
-Nivel 6: Al principio, con el código que le había dado avanzó el droide la mitad del nivel pero callo
en un pozo con pinchos. Luego de unas modificaciones al código de detencion de pinchos, el
droide pudo pasar callendo en la almhoada. Luego un problema grande surgió. Devía detectar los
trampolines. Con un código de detección que me costó lo solucioné.
-Nivel 7: Lo superé rápido. No hubo basicamnte problemas.
-Nivel 8: Fue un poco dificil configurar el movimiento en las dos direcciones con esas rocas, pero despues
no hubo mayores problemas.
Guacusio
//Registro
//Fecha de inicio:07-05-09
//Fecha de término:16-05-09
//Autor:guacusio
//Funcionamiento:
/*Primero trabajé con 3 variables: izq, der y salto, donde cada una podía ser true o false,
dependiendo de si el personaje debía moverse a la derecha, a la izquierda y/o saltar.
Como vi que el código se estaba haciendo muy poco estructurado y difícil de depurar y hasta de entender,
mandé todo al diablo y comencé desde el principio con otra idea que recién estaba aprendiendo: máquinas de estados finitos
Utilicé una máquina de estados finitos (la primera que hago) XD
basándome en los geniales tutoriales de Fenris:
http://www.comunidadgm.org/index.php?page=60
http://www.comunidadgm.org/index.php?page=57
http://www.comunidadgm.org/index.php?page=58
http://www.comunidadgm.org/index.php?page=59
La máquina tiene 4 estados:
quieto: no se avanza ni se salta
salto:está saltando o cayendo verticalmente, sin moverse hacia los lados
salto_avance:lo mismo que salto, pero incluye movimiento horizontal
avance:movimiento horizontal solamente, sin movimiento vertical
La dirección de avance la controla la variable avance (1=derecha, -1=izquierda, 0=sin avance)
La variable rec_avance guarda la dirección de avance en caso de detenerse, para luego retomar el avance en la dirección correcta
Los eventos para cambiar de estado son un montón. Se encuentran en los scripts asociados a los estados.
Hay explicaciones en los comentarios de esos scripts.
A continuación hay un resumen de los eventos de cada estado:
quieto:(se basa en la hipótesis de que los bloques móviles tienen como parent a obj_global_pinches)
-Si hay un tipo de pinche adelante que se mueve verticalmente y justo ahora se mueve hacia arriba permitiendo pasar, cambia al estado avance
salto:
-Si hay pinches adelante pero no hay en la próxima actualización cinemática(*), pasa al estado salto_avance
-Si abajo hay una pared y no hay pinches adelante ni está sobre un trampolín, cambia al estado avance
-Si está sobre un trampolín y ya llegó al punto más alto que puede llegar (aprox. 15 bloques de altura), cambia al estado salto_avance
(*)se refiere a los nuevos valores de x,y y gravity que calcula el script scr_step
salto_avance:
-Si hay pinches adelante, deja de moverse horizontalmente pero no cambia de estado por ahora. Si no hay, retoma el movimiento horizontal
-Si está sobre una esquina (a cualquier altura) y no hay pinches sobre su cabeza, cambia al estado salto
-Si inmediatamente abajo hay un muro, cambia al estado avance
-Si está sobre la esquina de adelante de un trampolín (a cualquier altura) y va cayendo, cambia al estado salto
avance:
-Si entra a una zona donde hay pinchos que suben y bajan, cambia al estado quieto
-Si adelante hay pinches, cambia al estado salto
-Si adelante hay un muro de hasta 3 bloques de altura, cambia al estado salto_avance, de lo contrario cambia de dirección de avance
-Si llega a una esquina y arriba no hay pinches, o si se encuentra con un slope desfavorable, o si frente a sus pies hay pinches, cambia al estado salto_avance
-Si llega al borde de un trampolín, cambia al estado salto
Otros scripts:
scr_guacusio_voltea: revisa si tiene frente al personaje una pared muy alta (más de 3 bloques de altura), si es así cambia el sentido de avance horizontal y reorna true; de otro modo retorna false
scr_guacusio_arriba: revisa si hay pinches sobre el personaje, hasta una altura de 3 bloques
scr_guacusio_abajo: devuelve 1 si el personaje está sobre suelo ahora y en el próximo estado cinemático, 2 si llega a una esquina de suelo normal y 3 si llega al borde de un trampolín
scr_guacusio_cambia_a: cambia al estado argument0, invocando las acciones asociadas al ingreso a ese estado (entre otras cosas, el valor de la variable avance)
scr_guacusio_aplasta: cambia al estado quieto si llega a una zona de pinchos que se mueven verticalmente
Suposiciones e imperfecciones
Por falta de tiempo (y de genio), esta IA no diferencia entre cojines y paredes, así que no aprovecha los primeros.
Esta IA supone que los bloques con movimiento vertical que matan al personaje tienen parent obj_global_pinches
Esta IA hace al personaje detener su avance horizontal en cada esquina si está en el estado salto o salto_avance. Esto ralentiza su avance pero fue la única forma que encontré de pasar ciertos obstáculos potenciales (que no salen en los niveles que hizo KrakenHimoto, por cierto) como pozos profundos, donde si llego y hago un salto completo desde el primer bloque que puedo, me puedo quedar atrapado en el pozo.
Esta IA, por lo dicho, no está optimizada para pasar el nivel lo antes posible, pero sí para llegar en forma segura.
Dificultades:
Todo fue difícil XD. Sin embargo, tuve especiales problemas para esquivar los pinches ya que hay una gran gama de combinaciones de posiciones relativas de los pinches respecto al jugador.
También me costó encontrar un método para hacer que el personaje supiera cuándo avanzar en sentido opuesto en el nivel 5 (aunque no fue difícil para nada implementarlo una vez se me ocurrió)
El uso de trampolines en el nivel 6 fue bastante complejo, principalmente porque no se me ocurría cuándo debía abandonar el trampolín.
Huarelion
Nombre del creador: Eduardo Ibarra (eduardo960)
---------------------- IA version 0.1 ----------------------
Fecha de inicio de la IA: Sábado 18 de Abril de 2009
Fechas de finalización de la IA: Domingo 19 de Abril de 2009
Cambios: Creación de la base de la IA, termina satisfactoriamente los 3 primeros niveles
------------------------------------------------------------
---------------------- IA version 0.2 ----------------------
Fecha de inicio de la IA: Lunes 20 de Abril de 2009
Fechas de finalización de la IA: Lunes 20 de Abril de 2009
Cambios: Optimizado el codigo de chequeo de paredes, solucionados unos detalles relacionados con los saltos de paredes
------------------------------------------------------------
---------------------- IA version 0.3 ----------------------
Fecha de inicio de la IA: Miércoles 22 de Abril de 2009
Fechas de finalización de la IA: Jueves 23 de Abril de 2009
Cambios: Solucionados algunos bugs de detecciones a la izquierda, IA un poco más inteligente (Términa los niveles en menos tiempo), Nivel 4 terminado,
arreglados más detalles relacionados con el salto del personaje, Detección de picos por encima del personaje, Detección de picos mejorada
------------------------------------------------------------
Eventos añadidos aparte de los ya por defecto:
- Alarma 1
Seguimiento de la IA:
Al comenzar con el desarrollo de mi IA del concurso GIA, lo primero que hice fue usar la lógica para planear como definiría la dirección para llegar
a su destino que sería la meta, hacer que se replantee la dirección en caso de que no encuentre un avance para aproximarse a la meta.
Los problemas que actualmente tiene mi IA es que es capaz de pasar un nivel complejo pero quedarse trabada en un nivel menos complejo, ya que el código
no esta totalmente optimizado, pero el codigo será optimizado para que pueda pasar niveles de todo tipo.
Pensamiento de la IA:
- Definir la dirección inicial a la que moverse
- Si el checkpoint se encuentra en una posición Y muy lejana, su dirección por defecto es 1 (derecha)
- La IA tiene un máximo de 2 intentos para pasar por una zona, si su posición X es igual después de todos los intentos, cambia de dirección
- Durante su ejecución, se pone en busqueda de aceleradores de velocidad
- Si encuentra un acelerador de velocidad contraria a su dirección, realiza un salto, si va hacia su dirección, camina para tomar velocidad
- Durante su ejecución, se pone en busqueda de bloques que puedan evitar que continue su camino
- Si no hay bloques que obstruyan el salto, lo realiza para pasar bloques que le impiden continuar
- Si no es posible pasar una pared de bloques, replantea la dirección para encontrar otro camino
- Identifica si el checkpoint se encuentra debajo de el
- Si esta por debajo de el y encuentra un espacio vacio para pasar, deja de moverse para bajar y continuar su camino
- Identifica hacia cuál dirección se acerca más al checkpoint desde la alarma 1
- Si la dirección en la que va lo acerca más, sigue en esa, sino, cambia de dirección
- Busca e identifica los picos próximos
- Al encontrar uno hace un cálculo para encontrar el sitio más lejano y seguro al que pueda llegar saltando
- Al llegar a la posición deseada deja de moverse hasta que este apoyado completamente en una plataforma y sigue moviendosé
Darth RPG
Registro de la IA:
Empezada en 17/4/2009
Terminada en 20/4/2009
Creada por Darth RPG
En una primera idea decidí que simplemente se moviera a la derecha, comprobando que no haya bloques por medio de su camino a la meta.
Si los hay que los salte y que continue. Sin embargo, esta idea ya en el primer nivel me trajo dificultades. Por ello implemente un sistema
para detectar qué tipo de suelo tiene justo debajo y delante. Si es una cinta que va en contra de su movimiento, que la salte. Con esto
ya superé el primer nivel. El segundo ya fue más difícil. El código de detección con el collision_line funcionaba mal, así que, en una rabieta
hice un sistema más básico y conseguí que funcionara. El nivel tres fue, de lejos, el que más problemas me dio. Sin embargo, gracias a otra
de mis rabietas, hice un script que detectara la instancia de debajo y hice que si tenía un foso de pinchos muy ancho delante suyo y estaba en
un lugar seguro parara el salto. Con esto conseguí que superara ya el tercer nivel.
Mi IA básicamente, comprueba en qué dirección debe moverse. Luego, mira que no haya bloques en su camino. Si los hay, calcula la distancia al
más cercano y si está a 12 píxeles, salta. Si no hay bloques cerca, comprueba que no haya pozos delante y, si los hay, los salta. Además, si
está saltando y tiene un rellano cerca y un foso delante, se para en el rellano a esperar para saltar de nuevo.
BrandNew
//Bitácora de IA
/*
La primera idea que surgió fue que la IA debería estar avanzando constantemente,
pues el primer nivel es una linea recta con tan sólo un obstáculo, que era evitar
las flechas que te alentan. Así que el primer nivel fue simplísimo, y la IA lograba
un tiempo record tan solo con scr_walk(1) y detección previsiva de las molestas flechas.
Para el segundo nivel el cambio no fue mayor: el droide solo debería brincar cada vez
que detectaba una pared o un hoyo adelante. Durante este tiempo logré mejorar
el puntaje en el primer nivel y poco a poco fue mejorando el del segundo.
Para el tercer nivel se complico la cosa, puesto que ahora había pinchos sobre los
que puedes caer. Aunque la IA brincaba en presencia de un hoyo, tendìa a aventarse
directamente contra unos pinchos que se encontraban màs adelante.
Esto llevó a desarrollar un algoritmo para que el droide, al brincar, deje de moverse si prevee
que va a caer sobre pinchos. (vease el primer ciclo for{} del evento Step)
Uff, el ultimo nivel resulto el mayor reto. Primero,encontrar una manera de detectar
la dirección hacia la que el droide tiene que moverse. Después, evitar que el droide
de saltos desde muy alto para no caer y aplastarse. Después, evitar hacer contacto con
los pinchos invertidos, y al final se modifico un poco del codigo ya creado para que
el brinco del droide llegara a la ultima parte del laberinto.
En concreto, la IA funciona a base de detección previsiva del entorno para tomar una decisión.
*/
Shaoran
/*
------------------------------------
////////////////////////////////////|
/////Datos de el IA:////////////////|
////////////////////////////////////|
//Fecha de Inicio:25/04/2009////////|
////////////////////////////////////|
//Fecha de Finalizacion:28/08/2009//|
////////////////////////////////////|
//Autor: Shaoran////////////////////|
////////////////////////////////////|
------------------------------------
--------------------
|Pensamiento del IA:|
--------------------
- Se basa en verificar si adelante de ella tiene "piso" para caminar,
de no tenerlo verifica de que se trata lo que esta adelante y de
acorde a eso hace o no determinada accion.
-------------------
|Problemas surgidos:|
-------------------
- Saltaba al final del nivel(sobre la meta)me costo encontrar el porque de ello
- Aun persiste el problema con lo pinches para poder pasarlos.
Asava
No se encontró (capaz debido a su participacion no oficial ya que organizaba el concurso)
Especial agradecimiento a Ciberman por hacer la recopilacion de los registros.
Iré actualizando todo lo referente al tema... me despido, KrakenHimoto.