[Adabot-devel] Estructura de adabot

[alfonso_acosta_mail]

Holas:

Despues de saber que soy el único que se entera de la estructura de 
adabot escribo este mail para aclararlo un poquillo.

El procedimiento principal del robot esta, logicamente, en adabot.adb . 
Como veis llama a Initilize (aun no implementada) que se encarga de 
mandar los mensajes de inicializacion al servidor (Nombre del robot, 
comunicacion de entrada salida con el servidor etc...) Despues entra en 
un bucle infinito. Extraño? no tanto. Si os fijais, este procedimiento 
incluye el paquete signal_handlers donde se asocia el procedimiento 
HandleSIGUSR1 a la señal USR1. Por tanto HandleSIGUSR1 se ejecutara cada 
vez que adabot reciba la señal USR1 (ver mensajes anteriores de la lista 
para un buen ejemplo).

Puesto que recibiremos la señal USR1 cada vez que tengamos un nuevo 
mensaje del servidor esperandonos en la entrada estandar es
HandleSIGUSR1 el encargado de leerlo actualizar la informacion del juego 
y generar la respuesta de nuestro robot.


¿Como he modelado los mensajes, el comportamiento del robot y la 
informacion del juego?

* Los mensajes y sus estructuras de datos estan especificados en el 
paquete messages.ads e hijos (messages-io.ads etc ...). Para poder 
utilizar las colas he utilizado algunos archivos de la libreria libra 
que estan en el directorio lib. Para enterarse mejor de mi intencion al 
implementar este archivo seria util echarle un vistacillo al Messages.h 
del RealTimeBattle.

* Un comportamiento es un objeto que puede tomar distintos modelos de 
comportamiento (behaviour_model, implementado en behaviours.ads) estos 
-podrían- ser (muerto, agresivo, exploracion etc..). Actualemte solo 
esta implementado el modelo dead (muerto). La implementacion de los 
distintos comportamientos debera incluirse en el directorio behaviour_models

Adabot siempre tiene un comportamiento asociado.

Un comportamiento toma la informacion del juego (leer mas abajo)
y devuelve una cola de mensajes con la respuesta del robot 
(apply_behaviour en behaviours.ads), por ejemplo, un comportamiento con 
el modelo dead, dejaria la cola de mensajes vacia.

* La informacion sobre el juego (game_info.ads) se compone de:

 - Informacion sobre el mapa (arena_info.ads, aun no decidido nada del 
interfaz).

 - Informacion general sobre el juego (gen_info.ads) como por ejemplo 
la velocidad de disparo etc... estas constantes son enviadas por el 
servidor al comienzo del juego.

 - Limites en los argumentos de los mensajes. Al comienzo del juego, 
ademas de darnos informacion de ciertas constantes (gen_info.ads), 
maxima energia de disparo del robot (la energia del disparo es un 
argumento del mensaje Shoot) Habra que tener cuidado de que el robot no 
emita mensajes fuera de rango.


Problema actual de diseño:
==========================

Dentro de la informacion sobre el juego (game_info.ads) es necesario 
incluir el comportamiento del robot, pero por otro lado, un 
comportamiento (behaviours.ads) necesita conocer la información del 
juego para poder generar la cola de mensajes.

Esto causa que game_info.ads importe a behaviours.ads y behaviours.ads 
importe a game_info.ads provocando, logicamente, un problema de 
dependencia circular a la hora de compilar. La pregunta es, ¿estoy 
cometiendo un error de diseño? ¿como podria solucionarse el problema?

Espero que os sea util y por favor preguntad cualquier duda sobre lo que 
he dicho. Cualquier critica es igualmente bienvenida.


Saludos:

Fons



___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito
en http://moviles.yahoo.es