Screamming Racers

Martes, 14 de junio de 2005

Screaming Racers continúa adelante

Os pedimos disculpas por el tiempo que llevamos sin postear nada. En estos últimos días, el nivel de trabajo en Cheesetea nos está desbordando con creces y apenas nos queda tiempo para prestar atención al blog.

Seguramente, continuaremos poniendo novedades a partir del próximo día 5 de julio, que será cuando Screaming Racers pase su primer control ante un tribunal de suficiencia investigadora.

Por el momento, aquí os dejamos un par de capturas para que veais el estado actual de desarrollo.




Nuevamente, comentaros que cualquier sugerencia, pregunta o comentario que queráis hacernos sobre el juego, siempre será bien recibida :).

Por: ronaldo | General | Comentarios (2) | Referencias (0)

Lunes, 09 de mayo de 2005

Reestructuracion del motor

He empezado a añadir soporte para OpenGL en el motor. Debido a que inicialmente solo se habia pensado en soporte software, hay que hacer una ligera reestructuración en las clases CEngine y CRender.

A partir de ahora, CRender será una clase base estandar de la que se derivan otras dos: CRenderSoft y CRenderGL.
Se va a intentar hacer lo mas generico posible, por si decidieramos hacer una version DirectX en algun momento :O.
Además se tiene que modificar un poco la clase CObjeto. Se añadirá un identificador unico a cada objeto registrado en el motor. Este id se usará en la compatibilidad de OpenGL, al menos temporalmente. Por ahora la única solución que se me ocurre es crear una copia de todos los objetos del motor en formato OpenGL. Esta lista se mantiene en memoria. El motor sigue operando internamente en su propio formato, y cuando ha realizado el proceso de clipping y seleccionado los objetos a renderizar, se los pasa a CRenderGL, que actualiza los objetos equivalentes en formato GL y los renderiza.

Además no es mala idea que cada objeto tenga su propia id, por si el usuario que utilice el motor quiere darle alguna utilidad, referenciando a los objetos por su id.

También he cambiado algunas cosas en CEngine. Se ha añadido una función de cambio de resolución CambiarResolucion(ancho,alto,bpp), una funcion SwitchFullScreen() que alterna entre modo ventana y pantalla completa, y se esta teniendo en cuenta que se pueda cambiar el tipo de render soft/GL en cualquier momento, sin que haya que reiniciar el juego.

Por: Predator | Motor grafico | Comentarios (1) | Referencias (0)

Lunes, 09 de mayo de 2005

Conductores aprendiendo nuevas habilidades!

La inteligencia artificial de Screaming Racers comienza a dar sus primeros frutos. En los últimos experimentos realizados, ya hemos podido disfrutar observando a los primeros corredores que aprendían a dar vueltas a algunos circuitos simples :).

Las novedades en esta última entrega son las siguientes:

• Los conductores ya responden a los parámetros que se les indican desde la interfaz de usuario. De modo que si le indicamos que sean más agresivos o menos autoexigentes, nuestros corredores responderán con distitos aprendizajes a la hora de conducir.
  
• Ya se suceden distintas generaciones de corredores siguiente el plan de entrenamiento definido por el usuario. Además, de generación en generación, las mentes de los corredores evolucionan gracias al algoritmo genético.
  
• Descubrí un fallo que afectaba a la ordenación de los conductores según sus puntuaciones. Al no ordenarse de mayor a menor, la evolución no tenía en cuenta a los mejores, siendo más bien aleatoria.
  
• En cada nueva generación, el mejor corredor de la generación anterior aparece en rojo.
  

Ahora mismo, lo más importante es depurar errores. La evolución todavía no es buena, puesto que no hay una mejora espectacular de habilidades. También es necesario cambiar algunas cosas respecto a la forma de medir tiempos, para evitar que los corredores puedan salirse del circuito, y para poder hacer simulaciones aceleradas. Además, es conveniente añadir un buen generador de números aleatorios, y una clase para la lectura de parámetros desde archivos XML.

Por: ronaldo | I.A. | Comentarios (4) | Referencias (0)

Lunes, 02 de mayo de 2005

Redes Neuronales operativas! :)

Por fin! Tras unas duras sesiones de implementación y depuración, ya pueden verse los primeros conductores capaces de tomar decisiones en función de las lecturas de los sensores, utilizando sus propias redes neuronales.



Estos pequeños cerebritos, todavía aleatorios, ya empiezan a dar mucha luz sobre los posibles resultados del proyecto. En un experimento, realizado esta mañana sobre las 12:40h, con una población de tan sólo 60 individuos, ha aparecido uno que era capaz de interpretar bien sus sensores, detectando las paredes y siguiéndolas. Era fascinante ver como giraba en las curvas y como aceleraba y frenaba. Mucho más alucinante aún, es el hecho de saber que la red neuronal de este individuo es aún aleatoria, y no contiene neuronas en capa oculta. Esto significa, que la evolución de las redes neuronales puede dar lugar a individuos realmente espectaculares :).

Bien, dado este claro avance significativo, se produce un aumento en el número de versión, pasando de la 0.9.17m8.3b a la 0.10.0m8.3b. Los cambios realizados desde la última noticia son:

• Ahora calculamos la máxima distancia de alcance de los sensores, con lo que podemos comprobar el Bounding Circle de visión del conductor para ver a que rectas del circuito afecta. De esta forma, sólo comprobamos colisiones de los sensores con la recta actual y las más próximas cuya recta de fin de tramo caiga dentro del Bounding Circle.
  
• Se detectó un Bug cuando los coches circulaban hacia atrás en el circuito, que hacía que obtubieran un número de recta mayor que la última recta del circuito. Esto pasaba por usar Circuito::GetNumRectas(). Ahora se utiliza Circuito::GetUltimaRecta() para evitar confusión.
  
• Se ha actualizado la rutina de comprobación de los sensores, para que ahora comprueben realmente todas sus rectas más próximas. Antes sólo comprobaban la recta por la que iban, pues estaba el sistema en fase de prueba.
  
• Se ha detectado un fallo a la hora de colocar los coches en la salida. Dado que la recta de salida no tiene porqué tener un fin de tramo inicial que sea perpendicular a ambas rectas laterales (izquieda y derecha), esto hace que en circuitos como un simple Cuadrado, los coches se situen a la hora de salir en la última recta del circuito, en vez de en la primera. Esto hace que se confundan, puesto que creen estar en la primera. Por todo esto, acaban saliéndose del circuito. Este fallo está pendiente de corregir.
  
• Se ha detectado un importante bug que afectaba al cambio de tramo. Para detectar cuando un corredor cambiaba de tramo, utilizaba dos vectores: El vector que define la recta de fin de tramo y el vector que tiene el mismo origen que el anterior, pero que apunta al centro del coche. Comparando los ángulos de ambos vectores, si uno es mayor que el otro, está más a la izquierda. Esto tiene un problema, y es el hecho de que la recta de fin de tramo puede tener un vector de ángulo 0, lo que significa que el otro vector siempre tendría un ángulo mayor. Con este problema, jamás podría detectar cuando el centro del coche ha atravesado la recta de fin de tramo. Todo esto lo he solucionado añadiendo el método CVector2D::SignoProdVectorial() y utilizando este signo para distinguir cuando un vector está a la derecha o a la izquierda del otro (mediante la regla del sacacorchos ;))
  
• Para fines de depuración, he añadido la interesante posibilidad de pilotar los coches con el teclado. Para esto, es necesario activar la constante global g_Constantes.bControlTeclado, y utilizar las teclas del cursor del teclado numérico (2, 4, 6 y 8).
  
• Corregido un fallo del Bounding Circle de los sensores, que hacía que algunas rectas siguientes o anteriores no fueran bien detectadas. Esto se debía a que utilizaba la distancia del centro del coche a cada uno de los puntos de inicio de las rectas del siguiente tramo, a la hora de comparar con el Bounding Circle, lo cual, bajo determinadas circunstancias, no es preciso (véase el circuito cuadrado). La solución ha sido comparar con la distancia del centro del coche a la recta de fin de tramo, usando el método CPunto2D::DistanciaARecta.
  
• A partir de ahora, el método RedNeuronal::Actualizar acepta como entrada un cont TSensores& en lugar de un vector<double>. De esta forma, es mucho más práctico y simple de usar.
  
• Se ha detectado otro bug que afectaba a la clase CGenoma, y que hacía que los genes no se creasen bien, puesto que faltaba utilizar un new en lugar de un constructor estático (lo que hacía que el Genoma así construido se autodestruyera al cerrar el ámbito local).
  
• Otro pequeño bug en la clase CGenoma consistía en el descuido de no haber incluido la creación de una neurona de entrada para el sesgo.
  
• Por último, un despiste a la hora de comprobar cuando un jugador pasaba de la última recta a la primera, hacía que cuando atravesaba la penúltima, se creyera que estaba ya en la primera, saliéndose del circuito. El error era tan simple como una comprobación que decía nRecta >= Circuito.GetUltimaRecta(). Una vez sustituido el >= por >, se ha solucionado el problema.
  

Bien, eso es todo hasta ahora. Toca comenzar a evolucionar las mentes. Ya queda poco para empezar a ver coches inteligentes... :).

Por: ronaldo | I.A. | Comentarios (1) | Referencias (0)

Domingo, 01 de mayo de 2005

Sensores Funcionando!

Después de revisar el código y depurar adecuadamente todo, ya funcionan correctamente los sensores de visión de los coches! :) En esta anotación se pueden ver las primeras imágenes de los sensores en funcionamiento.



El principal fallo que impedía el funcionamiento de los sensores fue un despiste mío. Como comenté en el artículo anterior, realizaba la traslación de las rectas de los sensores, pero esto no es suficiente, ya que las rectas deben ser rotadas también. Así pues, para corregir este fallo, lo primero que he hecho ha sido implementar el método CRectaS2D::Girar, con el que ahora es posible girar una recta un ángulo determinado. Seguidamente, he cambiado el método CSensor::Trasladar por el método CSensor::RotarYTrasladar que hace ambas cosas en un solo paso. De esta forma, las rectas de visión que representan los sensores ya ocupan su lugar adecuado en el mundo, y las intersecciones con el resto de objetos funcionan perfectamente.



También encontré un segundo fallo, más simple pero igualmente complicado de detectar. Cuando calculaba el porcentaje normalizado de recta de visión que hay desde el comienzo del sensor hasta la intersección con el objeto detectado, lo hacía al revés; en lugar de dividir la recta parcial entre la recta total, dividia recta total entre recta parcial. Así pues, los resultados eran siempre >= 1, en lugar de <= 1, que es lo que esperaba recibir el sensor.

Ahora mismo, los sensores funcionan perfectamente. Lo siguiente que resta hacer con ellos, es crear un algoritmo para que detecten las rectas anteriores y siguientes a la recta por la que circula el coche en un instante dado. Toca pensar... :P

Por: ronaldo | General | Comentarios (2) | Referencias (0)