Dominados por el tiempo

Hoy presentamos el sistema para medir el tiempo en el que nos basaremos. Para ello, utilizamos la clase de java System.currentTimeMillis, que nos provee el tiempo del reloj del sistema, en milisegundos.

Aquí podemos ver el fragmento de código mediante el que podemos medir el tiempo en el menu principal, acumulandolo en caso de cerrar el juego.

private Button.OnClickListener btnSetWallpaperListener = new Button.OnClickListener(){
public void onClick(View v){updateTime(initialTime);}
};
public void update(){
if (mode == GameView.MODE_READY) {
updateTime(initialTime);
}
updateHandler.sleep(TIME_TO_SLEEP);
}
public long updateTime(long timeInitial){
long sixty = 60;
now = System.currentTimeMillis();
long time = ( now-initialTime) / 1000 ;
String total_time;
if(time < total_time =" (Long.toString(time)">= 60.0 && time < min =" (" sec =" (" total_time =" Long.toString(min)" hour =" (time/sixty);" min =" (" sec =" (" total_time =" Long.toString(hour)">

Básicamente, en este código vemos como recogemos la hora del sistema y la tratamos para medir el tiempo transcurrido. Esto lo hacemos utilizando un tiempo de referencia al iniciar el juego (evento super.onCreate, tiempo initialTime) y lo comparamos con los tiempos que vamos recogiendo en los instantes en que pulsamos el botón Actualizar correspondiente de cada Actividad (evento onClickListener, tiempo Now).

Podreís ver los resultados técnicos en el siguiente video:

El problema principal encontrado a la hora de gestionar el tiempo es como acumular el tiempo pese a los cambios de Actividad (pantallas) y entrada en subactividades, dónde debemos de acabar como realizar la programación para que no se inicialice la cuenta de tiempo cada vez que se entra en una pantalla.

Seguimos trabajando en ello.

Saludos

Movimiento dentro el mapa

Finalmente hemos conseguido crear un cursor para irnos moviendo a través del mapa.
Los movimientos se realizan con el touchpad en los 4 sentidos (izquierda, derecha, arriba, abajo) en el que cada movimiento corresponde a 5 pixeles.
Sabiendo que al iniciar el programa el cursor se encuentra en la coordenada (0,0) podremos ir haciendo los cálculos pertinentes para saber en cada momento en dónde estamos.
El problema que nos encontraríamos ahora es como reconocer que el usuario quiere acceder en una casilla en concreto, ya que sabemos en la que se encuentra a través de las coordenadas, pero para que reconozca que hay debajo e inicie una acción pertinente es lo que estamos investigando ahora.

A continuación se puede ver el código que tenemos para movernos por el mapa:
@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
// TODO Auto-generated method stub
boolean procesada= true;

switch(keyCode){
case KeyEvent.KEYCODE_DPAD_UP:
posY-=MOVIMIENTO;
break;
case KeyEvent.KEYCODE_DPAD_DOWN:
posY+=MOVIMIENTO;
break;
case KeyEvent.KEYCODE_DPAD_LEFT:
posX-=MOVIMIENTO;
break;
case KeyEvent.KEYCODE_DPAD_RIGHT:
posX+=MOVIMIENTO;
break;
default:
procesada=false;
break;
}

//correcció en cas de que sortim de pantalla
if(posY<0) posy="0;" posx="0;">altoPantalla)
posY=altoPantalla-altoPosicion;
if(posX+anchoPosicion>anchoPantalla)
posX=anchoPantalla-anchoPosicion;

return procesada;

}
Se debería encontrar una solución similar para que reconociera con un click la aldea a la que se quieren ver los detalles.

Diseño de clases : Edificios

En esta entrada voy ha hablaros de la solución que hemos implementado para definir la lógica de los edificios en C#.

En cuanto a su estructura, hemos creado una clase llamada “Edificio” y hemos decidido que cada uno de ellos será una clase heredada de "Edificio". Por ello, todos nuestros edificios tendrán unas semejanzas y unas peculiaridades. Abajo os adjunto una captura del editor UML que hacemos servir para definir las clases.



Los edificios están identificados en el árbol de construcción de la anterior entrada con tema “Propuesta de edificios”. Ahora, podemos añadir que todos nuestros edificios funcionarán de una forma similar, todos recibirán algo (mantenimiento) para ofrecernos alguna otra cosa (posibilidades, producción, etc.), podemos ver un diagrama que ilustra esto abajo. Esto se definirá con métodos propios de cada edificio y será gestionado por la aldea.



El problema más grande que nos hemos encontrado a la hora de definir esta parte ha sido el almacén de los datos de cada edificio. Cada uno tiene muchísima información referente a cada uno de los niveles que se puede encontrar (20 generalmente).

Al principio, para que el sistema fuera más flexible, decidimos que cada objeto tuviera su información, pero la naturaleza de nuestra aplicación (tendencia a hacer muchas aldeas) hacia que tuviéramos muchísima información redundante. Por ello, creamos una clase pública y estática que contendrá toda esta información, y cada edificio podrá consultarla cuando lo necesite. Con esto centralizamos la información en una especie de base de datos pública y evitamos repetir información.



En esta ilustración podemos ver claramente como en el primer modelo (ilustrado en la izquierda), los objetos eran pesados y se repetía la información. Mientras que en el dibujo de la izquierda vemos objetitos consultando la clase que contiene los datos.

Saludos